Re: Distinguish column header from normal button
On 9/16/05, Todd Berman [EMAIL PROTECTED] wrote: On Thu, 2005-09-15 at 23:24 +0200, David Christian Berg wrote: Therefore I'm certain it won't break anything. I personally use the trick reminic mentioned since a long while with my eXperience theme. Since I use this trick quite often (buttons in the panel look different from buttons in dialogues etc) I didn't bother so far. Still I personally like the approach of reminic, because it allows you too theme the ends of the header differently. This definitely would be an improvement. You can already do that, if you look at the clearlooks source, they use the API to get the column information, as in, which column it is, is it the first, or middle, or last. So that information is already available and usable today. So I take it this is going to stay unchanged? Personally I'm absolutely not happy with using the API to get the column information, since it doesn't work for too many apps. Evolution being one of the most popular. What's against using extended style parameters? Is it just not possible to do? - 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
Hey guys, hey reminic! 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. Ok, let's face it. Most themes don't care, what where a button is drawn. The buttons in top of a list will still be GtkButtons, if you add a detail. I don't think they even _have_ a detail right now. 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 :(. Therefore I'm certain it won't break anything. I personally use the trick reminic mentioned since a long while with my eXperience theme. Since I use this trick quite often (buttons in the panel look different from buttons in dialogues etc) I didn't bother so far. Still I personally like the approach of reminic, because it allows you too theme the ends of the header differently. This definitely would be an improvement. I don't know a first thing about programming or how things work behind the scenes, but as I said before, I don't see the problems Tedd is talking about. Take care! David ___ 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 Thu, 2005-09-15 at 23:24 +0200, David Christian Berg wrote: Hey guys, hey reminic! 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. Ok, let's face it. Most themes don't care, what where a button is drawn. The buttons in top of a list will still be GtkButtons, if you add a detail. I don't think they even _have_ a detail right now. I havn't seen a theme in a long time that just rendered the normal Button look, of course I have only been using mist, industrial and clearlooks recently. Well, as well, the wimp theme. 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 :(. Therefore I'm certain it won't break anything. I personally use the trick reminic mentioned since a long while with my eXperience theme. Since I use this trick quite often (buttons in the panel look different from buttons in dialogues etc) I didn't bother so far. Still I personally like the approach of reminic, because it allows you too theme the ends of the header differently. This definitely would be an improvement. You can already do that, if you look at the clearlooks source, they use the API to get the column information, as in, which column it is, is it the first, or middle, or last. So that information is already available and usable today. --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 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
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 insert good estimate of amount 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 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
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 insert good estimate of amount 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
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 insert good estimate of amount 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: 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 insert good estimate of amount 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
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 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 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
