On Sat, 2004-06-19 at 17:15, Havoc Pennington wrote: > One a quick read and looking at how gtk_style_attach() works, your patch > is going to create a whole lot of copies of GtkStyle that are exactly > the same. When a frame has the same visual as MetaFrames::style you just > ref that style, but when a frame has a different visual you'll make a > new copy - but the new copy is per-frame, not per-visual. Ergo lots of > new copies made. Without really looking at either the patch or at the metacity code, if I create a style, then call gtk_style_attach (style, widget_a) gtk_style_attach (style, widget_b) gtk_style_attach (style, widget_c) gtk_style_attach (style, widget_d) And a,c and b,d share the same colormap, I'll only have two copies of the style. (There is a little funniness in gtk_style_attach() - I just filed http://bugzilla.gnome.org/show_bug.cgi?id=144706. But I don't think it affects the normal case) > So I think we need to go per-visual. Styles are per-colormap, not per-visual. Now, with the demise of pseudo-color, that doesn't matter much, but in terms of organizing the code... > 1. Make a MetaFrames per-visual > 2. Make a GtkStyle per-visual It's certainly legitimate to have multiple styles attached to a single widget. [...] > My only misgiving here is unhappiness about poking crap into > widget->style under GTK's nose (a feature your current patch also has); > so to use this approach I think we need to ask Owen or Matthias if it's > going to work. In a widget implementation it's perfectly legitimate to do whatever you want to widget->style. The canonical style handling of, in realize doing: widget->style = gtk_style_attach (widget->style, widget->window); in you realize() is just an example. gtk_widget_real_unrealize() does detach widget->style and since you probably chain up to it, you should have an attached style in widget->style at that point. However, I can't say it's very *nice* to swap around the widget->style field for different sections of your code. If you can get the style down to the drawing code in some other way that's certainly going to be cleaner. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part