Re: stock system
- From: Havoc Pennington <hp redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: stock system
- Date: 27 Jul 2000 01:48:03 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]