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

[Tomeu Vizoso]

On Sun, Dec 6, 2009 at 14:53, Aleksey Lim <alsroot at member.fsf.org> wrote:
> 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

The API looks very good to me, just one thing: what means 3, 3 here?

table = SmoothTable(Cell, 3, 3)

>> > 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

I don't think the overhead of using widgets instead of renderers will
be noticeable given that we render svg icons there.

>> > * 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)

For example this: http://pvanhoof.be/blog/index.php/2009/08/24/as-it-should-be

The GNOME Activity Journal people are also looking for something lik
this but I don't know of any public discussion.

Regards,

Tomeu

>> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning