GNOME Bugzilla – Bug 350815
GtkCellView: shrink cells when allocated too few space
Last modified: 2007-05-15 10:48:42 UTC
Attached patch from maemo-gtk modifies cell allocation when there is too few space. Instead of drawing pack_end cells on top of pack_start ones, and then cutting off cells, it tries to distribute the shrinkage among the expanding cells first.
Created attachment 70679 [details] [review] Patch implementing the above For quickly trying old and new behavior, there's an "#if 1" in the patch.
since there's no way to scroll cells if they are allocated too little space, i think a proper solution here should go even further. that is, after distributing negative extra_space across expanded cells, remaining negative etxra_space (if any) should be distributed across *all* cells (ideally starting with shrinking the biggest cells first).
First note that cell renderers always request the minimum space they need to be able to draw their contents on the screen. If they get less than requested the cells are basically cut off. In the Maemo patch only the cells which are flagged to be expanded will be allocated less space than requested, so those are the only ones which are cut off. I think this is weird and inconsistent behaviour. I think that shrinking the cells by giving them less space than (the absolute minimum) they request is not a good idea -- it's probably much better to hide the cells which won't fit. The first cell which won't fit would still be visible, but cut off. We stop with drawing cells after that. This would look the same as a column in a tree view which was not allocated enough space to draw its cells. The cell view was originally designed to mimic the allocation behaviour of tree view columns. If we completely change the allocation behaviour of the cell view, the "looks" of the cell view and tree view in the list-mode combo box will be inconsistent.
(In reply to comment #3) > In the Maemo patch only the cells which are flagged to be expanded will be > allocated less space than requested, so those are the only ones which are cut > off. I think this is weird and inconsistent behaviour. note that this is also what gtk does in other places, e.g. GtkTable and IIRC also Gtk*Box.
Resolving this bug as WONTFIX: GtkCellView has been designed to closely follow GtkTreeViewColumn's cell layouting scheme and both implement the GtkCellLayout interface. As for GtkTreeViewColumn, I've never seen a list view which cuts off contents on a per-column basis. When packing cells into a column you'll have to think about situations where the column is not wide enough to show all the contents; the same argument can be made for cell views. IMHO both should follow the same packing scheme.