On Thu, 2017-04-27 at 12:31 +0200, Murray Cumming wrote: > The gtk_box_pack_start()/pack_end() API changed slightly, > meaning that our C++ pack_start()/pack_end() convenience overloads > can > no longer have a default value for our PackOptions convenience enum: > https://git.gnome.org/browse/gtkmm/commit/?id=b07a05bba3a2e1df8778683 > a4 > 7e50d8c8f3fb26b > > As the commit message says, that's awkward because the behaviour has > now changed silently, meaning you need to do this to get the old > behaviour (assuming my new implementation works as intended): > https://git.gnome.org/browse/gtkmm/commit/?id=214be98c94d85aa5ac79031 > fa > a5f995e4b797c26
If we had a gtkmm 3.23/34, we could just remove the default value, forcing people to specify the value in their code, thus making it ready for gtkmm 4. Such a small API change is acceptable between, for instance, 3.22 and 3.24, but would be an unpleasant surprise for people if we did it, for instance, between 3.22.1 and 3.22.2. > Thoughts? Should we remove these gtkmm-specific > Box::pack_start()/pack_end() methods anyway? That will still have the > same change-of-behaviour problem for this code: > box.pack_start(child) > but if an application also has code like this it will at least cause > a > compiler error that forces the developer to think about it: > box.pack_start(child, Gtk::PACK_SHRINK). > > -- Murray Cumming murr...@murrayc.com www.murrayc.com _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
