After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 629133 - Allow alignment of multiple cell renderers in the combo's drop-down menu
Allow alignment of multiple cell renderers in the combo's drop-down menu
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkComboBox
unspecified
Other All
: Normal enhancement
: 3.0
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2010-09-09 04:46 UTC by Tristan Van Berkom
Modified: 2018-02-10 04:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case showing unaligned renderers in combo-box (2.29 KB, text/x-csrc)
2010-09-09 04:46 UTC, Tristan Van Berkom
Details

Description Tristan Van Berkom 2010-09-09 04:46:41 UTC
Created attachment 169825 [details]
Test case showing unaligned renderers in combo-box

GtkComboBox does not provide a way to align multiple variable width
cell renderers with other rows.

While it's nice that we can use a more compact unaligned packing
of renderers in the underlying GtkCellView, it would also be an important
option to allow them to be aligned (likewise... it would be nice to have
an option for GtkTreeViewColumn to let the renderer's flow across a
single column without being aligned... in the treeview case they are
*always* aligned... but that's another story...).

I'm attaching a test case that shows how the combo does not align
columns... note in the test case
  - The two first columns/renderers are packed with expand=FALSE
  - The two last columns/renderers display variable width text
  - The first combo-box aligns all text at 0.0, the second combo
    at 0.5 and the third combo at 1.0
Comment 1 Murray Cumming 2010-09-09 09:51:03 UTC
It seems like this would be clearer if GtkComboBox had multiple GtkTreeViewColumns (and exposed that fact in it's API) instead of having just one (hidden in the API) GtkTreeViewColumn.
Comment 2 Tristan Van Berkom 2010-09-09 15:24:03 UTC
Unfortunately GtkComboBox does not use GtkTreeViewColumn (treeviewcolumn
code is heavily hard-coded as GtkTreeView's counterpart).

Although it was a vague idea which I expressed earlier on the list today:
http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00124.html

I would certainly aim for centralizing the columnized cell rendering
code in GtkTreeViewColumn and reusing that somehow for combo box menus.

The combo-box uses GtkCellView to render every row individually,
each GtkCellView has no knowlage of other CellView widgets in the menu
and thus there is no coordination in place to align cells in the
dropdown menu.
Comment 3 Murray Cumming 2010-09-09 20:24:16 UTC
(In reply to comment #2)
> Unfortunately GtkComboBox does not use GtkTreeViewColumn

But it really seems to:
http://git.gnome.org/browse/gtk+/tree/gtk/gtkcombobox.c#n2859
Comment 4 Matthias Clasen 2010-09-09 20:38:13 UTC
Murray: the combobox code is sorta confusing. It _does_ use a treeview (and treeviewcolumn) in list mode. The menu mode is the one where cell views are used.

I think this is a very sensible enhancement request. I fear there may be considerable refactoring necessary to implement this, though. The cell view thing was really only meant to be used with fixed-size-icon + label configurations, where the alignment comes from the fixed size of the first column cells...
Comment 5 Kristian Rietveld 2010-09-14 11:57:56 UTC
(In reply to comment #2)
> The combo-box uses GtkCellView to render every row individually,
> each GtkCellView has no knowlage of other CellView widgets in the menu
> and thus there is no coordination in place to align cells in the
> dropdown menu.

Exactly, the fact that GtkCellView does not know about the other GtkCellViews in the same context is what will make it very hard to add columns in addition to cells.  GtkCellView was designed to display a single row and single column.  It feels like you want to have a specialized container that re-uses the GtkTreeViewColumn and GtkTreeView algorithms to determine the location of the cells.

I am not sure how exactly this should work, having another (container) object control the layouts of a bunch of GtkCellView objects seems cumbersome.  The same holds true to having a new container that manages GtkCellRenderers which would be kind of like GtkTreeView but then acting like a menu.

(I have vague ideas of how to refactor GtkTreeView into separate components: have separate classes for layouting algorithms, input handling (mouse clicks, selection handling, editing, etc), rendering, etc.  From these classes you would then compose a GtkTreeView, GtkIconView and other kinds of such views.  The code is then shared and in one of these component classes instead of duplicated.  The idea raised for combo box in this bug might be able to also take advantage of that).

> I would certainly aim for centralizing the columnized cell rendering
> code in GtkTreeViewColumn and reusing that somehow for combo box menus.

Yes, I think you would actually want to separate those layouting algorithms out of GtkTreeViewColumn and GtkTreeView (like mentioned above) and then re-use them where needed.  Keep in mind that GtkTreeViewColumn lays out the cells, GtkTreeView lays out the columns.
Comment 6 Matthias Clasen 2018-02-10 04:37:37 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.