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