Re: gtk_widget_draw()

[Alexander Larsson <alexl redhat com>]

On Tue, 2010-08-17 at 16:04 -0500, Federico Mena Quintero wrote:
> On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote:

> > 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...)

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.

> > > 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.

Yeah, but the way you do this is via gdk. It is the bridge to the native
windowing system. Just ignoring that is not gonna help us.

> > 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...

Such callbacks would be very costly in an client-server over-network
model, since there will be many roundtrips per event.

> So, apart from the general pending cleanup, are we just lacking the
> "don't clip" flag discussed above for transparent 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.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a bookish moralistic stage actor on the hunt for the last specimen of a 
great and near-mythical creature. She's a strong-willed French-Canadian 
barmaid trying to make a difference in a man's world. They fight crime!