2009/2/12 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> Well, a mouse event is a mouse event, you can't treat it differently. :)
>
> Oh, but you can! Just look at #swapMouseButtons. More interestingly along
> these lines is that there are synthesized events (mouse enter/leave for
> example) that all UI frameworks have but that aren't part of the "kernel"
> event types. So in order to make this fit "your framework" you'd have to
> munge with the kernel types. That's why I'm saying that unless you are
> insisting on a single framework there will always be differences in how the
> event structures are modeled and a one-size-fits-all-approach isn't very
> helpful.

A framework free to interpret events as it likes to. I don't see a
conflict here.
Imagine two host windows, each running own UI framework. One is
swapping buttons, other don't.
Both frameworks receiving events from a single source (event sensor),
and its not an event sensor's job to interpret events.
Its job is to represent them with nice objects, which have a nice
protocol, so these frameworks will work with events instead of trying
to decipher raw events originated from VM.

>
>> This is why i thinking that even wrapping event buffer by specialized
>> event subclass could be helpful.
>> I.e.
>>
>> event := KernelMouseEvent from: eventBuffer.
>>
>> so, then you can write:
>>
>> event isMouseEvent
>> instead of:
>> (eventBuffer at: 1) = EventTypeMouse
>>
>> The idea is to promote most basic event types from Morphic-Events to
>> Kernel-Events.
>> So then another framework could reuse them as a base, without poking
>> in raw event buffer.
>
> Understood. Yes, this could be helpful for some purposes. The reason why I
> don't like it is that since a UI framework will require its own events to
> begin with (see above) why clutter the kernel with artificial distinctions
> about event types that the kernel really doesn't care about? What good would
> it do Morphic or MVC or Tweak if you were to add these events? Given the
> tiny interface between the sensor and its clients[*] it seems like a
> complication with very little benefit to me.
>

Let me describe a little how i see it.
An event sensor having a little logic in itself: it simply stands a an
interface which connects a low-level VM with a language side.
Once event sensor receiving an event in a raw buffer, it should encode
it into an instance of appropriate event class.

/* from sq.h */
#define EventTypeNone		0
#define EventTypeMouse		1
#define EventTypeKeyboard	2
#define EventTypeDragDropFiles	3
#define EventTypeMenu		4
#define EventTypeWindow		5

EventTypeClasses := #(NotAnEvent MouseEvent KeyboardEvent
DragDropEvent MenuEvent WindowEvent).
event := (EventTypeClasses at: (eventBuffer at: 1)) from: eventBuffer.

Now, an event consumer could do:

event handleWith: handler.

and handle receiving a nice #handleMouseEvent: , #handleMenuEvent: etc.
no need to test event type anymore , anywhere.

See, how easily this thing can be extended:

#define EventTypeMyUberEvent 6

then change EventTypeClasses
then add a #handleAppropriateEventType: in your framework. Done.


> [*] Never mind all the abuses of Sensor.
>
>> It is also useful in a way, that in case if we need to alter event
>> handling logic in future VM, then we will have a much less places to
>> visit in image to adopt these changes.
>
> That's a much better argument and one of the few I'd be willing to accept
> from what has been said so far. The other one is actually documentation - it
> can be quite difficult to wade through tons of constants trying to figure
> out which bit corresponds to what field.
>
>> The custom framework could always adopt these events for own need , by
>> encapsulating them with own event types/whatever.
>>
>> I just think that events deserve to be encapsulated into a
>> well-defined objects at kernel level.
>> In current state it looks like, that if you have a socket primitives,
>> but have no Socket class which enables to work with them in a
>> meaningful way, so each user of sockets needs to deal with primitives
>> directly and write own data handling logic :)
>
> This on the other hand is not a very good argument since there is only a
> single user of socket primitives (Socket) and there aren't multiple
> competing types of Sockets. Following this logic you might as well create
> Morphic events right in Sensor.
>
It may be a bad example. My point is, that we should enforce a good
practice early, to hide unnecessary implementation complexity details
from the end user.

> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.