Re: gtkmm4: Box::pack_start()/pack_end()

[Murray Cumming <murrayc murrayc com>]

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
murrayc murrayc com
www.murrayc.com