GNOME Bugzilla – Bug 88556
pack_start and AttachOptions is still confusing
Last modified: 2004-12-22 21:47:04 UTC
As discussed on the mailing list, the AttachOptions enum is confusing for Gtk::Box::pack_start() because the interface allows more options than are valid in the implementation. The patch creates a new Gtk::PackOptions enumeration: /** Packing options for adding child widgets to a Box with pack_start() and pack_end(). */ enum PackOptions { CONTRACT, /**< Space is contracted to the child widget size. */ EXPAND_PADDING, /**< Space is expanded with extra space filled with padding. */ EXPAND_WIDGET /**< Space is expanded with extra space filled by increasing the child widget size. */ };
Created attachment 9958 [details] [review] Add PackOptions enumeration
Please use the PATCH keyword in future. Thanks a lot. This was very cleanly done. However, how did you decide on the correct pack options in the packbox example? By looking at the C original? Leaving bug open so you can reply. Applied, with these changes: 2002-07-19 Murray Cumming <murrayc@usa.net> * Prefixed PackOptions values with PACK_ to avoid conflicts and confusion with other enum values. * Looked at Table::attach() and Paned::pack*() and decided that they should continue to use the separate AttachOptions enum - for Table that is not even a change from GTK+. * Added back the bool, bool pack methods so that it's easier to port from gtkmm 1.2, or from GTK+.
Thanks. I didn't look at the C packbox. I just translated the AttachOptions arguments like so: SHRINK -> CONTRACT FILL -> CONTRACT EXPAND -> EXPAND_PADDING EXPAND|FILL -> EXPAND_WIDGET As the Gtk documentation says, fill without expand has no effect and is equivalent to CONTRACT. I think the fact that it has been used in code, even in Gtk examples, shows that people have trouble with these functions. We think the exceptions are when something external affects the size, such as another row in a Table or maybe if the homogenous flag is set, in which case EXPAND_PADDING or EXPAND_WIDGET indicates the fill setting. The text on the buttons in the packbox example is still the C booleans, translated from PackOptions using the same logic as the Box class uses. Should I change this to display the C++ API? If you prefix the options with PACK, is it worth the time to change CONTRACT back to SHRINK, or did you already do this? It would be more consistent. I agree that adding back the bool,bool pack methods is a good idea.
> The text on the buttons in the packbox example is still the C > booleans, translated from PackOptions using the same logic as the Box > class uses. Should I change this to display the C++ API? I guess so. Yes, I have changed it from CONTRACT to SHRINK. By the way, we prefer cvs patches. See the bugs.sthml page.
Created attachment 9974 [details] [review] Fix examples/packbox
Thanks.