On Wed, 2010-08-18 at 11:13 -0500, Federico Mena Quintero wrote: > On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: > > [Border around windows so you can "glow" around a widget] > > There are all sorts of ways you can hack it into GtkButton or any > > specific widget, I'm sure. However, its hard to do in a more generic way > > for a theme. I was thinking the theme could just set a style property to > > have the widget enlarge its border, and then the theme just draws a bit > > outside in its normal rendering operation. No hacks, no special code, > > works for all widgets. > > Hmm. I just think it's overkill to complicate the GdkWindow abstraction > just for themes' sake. > > Correct me if I'm wrong, but I think you imagine the > glow-around-a-button to actually have allocated space around the button > > ************ > * +------+ * +------+ > * |button| * |button| > * +------+ * +------+ > ************ > > while I'm imagining that the glow actually overlaps anything around the > widget > > ************** > * +------+ +*-----+ > * |button| |*utton| > * +------+ +*-----+ > ************** > > The latter is doable if the theme creates a temporary window as a child > of the toplevel, on top of all the other subwindows.
Themes can't generally modify the window hierarchy or have other state like this. They just affect the drawing of the widget. > [Do we just lack the "don't clip" flag on windows] > > To fully take advantage of it we would also like to remove no-window > > widgets in Gtk and make getting a "standard" window easy via some > > default realize handler setup. > > I guess InputOnly windows are trivial when we get the transparent > windows we've been talking about - you just never draw to them. Old > apps could still use them to get events. We already support InputOnly windows fine in csw. > Getting rid of no-window widgets would be trivial in GTK+, but it would > break a lot of code that already uses that trick and does all the > coordinate-munging on its own... maybe we should make "no-window" mean > "you won't know it, but you really get a cairo_t with a transformation > relative to your parent widget"? That way you still have to make the > changes to take a cairo_t instead of a GdkWindow (for the draw() > method), but you don't have to change your delicate code that deals with > coordinates. The problem with no-window widgets is not really for the no-window widget, but rather that all parents must have special expose code that chains to the no-window widgets. If we want to clean up the drawing code this is kinda ugly. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc al...@redhat.com alexander.lars...@gmail.com He's a benighted arachnophobic librarian with a robot buddy named Sparky. She's a mistrustful red-headed bodyguard fleeing from a Satanic cult. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list