Re: additions to gnome-app-helper

[Federico Mena <federico nuclecu unam mx>]

[Note: I CC'ed this to gtk-list because the toolbar part is of general
interest]

>  I'm starting to make some changes to the menu/toolbar stuff to
>  allow check/toggle buttons and radio buttons.  In order to do so
>  I've had to add an element or two to struct _GnomeUIInfo for things
>  like initial state.  This will break existing code -- what do
>  you think?  Should I just go through and fix all the code?

[The following paragraph may only be of interest to Gnome programmers]

Hmm.  I haven't thought much about this, but to me at first glance it
seems to be better to set the initial state "outside" of the
GnomeUIInfo structures.  If you put too much initial state in the
structures, I'm afraid you'll end up translating much of Gtk's API in
them.  Feel free to ignore me if you have a better reasons :-)

>  Also, it seems that there is not a "standard" way to add
>  check/toggle buttons and radio buttons to the current toolbar widget.
>  Is this right Federico?  I'd like to be able to add toggle buttons 
>  (those that stay down or up when I press them, indicating state),
>  and radio buttons (just like the toggle buttons, but they are grouped
>  and only one stays down at a time).
>  
>  It seems both could be implemented using the current gtktogglebutton
>  widget.  If that's right, I can take a crack at it, unless you'd like
>  to do it :-).

Hehe.  When I first implemented the toolbar I knew this would be
needed some day, so here it goes :-)

Right now GtkToolbar contemplates three kinds of children:  buttons,
widgets, and spaces.  Buttons are GtkButtons with special geometry
management by the toolbar (they are all allocated the same size).
Widgets are arbitrary widgets, and they are only allocated the space
they requested.  Spaces are, well, spaces.

I propose two things:

  - We need a radio button class with the same look and feel of the
    GtkToggleButton widget.  It can either be derived from
    GtkToggleButton (to keep the drawing functions) and add a 
    GSList *group field.  Or it can be derived from GtkRadioButton (to
    keep the GSList *group field) and add new drawing functions that
    would be a copy of those in GtkToggleButton.  You figure out that
    part to see what's the best way to do it.

  - Change the gtk_toolbar_{append,prepend,insert}_item functions to
    look like this:

	void
	gtk_toolbar_append_item (GtkToolbar *toolbar,
				 GtkButton  *button,
				 const char *text,
				 const char *tooltip_text,
				 const char *tooltip_private_text,
				 GtkWidget  *icon);

    As you can see, this is the same as the current version, except
    that it does not have the callback and user_data fields.  Instead
    it has a generic button field.

    The idea is that the user creates the desired button type (normal,
    toggle, or radio button) outside of this function, connects the
    relevant signals himself (because you may want "clicked" for
    buttons or "toggled" for other stuff), and just lets this function
    set up the contents of the button widget to the properly laid-out
    icon and label.

    (If you want to be really generic, you can substitute GtkButton *button
    by GtkContainer *item.  Right now I can't think of any situations
    in which you would want a toolbar child with special geometry
    management to be something other than a button).

This is a change simple enough to be worth doing, I think.  Yes, it's
an API change and all clients of GtkToolbar will have to be modified,
but I don't think it will be painful at all.

What do you think?  Feel free to implement it as desired.

  Quartic