Re: [gtkmm] Actions / UIManager and OO programming style
- From: Christer Palm <palm nogui se>
- To: Murray Cumming <murrayc murrayc com>
- Cc: gtkmm-list <gtkmm-list gnome org>, GTK-list <gtk-list gnome org>
- Subject: Re: [gtkmm] Actions / UIManager and OO programming style
- Date: Tue, 29 Jun 2004 22:37:38 +0200
Murray Cumming wrote:
On Tue, 2004-06-29 at 01:29 +0200, Christer Palm wrote:
First of all, although I can connect a Button to an Action using
connect_proxy(), it won't get the Icon specified by the Action. Neither
can the Action create a button. It appears that it would be natural for
Actions to provide the same support for Buttons as it does for MenuItems
and ToolItems.
Yes, that would be nice. I don't know if it's meant to be possible, or
how you would do it. You might ask on gtk-list gnome org
Hence the cross-post :-)
I thought that if I only understood the mechanism used by GtkAction to
modify the properties of the proxy widget I could create my own
"GtkActionButton" which would have both a Icon + Label set by the
Action. However, I was somewhat suspicious as connect_proxy() is taking
a GtkWidget*, and I couldn't find any API support for doing this at the
GtkWidget level.
Checking out the GtkAction implementation confirms my suspicions. The
proxying of the Label, Icon and even connecting the actual "activate"
callback is done using code like:
if (GTK_IS_MENU_ITEM (proxy)) {
...
} else if (GTK_IS_TOOL_ITEM (proxy)) {
...
} else if (GTK_IS_BUTTON (proxy)) {
...
}
This is really stupid because implementation details about the proxy
widget is embedded right into the Action itself and efficiently closes
the door on any attempts on extending the mechanism without modifying
the GTK+ source. IMHO, stuff like that shouldn't belong in GTK+.
Now, unfortunately I won't be the one to attempt to fix it. I hope
someone still finds my €.02 worth of rants useful in some way.
Second, Action doesn't have any useful public/protected constructors.
There are no public constructors because they are meant to be used via
RefPtr. There are protected constructors, so you can derive. If you need
an extra constructor then I would be happy to look at a patch.
I looked at the protected constructor but it didn't look too useful at
the "user" level, neither is it documented [== a big warning sign saying
"this is internal stuff - use at your own risk"]. I will spend some more
time with it and see if I can make anything useful out of it, though.
RefPtr's are nice, but at the expense of extensibility - I don't know.
Perhaps that's something to keep in mind when doing the wrapper design?
--
Christer Palm
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]