Some introspection on GtkContainer children.
Hi all, I know that there was much talk of introspection back in febuary; I didnt really follow this extensive thread: (Introspection API) http://mail.gnome.org/archives/gtk-devel-list/2005-February/msg00088.html but I wonder what decisions essentially were taken as a big picture; particularly: are there any clear plans on enhancing GObject introspection and GTK+ introspection overall any time soon ? and are there people working on that ? On a more practicle note; I was thinking that internal children of composite widgets should be more introspectable; for the purpose of GUI builders and loaders, if every child widget implicitly created by its parent at least had a name, we could avoid alot of special case code and maintanence. Maybe this has been thoroughly addressed and I missed it... Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 13:16 -0500, Federico Mena Quintero wrote: > On Wed, 2005-09-14 at 02:01 -0700, Todd Berman wrote: > > > The current hacks that 3rd party developers have to go through when they > > want to render something that looks like a themed native treeview header > > are bad enough (creating a fake treeview, adding a column, and passing a > > widget somewhat deep in the columns child tree). Making it completely > > private will prevent this from being possible at all. > > Generally, if you want to do "make a widget of type Foo look like a > widget of type Bar", you are on your own. GTK+ doesn't have explicit > support for that. > Yeah, but the real world has requirements :). > If you are writing your own list widget *and* you want it to look like > the stock GtkTreeView, I'd say it's way easier to just set your button > headers to use the detail hint I proposed, than hacking up a treeview > and extracting stuff from it. Oh for sure, it is easier, but it is a break, because old themes wont support it, and new themes will, and 3rd party apps and ISVs will be left in the cold again. > > > Although, I guess if this means the hacky stuff theme authors do to see > > if the widget's parent is a treeview, or clist, or etree (in clearlooks > > case) would be removed, and then widget authors could just pass in the > > proper detail to the paint_box calls would end up being a win. But only > > once all themes support it, until then, they would have to figure out > > which way the theme uses to detect it needs to draw a treeview header > > and act accordingly. > > If current themes check the parents of buttons to make treeviews a > special case, they'll keep working even with the proposed detail hint. > New themes can first check the detail hint, then fall back to checking > the parent of the button in case an older GTK+ is installed. > They all seem to do a check to see if the detail is "button" and if the widget->parent is treeview or clist. This is the issue. If the details gets changed to "treeview-header-left" then that check stops matching for older themes, and then they stop working. I would love to see the "treeview-header-left" stuff personally, but breaking all themes and apps attempting to use the current system sucks bad too :(. While I understand that none of this is really documented, and could (I guess) fall under some peoples interpretation of not breaking ABI, to me, it really would seem to be one. --Todd ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
JP Rosevear writes: > Even if not in glib we should be creating an official solution that > hooks nicely in to the mainloop rather than neon/curl/soup. There is also linc2 (in ORBit2) and gnet. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On 14 Sep 2005 19:08:39 +0200, Soeren Sandmann <[EMAIL PROTECTED]> wrote:
> Federico Mena Quintero <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote:
> >
> > > To distinguish Column headers from normal buttons, I check if its
> > > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the
> > > only way.
> > > In order to properly distinguish a column header from a normal button,
> > > I was thinking about setting a name on the column header button, using
> > > gtk_widget_set_name. Perhaps something like "Header:First",
> > > "Header:Middle", and "Header:Last".
> >
> > The right way to do it is to add a private API to GtkButton, so that the
> > tree view can tell the button which hint to pass to the gtk_paint_*()
> > functions. The theme engine will then use this hint to draw the proper
> > box type for the tree column's buttons.
>
> There is precedence in the toolbar for just setting a name:
>
> static void
> gtk_toolbar_init (GtkToolbar *toolbar)
> {
> ...
> priv->arrow = gtk_arrow_new (GTK_ARROW_DOWN, GTK_SHADOW_NONE);
> gtk_widget_set_name (priv->arrow, "gtk-toolbar-arrow");
> gtk_widget_show (priv->arrow);
> ...
> }
If this is done for the arrow, then why not do it for buttons as well?
For example
gtk_widget_set_name (priv->button, "column-header-first");
This would not break any existing apps. An added advantage is that
'fake' GTK+ apps and custom widgets can use this system too, avoiding
the need to derive from a GtkTreeView. However, doing a string
comparison on every button inside the engine sounds pretty hacky
too...
But I think there's a better solution.
Maybe some new API could be added that an engine can use to determine
if there are special properties?
gboolean gtk_widget_has_extended_style(GtkWidget*);
const gchar* gtk_widget_get_extended_style(GtkWidget *widget, const
gchar *property);
I'm not 100% sure, but I assume this can be done without breaking the ABI.
Ofcourse, it would still require a 'dummy' GtkWidget object for
Mozilla and other fake GTK+ apps, but it's better than nothing.
- Richard Stellingwerff.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 02:01 -0700, Todd Berman wrote: > The current hacks that 3rd party developers have to go through when they > want to render something that looks like a themed native treeview header > are bad enough (creating a fake treeview, adding a column, and passing a > widget somewhat deep in the columns child tree). Making it completely > private will prevent this from being possible at all. Generally, if you want to do "make a widget of type Foo look like a widget of type Bar", you are on your own. GTK+ doesn't have explicit support for that. If you are writing your own list widget *and* you want it to look like the stock GtkTreeView, I'd say it's way easier to just set your button headers to use the detail hint I proposed, than hacking up a treeview and extracting stuff from it. > Although, I guess if this means the hacky stuff theme authors do to see > if the widget's parent is a treeview, or clist, or etree (in clearlooks > case) would be removed, and then widget authors could just pass in the > proper detail to the paint_box calls would end up being a win. But only > once all themes support it, until then, they would have to figure out > which way the theme uses to detect it needs to draw a treeview header > and act accordingly. If current themes check the parents of buttons to make treeviews a special case, they'll keep working even with the proposed detail hint. New themes can first check the detail hint, then fall back to checking the parent of the button in case an older GTK+ is installed. It's not a big problem, really. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 09:29 +0200, Richard Stellingwerff wrote: > By "hint," do you actually mean the 'detail' parameter that gets > passed on to gtk_paint_*()? Simply changing that would break a lot of > themes that currently don't know how to handle the new 'detail'. Yes, I meant the "detail" parameter. Theme engines are expected to handle unknown hints just fine. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 20:55 +0300, Kalle Vahlman wrote: > 2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > > On Wed, 2005-09-14 at 12:18 +0300, Kalle Vahlman wrote: > > > 2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > > > > Although, I guess if this means the hacky stuff theme authors do to see > > > > if the widget's parent is a treeview, or clist, or etree (in clearlooks > > > > case) would be removed, and then widget authors could just pass in the > > > > proper detail to the paint_box calls would end up being a win. But only > > > > once all themes support it, until then, they would have to figure out > > > > which way the theme uses to detect it needs to draw a treeview header > > > > and act accordingly. > > > > > > Are you really suggesting that implementing a good way to do things > > > should be pending on hackily > > > implemented themes to be fixed (to the implementation that doesn't > > > exist) or working around those hackily implemented themes? > > > > > > Sounds like a bad suggestion to me. > > > > > > > No. But I am suggesting that breaking working applications and themes > > seems like a clear ABI break, and doesn't sound like a good thing to do. > > What applications would break and why if I may ask? I thought the > rendering details were hints to the theme engines, not applications. > 2 that I know of offhand. 1) The app we are writing at work (not interesting) 2) Mozilla Mozilla uses the same method we do to render things that look like treeview headers. But possibly more, basically any application that wants to render something that looks like a themed treeview header would break. > > I don't like the way it currently works, as it was a headache to get it > > working for myself, and assume it is somewhat of one for others as well. > > > > However, breaking the way it seems to have been working since gtk+ 2.0 > > seems just as bad and as much of a headache as it being somewhat of a > > hack in the first place. > > Ah, but it isn't working is it? There is no way to tell the difference > other than the hack. Besides, I'd guess that a sensible fallback chain > should be in the theme engines (eg. look at the detail, unkown falls > back to the hack, that falls back to the default rendering), and not > in treeview... > No. It works. Its just a horrible hack to get working properly, which you have to discover via reading code and testing a lot. > > > Good themes wwould be fixed promptly anyway (by social pressure or by > > > contributions), bad ones are not that critical ;) > > > > > > > Tell that to the users using those 'bad' themes. > > And they'll tell the maintainers to upgrade for the newer GNOME they > just installed. It's not like the change would go to people's machines > and break them by themselves. If you upgrade by hand, prepare for > trouble. If you upgrade in a distro, hope that the distro makers have > prepared for trouble. In a perfect world, yes. In reality, it seems to me to be an ABI break, which is bad. --Todd ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > On Wed, 2005-09-14 at 12:18 +0300, Kalle Vahlman wrote: > > 2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > > > Although, I guess if this means the hacky stuff theme authors do to see > > > if the widget's parent is a treeview, or clist, or etree (in clearlooks > > > case) would be removed, and then widget authors could just pass in the > > > proper detail to the paint_box calls would end up being a win. But only > > > once all themes support it, until then, they would have to figure out > > > which way the theme uses to detect it needs to draw a treeview header > > > and act accordingly. > > > > Are you really suggesting that implementing a good way to do things > > should be pending on hackily > > implemented themes to be fixed (to the implementation that doesn't > > exist) or working around those hackily implemented themes? > > > > Sounds like a bad suggestion to me. > > > > No. But I am suggesting that breaking working applications and themes > seems like a clear ABI break, and doesn't sound like a good thing to do. What applications would break and why if I may ask? I thought the rendering details were hints to the theme engines, not applications. > I don't like the way it currently works, as it was a headache to get it > working for myself, and assume it is somewhat of one for others as well. > > However, breaking the way it seems to have been working since gtk+ 2.0 > seems just as bad and as much of a headache as it being somewhat of a > hack in the first place. Ah, but it isn't working is it? There is no way to tell the difference other than the hack. Besides, I'd guess that a sensible fallback chain should be in the theme engines (eg. look at the detail, unkown falls back to the hack, that falls back to the default rendering), and not in treeview... > > Good themes wwould be fixed promptly anyway (by social pressure or by > > contributions), bad ones are not that critical ;) > > > > Tell that to the users using those 'bad' themes. And they'll tell the maintainers to upgrade for the newer GNOME they just installed. It's not like the change would go to people's machines and break them by themselves. If you upgrade by hand, prepare for trouble. If you upgrade in a distro, hope that the distro makers have prepared for trouble. BUT I just pretend to know anything about the way themeing works, so if I'm wrong, please ignore me. -- Kalle Vahlman, [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Wed, Sep 14, 2005 at 12:02:46PM -0400, JP Rosevear wrote: > Its a fine line, but I can't see how network connections don't fit in as > an acceptable low level operation when we have the following in glib: > > 1) lexical scanner > 2) xml subset parser > 3) IO Channels > > Even if not in glib we should be creating an official solution that > hooks nicely in to the mainloop rather than neon/curl/soup. While adding network libraries to GLib/GNetwork, I feel that integrated, high-level service discovery and publishing objects, ala GServiceDiscovery and $OBJECTNOTYETWRITTEN are good candidates for the stack. While they are currently dependant on Avahi, the idea is to prevent them from unnessecarily exposing Avahi implementation details so that they could be use opaquely with other mDNS/DNS-SD implementations (eg. Apple's). --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
Federico Mena Quintero <[EMAIL PROTECTED]> writes:
> On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote:
>
> > To distinguish Column headers from normal buttons, I check if its
> > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the
> > only way.
> > In order to properly distinguish a column header from a normal button,
> > I was thinking about setting a name on the column header button, using
> > gtk_widget_set_name. Perhaps something like "Header:First",
> > "Header:Middle", and "Header:Last".
>
> The right way to do it is to add a private API to GtkButton, so that the
> tree view can tell the button which hint to pass to the gtk_paint_*()
> functions. The theme engine will then use this hint to draw the proper
> box type for the tree column's buttons.
There is precedence in the toolbar for just setting a name:
static void
gtk_toolbar_init (GtkToolbar *toolbar)
{
...
priv->arrow = gtk_arrow_new (GTK_ARROW_DOWN, GTK_SHADOW_NONE);
gtk_widget_set_name (priv->arrow, "gtk-toolbar-arrow");
gtk_widget_show (priv->arrow);
...
}
Not that that is necessarily any indication that it's the right way to
do it of course.
Søren
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 12:18 +0300, Kalle Vahlman wrote: > 2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > > Although, I guess if this means the hacky stuff theme authors do to see > > if the widget's parent is a treeview, or clist, or etree (in clearlooks > > case) would be removed, and then widget authors could just pass in the > > proper detail to the paint_box calls would end up being a win. But only > > once all themes support it, until then, they would have to figure out > > which way the theme uses to detect it needs to draw a treeview header > > and act accordingly. > > Are you really suggesting that implementing a good way to do things > should be pending on hackily > implemented themes to be fixed (to the implementation that doesn't > exist) or working around those hackily implemented themes? > > Sounds like a bad suggestion to me. > No. But I am suggesting that breaking working applications and themes seems like a clear ABI break, and doesn't sound like a good thing to do. I don't like the way it currently works, as it was a headache to get it working for myself, and assume it is somewhat of one for others as well. However, breaking the way it seems to have been working since gtk+ 2.0 seems just as bad and as much of a headache as it being somewhat of a hack in the first place. > Good themes wwould be fixed promptly anyway (by social pressure or by > contributions), bad ones are not that critical ;) > Tell that to the users using those 'bad' themes. --Todd ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 09:15 -0400, Matthias Clasen wrote: > On Wed, 2005-09-14 at 09:29 +0200, Richard Stellingwerff wrote: > > On 9/14/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote: > > > > > > > To distinguish Column headers from normal buttons, I check if its > > > > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the > > > > only way. > > > > In order to properly distinguish a column header from a normal button, > > > > I was thinking about setting a name on the column header button, using > > > > gtk_widget_set_name. Perhaps something like "Header:First", > > > > "Header:Middle", and "Header:Last". > > > > > > The right way to do it is to add a private API to GtkButton, so that the > > > tree view can tell the button which hint to pass to the gtk_paint_*() > > > functions. The theme engine will then use this hint to draw the proper > > > box type for the tree column's buttons. > > > > By "hint," do you actually mean the 'detail' parameter that gets > > passed on to gtk_paint_*()? Simply changing that would break a lot of > > themes that currently don't know how to handle the new 'detail'. > > Themes that can't handle unkown details are already broken, just like > themes that can't handle widget being NULL... I think (but am not sure) that his point was that changing from passing a detail of "button" with a widget->parent of either treeview or clist to passing a detail of "gtk-treeview-header-right" or whatever, will break current theme's treeview header rendering. --Todd PS - Sorry for the double post for some of you, still working out this whole how-to-email issue :). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
On Fri, 2005-08-26 at 07:53 +0200, Murray Cumming wrote: > > But being as part of the official library pack makes them be official, > > and avoid people using different solutions for the same problem. > > That's the idea of being in the GNOME Development Platform. I don't see > how putting the whole platform in one tarball makes it much more official. > > That's just an invitation to JDKesque quality problems due to lack of > modularity - meaning: > - you have to wait to release a bugfix because of a bug in another part of > the library that surfaced in the meantime, and > - you force people to suffer bugs in another part of the library when > releasing a bugfix for one part of the library. Its a fine line, but I can't see how network connections don't fit in as an acceptable low level operation when we have the following in glib: 1) lexical scanner 2) xml subset parser 3) IO Channels Even if not in glib we should be creating an official solution that hooks nicely in to the mainloop rather than neon/curl/soup. -JP -- JP Rosevear <[EMAIL PROTECTED]> Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Wed, 2005-09-14 at 09:29 +0200, Richard Stellingwerff wrote: > On 9/14/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote: > > > > > To distinguish Column headers from normal buttons, I check if its > > > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the > > > only way. > > > In order to properly distinguish a column header from a normal button, > > > I was thinking about setting a name on the column header button, using > > > gtk_widget_set_name. Perhaps something like "Header:First", > > > "Header:Middle", and "Header:Last". > > > > The right way to do it is to add a private API to GtkButton, so that the > > tree view can tell the button which hint to pass to the gtk_paint_*() > > functions. The theme engine will then use this hint to draw the proper > > box type for the tree column's buttons. > > By "hint," do you actually mean the 'detail' parameter that gets > passed on to gtk_paint_*()? Simply changing that would break a lot of > themes that currently don't know how to handle the new 'detail'. Themes that can't handle unkown details are already broken, just like themes that can't handle widget being NULL... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
2005/9/14, Todd Berman <[EMAIL PROTECTED]>: > On Tue, 2005-09-13 at 17:48 -0500, Federico Mena Quintero wrote: > > On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote: > > > > > To distinguish Column headers from normal buttons, I check if its > > > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the > > > only way. > > > In order to properly distinguish a column header from a normal button, > > > I was thinking about setting a name on the column header button, using > > > gtk_widget_set_name. Perhaps something like "Header:First", > > > "Header:Middle", and "Header:Last". > > > > The right way to do it is to add a private API to GtkButton, so that the > > tree view can tell the button which hint to pass to the gtk_paint_*() > > functions. The theme engine will then use this hint to draw the proper > > box type for the tree column's buttons. > > > > Please no. > > The current hacks that 3rd party developers have to go through when they > want to render something that looks like a themed native treeview header > are bad enough Hacks are always bad. Even if they work. > Although, I guess if this means the hacky stuff theme authors do to see > if the widget's parent is a treeview, or clist, or etree (in clearlooks > case) would be removed, and then widget authors could just pass in the > proper detail to the paint_box calls would end up being a win. But only > once all themes support it, until then, they would have to figure out > which way the theme uses to detect it needs to draw a treeview header > and act accordingly. Are you really suggesting that implementing a good way to do things should be pending on hackily implemented themes to be fixed (to the implementation that doesn't exist) or working around those hackily implemented themes? Sounds like a bad suggestion to me. Good themes wwould be fixed promptly anyway (by social pressure or by contributions), bad ones are not that critical ;) I'd definitely go for it. -- Kalle Vahlman, [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On Tue, 2005-09-13 at 17:48 -0500, Federico Mena Quintero wrote: > On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote: > > > To distinguish Column headers from normal buttons, I check if its > > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the > > only way. > > In order to properly distinguish a column header from a normal button, > > I was thinking about setting a name on the column header button, using > > gtk_widget_set_name. Perhaps something like "Header:First", > > "Header:Middle", and "Header:Last". > > The right way to do it is to add a private API to GtkButton, so that the > tree view can tell the button which hint to pass to the gtk_paint_*() > functions. The theme engine will then use this hint to draw the proper > box type for the tree column's buttons. > Please no. The current hacks that 3rd party developers have to go through when they want to render something that looks like a themed native treeview header are bad enough (creating a fake treeview, adding a column, and passing a widget somewhat deep in the columns child tree). Making it completely private will prevent this from being possible at all. Although, I guess if this means the hacky stuff theme authors do to see if the widget's parent is a treeview, or clist, or etree (in clearlooks case) would be removed, and then widget authors could just pass in the proper detail to the paint_box calls would end up being a win. But only once all themes support it, until then, they would have to figure out which way the theme uses to detect it needs to draw a treeview header and act accordingly. --Todd ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distinguish column header from normal button
On 9/14/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote: > > > To distinguish Column headers from normal buttons, I check if its > > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the > > only way. > > In order to properly distinguish a column header from a normal button, > > I was thinking about setting a name on the column header button, using > > gtk_widget_set_name. Perhaps something like "Header:First", > > "Header:Middle", and "Header:Last". > > The right way to do it is to add a private API to GtkButton, so that the > tree view can tell the button which hint to pass to the gtk_paint_*() > functions. The theme engine will then use this hint to draw the proper > box type for the tree column's buttons. By "hint," do you actually mean the 'detail' parameter that gets passed on to gtk_paint_*()? Simply changing that would break a lot of themes that currently don't know how to handle the new 'detail'. > Speaking of Clearlooks... currently, the hints that get passed to the > gtk_paint*() functions are totally undocumented. Theme authors have to > dig in the GTK+ sources to see how each widget draws itself. It would > be *fantastic* if you could cook a list of the hints for each widget, > and leave it as a reference for other theme authors :) Again, I asume you mean the 'detail' here. I won't make any promises, but I'll consider documenting it. Kind regards, Richard Stellingwerff. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
