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
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: Some introspection on GtkContainer children.
> Damon Chaplin wrote: > They can also be named with gtk_widget_set_composite_name(), though this > hasn't been used much in GTK+ itself. And thats a damn shame :( Right now I think the most evident practicle problems I'm seeing is: - Composite children need to be marked as such in order to properly implement copy/paste (i.e. recursivly duplicate) composite widgets. - Composite children need to be named in order to reference them in the glade file to set properties on them without creating them. At the moment in glade-3; I'm trying to mark all composite children explicitly; and I know it wont work properly unless *all* composite children are marked manually, this will turn out to be a nightmare in the long run for two reasons: - For each composite child we'll have to struggle to mark it both in libglade & in the builder. - The moment that someone enhances a Gtk+ composite widget adding a composite child the whole system will break; which leads me to ask; Do we need to implement composite children metadata in the builder with versioning information ? (i.e. composite child exists "Since 2.6") ? Ofcourse, all of these problems would be completely (or almost completely) addressed if gtk_widget_set_composite_name() was a requirement for composite children (then I'd only have versioning information to worry about). Here's a practicle question; If we were to enforce gtk_widget_set_composite_name() throughout the Gtk+ code base (I'm sure I could get through it in no time): When would I see that code in a released version of GTK+ ? glade-3 is definitly stablizing, if composite widget issues we're out of the way we'd have custom editors (i.e. menu/toolbar editors) to deal with and a few minor details (i18n'ness & a11y stuff) before I could envision a serious beta release. All that being considered, would it be reasonable to target a Gtk+ version that has gtk_widget_set_composite_name() enforced ? (I for one think so... since that wouldnt break compatibility with older versions of glade files afaics...) Dan Winship wrote: Damon Chaplin wrote: [...] Ideally a GUI builder shouldn't have to touch composite children - the properties of the widget should be enough to configure it completely. And we're far from that ideal, because widgets are totally inconsistent about how they treat their internal children. Agreed for the most part, but what about adding buttons manually to a composite child; example is the action_area hbuttonbox of a GtkDialog & children ? Maybe ideally a composite widget should have an api for adding children ? or one could use a "action-widget" child property on the GtkDialog so that the GtkDialog could hold a reference and implicitly put it in the action area ? (which wouldn't work since a GtkDialog is a GtkBin...) My thoughts on some things that could be done to fix this: [...] Agreed for the most part on all of these idealistic comments :) as specially noted that there are in effect three types of child widgets; "normal", "added as a result of a property value"; "added as a composite child which is constantly present". I think that if we're going to talk of ideal scenarios, GtkContainer should probably be a GInterface and allow for any object to have child objects; which also could be composite or not; children also tend to have different relationships to parents; for example a GtkMenuItem parented by a GtkMenu isnt exactly a GtkContainer --> GtkWidget relationship, its also concievable that a parent object can have multiple children of multiple relationship types. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
Damon Chaplin wrote: Composite children can be marked when created by the container calling gtk_widget_push_composite_child()/gtk_widget_pop_composite_child(). Unfortunately, the way it works is sort of broken, because eg, if a GtkDialog does: gtk_widget_push_composite_child (); button = gtk_button_new_from_stock (GTK_STOCK_OK); gtk_widget_pop_composite_child (); then the GtkButton's label and icon will also be marked as being composite children, even though GtkButton didn't want them to be (though it probably should have wanted them to be, but that's a separate problem). Ideally a GUI builder shouldn't have to touch composite children - the properties of the widget should be enough to configure it completely. And we're far from that ideal, because widgets are totally inconsistent about how they treat their internal children. My thoughts on some things that could be done to fix this: 1. Deprecate all the composite-child-related methods/flags, because they can't be fixed without breaking API. 2. Add a new GtkContainer child property indicating whether a child widget is: A. "Normal", meaning that the user explicitly added it via gtk_container_add() or the like, and that the user could also remove (or at least replace) it if they chose. B. "Structural", meaning that it's part of the internal structure of the parent, and you shouldn't frob it directly, but it might have "Normal" children, so it needs to be included in the glade file. (Eg, a GtkDialog's vbox.) C. "Other" (Um.. "Implicit"? "Emergent"?), meaning that the child was *implicitly* requested by the caller and reflects the state of some property on the parent, and shouldn't be modified directly, and doesn't need to be included in the glade file, because its state is completely determined by the parent. (Eg, a GtkMessageDialog's buttons, or a GtkButton's label). Maybe this shouldn't be a child property per se, but should be exposed in some other way. In particular, we might want to say that only "Normal" children have child properties at all, and that the results of trying to get or set child properties on "Structural" or "Other" children are undefined 3. Deprecate gtk_container_foreach(), since there's not much consistency in how widgets currently distinguish it from forall(), and we can't make them consistent without breaking existing apps. Add a new replacement for it that wraps forall() but filters the result according to a bitmask of the child types above. 4. Make glade's concept of "internal-name" be explicit, either as a new GtkContainer child property, or by the parent using gtk_widget_set_name(). Require all "Structural" children to have an internal name. 5. Have some way for container subtypes to indicate that they shouldn't actually be treated like containers, for things like GtkFileChooserButton (which is a subclass of GtkHBox, but shouldn't be treated as such). One possibility would be gtk_container_get_max_children(), which could return -1 (no limit), 0 (GtkFileChooserButton, etc), 1 (GtkBin and subclasses), 2 (GtkPaned), etc. -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
On Wed, 2005-09-14 at 23:27 -0400, Tristan Van Berkom wrote: > 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. Composite children can be marked when created by the container calling gtk_widget_push_composite_child()/gtk_widget_pop_composite_child(). They can also be named with gtk_widget_set_composite_name(), though this hasn't been used much in GTK+ itself. Ideally a GUI builder shouldn't have to touch composite children - the properties of the widget should be enough to configure it completely. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
