Re: stock system

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes: 
> yes, and now i'm pretty sure we want user-definable size,
> and even let them override aliases. e.g. MENU could default to 16x16,
> but blind-eyed-joe might want to make MENU evaluate as 128x128 so
> he actually sees the icon ;)
> a better example is probably my PALETTE->LARGE_TOOLBAR->(default)48x48
> case that'd i actually need ;)
> 

I think you're right, I will have to think about how to implement
this.

> > 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.
 
> > and also to create your button:
> >  button = gtk_button_new_stock (GTK_STOCK_BUTTON_OK, accel_group);
> 
> this is the accel_group used for the stock accelerators, not ulines right?
>

Hrm, right now I guess I'm using the same accel group for both. 

Just tell me the right thing to do and I'll implement it. I'm not
totally clear on how all the accel stuff works.

> > You can override the factories via an RcStyle; the stack is just a
> > fallback if no icon is found in widget->style->icon_factories.
> > 
> > The idea is that GTK+, gnome-libs, Nautilus, etc. can install their
> > own sets of stock icons, and then the theme always overrides the
> > programmatically-installed default icons.
> 
> ok i see. though i'm not sure yet, i think that does eliminate the
> prioritizing then.
>

A nice thing about it is that themes can have support for GNOME,
Nautilus, etc. in addition to the icons that come with GTK.
If a theme specifies icons for a stock ID an application doesn't use,
there's no harm done.

> > 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.
 
> 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.

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.

> 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?

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.

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

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.

Havoc