[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.
Excellent idea!!! On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek < abdelkhalekdev@gmail.com> 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.
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 <stepharo.self@gmail.com> wrote:
Excellent idea!!!
On Wed, Mar 29, 2017 at 5:39 PM, Elhamer Oussama AbdelKHalek < abdelkhalekdev@gmail.com> 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.
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
To me a datasource should deliver data and not UI elements. On Thu, Mar 30, 2017 at 12:43 PM, Stephan Eggermont <stephan@stack.nl> 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
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
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 <stephan@stack.nl> 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
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 <stepharo.self@gmail.com> 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 <stephan@stack.nl> 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
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 < abdelkhalekdev@gmail.com> 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.
Hi Andrei, Elhamer, 2017-03-29 18:00 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com>:
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 < abdelkhalekdev@gmail.com> 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.
Hi Elhamer, 2017-03-29 18:00 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com>:
- 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.
participants (7)
-
Andrei Chis -
Denis Kudriashov -
Elhamer Oussama AbdelKHalek -
Guillermo Polito -
Stephan Eggermont -
Stephane Ducasse -
Thierry Goubier