Making the GTK people happy (was: Re: [Fwd: todo items])

Daniel Stone daniel at fooishbar.org
Sat Jan 10 03:05:54 PST 2009


Catching up on old mail ...

This was from GUADEC 2007 (cough), where the GTK+ people told us what we
want from X.  I keep on forgetting this is in my inbox, and I guess it
should be on the wiki somewhere, but as I'm offline, mail will have to
do.

On Thu, Aug 23, 2007 at 06:05:33PM -0400, Adam Jackson wrote:
Content-Description: Forwarded message - todo items
> Subject: todo items
> From: Ryan Lortie <desrt at desrt.ca>
> To: ajax at redhat.com
> Date: Sat, 04 Aug 2007 19:34:05 -0400
> Message-Id: <1186270445.7528.7.camel at moonpix.desrt.ca>
> 
> support for watching for single property changes

This is pretty easy; just add the relevant code to XFixes, and the event
delivery itself doesn't really change much.

> support for removing _all_ policy from the server for powersaving stuff
> (ie: we want it so that the monitor doesn't even come back from dpms
> when the mouse moves -- until we explicitly tell it to)

I think this should more or less take the form of a DPMS grab, which I'm
pretty sure we've discussed previously ...

> event re-injection stuff: the purpose of this is to have grabs that can
> act more like filters (and then send the events that they don't care
> about back to the server for normal delivery).  some form of layering of
> grabs might be appropriate.  something else might be more appropriate
> (for example, a VERY expressive "events that i am interested in"
> language).

Hmmm.  This is getting into the realm of ludicrous complexity, but I'm
fairly sure the ordered-priority-grabs thing will take care of their
needs here.

> support for freezing the delivery of damage events.  not sure if this is
> a good idea or not, since the possibility of the window being redrawn
> for unrelated reasons is pretty high...

I'm not entirely sure what the use case is here tbh, and it seems a bit
dangerous.

> support for saner input focus semantics.  it would be great if keyboard
> events always went to the window given to XSetInputFocus instead of
> possibly a child window thereof depending on the position of the mouse.
> xembed would thank you :)

XSetDeviceFocusExt(dpy, dev, window, revert_to, time,
                    { FocusChildren, FocusStrict })?

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20090110/4725e88e/attachment.pgp>


More information about the xorg mailing list