Smalltalk › Pharo › Pharo Smalltalk Developers

[Gsoc] [FastTable improvements] [Features request]

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Elhamer

[Gsoc] [FastTable improvements] [Features request]

Dear Pharo community,

I am planning in working on FastTables improvements during Gsoc as suggested by Mr. Stephan Eggermont.

I’ve managed to collect some important features and ideas suggested by some of you (thanks to @stephan, @cyrilferlicot, @thierrygoubier, @estebanlm, @jfabry) in the following repo (as issues):

https://github.com/SamTheDev/Pharo-FastTable-improvements/issues

You might come across some FT limitations or issues while working with Pharo as a user or as a contributor, I would appreciate hearing your thoughts on this, please feel free to share your reviews/ideas/requests … on the repo.

Thank you for your contribution,

Elhamer.

Stephane Ducasse-3

Re: [Gsoc] [FastTable improvements] [Features request]

Excellent idea!!!

On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek <[hidden email]> wrote:

Dear Pharo community,

I am planning in working on FastTables improvements during Gsoc as suggested by Mr. Stephan Eggermont.

I’ve managed to collect some important features and ideas suggested by some of you (thanks to @stephan, @cyrilferlicot, @thierrygoubier, @estebanlm, @jfabry) in the following repo (as issues):

https://github.com/SamTheDev/Pharo-FastTable-improvements/issues

You might come across some FT limitations or issues while working with Pharo as a user or as a contributor, I would appreciate hearing your thoughts on this, please feel free to share your reviews/ideas/requests … on the repo.

Thank you for your contribution,

Elhamer.

Stephane Ducasse-3

Re: [Gsoc] [FastTable improvements] [Features request]

What I do not like is that a source is a Morph and not a domain object.

To me there is something wrong. I do not understand why we will have to rewrite source objects

to get fast table in another UI.

On Wed, Mar 29, 2017 at 5:52 PM, Stephane Ducasse <[hidden email]> wrote:

Excellent idea!!!

On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek <[hidden email]> wrote:
Dear Pharo community,

I am planning in working on FastTables improvements during Gsoc as suggested by Mr. Stephan Eggermont.

I’ve managed to collect some important features and ideas suggested by some of you (thanks to @stephan, @cyrilferlicot, @thierrygoubier, @estebanlm, @jfabry) in the following repo (as issues):

https://github.com/SamTheDev/Pharo-FastTable-improvements/issues

You might come across some FT limitations or issues while working with Pharo as a user or as a contributor, I would appreciate hearing your thoughts on this, please feel free to share your reviews/ideas/requests … on the repo.

Thank you for your contribution,

Elhamer.

Andrei Chis

Re: [Gsoc] [FastTable improvements] [Features request]

In reply to this post by Elhamer

Hi Elhamer,

A few other things that could possible be done:

- Horizontal scrollbars

- Better integration between Glamour and FastTable (there are quite a few issues on the bug tracker about this)

- Better support for lazy DataSources especially in the tree widget.

- Support to automatically resize columns to fix the content

Cheers,

Andrei

On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek <[hidden email]> wrote:

Dear Pharo community,

I am planning in working on FastTables improvements during Gsoc as suggested by Mr. Stephan Eggermont.

I’ve managed to collect some important features and ideas suggested by some of you (thanks to @stephan, @cyrilferlicot, @thierrygoubier, @estebanlm, @jfabry) in the following repo (as issues):

https://github.com/SamTheDev/Pharo-FastTable-improvements/issues

You might come across some FT limitations or issues while working with Pharo as a user or as a contributor, I would appreciate hearing your thoughts on this, please feel free to share your reviews/ideas/requests … on the repo.

Thank you for your contribution,

Elhamer.

Thierry Goubier

Re: [Gsoc] [FastTable improvements] [Features request]

Hi Andrei, Elhamer,

2017-03-29 18:00 GMT+02:00 Andrei Chis <[hidden email]>:

Hi Elhamer,

A few other things that could possible be done:

- Horizontal scrollbars

This one is already listed.

- Better integration between Glamour and FastTable (there are quite a few issues on the bug tracker about this)
- Better support for lazy DataSources especially in the tree widget.

Lazy datasources with items of varying height with no performance impact...

- Support to automatically resize columns to fix the content

Something related to the horizontal scrollbars in fact. But more complex if you add support for a user to trigger that (very convenient feature in Excel and friends, by the way)

Thierry

Cheers,
Andrei

On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek <[hidden email]> wrote:
Dear Pharo community,

I am planning in working on FastTables improvements during Gsoc as suggested by Mr. Stephan Eggermont.

I’ve managed to collect some important features and ideas suggested by some of you (thanks to @stephan, @cyrilferlicot, @thierrygoubier, @estebanlm, @jfabry) in the following repo (as issues):

https://github.com/SamTheDev/Pharo-FastTable-improvements/issues

