Hi Quentin On 26/02/2011, at 02:53 AM, Quentin Mathé wrote:
> Sharing can be achieved in various ways imo: > - remote storage (in the sense that CoreObject is a distributed database > where the persistent core objects is a simple URL/UUID pair list from the > store viewpoint, and a remote core object can be read/write through exisiting > network protocols) > - supporting multiple users per database > - supporting to hold read-only or read/write references on core objects that > belongs to another CoreObject database (not supported but I think it's > possible to do, although I think it isn't worth the trouble) > - copying core objects between database (in Eric's Object Merging, each > version is identified by UUID, which means it's possible to reason on the > entire history of a core object even if it's a copy, and even if the core > object is moved around between two or more CoreObject databases… various > operations such branching or moving a core object between databases can be > implemented/emulated as a copy variation) Sounds alright, but much of it could be for the "next version" :-) > I fully agree, limiting sharing "objects" and not "views" between projects > seems like a good principle to ensure "things don't jump around" and the > workspace remains organized as the user has decided it. Okay, I'll restrict a view to one project i.e. they cannot be shared. Possibly they can be moved, but this allows multiple views of the same thing per project (which isn't necessarily wrong, but requires more support). > Well, it's not a concurrency problem, there are two perspectives… > > First, since we have no fine-grained memory protection model, the idea is to > leverage the coarse-grained memory protection provided by processes as much > as we can. Based on the Tag overlay section visible in > <http://jesseross.com/clients/etoile/ui/concepts/02/workspace_100.jpg> … > If all overlays runs in the same process, you can more or less end up > (depending on how much is built-in into each overlay and what they delegate > to external services) to run in the same address space: > - a "file-like" manager > - an address book > - a mail client, a calendar > - a Shelf (as a pasteboard mechanism) > - etc. > > Also if each overlay runs in its own process, you can easily switch it back > to a normal application mode where it shows a menu, without quitting the > Overlay and launching the counterpart that corresponds to a standalone > application (e.g. a Mail client). I'm not saying that's something we want to > support that or it makes sense, but it's a need that could arise I think. Ok that makes sense - I've always considered how we might achieve good memory separation for different tasks. I forgot about tag overlays, and of course, they would need to be customised based on the stuff they're displaying. They may need more general support in the UI instead of just showing an Object Manager view for them. >> We can't anyway if they are the same application, because GNUstep stops an >> application from running more than one instance of itself. > > You can run several instances of a GNUstep application by setting > NSUseRunningCopy to NO. ok. >> I didn't mean branching :-). > > I misread what you write :-) Thats ok; I wasn't specific. The information on branching was still interesting. I was running under the assumption it couldn't be done. >> I only meant making an entire copy of an object so that you could alter it >> independently and use it like a template (sort of like the Prototype design >> pattern). > > Do you mean how the UI would provide a visual hint starting that an object is > a copy or how you mark/use an object as a template? > > For using objects as templates… > What I had in mind it to have "aspect repositories" in which you can put > arbitrary objects into it organized by categories/kinds (Colors, Layouts, > Images, Shapes etc.). Because a repository would accept arbitrary objects (by > allowing new categories to be added), you could use it to organize templates > or styles. By using such a repository as a model object with EtoileUI, you > could easily materialize various UI stereotypes (that would me made available > as reusable EtoileUI layouts): > - an object palette > - a style picker/palette > - a template chooser > > To give some concrete examples… a wiget palette in a UI builder, a > color/pattern palette in a graphics editor, a document template chooser etc. > would fit into these UI stereotypes. > > Also each aspect repository would be a core object, so the changes to them > would be recorded. > > But I haven't give much thinking to how the documentation creation should > work step-by-step when you decide to start from a template rather than a > "blank page"… > > Each project could include a default aspect/template repository when created. > May be some inheritance mechanism could be needed?… For example, if you copy > a project (in the sense you use it as template), then the new project could > have its default repository set to inherit from the default repository of the > original project. In fact, it could be easier/simpler to just copy the > templates from the original project into the new project. > > I'll commit this aspect repository thing to EtoileFoundation next month. > > What's your on take on that? I'm not sure - I don't quite grasp the concept :-(. If I were to interpret what you saying, a project is to be created with a set of templates (your aspect repository) that dictate the default template for new documents in that project. You create these aspect repositories by putting copies of documents you've created into them. > And did I reply to you question or I did miss the point? I think you've successfully enumerated everything I wanted to know about this point. > > It depends, I think I wouldn't mind to have the possibility to undo these > actions :-) > Eric's Object Merging has support to record such arbitrary history > informations with "history tracks" (the background idea is to support > multiple tracks for undo/redo, rather than a single one as current apps do). > For example, in Project Demo you have a track for non-document related > changes, which records the frame changes of windows, this way you can > undo/redo a window move. ok. By the way - how do you get ProjectDemo working? I tried to compile it with XCode (I'm on 10.6), but it couldn't find the EtoileFoundation headers. Is everything I need under the branches/ericwa directory? >> Hopefully I'll get round to writing some more of these ideas soon. > I've written my last set out into a new copy of the documentation, sitting as a LaTeX file in SVN under trunk/Documentation somewhere. Thanks again Chris -------- Christopher Armstrong carmstr...@fastmail.com.au _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
