Re: stock system

[Tim Janik <timj gtk org>]

On 27 Jul 2000, Havoc Pennington wrote:

> > > You use this in gtkrc:
> > >  stock["gtk-button-ok"] = { { "filename.png", *, *, * } }
> > 
> > this is a bit perl-ish ;)
> 
> Unsurprising, since Owen came up with it. ;-)
> 
> > i had probably made the syntax correspond to style syntax, i.e.
> > 
> > style "ugly-buttons" {
> >   stock "gtk-button-ok" { ... }
> > }
> > 
> 
> Pretty trivial to implement that, we just remove the parsing of the
> [], if you want it. I am pretty much totally indifferent.

i'm not in^H^Hfdifferent enough to fight over this with owen ;)
using strings as a stock index is pretty much what we do, so
the syntax is pretty ok i guess.

> > > Note that dialogs are crammed in to the stock framework. This is a
> > > little bit questionable, since they don't have accelerators and don't
> > > really represent an action. However GTK+ will happily use a dialog
> > > stock ID to create a button called "Error" if you try to do that. ;-)
> > 
> > ok, so why do we need those dialog stock ids, if i'm not intended
> > to create buttons from it? ;)
> >
> 
> 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?

> > hm, i haven't seen code for creating menu items yet, is that to
> > come?
> 
> Yes I haven't written it, the two main reasons are that first we have
> to make a hack to GtkMenuItem which is equivalent to GtkPixmapMenuItem
> in gnome-libs, and second that I don't understand the accelerator
> stuff well. So your explanation helps with the second issue.
> 
> 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>" },

?

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.

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?" ;)

> For the GtkPixmapMenuItem thing, we've talked about it some at the
> Labs and I think we just want a subclass of GtkMenuItem that can
> display a child widget on the left side, which can be a GtkImage; I'm
> not sure what to name the subclass.

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)

> > that of course has issues with accelerator propagation and persistence
> > and needs to be carefully thought out.
> > 
> > > The stock label can be a uline string, GTK will parse this for the
> > > accelerator when creating a stock widget. If you have a uline and also
> > > specify an accelerator in the GtkStockItem struct, GTK just installs
> > > both accelerators, I'm not sure what else to do there.
> > 
> > that's quite simple, for menu items:
> > - uline accels get added without modifiers to the menu item's menu's
> >   internal accel group. if the menu item's parent is actually a menu bar,
> >   we use GDK_MOD1_MASK and add the accelerator to the menu bar's public
> >   accel group that has to be installed on the menu bar's window.
> > - accelerators get installed on the menu's public accel group and that
> >   has to be added to the window the menu is used in (in light of the
> >   recent default accel group bug triggered on gtk-list, i'm pondering
> >   about making this "adding to the window" non-explicit)
> > 
> > for buttons, you should do quite the same, treating them as menu items
> > in menu bars, i.e.:
> > - add uline accels to the button's window's default_accel_group with
> >   GDK_MOD1_MASK
> > - add the stock accelerator to the button's window's default_accel_group
> >   right away
> > 
> 
> So do you think I should remove the accel_group argument to
> gtk_button_new_stock(), and simply always use the default accel group?

you can't, you don't have the window around at the time where you
create the button. i'm pondering whether we need to revamp the accelerator
stuff a bit to move those explicit accel group passing behind the scenes
and if that's possible...
of course, if we had something like ::anchestored and ::unanchestor
signals, that would be emitted on the widget tree once the window
is present in the heirachy, and be emitted on a branch that gets
unparaneted, we could do a lot of such magic...
for now, leave the argument there, we need to discuss this more
detailedly later on.

> I actually created gtk_window_get_default_accel_group() so users could
> use it to obtain an accel group to pass to gtk_button_new_stock(). But
> if there's no good reason to pass a different accel group, we may as
> well not require them to type it in.

i can't see a good reason to pass another accel group in, it's
more a matter of we have to since the window isn't present at the
time the accelerator gets installed.

> Alternatively passing NULL for accel group could mean "use the
> default group" (right now it means "don't install accelerators").

hum... OTOH, there's nothing else you could do currently ;)

> Also note that I threw in gtk_button_new_accel(), which is just
> gtk_button_new_with_label() that parses a uline on the label and sets
> up the accelerator - this isn't related to the stock stuff, but seemed
> like a good idea.

jup, saw that.

> 
> Havoc
> 

---
ciaoTJ