Re: (no subject)

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]> 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.
>
> > 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.
>
> > 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);
> };
>
> > 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.
>
> 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.
>
> Well, still mainly a matter of personal preferences...
>
> > 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?
>
> > 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?
>
> Thanks for the feeback!
>
>
>


-- 
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