Re: (no subject)

On 05/14/2012 08:34 AM, Jorrit Tyberghein wrote:
> Shouldn't this discussion go on crystal-develop? May also be 
> interesting to Andrei :-)
>
> Greetings,
>
> On Sun, May 13, 2012 at 4:01 PM, Christian Van Brussel 
> <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     > Hehe quite the list Christian :)
>
>     Actually, I thought that the cseditor would still need a lot of
>     work, but
>     it seems that you already implemented almost everything :)
>
>     > not entirely sure what you mean with contexts/plugins here, but i'm
>     > assuming its just different configurations of panels/views?
>
>     I meant having possibly a different iContext and a different set of
>     iPanel/iHeader/iSpace per top-level frame.
>
>     Say for example that the application wants to split its editor in
>     several
>     sub-editors to be run in different top-level frames, this would allow
>     that.
>
The latter is already possible, with the exception being the lack of 
multiple iContexts.
>
>
>     > As for the context per frame, you won't be able to share for example
>     > selected objects that way (updating 3d view and tree view if
>     they're on
>     > separate screens and in different windows) is that what we want?
>
>     Since the user sets manually the iContext to the top-level frame,
>     he can
>     decide whether or not this iContext would be shared between top-level
>     frames. So yes, this would still be possible to share eg the
>     selection of
>     objects across frames.
>
>     That's basically adding the possiblity to have a different context per
>     top-level frame. This would allow for example to edit two different
>     objects simultaneously, without any interference between the two
>     sessions.
>
>     > The iContext was modeled after Blender's context api somewhat,
>     allowing
>     > easy access to the current state of the editor
>     > (like selected objects, active object, camera, ...)
>
>     My point of view was that the type of the selected objects is probably
>     application specific, maybe even the possibility to select objects.
>
>     Same goes for the camera management.
>
>     > Not sure if user-set contexts is viable in a plugin-based system
>     though,
>     > you'd have to change the context code every time you
>     > add a plugin(which uses shared state).
>
>     Instead of having to change the context code every time you add a
>     plugin,
>     isn't it instead each time that you add a plugin that uses a
>     feature not
>     present in your current context?
>
>     So each editor plugin would have some dependency on some feature
>     of the
>     iContext.
>
>     I see two possibilities to manage this:
>     - each feature is put in a different iContextXXX interface, and we add
>     tools to help creating iContext objects that would implement the
>     needed
>     interfaces. That would still be a quite tricky part of the use of the
>     cseditor framework.
>     - we switch to an iModifiable in order to represent the iContext. That
>     way, it would become possible to have each editor plugins
>     declaring their
>     dependency to the context, and have some tool able to create
>     automatically
>     a context from the list of dependencies.
>
Well plugins can already specify dependencies, if we make the context a 
plugin as well it
can be specified in the plugin's .csplugin file. (I'm already doing some 
custom handling of these files to control panel/header behaviour)
>
>
>     > Should we have a GlobalContext and FrameContext for different
>     kinds of
>     > data?
>
>     Well, that's a third possibility: have the iContext able to hold user
>     specific data buffers/iBase pointers.
>
>     What about that:
>
>     struct iContext : public virtual iBase
>     {
>       /// To be called by the plugins at registration time. data is the
>     default value.
>       /// It has no effect if the ID is already registered
>       void RegisterData (csStringID id, iBase* data);
>
>       /// Will fire an event for context change
>       void SetData (csStringID id, iBase* data);
>
>       /// Get a specific context data
>       iBase* GetData (csStringID id);
>
>       /// In order to bind some functor to a given data
>       wxEvtHandler* GetEventHandler (csStringID id);
>     };
>
Although very flexible, it's rather prone to runtime errors, wrong 
csStringID, wrong cast and poof goes the editor.
So perhaps meet somewhere in the middle of all this; iContextXXX as 
favored for stable features and the flexible context to fill up the gaps 
and to prototype with (commonly used csStringIDs migrated to iContextXXXs)
>
>
>     > rather a namespace than a pre/suffix...
>
>     Hehe, I guess that here we are touching to personal preferences ;)
>
>     The reason why I prefer a prefix is that I suppose that the cseditor
>     namespace wouldn't hold only the core editor interfaces/classes
>     but also
>     some application specific ones, tools etc. An iEditor prefix would
>     allow
>     to see clearly the ones that are part or not of the core framework.
>
well cs:editor:framework:: and cs:editor:tools:: or so then :)
>
>
>     Also, the class list generated by doxygen doesn't use the
>     namespaces when
>     sorting the names of the classes, having a common prefix have the
>     effect
>     to pull all related classes together.
>
Anyone know how to change this doxygen behaviour? :)
>
>
>     Well, still mainly a matter of personal preferences...
>
CS has been cleaning code and all new features have been put in 
namespaces and such(although mostly dropping cs prefix)
so yeah i don't know, using prefixes seems like taking a step back (I've 
been coding a lot of java for work lately so maybe i should STFU about C 
coding styles and organizing :P )
>
>
>     > Don't like the idea of merging them though, then you get
>     something like
>     > iEngine, which is a gigantic abomination :)
>     > Can we comprise with having functions like GetActionManager() in the
>     > iEditor interface? (that way they don't get lost in the object
>     registry,
>     > but the interfaces are still functionally separate)
>
>     Huhu, good point for the iEngine ;)
>
>     But here for the iEditor, aren't we going too far and creating another
>     type of Frankenstein monstruosity, ie having an iEditor with only
>     GetXXXXManager() methods?
>
>     Let's look at the iEditor's list of methods once removed all the
>     application specific stuff we talked about:
>
>      virtual wxFrame* GetFrame () = 0;
>      virtual iMenuBar* GetMenuBar () const = 0;
>      virtual iOperatorManager* GetOperatorManager () const = 0;
>      virtual iSpaceManager* GetSpaceManager () const = 0;
>      virtual iProgressMeter* GetProgressMeter () const = 0;
>
>     Mmm, nothing excentric.
>     Or maybe, we remove the methods GetOperatorManager() and
>     GetSpaceManager()
>     and we let the iEditor plugin implement also those interfaces?
>
Well imho the reason for all those functions is to avoid 
scfqueryinterface calls, so it's easier for new people to get to 
everything. If you'd implement the interfaces in the editor plugin you'd 
have to query that object for the different interfaces again defeating 
the purpose of this 'access'-object. Unless you mean just moving those 
interface functions to the iEditor interface, but then my objection 
would be; what's stopping other people from doing the same with their 
stuff? (iow we'll end up with another iEngine :) )

But in the end it's personal preference again, so who ever does the 
actual coding gets to decide :)
>
>
>     > Never got that far with the new blenderish stuff :s (had some
>     older code
>     > for the aui layout saving though)
>     > iEditorComponent sounds good!
>
>     OK, I'll add that for the background editor plugins:
>
>     struct iEditorComponent : public virtual iBase
>     {
>      virtual void Save (iDocumentNode* node) const = 0;
>      virtual bool Load (iDocumentNode* node) = 0;
>      virtual void Update () = 0;
>     };
>
>     plus a method in iSpaceManager: RegisterComponent (const char* name);
>
>     The iPanel, iSpace and iSpaceManager would also receive the additional
>     methods Save/Load().
>
>     And the iSpace would also receive an Update() method in order to
>     replace
>     the pump (the other interfaces wouldn't need it as you explained).
>
>     > wxwidget's 2.9 binding is a lot like boost:bind, since i used
>     boost:bind
>     > in the DAMN plugin, i'm kinda all for that system :)
>
>     OK, let's go for bind's :)
>
>     > I was thinking it could allow for some quick expansion of the
>     layout,
>     > eg. show an extra button or so in _existing_ panels/headers
>     > without you having to write a custom version of that panel/header
>     > (for example show a DAMN menu entry in the panel header if the
>     plugin is
>     > loaded)
>     > But it's currently unused.
>
>     Then I'll probably remove it from the current API, and we'll add that
>     later whenever we need it. OK?
>
Yeah that's fine.
>
>
>     Thanks for the feeback!
>
>
>
You're welcome.
>
>
> -- 
> Project Manager of Crystal Space (http://www.crystalspace3d.org)
> and CEL (http://cel.crystalspace3d.org)
> Support Crystal Space. Donate at 
> https://sourceforge.net/donate/index.php?group_id=649
> Personal page: http://users.telenet.be/jorritTyberghein/
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Crystal-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crystal-develop

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop