Re: stock system

[Tim Janik <timj gtk org>]

On 27 Jul 2000, Havoc Pennington wrote:

> Tim Janik <timj@gtk.org> writes:

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

leaving the dialog icons aside (as you said, they are a special case
anyways, mostly to avoid bloat), _conceptually_ menu items, toolbar
buttons, palette buttons and prolly dialog buttons are the same,
i.e. stock items (labled action, i18n, accel, icon).
so i'd really have expceted the dialog button to come with that same
accelerator as the menu item...

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

and if there's no menu in that dialog? having the stock accelerator
for Close work tehre as well would be a win, wouldn't it?

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

hm, maybe it'd help if you outlined what kind of ideas you had
(probably best in a seperate thread), worst case we're back here,
but there could be a chance of improving the system through other
people's input.

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

i see, quite some problems with

#define GNOME_STOCK_OPEN GTK_STOCK_OPEN

this will work at the C level, but you'll after some while
be flooded with "why doesn't stock['gnome-open'] = { } affect anything?"
in all sorts of flavours that end-user confusion can come across ;)

if some brave gnome hacker is really convinced that
GTK_STOCK_DIALOG_COLORSELECTOR is good to keep around (maybe
because it became standard and people are used to it), but also
wants to provide GNOME_STOCK_DIALOG_COLORSELECTOR since that's a
tiny bit better, flashier, whatever, you've got overseeable diversities.

libgnomeui introduces

#define GNOME_STOCK_DIALOG_DIE "gnome-dialog-die"

that plain gtk doesn't have. so people configure stuff:
stock["gnome-dialog-die"] = { { "/pics/terminator2.png" } }
after a while we figure everyone on the planet needs
_STOCK_DIALOG_DIE, so we move it down:

1) #define GTK_STOCK_DIALOG_DIE "gnome-dialog-die" /* urg */
2) #define GTK_STOCK_DIALOG_DIE "gtk-dialog-die" /* ok, but not compatible */

in case 2), for compat reasons libgnomeui even keeps
#define GNOME_STOCK_DIALOG_DIE "gnome-dialog-die"
instead of doing the appropriate:
#define GNOME_STOCK_DIALOG_DIE GTK_STOCK_DIALOG_DIE
and there the whole thing goes down the drain.

we can try to guard these kind of problems with loads of conventions,
but i doubt every developer will get them right or even grasp (if
_read_) them.

so i'm inclined to look around for something better ;)


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

urg ;(
ok, i haven't seen that yet, but if we want to feature icons for
menu items, we should be as generic as with accelerators. and that
includes the ability to have icons for toggle/radio items as well
(meant to mention that in my last mail. forgot. need sleep. bzzzt ;)
that is, prolly change gtk_menu_size_request() ala:

+ max_icon_size = 0;
  max_toggle_size = 0;
  max_accel_width = 0;

  children = menu_shell->children;
  while (children)
    {
      child = children->data;
      children = children->next;

      if (GTK_WIDGET_VISIBLE (child))
        {
          GTK_MENU_ITEM (child)->show_submenu_indicator = TRUE;
          gtk_widget_size_request (child, &child_requisition);

          requisition->width = MAX (requisition->width, child_requisition.width);
          requisition->height += child_requisition.height;

+         max_icon_size = MAX (max_icon_size, GTK_MENU_ITEM (child)->max_icon_size);
          max_toggle_size = MAX (max_toggle_size, MENU_ITEM_CLASS (child)->toggle_size);
          max_accel_width = MAX (max_accel_width, GTK_MENU_ITEM (child)->accelerator_width);
        }
    }

- requisition->width += max_toggle_size + max_accel_width;
+ requisition->width += max_icon_size + max_toggle_size + max_accel_width;
  [...]

  children = menu_shell->children;
  while (children)
    {
      child = children->data;
      children = children->next;

+     GTK_MENU_ITEM (child)->max_icon_size = max_icon_size;
      GTK_MENU_ITEM (child)->toggle_size = max_toggle_size;
    }

yes, it's a hack, but not more than max_toggle_size/max_accel_width already
is, so psssssst, just don't tell anyone ;)


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

> 
> Havoc
> 

---
ciaoTJ