unity-design team mailing list archive

[Cody Russell <bratsche@xxxxxxxxx>]

-------- Forwarded Message --------
From: Cody Russell <cody.russell@xxxxxxxxxxxxx>
To: ayatana@xxxxxxxxxxxxxxxxxxx
Subject: Keyboard focus location, relation to notify-osd placement
Date: Wed, 02 Sep 2009 13:21:34 -0500

(trying to re-send since it didn't go through yesterday for some reason)

Hi,

I haven't really been following this whole thread in much depth but my
understanding was that one of the major blockers right now is
determining where the keyboard focus is, because we don't want to popup
a notification bubble over a text entry that someone is typing into (or
if we do, we want it to be almost invisible).  The problem is that there
is no keyboard focus equivalent of XQueryPointer since this is more of a
toolkit-level concept.

One thing that we could try to do is try to develop a solution to this
problem using XFixes extension to mark an X server-side region as having
keyboard focus.  This would need to be done at the toolkit level to be
effective, but then other clients that care about this information
(e.g., notify-osd) could query it.  It also seems potentially useful for
other features; for example, Ted suggested today at lunch that we could
have a feature where if you're trying to quickly see where your keyboard
focus is then there could be a compiz plugin that searches for this
region I'm proposing and highlights it or makes it jiggle for a second
to get your attention.  I can't help but think that the ability to know
where keyboard focus is could open a lot of possibilities that nobody
has thought of yet since it doesn't exist. :)

Mirco, if this were doable would it be possible for notify-osd to figure
out what window is potentially under the bubble and then we could query
the keyboard-focused region from that window?  Otherwise we could put
the property on root, but that seems wrong to me from a toolkit
perspective.

If this sounds like it's of interest I can cook up some tests after I
finish some current stuff in my work list.  If it works well then I
could implement it in gtk+ and we can try to enlist some help to
implement it in Firefox and Qt (using a consistent name for the
property, of course) and propose the patches and the name to fdo.  If we
want to go this route then we should discuss at more length how it
should really work (e.g., does it apply only to text fields?  What about
multi-line editors that could be really big?)

/ Cody

--- Begin Message ---

• To: ayatana@xxxxxxxxxxxxxxxxxxx
• From: Cody Russell <cody.russell@xxxxxxxxxxxxx>
• Date: Wed, 02 Sep 2009 13:21:34 -0500

(trying to re-send since it didn't go through yesterday for some reason)

Hi,

I haven't really been following this whole thread in much depth but my
understanding was that one of the major blockers right now is
determining where the keyboard focus is, because we don't want to popup
a notification bubble over a text entry that someone is typing into (or
if we do, we want it to be almost invisible).  The problem is that there
is no keyboard focus equivalent of XQueryPointer since this is more of a
toolkit-level concept.

One thing that we could try to do is try to develop a solution to this
problem using XFixes extension to mark an X server-side region as having
keyboard focus.  This would need to be done at the toolkit level to be
effective, but then other clients that care about this information
(e.g., notify-osd) could query it.  It also seems potentially useful for
other features; for example, Ted suggested today at lunch that we could
have a feature where if you're trying to quickly see where your keyboard
focus is then there could be a compiz plugin that searches for this
region I'm proposing and highlights it or makes it jiggle for a second
to get your attention.  I can't help but think that the ability to know
where keyboard focus is could open a lot of possibilities that nobody
has thought of yet since it doesn't exist. :)

Mirco, if this were doable would it be possible for notify-osd to figure
out what window is potentially under the bubble and then we could query
the keyboard-focused region from that window?  Otherwise we could put
the property on root, but that seems wrong to me from a toolkit
perspective.

If this sounds like it's of interest I can cook up some tests after I
finish some current stuff in my work list.  If it works well then I
could implement it in gtk+ and we can try to enlist some help to
implement it in Firefox and Qt (using a consistent name for the
property, of course) and propose the patches and the name to fdo.  If we
want to go this route then we should discuss at more length how it
should really work (e.g., does it apply only to text fields?  What about
multi-line editors that could be really big?)

/ Cody

--- End Message ---