You might come across some FT limitations or issues while working with Pharo as a user or as a contributor, I would appreciate hearing your thoughts on this, please feel free to share your reviews/ideas/requests … on the repo.

Thank you for your contribution,

Elhamer.

Stephan Eggermont-3

Re: [Gsoc] [FastTable improvements] [Features request]

In reply to this post by Stephane Ducasse-3

On 29/03/17 17:53, Stephane Ducasse wrote:
> What I do not like is that a source is a Morph and not a domain object.
> To me there is something wrong. I do not understand why we will have to
> rewrite source objects
> to get fast table in another UI.

What exactly do you mean by a source is a Morph?
The FTDataSource is just a helper object returning widgets for the
cells, and they happen to be Morphs. Looks like a clean interface to me.
What am I missing?

Stephan

Denis Kudriashov

Re: [Gsoc] [FastTable improvements] [Features request]

In reply to this post by Andrei Chis

Hi Elhamer,

2017-03-29 18:00 GMT+02:00 Andrei Chis <[hidden email]>:

- Support to automatically resize columns to fix the content

What I want first is ability to setup "spaceFill resizing" for columns. It will improve current tools immediately.

For example in MessageBrowser all columns are fixed (there is no other possibility). And columns are not increased when window is expanded. So you always need to resize columns manually to see long content.

Stephane Ducasse-3

Re: [Gsoc] [FastTable improvements] [Features request]

In reply to this post by Stephan Eggermont-3

To me a datasource should deliver data and not UI elements.

On Thu, Mar 30, 2017 at 12:43 PM, Stephan Eggermont <[hidden email]> wrote:

On 29/03/17 17:53, Stephane Ducasse wrote:

What I do not like is that a source is a Morph and not a domain object.
To me there is something wrong. I do not understand why we will have to
rewrite source objects
to get fast table in another UI.

What exactly do you mean by a source is a Morph?
The FTDataSource is just a helper object returning widgets for the cells, and they happen to be Morphs. Looks like a clean interface to me. What am I missing?

Stephan

Stephan Eggermont-3

Re: [Gsoc] [FastTable improvements] [Features request]

On 31/03/17 08:14, Stephane Ducasse wrote:
> To me a datasource should deliver data and not UI elements.

AFAIK it is an old established designation for this.
It is the data source of the table view, not of the persistency
layer. It provides a single point of access to the data in a form that
the table view can understand, which is cells.

https://developer.apple.com/reference/uikit/uitableviewdatasource
https://developer.apple.com/reference/uikit/uitableviewdelegate

Stephan

Stephane Ducasse-3

Re: [Gsoc] [FastTable improvements] [Features request]

I read and could not understand. Now what I see is that there are view in the class name.

So at least dataSource should be called dataSourceViewProvider.

On Fri, Mar 31, 2017 at 9:56 AM, Stephan Eggermont <[hidden email]> wrote:

On 31/03/17 08:14, Stephane Ducasse wrote:

To me a datasource should deliver data and not UI elements.

AFAIK it is an old established designation for this.
It is the data source of the table view, not of the persistency
layer. It provides a single point of access to the data in a form that the table view can understand, which is cells.

https://developer.apple.com/reference/uikit/uitableviewdatasource
https://developer.apple.com/reference/uikit/uitableviewdelegate

Stephan

Guillermo Polito

Re: [Gsoc] [FastTable improvements] [Features request]

I understand that the data source we have right now is too low level. I'd prefer to call it "Cell data source" rather than view as it is more specific to the table, unless we want to reuse it in other scenarios....

Now, maybe part of GSOC could be to provide a higher-level provider able to nicely map domain objects to cells, wether it is text, icons, pictures, morphs, widgets.

On Fri, Mar 31, 2017 at 7:24 PM, Stephane Ducasse <[hidden email]> wrote:

I read and could not understand. Now what I see is that there are view in the class name.
So at least dataSource should be called dataSourceViewProvider.

On Fri, Mar 31, 2017 at 9:56 AM, Stephan Eggermont <[hidden email]> wrote:
On 31/03/17 08:14, Stephane Ducasse wrote:

To me a datasource should deliver data and not UI elements.

AFAIK it is an old established designation for this.
It is the data source of the table view, not of the persistency
layer. It provides a single point of access to the data in a form that the table view can understand, which is cells.

https://developer.apple.com/reference/uikit/uitableviewdatasource
https://developer.apple.com/reference/uikit/uitableviewdelegate

Stephan

Stephan Eggermont-3

Re: [Gsoc] [FastTable improvements] [Features request]

On 01/04/17 15:06, Guillermo Polito wrote:
> Now, maybe part of GSOC could be to provide a higher-level provider able
> to nicely map domain objects to cells, whether it is text, icons,
> pictures, morphs, widgets.

Yes, a magritte report implementation is indeed also missing

Stephan