Re: Optional keybindings

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Tue, 15 Jan 2002, Owen Taylor wrote:
> 
> > As was discussed some earlier, here is a patch to allow keybindings to be
> > optional: if the action signal for a keybinding has a boolean return value
> > and returns FALSE, then it is as if that binding didn't exist.
> > 
> > This is needed in particular to fix a problem with activateable
> > widgets in notebooks. If you hit "space" with the focus on one, then
> > the space propagates up until it hits the notebook, which has a
> > binding for "Space" and eats the keystroke. (I think we also need
> > such binding for GtkPaned)
> > 
> > The notebook patch using this is attached; it makes bindings that should
> > only have an effect when the focus is on the tabs return FALSE if the
> > focus is on the child.
> > 
> > There are no compatibility problems with the binding change since action
> > signals with a boolean return were not previously allowed in this context.
> > 
> > It is a newly exported public API, but I don't see any way around
> > this ... we need the functionality internal to GTK+, and we can't hide it
> > since it is a matter of use of existing function calls than adding new
> > ones.
> 
> this needs a proper entry in Changes-2.0, as it is changing the return type
> of three signals which existed in 1.2 already. users who emit those signals
> from their code may get a segfault or similar for not passing a return
> value location.

No, these signals weren't in 1.2. You are right, there is an API
change here from earlier 1.3.x ... but my judgement here is that these
are internal details and if you either:

 - Emit them directly
 - Derive from GtkNotebook and override them

You are sticking out your chin and saying "'cmon, hit me, bet
you can't do it".

I wish we could just stop people from doing these things for action
signals used for key bindings, but there is no real way to do that.

(In terms of emitting them directly, maybe gtk_signal_emitv() /
g_signal_emit() should be nice and allow you to ignore return
values as you can in C and most other programming languages?)
 
> for a semi-related item, since we're talking about the notebook here,
> i was recently prompted by someone on irc (think the xchat maintainer),
> he suggested we change:
> 
>   void (*GtkNotebook::switch_page) (GtkNotebook     *notebook,
>                                     GtkNotebookPage *page,
>                                     guint            page_num);
> to
>   void (*GtkNotebook::switch_page) (GtkNotebook     *notebook,
>                                     GtkWidget       *page_child,
>                                     guint            page_num);
> 
> since GtkNotebookPage* is now opaque, and we don't have any accessors
> for it, it's basically useless. 
> and i have to admit that using
>   widget = gtk_notebook_get_nth_page (notebook,
>                                       gtk_notebook_get_current_page (notebook));
> within a GtkNotebook::switch_page handler is rather awkward.
> so since GtkNotebookPage* is currently useless anyways, this change
> would have exactly zero impact on current code, and i think we
> should make it, for "fixing" the uselessness of a pointer ;)

I don't want to do this:

 - Unlike the above change, it's an API addition that people
   will use, so there is a real possibility that code writtern
   for 1.3.13 would segfault with 1.3.12, which is the
   type of thing the API freeze was designed to prevent. 

 - There is no pressing need to make this change ... all
   information is provided.

 - If we were designing this api from scratch now, we would
   include either the number or the GtkWidget *, but certainly
   not both, so I don't think we should stick in the GtkWidget *
   just because we have a spare slot for it. 

Regards,
                                        Owen