pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: KeyListeners on ImageView
Date Sat, 05 Mar 2011 12:56:05 GMT

Take a look at the attached app.
It opens 2 native OS windows, each containing 4 types of Pivot Windows (none
of which contain any focusable Components).
It uses a simple mechanism to forward unhandled keyboard events to the
active Pivot Window (if there is one)

Hopefully it demonstrates that you can target active Dialogs, Alerts &
Frames without too much hassle.
I can see the value of building this kind of logic into Pivot's event
handling, though.  Anyone else have any thoughts on this?

1. Send the event to the focused Component if there is one
2. If not, send to the active Window if there is one    <-- new step
3. If not, send to the UnprocessedKeyHandler if there is one

You might well be able to achieve something similar with a
WindowClassListener too.
See org.apache.pivot.wtk.Window.getWindowClassListeners()


On 5 March 2011 14:36, Bill van Melle <bill.van.melle@gmail.com> wrote:

>> Could you clarify what you mean by 'top-level windows'?
>> http://pivot.apache.org/tutorials/windows.html
> Sorry, that was my shorthand for "org.apache.pivot.wtk.Window opened on a
> Display object", thus corresponding in an obvious way to a window-system
> window.  So you interpreted me correctly.
>> Yes, I think there is a 1:1 relationship between an OS WIndow and a
>> Display.  If the OS window has focus, but no Pivot Component inside of it
>> has focus, the Application.UnprocessedKeyHandler will get the key presses.
> which, of course, being in Application, is far removed from the window
> being opened by some random other part of the program.  Of course, if
> the UnprocessedKeyHandler passed along the Display on which the key was
> pressed, it might still be usable (albeit clumsy) for what I want, but it
> doesn't.  Which also means that, unless UnprocessedKeyHandler only gets
> called on the app's "main" display (and not for *every* Display as you
> suggest), I don't see how one could ever use it in a multi-OSWindow
> application.

View raw message