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

[James Gardiner <jamgard sprintmail com>]

Hi, I'm new to the list...

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.

My tack on this is about the default behavior within menus to create
"auto-accelerators" when a user hits a key.  This is dangerous for the new
user of a GTK+-based application:  User accesses a "File" menu which has an
item called "Quit" which quits the application.  The user accidentally
presses the spacebar instead of the mouse button (I use a laptop...it's a
definite possibility).  This sets up the menu item to be activated when the
user hits the spacebar.  User is using application, hits spacebar, maybe
enter...Voila, application closes, might even lose data!

Now I know that there are some steps that the programmer can take to protect
the user from him/herself, but it would be better if this behavior can be
deactivated or just regulated (maybe per menu item).

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)?

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.

Thanks!!!
  James Gardiner

P.S.  Another nice thing that could be done maybe regarding the accelerators,
and one that probably would require a redesign of the menu-accelerator
relationship would be to allow disabling the auto feature per menu item, or
maybe just figuring out a way to disable the auto feature with an rc file
option (for the users to configure for themselves!).