Re: [java-gnome-hackers] [MERGE] added grabAdd and grabRemove methods.

[Andrew C. <an...@op...>]

On Wed, 2009-04-01 at 21:44 +0100, Martin Garton wrote:

> Yes, I could have done that, so I don't really need this.  I was just
> porting some existing [GTK] code and that's how it was working.


And that's as good a reason as any to expose it. There's nothing
illegitimate about it - but at least you know why it wasn't exposed as
yet.

[Likewise, I personally tend not to be in to much of a rush to expose
property getters; after all, in most cases, you know if you set the damn
thing in the first place. Other people have legitimate uses for them;
they can do the work to expose them. All good]

> > We go to a lot of trouble in GTK land to warn people about the dangers
> > of making Windows modal...

> ...It is used as part of a calendar
> selection widget that is made up of an entry, with a popup calendar
> below it. There is a ToggleButton to open the calendar window, and while
> the calendar window is displayed, the containing VBox is grabAdd()ed.
> So the only options for the user are to select a date or toggle to close
> the window. I would agree it is not ideal.

(huh. Neat)

Well, as I said, if you can just put a bit of explanation or cautionary
text beside it, that'll help developers in the future who are busy
learning GTK and wonder what the heck they're supposed to use [the only
problem with Widget being the ancestor ... so many methods visible &
inherited, as opposed to decorating as you get richer. {shrug} Is what
it is]

> I think it is the only
> way to remove the image from a button.

Sure.

It makes sense, and that's the remove idiom for lots of other
properties, and the getter can return null. But I have been caught by
surprise MANY times by GTK with regards to this sort of thing, and
normalizing such in our public API has been a lot of [im]patient work.
Rewarding, but work. :)

AfC
Sydney