[Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88

Aleksey Lim alsroot at member.fsf.org
Sun Dec 6 11:53:59 EST 2009


On Sun, Dec 06, 2009 at 02:37:07PM +0100, Simon Schampijer wrote:
> On 11/28/2009 05:00 AM, Aleksey Lim wrote:
> > Hi all,
> 
> Hi Aleksey,
> 
> thanks for proposing this feature!
> 
> > http://wiki.sugarlabs.org/go/Features/TableView_Widget
> >
> > GTK widget to replace gtk.TreeView in Journal.
> >
> > Benefit to Sugar
> >
> > Standard gtk components are not designed to be lazy. Third party
> > widgets, I managed to find, uses scheme with renders(like gtk
> > components), introduced component uses widgets instead(could have
> > performance penalties, I guess, in common case but we don't have many
> > rows in Journal view, so should be ok for us).
> 
> Can you elaborate on this? Instead of using the cell renderers to draw 
> the data in the tree model we would pack widgets?

we should just implement Cell class(regular wigdet) and it will be used
for all(visible) cells, see example
http://wiki.sugarlabs.org/go/Features/TableView_Widget#Simple_example_for_SmootTable_widget

> > Benefits we have for such scheme:
> 
> Can you describe the benefit for a user? Faster scrolling?

I meant here only developers,
for users it could have only disadvantages :) if we have many visible
cells at the same time, but in our case it should be ok, I tested
thumbs view on XO-1 and didn't see lags

> > * coding cells is more useful by using widgets then renders, we can
> >    reuse our existed custom widgets instead of coding sugarized cell
> >    renders
> > * in some cases its hard to sugarize cells theme(we still have
> >    ugly progress bar for Journal entries), with new widget, we
> >    use just gtk.ProgressBar
> 
> Don't we use the gtk.ProgressBar already?

not for TreeView, it uses progress render

> Or do you mean it would just 
> look better?

Our cells will look like other widgets(since cells are the same widgets)
and we won't have to sugarize renders' theme(e.g. in exsited code, we
have not fully sugarized pregress renders)

> > There is an ongoing discussion in gnome community about replacing
> > GtkTreeView, not sure if new widget is ready to use for 0.88 and since
> > Journal's view widget is pretty simple we can use our own
> > simple implementation(360 lines of code).
> 
> Do you have pointers to the GNOME discussion? I found that snippet from 
> someone having the same problem: 
> http://www.mail-archive.com/gtk-app-devel-list@gnome.org/msg12127.html

Better to ask tomeu, I heard about GNOME discussion from him
I guess better for us will be switching to GNOME implementation when
it's ready(for now we can use as simple as possible lazy view implementation
and imho proposed widgets meet that)

> Do you have written some code already?

The model less widget is fully implemented,
in case of model, current code has TableView class which uses gtk.TreeModel.
Exact model scheme will depend on what we will use in Journal

-- 
Aleksey


More information about the Sugar-devel mailing list