Re: stock system

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes:
> > I think the real reason to have dialog labels/images in the stock
> > system is so they can be themed. If we put the dialog images in a
> > different system we'd need to introduce a new way to theme them and
> > change the images for RTL languages, and that would be all kinds of
> > overhead for only 5 kinds of dialog and 5 images, it doesn't seem
> > worth having a different system for that.
> 
> oh, so the dialog stock ids are just there to create indicative
> images for the dialogs?
>

GtkMessageDialog has the little images like GnomeMessageBox and the
Motif message box.

> > Also, GtkItemFactory should probably support a "<Stock>" item type,
> > once we have the menu item stuff.
> 
> i'm not sure i know what you mean. something like:
> 
> static GtkItemFactoryEntry menubar_entries[] =
> {
> #define BST_OP(bst_op) (bst_app_operate), (BST_OP_ ## bst_op)
>   { "/_File",                           NULL,           NULL, 0,                        "<Branch>" },
>   { "/File/<<<<<<",                     NULL,           NULL, 0,                        "<Tearoff>" },
>   { "/File/_New",                       "<ctrl>N",      BST_OP (PROJECT_NEW),           "<Item>" },
> - { "/File/_Open...",                   "<ctrl>O",      BST_OP (PROJECT_OPEN),          "<Item>" },
> + { "gtk-file-open",                    NULL,           BST_OP (PROJECT_OPEN),          "<Stock>" },
> 
> ?
>

Right, along those lines. I'm not sure what the syntax would actually
be, but the idea is that you give a stock id and it fills in the item
text and accelerator for you.
 
> uhm, i just noticed, why do we actually have:
> 
> +#define GTK_STOCK_BUTTON_APPLY     "gtk-button-apply"
> +#define GTK_STOCK_BUTTON_OK        "gtk-button-ok"
> 
> instead of just
> 
> +#define GTK_STOCK_APPLY     "gtk-apply"
> +#define GTK_STOCK_OK        "gtk-ok"
> 
> that can be used (including same uline accels and same accelerator)
> for menu items? your size specification in GtkIconSource accounts
> for that as well.
> 

It's because we are cramming three slightly different things into the
stock system:

 - menu items and toolbar buttons
 - dialog buttons
 - message dialog icons

Stock items are often "designed" for one of these three, e.g.  a menu
item for GTK_STOCK_DIALOG_ERROR would be silly, or, dialog button:

  { GTK_STOCK_BUTTON_CLOSE, N_("_Close"), 0, 0, GTK_DOMAIN },

vs. menu item:

  { GTK_STOCK_CLOSE, N_("Close"), GDK_CONTROL_MASK, 'w', GTK_DOMAIN },

The dialog button probably shouldn't have the Ctrl-w accelerator.

It's also just for user documentation, so they can look at all the
dialog items, all the button items, or all the menu/toolbar items at
once... 

This has actually always bothered me about the libgnomeui system, but
when I tried to fix it I couldn't come up with a solution that didn't
make things all yucky and complicated.

> another issue i see is the namespace prefixing for stock ids, GNOME
> shouldn't actually overload "gtk-file-open", or "gtk-apply", it'd come
> with "gnome-file-open" and "gnome-apply", but we don't want to change
> all those ids in the application then...
> 
> it's also confusing, ettore will probably scratch his head over
> "what should i take again? gtk-apply, gnome-apply or nautilus-apply?" ;)
>

The way it works now, if you gtk_stock_add() a stock id that already
exits, you will overwrite the old value; so GNOME could just forcibly
change the stock items installed by GTK, and basically that's allowed
(we guarantee that first GTK installs its items in gtk_init(), then
gnome will install its items in gnome_init(), then after that the
application can overwrite any items)

I was thinking that GNOME would not provide gnome-file-open, or at
most it would #define GNOME_STOCK_OPEN GTK_STOCK_OPEN, if GNOME wants
to default to different values it would just overwrite the GTK values,
and to change the image of course you push a different icon factory on
to the default search stack.

Of course this leaves the application programmer wondering which
prefix a given item lives in, which is kind of ugly; the only solution
I can think of is to get rid of the #define thing, and just use
strings, because if we just use strings we could maybe say "no
namespaces". But of course then the compiler won't catch incorrect
spellings.
 
> subclassing isn't the issue here. i'm more concerned that if we
> don't add the support into GtkMenuItem itself, you end up with
> menus ala: ("##" is a really neat hot picture)
> 
> ## Energetize         Ctrl-E
> Frobnicate            Ctrl-F
> Havocoid                   H
> ## Owenizer Shift-Ctrl-Alt-O
> Quarticle                  Q
> 
> while if it's in GtkMenuItem, you get:
> 
> ## Energetize            Ctrl-E
>    Frobnicate            Ctrl-F
>    Havocoid                   H
> ## Owenizer    Shift-Ctrl-Alt-O
>    Quarticle                  Q
> 
> unless we do some ugly hackery, accelerator-space-preserving-stylish ;)
> 
> (granted, both aren't cool if you don't have icons for everything, but
> at least for BEAST i preferred the second over the first form)
>

jrb did some hacks to GtkMenuItem so that it's now possible to make a
subclass that works properly; basically he added a toggle_size_request
method to GtkMenuItemClass, IIRC. It's a pretty clean solution. So
first I'd need to apply that patch, then look at writing my subclass.
 
It might be better to just modify GtkMenuItem instead of using a
subclass, but Jonathan did the work already for a subclass if we need
it.
 
> you can't, you don't have the window around at the time where you
> create the button.

Oh, right. Blah.

> for now, leave the argument there, we need to discuss this more
> detailedly later on.
>

Yep.

Havoc