Re: Mnemonics patch

[Alexander Larsson <alla lysator liu se>]

On Thu, 22 Mar 2001, Tim Janik wrote:

> On Wed, 21 Mar 2001, Alexander Larsson wrote:
> > @@ -174,6 +176,19 @@ GList*	   gtk_window_list_toplevels
> >
> >  /* Get the "built-in" accel group (convenience thing) */
> >  GtkAccelGroup* gtk_window_get_default_accel_group (GtkWindow *window);
> > +
> > +void     gtk_window_add_mnemonic          (GtkWindow *window,
> > +					   guint      keyval,
> > +					   GtkWidget *target);
> > +void     gtk_window_remove_mnemonic       (GtkWindow *window,
> > +					   guint      keyval,
> > +					   GtkWidget *target);
> > +gboolean gtk_window_activate_mnemonic     (GtkWindow *window,
> > +					   guint      keyval,
> > +					   guint      modifier);
> > +void     gtk_window_set_mnemonic_modifier (GtkWindow *window,
> > +					   guint      modifier);
> > +
>
> either add_mnemonic/remove_mnemonic need to be signals, or we need a
> ::mnemonics_changed signal for GtkWindow, otherwise the accel group
> or plug/socket can't monitor mnemoics. also for that purpose,
> we need a list_mnemonics function.
> as for add_mnemonic/remove_mnemonic vs. mnemonics_changed, the former
> is better to keep detailed track of the mnemonics list on a window,
> i'm not sure however we really need that.
> i don't know exactly what owen wants for plug/socket, but at least
> for accel group negotiation, i'd be fine with gtk_window_add_mnemonic
> and gtk_window_remove_mnemonic queueing an idle notifier to emit
> ::mnemonics_changed and then query the new mnemonics list from there.
> the only thing that needs to be taken care about is that the idle notifier
> priority, to avoid key events being handled before accel groups could
> react to mnemonic changes, the idle notifier needs to be queued with
> higher priority than the normal event handlers. since accel group
> notification of mnemonic changes may involve accelerator changes,
> which will most probably queue a resize on the widgets displaying
> accelerator bindings, choosing a priority higher than GTK_PRIORITY_RESIZE
> is prolly also not a bad idea.
>
> owen, what do you think about:
> #define GTK_PRIORITY_REDRAW     (G_PRIORITY_HIGH_IDLE + 20)
> #define GTK_PRIORITY_RESIZE     (G_PRIORITY_HIGH_IDLE + 10)
> #define GTK_PRIORITY_NOTIFY     (G_PRIORITY_HIGH_IDLE + 0)
> ?

I chosed not to implement any mnemonic notification stuff, since i was
now certain what kind of stuff plug/socket and accel negotiation needed. I
leave this up to you and owen.


> > +static gboolean
> > +gtk_label_activate_mnemonic (GtkWidget *widget,
> > +			     gboolean   group_cycling)
> > +{
> > +  GtkWidget *parent;
> > +
> > +  if (GTK_LABEL (widget)->mnemonic_widget)
> > +    return gtk_widget_activate_mnemonic (GTK_LABEL (widget)->mnemonic_widget, group_cycling);
> > +
> > +  /* Try to find the widget to activate by traversing the widget
> > +   * hierarachy.
> > +   */
> > +
> > +  parent = widget->parent;
> > +  while (parent)
> > +    {
> > +      if (GTK_WIDGET_CAN_FOCUS (parent) ||
> > +	  (!group_cycling && GTK_WIDGET_GET_CLASS (parent)->activate_signal) ||
> > +	  (parent->parent && GTK_IS_NOTEBOOK (parent->parent)) ||
> > +	  (GTK_IS_MENU_ITEM (parent)))
> > +	return gtk_widget_activate_mnemonic (parent, group_cycling);
> > +      parent = parent->parent;
> > +    }
>
> ok, this isn't particularly nice, it's about ugly enough
> to justify a GTK_WIDGET_FLAG_MNEMONIC_ACTIVATABLE flag.
> gtknotebook should then set that automatically on all its
> tab_labels, since it handles their mnemonic activation through
> signal handlers.
> that we actually need to special case MENU_ITEM here is due to menus
> not using the normal focussing mechanisms, so menu items don't have
> the CAN_FOCUS flag set. that's a bit odd, but definitely menu item
> specific, it'd be taken care off by GTK_WIDGET_FLAG_MNEMONIC_ACTIVATABLE
> as well though.

Seems like a good idea. Then strange stuff like the notebook hack can be
done outside Gtk+.

> btw, i think gtk_widget_mnemonic_activate() is a better name than
> gtk_widget_activate_mnemonic(), since we don't activate the widget's
> mnemonic key, but, due to a mnemonic key being pressed, activate the widget.
> (if there're no further objections on this, i'll change this the next
> few days)

I think gtk_widget_activate_mnemonic() is better. I don't think
of the term "mnemonic" as the specific key value, but rather the
connection/association between the key and the target widget, and it is
that association that is "activated". But I don't feel strongly about
this.

/ Alex