Hello, Thank you very much Quentin. I updated and the application is running finally. I'll continue investigating the other areas for further integrations, especially COObject.
Best, Al Chemyth. On Tue, May 15, 2012 at 12:34 AM, Quentin Mathé <[email protected]> wrote: > Le 11 mai 2012 à 17:13, Al Chemyth a écrit : > > > I wonder if it makes any sense to distributing ETEvent without EtoileUI, > The current code is rerouting NSEvent in a terrible way. The goal is to > route events from 2D views into AP3's 3D spaces. It buries a 3D context > which provides eye location and frustum for each view by replacing > NSView.event_context with the context. The better approach could be > generating and rerouting non-view events into the 3D spaces, by > implementing another backend for ETEvent, as far as I understand the > current design decision. > > ETEvent is designed to be an abstract, which it isn't currently. The plan > is to introduce ETAppKitEvent as a concrete subclass (I understand that's > what you mean by another backend for ETEvent). For few other classes such > as ETWindowItem, similar abstract vs concrete class changes are planned. > > For example, ETEventProcessor already uses this design, you have a > concrete subclass called ETAppKitEventProcessor. > > The long term plan is to reduce EtoileUI dependencies to a small AppKit > subset (the AppKit would just provide the drawing primitives such as > NSFont, NSImage etc. as CoreGraphics/Opal does in a way), and EtoileUI > would support additional widget backends e.g. GTK, Android etc. For > example, this would involve various concrete classes such as ETGTKEvent, > ETGTKEventProcessor, ETGTKWindowItem. > > But additional widget backends is a really low-priority for me, so I > haven't worked on it, I just tried to take in account it in account during > the design. > > So in your case you can imagine to subclass ETAppKitEventProcessor… or > subclass ETEventProcessor and use this new subclass as a decorator on the > ETAppKitEventProcessor. Feel free to improve the API. > > We can then have a method such as +[ETEventProcessor eventClass] or > +eventClassForTarget: (id)aView (could be a good delegate method too) which > would return ETAP3Event when necessary. > That's just some random ideas that might require to be seriously rethought > :) > > Cheers, > Quentin. > > > > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss >
_______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
