Re: gtk_widget_draw()

[Alexander Larsson <alexl redhat com>]

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 
       alexl redhat com            alexander larsson 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!