On Fri, 2017-04-28 at 14:34 +0200, Murray Cumming wrote: > On Fri, 2017-04-28 at 13:25 +0200, Kjell Ahlstedt wrote: > > On 2017-04-28 09:08, Murray Cumming wrote: > > > On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote: > > > > Why does Gtk::PackOptions affect only horizontal expansion and > > > > alignment? Look for instance at one of the 3 TreeView demo > > > > programs. > > > > The ScrolledWindow is expanded horizontally but not vertically. > > > > Before the expand and fill parameters were removed from > > > > gtk_box_pack_start() the ScrolledWindow was expanded in both > > > > directions. > > > > > > Maybe our pack_start/end() implementation should set > > > hexpand/halign > > > or > > > vexpand/valign depending on the orientation, or always set both. > > > > > > > I vote for always setting both, if we will keep Gtk::PackOptions. > > This fixes that problem with the ScrolledWindow: > https://git.gnome.org/browse/gtkmm/commit/?id=ece3794336e7216c4d25484 > be > 432d5d142ebab1b > > but it causes the left-hand treeview (list of examples) in the demo > to > not expand vertically, and the "Add item" and "Remove item" buttons > in > the "Editable Cells" example now appear to the left instead of > filling > up the whole horizontal space. > > With the attached patch, things seem better, but then those buttons > expand vertically too. > > I guess we need to find out exactly what > halign/hexpand/valign/vexpand/whatever values are really meant to > provide the same behaviour as the previous pack_start(child, expand, > fill): > https://developer.gnome.org/gtk3/stable/GtkBox.html#gtk-box-pack-star > t > > It doesn't look like our old pack_start(child, SHRINK) is the same as > the new gtk_box_pack_start(child).
This seems to explain it: https://mail.gnome.org/archives/gtk-devel-list/2017-April/msg00048.html I guess application code must add an extra box.set_vexpand(false) or box.set_hexpand(false) to get the old behaviour, but not always. I guess we should remove our pack_start/pack_end(options) method, but I'd like to keep it just a little longer, so we can port application code gradually. -- Murray Cumming murr...@murrayc.com www.murrayc.com _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
