Re: [gtk-list] Auto-accelerators and public/private interfaces

[Ulric Eriksson <ulric edu stockholm se>]

On Sun, 5 Jul 1998, James Gardiner wrote:

> I've been reading posts about the public/private interface documentation issue
> and I have to side with the people looking for more information in the header
> files about which data members are considered public or private.

[snip]

> I found a way to deactivate the auto-accelerators within a given application:
> The routine to add accelerators to a menu item at the touch of a key is in
> gtkmenu.c.  It is linked into the class through the key_press_event handler
> and is a class function (method?).
> 
> Therefore, for a menu named menu1 you could disable the auto-accelerators by:
> 
> GTK_WIDGET_CLASS(GTK_OBJECT(menu1)->klass)->key_press_event = NULL;
> 
> Now you would probably save the contents of the function pointer before
> NULLing it so you could restore it under controlled circumstances, but you get
> my drift.
> 
> Now my problem is this:  When I use my newly found solution will I be safe in
> a future version of GTK+?  Or will I have to resort to a hack?  Or will I just
> have to live with the default behavior (I find this last one unacceptable)?

No, you won't be safe. Any library that makes all the internal data
structures part of its API will become incompatible every time a
developer sneezes.

> I don't know the GTK+ powers-that-be, but could we get this maybe included as
> an interface function in a future version?  Or could we maybe just get a
> little clarification as to what is public and private?  I really like the
> design of GTK+ but some assurances are always nice when designing for a
> particular toolkit.  BTW, if I hadn't had access to the source for GTK+, I
> would have been up the proverbial creek.

The only reasonable way to handle the public/private issue is to have
everything be private unless explicitly exported through whatever means
the language permits. In C, this means either using the opaque data types
for private data that Tero was talking about, or doing it the Xt way. The
former is slightly more efficient, the latter makes binary compatibility
less brittle.

Ulric