adobe-source-devel

[Adobe-source-devel] keyboard handling

[Ralph T. <ra...@gm...>]

Hi list,

  How does adobe::keyboard_t work:

  - How do keyboard events get put in there? (On Windows I can see
that the top-level window puts some in, but it won't get all of them,
will it? On Mac I can't see anything that calls
keyboard_t::dispatch...)
  - What is underlying_handler() used for?

Thanks,
 Ralph

Re: [Adobe-source-devel] keyboard handling

[Foster T. B. <fbr...@ad...>]

Hi Ralph,

keyboard_t is a step in the direction of splitting out the various event
trees into their separate components. keyboard_t is intended to be the even=
t
tree for all events related to the keyboard. Individual widgets can attach
themselves into the keyboard handler tree if they'd like to receive
notification of keyboard events in particular. It is our intent to
eventually have event trees for other events as well (e.g., mouse_t)

The only place keyboard_t is driven is from within handle_dialog. One of th=
e
big issues we have yet to tackle is getting this new event mechanism
integrated into legacy event handling systems. Because we haven't tackled
this problem yet, Begin doesn't have a top-level mechanism to translate
events from its event handlers (be they win32 or Carbon) to keyboard_t. We
started down this road with handle_dialog because it has a subloop over
which we have complete control. I'd recommend having a look within
modal_dialog_interface.cpp, as that's where all the fun is being had at thi=
s
time.

The underlying_handler routine is an access function for the keyboard_t
mechanism so it can get to the platform-specific "thing" that does the
actual handling of the event. Again, the need for this routine comes out of
the need to integrate keyboard_t into the classical event handling systems
found in Carbon and win32.

I hope that sheds some light on the subject. If there's anything more I can
do to help answer your questions, please let me know.

Blessings,
Foster


On 1/5/07 11:31 p, "Ralph Thomas" <ra...@gm...> wrote:

> Hi list,
>=20
>   How does adobe::keyboard_t work:
>=20
>   - How do keyboard events get put in there? (On Windows I can see
> that the top-level window puts some in, but it won't get all of them,
> will it? On Mac I can't see anything that calls
> keyboard_t::dispatch...)
>   - What is underlying_handler() used for?
>=20
> Thanks,
>  Ralph
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

--=20
Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><                Romans 3:=
21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build components
but how to use them." -- Alexander Stepanov
"Now we have very simple code and the meaning is perfectly clear. Drink the
Kool-Aid" -- Sean Parent

Re: [Adobe-source-devel] keyboard handling

[Sean P. <sp...@ad...>]

I'll add a little more on where this is going and why -

Most frameworks end up with a "view system" (we call this a display =20
system so as not to confuse it with view in MVC) which also =20
dispatches events and in every framework I've used this ends up being =20=

a fairly large tangled mess. There is only a small correlation =20
between the view hierarchy and the event hierarchy -

To date, with the widget library we've been focused on the controller/=20=

view side of the widget - not how the backend side of the widget (how =20=

does it handle events and drawing) - but we have a rough idea of what =20=

we want for these things - they are containers. A display_t will =20
eventually hold drawable items and a keyboard_t holds key event =20
handlers... Right now, this are small shims over the platform =20
mechanism where how the drawing/event handling happens is platform =20
specific communication between the widget and the system.

Eventually we'll flesh these out to be more complete - and provide a =20
platform independent way to write a widget (though I'd like to keep =20
the ability to use the platform widgets) - I had hoped to use =20
Antigrain as the drawing library for this but their recent move to a =20
GPL license pretty much kills this plan.

Sean

On Jan 8, 2007, at 10:24 AM, Foster T. Brereton wrote:

> Hi Ralph,
>
> keyboard_t is a step in the direction of splitting out the various =20
> event
> trees into their separate components. keyboard_t is intended to be =20
> the event
> tree for all events related to the keyboard. Individual widgets can =20=

> attach
> themselves into the keyboard handler tree if they'd like to receive
> notification of keyboard events in particular. It is our intent to
> eventually have event trees for other events as well (e.g., mouse_t)
>
> The only place keyboard_t is driven is from within handle_dialog. =20
> One of the
> big issues we have yet to tackle is getting this new event mechanism
> integrated into legacy event handling systems. Because we haven't =20
> tackled
> this problem yet, Begin doesn't have a top-level mechanism to =20
> translate
> events from its event handlers (be they win32 or Carbon) to =20
> keyboard_t. We
> started down this road with handle_dialog because it has a subloop =20
> over
> which we have complete control. I'd recommend having a look within
> modal_dialog_interface.cpp, as that's where all the fun is being =20
> had at this
> time.
>
> The underlying_handler routine is an access function for the =20
> keyboard_t
> mechanism so it can get to the platform-specific "thing" that does the
> actual handling of the event. Again, the need for this routine =20
> comes out of
> the need to integrate keyboard_t into the classical event handling =20
> systems
> found in Carbon and win32.
>
> I hope that sheds some light on the subject. If there's anything =20
> more I can
> do to help answer your questions, please let me know.
>
> Blessings,
> Foster
>
>
> On 1/5/07 11:31 p, "Ralph Thomas" <ra...@gm...> wrote:
>
>> Hi list,
>>
>>   How does adobe::keyboard_t work:
>>
>>   - How do keyboard events get put in there? (On Windows I can see
>> that the top-level window puts some in, but it won't get all of them,
>> will it? On Mac I can't see anything that calls
>> keyboard_t::dispatch...)
>>   - What is underlying_handler() used for?
>>
>> Thanks,
>>  Ralph
>>
>> ---------------------------------------------------------------------=20=

>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to =20
>> share your
>> opinions on IT & business topics through brief surveys - and earn =20
>> cash
>> http://www.techsay.com/default.php?=20
>> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
> --=20
> Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><=
                =20
> Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build =20
> components
> but how to use them." -- Alexander Stepanov
> "Now we have very simple code and the meaning is perfectly clear. =20
> Drink the
> Kool-Aid" -- Sean Parent
>
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel