Re: gtk_widget_draw()

[Federico Mena Quintero <federico ximian com>]

On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote:

[Widgets with an InputOnly window for events]
> Yeah, they do it to avoid the window resize being asynchronous with
> respect to the repainting, etc, causing ugly looking resizes.

Oh, I thought they did it to get the parent's background.  So there are
multiple reasons to do this :)

> This is exactly the current model with client side windows.

Perfect, so we are on the same page and I just need to re-understand the
current state of GDK :)

> Additionally I was thinking one could specify a "border" on the window
> such that for clipping purposes and calculation of what has to be
> repainted we grow the window by the border width, while for events and
> the rest we use the normal size. This makes it easy to implement themes
> that have a more organic look, for instance having a "glow" on an active
> button that extends outside the button without affecting events, etc.

Do you need that?  Can't you create a separate window overlaid on your
button, and paint the glow on *that* one?  (The window would extend past
the "normal" window's edge; it would probably need the toplevel to be
its parent so the glow can go over everything, etc. - but it sounds
doable like that...)

> > Do we need a "window->need_parent_background" flag?  I.e. the "paint the
> > parent first, don't clip to the subwindow" flag?
> 
> Not sure what you mean. We need a single flag "is this window
> transparent". If it is that means:
> 1) It does not add to its parents clip-region
> 2) When redrawing it we must draw all parents and lower stacked siblings
> before drawing it.

Yes, that's exactly what I mean :)  A single flag that does exactly
that.

> > Who uses reparenting, anyway?
> 
> Dnd of toolbars items, detachable docks, putting plugs in sockets, etc. 

I don't think reparenting is needed for toolbar items and detachable
docks - unless X forces you to do it to get really smooth painting.

Plug/socket is special anyway, as you need to cross into the actual
window system.

[Anyway, this was about the impls being separate - if we keep
reparenting, then impls may need to stay... no idea.]

> Event masks affect more than performance though. They are combined to
> decide which window gets each event. For instance, if you have a window
> somewhere with a bunch of child hierarchies, and the window has the
> event mask for mouse motion, then it will get mouse motion even over the
> child windows, unless the child window sets mask for mouse motion too.
> So, just sending everything everywhere is not a solution.

Ah, OK :)  I guess this is due to X not having event callbacks and the
"boolean means whether the callback handled the event" thing...


So, apart from the general pending cleanup, are we just lacking the
"don't clip" flag discussed above for transparent windows?

  Federico