Re: Menu changes (fwd)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> > > > Particular things I think need improvement:
> > > > 
> > > >  * Unless they make sense (as in the GIMP), changing entries to have
> > > >    no-modifier accelerators should be disabled, because they are
> > > >    too easy to set accidentally while navigating the menus.
> > > 
> > > i guess we can add a special hint, e.g. "<FrozenAccels>" or somesuch to the
> > > ->item_type, so we get stuff like
> > > "<CheckItem><FrozenAccels>".
> > 
> > Blech, no. We don't want to disable setting accelerators, we just
> > don't want people to set up accelerators accidentally when they
> > are trying to switch to a different menu or something - so I
> > was thinking we should have a way of disabling setting accelerators
> > when someone types an unmodified key. (And possible disable
> > it by default)
> 
> hm, would you want to set that on a per-menu basis then?

It probably should be stored per-menu, but it needs to be 
set by the item-factory when it creates the menus. So it
probably also needs to be a global ItemFactory option.
 
> > I don't think so. A NULL value for the pattern is perfectly legitimate
> > and handled properly in the code. (it is the default, in fact). It
> > saves a ton of 1 byte malloc allocations. Of course, some languages
> > can't represent a NULL string, but some can. (In Perl, it maps
> > naturally to 'undef')
> 
> from menu-patch.gz:
> +void
> +gtk_label_set_pattern (GtkLabel           *label,
> +                      const gchar *pattern)
> +{
> +  g_return_if_fail (label != NULL);
> +  g_return_if_fail (GTK_IS_LABEL (label));
> +  g_return_if_fail (pattern != NULL);
> +
> +  if (label->pattern)
> +    g_free (label->pattern);
> +  label->pattern = g_strdup (pattern);
> 
> a pattern of NULL would actually produce a warning, so we either need to check
> for that in set_arg or adapt the gtk_label_set_pattern() function.

I've changed set_pattern() to remove this check now. (It was
just copied from set_label)

> > > > 
> > > > 	* gtk/gtkmenu.[ch]: Make menus no longer a toplevel widget.
> > > > 	  Instead, they create a GtkWindow and add themselves
> > > > 	  to that. (When torn off, another new feature, they
> > > > 	  create another GtkWindow to hold the torn off menu)
> > > > 
> > > > 	  New function gtk_menu_set_tearoff_state()
> > > 
> > > regarding the binding sets, its easier to do:
> > > 
> > > +  binding_set = gtk_binding_set_by_class (class),
> > > -  binding_set = gtk_binding_set_new ("GtkMenu");
> > > -  gtk_binding_set_add_path (binding_set, GTK_PATH_CLASS,
> > > -                           "GtkMenu", GTK_PATH_PRIO_GTK);
> > > 
> > > gtk_binding_set_by_class() sets the path already, and i'd rather like
> > > to see all internal per-class bidings run through this function, and
> > > keep gtk_binding_set_add_path() for use from gtkrc.c only.
> > 
> > You see, we need docs on this stuff. Wait a second, I was writing
> > those... I've made this change in menu-patch-2
> 
> ;)
> i've just comitted the rc side of the binding stuff. identifier->enum
> lookups still need to be implemented, but everything else should
> work fine. i'd like you to take a special look at the priority stuff,
> i think i got it right so far (the priority parsing function is also
> exported now, in case theme modules need it).

Hmmm, I don't think it will be needed since the theme modules
don't participate in the parsing of patterns, just in the parsing
of styles. 

>From briefly reading the source code and the testgtkrc the binding
stuff looks pretty much like I imagined it. I'll fool around
with it more later.
 
> > > about the tearoff_window, i think you should catch the delete_event for
> > > this window, though i might be wrong since i can't actuall try this out.
> > 
> > It is caught, but the signal handler is set up in GtkTearoffMenuItem.c
> > so you missed it. (Yes, there is a lot of weird dependency going on
> > between the files with this stuff, though no more so than there was
> > before in the menuing code)
> 
> ;) as i said, i need to try that out.
> 
> > 
> > Regards,
> >                                         Owen
> 
> if this mail doesn't get through to gtk-devel as well, i guess that
> post-only-request@redhat.com is broken, at least for newly created lists,
> is that possible? thing is, even if we want only subscribers to post to
> gtk-devel, i have timj@gtk.org in my From: line and still want to get
> list mails directly be send to Tim.Janik@Hamburg.Netsurf.DE without
> the extra roundtrip to wilber.

I'll see what I can find out.

Regards,
                                        Owen