> > However, it is important that you understand that *ALL* events are
> > processed at their terminators in Javascript. It is not
> possible for
> > your native code to ask AWS2's manager to forward events to it.
> > Technically this could be added in some cases, but it is
> not something
> > that I will add. Nor is it possible to listen for any
> given event via
> > AWS2. The manager understands mouse and keyboard events,
> period. It
> > provides access to mouse and keyboard events, period. All other
> > events originate from, and are delivered through, Javascript.
>
> So on an event (lets say "button X pressed") there will
> always be the chain CS mouse event -> AWS2 manager ->
> (internal dispatch in AWS2?) -> SpiderMonkey
> -> JS-script (even if just a tiny bit) -> AWS2 -> my notification ->
> -> (internal
> dispatch in my game library) -> my scripting interface
>
> Sounds both very efficient and very nice to debug :)
Yes, now let me explain why:
1. CS receives events from the OS.
2. AWS2 receives events from CS. **IMPORTANT** Raw events are USELESS to
an app.
3. AWS2's manager determines if it is a keystroke or a mouse event.
4. If it's a keystroke it is forwarded to whatever widget has keyboard
focus.
5. If it's a mouse event, the manager determines who owns the mouse (ie.
Is CaptureMouse() set? If not, is the mouse inside any given widget?)
6. At this point, the CS event is translated into a call to the
appropriate function for the given widget. If the widget supports the
given function, then it is called with the appropriate arguments.
7. From the AWS2 plugin's standpoint, the chain of event passing ends
here. HOWEVER:
8. The event function called may cause some state in the widget to
finalize, thus causing another event to fire. This event occurs
**strictly** inside the script portion of the code. There is no native
code interaction, except in the case where the event propagates back to
a user-defined notification object. In any case, the manager knows
NOTHING of this new event firing.
It is very efficient, as efficient as any other space partitioning
algorithm.
It is absolutely simple to debug because:
(1) Event propagation happens in two places:
(a) the manager's HandleEvent, and
(b) the widget's HandleEvent dispatcher.
(2) Events that you don't want to handle are *never* executed. Not
even some stub class that just returns.
(3) There are no side-effects to not handling an event.
(4) You don't have to worry about propagating an event back up an
inheritance chain, or emulating behavior that some parent expects.
> > I could technically provide a way to have AWS2 forward unused or
> > unknown events to the app, but that is silly since AWS2 *receives*
> > events from your app. If your app has it's own little
> events here and
> > there, then that's where you should handle them. Why does
> AWS2 need
> > to know about them?
> I am not talking about internal events in my application, but
> rather events _generated_ by AWS2 such as "button X pressed"
I felt that I explained that rather fully. The event gets back to your
code without you really having to write any Javascript.
> >
> > All of that being said, if you hate JS and you don't want
> to use it,
> > then AWS2 is not really for you. All of the labor-saving features,
> > the flexibility, and power of expression come from it's
> binding with JS.
> > I'm sorry that you don't like JS, but there are plenty of
> people who
> > don't like whatever scripting platform I might possibly choose.
> My main concern here is generality and uniforimty within CS.
>
> We already have a very general and well-working system for
> event dispatch, but as it seems AWS2 won't even consider
> using that.
For many good reasons, chief among which is that it is NOT the right
tool for the job. It works great for propagating certain events from CS
to plugins, but it requires you to have compile-time knowledge of all
the possible events you might want.
Another good reason is that, again IMHO, programmers should not
generally be in charge of interfaces. Especially game interfaces. An
artist shouldn't be required to compile and change complex code. The
scripting system is a compromise that allows the artist to use a
well-known (Javascript/XML) interface definition combination to define
and manipulate the appearance. You can provide event sinks for them to
plug stuff into, and they never have to compile anything. All they need
is the app.
Having events propagate back through the event handling framework is not
"The Right Thing" to do, IMHO.
> Same thing about scripting interface (they need
> to be worked on, sure, but that is also done by other
> people).
CS's scripting interface was inappropriate for AWS2 internally. I could
certainly use the CS scripting objects for the native/script interface
if that is preferable to everyone. I don't personally care. However,
the current script interfaces are not as simple and straightforward as
the method that exists in AWS2 at the moment. I was just trying to make
things easier. I don't care how technically superior some code is, if
you don't make it easy at the level where people need to interact with
it, people will avoid it.
> The more plugins that go and do stuff their own way
> the harder it becomes to learn, debug, maintain and document.
I understand and empathize with this, but consider too that if the
"CS-way" of doing things was simpler, or obvious, we wouldn't do it
ourselves. I'm not blaming anyone, and I'm sure everyone realizes that
the documentation is not as complete as it could be, nor are all the
interfaces as polished as they could be. I spend *a lot* of time
hunting through the API docs trying to make sense of, what I'm sure, was
obvious to the author.
> Also considering that CS is a SDK the main thing should not
> be how to make it as simple as possible in CS itself, but
> rather make it easy for the client (the
> user) to get the information he needs into his framework (be
> it CEL or any other system that you definitly will have on top anyhow)
My point exactly. Wherever the joint point is for the SDK user and the
library, that interface should be as simple as possible. If you have a
suggestion to simplify that, I have not qualms implementing it.
(Assuming that it really does implement it.)
-={C}=-
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
