[gtkmm] pack_start and AttachOptions is still confusing

[Michael Babcock <mbabcock la creatureshop henson com>]

Okay I realize it is probably too late to change this, but... I think if 
Gtkmm2 is changing the interface for pack_start from the Gtk version we 
should take this opportunity to try to make it easier to understand. 
Because we are losing the ability to take advantage of peoples existing 
documentation and experience with the Gtk version, as poor as that may be.

Now I hope many of us will agree that the Gtk pack_start function should 
 probably be in some API hall of shame as one of the worst function 
interfaces ever, so I understand the desire to change it in Gtkmm. After 
converting a bunch of code and writing new code using the current Gtkmm 
interface, however, I think we are only part way there.

The two booleans have been changed to a single bitwise ORable 
enumeration. This makes the code more readable than just seeing "true" 
or "false", but doesn't solve the other problem, which is that there are 
two separate parameters, yet they are not independent. Even though we 
only have the single enumeration now, by making them ORable, we still 
have more allowable combinations than we should (in fact, it's worse 
now, we have six possible attach options instead of four).

I propose a single, non-ORable enumeration that accurately reflects the 
possible packing options, perhaps something like:

SHRINK - Shrink space to widget's size request.
EXPAND_PADDING - Expand space with padding around widget.
EXPAND_WIDGET - Expand space by expanding the widget size.

Am I correct that these are the only options that are really valid? This 
seems much less confusing to me than having strange possibilites like 
FILL with no EXPAND, or SHRINK|FILL, etc. I can never remember which 
meaning is EXPAND or FILL either, and this eliminates that problem. 
Thoughts?

--
Michael Babcock
Jim Henson's Creature Shop