Re: [gtk-list] Re: additions to gnome-app-helper



Federico Mena <federico@nuclecu.unam.mx> writes:
> >  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 :-)

OK, that makes sense.  I'll leave them as is.

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

I'll have a look at deriving from GtkToggleButton and adding the
group stuff.  I think that will end up easier.

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

Yes, that looks good.

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

I think I'll skip this for now :-).

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

Sounds good to me.  I'll at least generate a patch.  Inclusion in
GTK 1.0 is up to people other than me :-).  Is the toolbar used
much outside of GNOME applications yet?

-Marc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]