GNOME Bugzilla – Bug 720850
Use GtkListBox for conversation list
Last modified: 2017-12-13 23:24:42 UTC
GtkTreeView / GtkCellRenderer has proven to be problematic for our Conversation List needs (see bug #720783, bug #713041, bug #713081, bug #714972). GTK 3.10 has a new GtkListBox which (hopefully) will solve a lot of our issues, in particular because it allows for widgets to be laid out rather than rendering the text by hand.
Also, it will fix the problem with RTL (the conversation list look realy bad with Hebrew text and RTL layout).
I don't think GtkListBox supports everything geary needs, e.g. it does not allow multiple selection [1]. [1] https://developer.gnome.org/gtk3/3.10/GtkListBox.html#gtk-list-box-set-selection-mode
Ah-ha -- that's kind of a deal-breaker. I've filed a request with the GTK+ team at bug #721440.
GtkListBox now supports multiple selections. That plus a list box model would go a long way to making it the perfect choice for Geary.
See also bug #730682.
Currently GtkListBox does not use a model (bug #710414). Do you think it is still worth to try or should we wait until it supports a model?
Geary is still tied to GTK+ 3.10, so using GtkListBox in Geary is a ways off anyway. I would *prefer* to wait for a proper model. I wrote my own list box model for California [1] but it doesn't deal with creating/destroying widgets as they come off and on the viewport, which is not a problem for California but would be a perfect fit for Geary. That said, there's a lot of work to be done to get this to work (moving to GtkListBox, laying out the widgets to replace the formatted cell, and so one). If someone wanted to tackle this now, a lot of that work would be reused with or without a model. But until Geary targets GTK 3.14 (where GtkListBox has multiple selection support), we can't land anything in master. [1] https://git.gnome.org/browse/california/tree/src/toolkit/toolkit-listbox-model.vala
(In reply to comment #7) > Geary is still tied to GTK+ 3.10, so using GtkListBox in Geary is a ways off > anyway. > > I would *prefer* to wait for a proper model. I wrote my own list box model for > California [1] but it doesn't deal with creating/destroying widgets as they > come off and on the viewport, which is not a problem for California but would > be a perfect fit for Geary. > > That said, there's a lot of work to be done to get this to work (moving to > GtkListBox, laying out the widgets to replace the formatted cell, and so one). > If someone wanted to tackle this now, a lot of that work would be reused with > or without a model. But until Geary targets GTK 3.14 (where GtkListBox has > multiple selection support), we can't land anything in master. > Jim, I think it will be great idea to try to move your code [1] to GTK+ itself. I guess the GTK+'s devs will take it in C + some changes, but it something we needs in GTK+ itself. > [1] > https://git.gnome.org/browse/california/tree/src/toolkit/toolkit-listbox-model.vala
(In reply to comment #8) > Jim, I think it will be great idea to try to move your code [1] to GTK+ itself. > I guess the GTK+'s devs will take it in C + some changes, but it something > we needs in GTK+ itself. Unfortunately, I don't have the time to port the code to C. Plus, it's quite possible that some of the widget's functionality will be moved into the model (i.e. filtering and sorting) which I personally think is a good idea. My model piggybacks on those features in the widget itself rather than replicate it in the model code. I'll comment on the ticket, though, to be involved in the discussion.
(In reply to comment #9) > (In reply to comment #8) > > Jim, I think it will be great idea to try to move your code [1] to GTK+ itself. > > I guess the GTK+'s devs will take it in C + some changes, but it something > > we needs in GTK+ itself. > > Unfortunately, I don't have the time to port the code to C. Plus, it's quite > possible that some of the widget's functionality will be moved into the model > (i.e. filtering and sorting) which I personally think is a good idea. My model > piggybacks on those features in the widget itself rather than replicate it in > the model code. > > I'll comment on the ticket, though, to be involved in the discussion. On second thought, maybe this is the time to start coding in Vala in GTK+? After all, for the tarball it not a problem (we can to provide the c-gen code from valac in the tarball, so there isn't any depend on valac in tarbal).
See also bug #736434.
*** Bug 714846 has been marked as a duplicate of this bug. ***
Marking as a duplicate of Bug 730682 since the plan is to use a GtkListBox for that. *** This bug has been marked as a duplicate of bug 730682 ***