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 al...@redhat.com alexander.lars...@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! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list