Hi Christopher, Le 24 févr. 2011 à 11:32, Christopher Armstrong a écrit :
> On 19/02/2011, at 06:48 AM, Quentin Mathé wrote: > >> Sounds much better, except a project isn't really a repository (if we >> consider a repository as something that sandboxes/encloses the objects it >> contains or implement a persistency model). >> A project doesn't version the objects it appears to contain. These objects >> (contact, document etc.) are in charge of versioning themselves and don't >> belong to the project, although the project references them. >> Any core object can be shared between multiple projects. > > I didn't mean repository in the sense of a closed container, but more of as a > grouping. "repository" was a bad choice of words. The repository is the > entire CoreObject database for a user, ok, I wasn't sure what you had in mind :-) > though the idea of linking in objects from other repositories seems nice > (like sharing objects over a network). I guess thats fairly "case by case" > though. 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) >> As a side note and from a usability perspective, whether or not core objects >> can be opened in several projects at the same time is still an open >> question. I'm tempted to say having a core object opened in multiple >> projects is just fine. For example, editing the same contact in two projects >> running in parallel makes totally sense (e.g. suppose you are working with >> this person on two separate work projects). It might be less desirable to >> support this ability on a compound document… but given CoreObject will push >> the changes back to all existing instances in memory, to keep things >> consistent in regard to the contact example I just gave, allowing the user >> to open a compound document in distinct projects seems reasonable. > > I agree with this too, but I'm worried that we may have to prevent the > sharing of "views", and only allow sharing objects. The reason being is that > if a view is adjusted in one project, but is shared across two or more, the > changes to the view will be reflected in all the other projects that share > that view including the position and size on screen. Furthermore, if the > object is shared in other projects, but not the same view, this could be > further confusing. Conversely, we could restrict objects to one view, but > that isn't useful and is also a bit limiting. 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. >> Each Overlay probably runs in its own process unlike a normal Object Manager >> instance which present multiples windows. Not sure about that… but just to >> bring the point into the discussion. > > I don't know why we want different processes. Might help if we need many > threads (but then we can just use threads). 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. > 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. >>> How a person is to distinguish between an object they share >>> between projects and one they "cloned" into another project I don't >>> know. >> >> Because a project isn't expected to contain or own core objects, you can >> share core objects freely without copying/cloning them. >> However that doesn't prevent to make a copy or a start a new branch for a >> particular core object… and only uses this copy or branch when working >> within a precise project. >> >> The branch case would need some special support to track the core objects >> which have branches explicitly associated with one or more projects. In >> reaction to 'Open Document', the editing would restart in the right branch. >> This branching use case might prove to be not so useful in the end… >> Basically I think we should support branching as a advanced user ability, >> but not bother too much with integrating branching deeply into the UI (as >> the project-based branch example I gave). My opinion is the branch concept >> is hard to grasp, and managing branches is hard conceptually too, even if we >> eliminate all the usability issues that plague current revision control >> system. > > I didn't mean branching :-). I misread what you write :-) > 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? And did I reply to you question or I did miss the point? >>> Personally, I think the first two are good enough. A document template >>> is just a copy of a document, and if a document includes the layout of >>> auxilliary windows, then you logically just customise the display/layout >>> of those windows after creating a document (possibly even using the new >>> customisation for a new template). >> >> I don't have a counter-example right now, so I agree :-) >> I'll try to think about various customization use cases to see whether >> Document Template preferences are enough or not. >> >> Some project preferences would be good though e.g. sound volume, desktop >> background. If we can support: >> - custom UI per project with template-based preferences >> - system-wide preferences per project >> then having an extra NSUserDefaults domain to allow customizing app >> preferences per project is probably not needed. > > Sounds correct. Not sure if it should be "preferences" in the traditional > sense, or an object with history. Probably depends on the use case. Agreed. > I could imagine having a history of something like the volume control or > desktop background could be a little too much information. 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. > Hopefully I'll get round to writing some more of these ideas soon. ok cool :-) Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
