Take a look at my Dynacore.. it contains the following: DynObject - contains child-parent relation handling (add/remove/delete) DynLayer - contains only Layer handling (move,size,create,etc..) DynDocument - contains only document handling. Events - are attached to DynObject, and making events available to all sub-classes (DynLayer, DynDocument, widets, managers, etc..) Which is, as far as I can tell, what you'r talking about. I'm not sure about your "application" object, if you mean a basic application-framework I think that should not be part of the DynAPI (it's an API) layout managing should be simpler using seperate managers for it (widget - like objects) That could be inheriting (there we have it again :) from the DynObject, automatically having the add/delete/remove functionality needed by other widgets. But again, I don't see the point of "starting" a next generation of this API.. The differences between DynAPI1 and DynAPI2 is huge, it's better coded, includes the main feature "on-the-fly" creation of layers and a kick-ass event system. What would be the extra functionality the "next generation" could supply us with? and don't look at the way you code it.. if you want another coding style in the DynAPI start your own distribution (an idea that works :-) it would add nothing extra to the end-users (site-developers.. the creative rock throwing people). I actually prefer the idea of getting a DynBuilder type thing working instead of a new DynAPI generation, this would give such a boost to the user-base of the DynAPI, and might actually make the DynAPI competing with things as Flash. Let's just finish this one up getting it to run cross-browser (and if possible cross-platform) and make it more user-friendly (widgets,editor, etc) Pascal Bestebroer ([EMAIL PROTECTED]) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]Namens Eytan > Heidingsfeld > Verzonden: dinsdag 30 januari 2001 9:32 > Aan: [EMAIL PROTECTED] > Onderwerp: [Dynapi-Dev] Next Generation part II > > > Ok, so now we have all discussed and recommended and finished throwing > stones. After we all got in-depth about OO and prototypes and > classes where > are we going. My recommendation of how to act is as such: > * Create a DynLayer(mayber change it's name) that is totally > seprate and > stand alone. It includes only methods to affect the layer and > events that > are triggered from the outside(mouse and keyboard events). > * Create the basic objects: Application, Object, Component > Application: > Manages the DynLayers focus and events > Object: > Basic object with create and destroy > Component: > Basic object with dynlayer. > > I'd be glad to change the model if anyone has new and improved ideas. > > Now except for the actual model I want to know if we have > enough ppl who > want a next generation to continue. > > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dynapi-dev
