Hi Quentin Sorry for the late reply.
Basically I agree with all of your counterpoints. Some more notes: 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, 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. > 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. >>> - "Project Overlay A window that is temporarily displayed over the top of >>> the workspace to allow the user the select a view to open." >>> >>> I'm not sure to understand what this is precisely. Would that be >>> specialized Object Manager for projects in the same way than Mélodie is a >>> specialized Object Manager for music? >>> The way I was envisionning project management and opening was to use the >>> generic Object Manager. Given that projects are core objects then they >>> can browsed, organized and opened exactly as other core objects. That >>> seems good enough to begin with, although a specialized Object Manager in >>> some sort of window overlay might worth to explore. >> >> I was referring to the idea of the project overlay given on the website >> in the walkthrough with screenshots. > > Ah ok, I forgot about this document. Based on Jesse's description, the > Project Overlay is a specialized Object Manager for Projects. > The description I'm referring to is: "The Project Overlay shows all the > non-active documents within the Project, and also includes a bottom bar." > You could imagine to replace the UI described above with something that gives > me a better overview of the project (contacts, bookmarks, recent work in this > project, todo etc.) though. In the long run, perhaps this UI should be > customizable to let he user decides what content is visible or summarized > about the project. > > Just make things clearer, here are some extra notes: > > An Overlay (the bottom bar + the semi-transparent area above which presents > various elements) is equal to a full-screen Object Manager minus its menu bar. > > An Object Manager not in full-screen mode and with a menu bar would look like > this: http://jesseross.com/clients/etoile/ui/concepts/03/workspace_100.jpg > (in this screenshot, it's generic Object Manager that is presented) > > But ultimately both uses the same code (the Overlay presentation might want > to use a custom UI though). From an implementation perspective, to get an > Overlay you could just launch an Object Manager app bundle with a custom > default stating run it as an Overlay. > In some cases, we might decide that an Object Manager will always be run in > Overlay mode and as such doesn't need a window-based UI and a menu bar. e.g. > the Shelf Overlay. Yep, sounds good. > 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). We can't anyway if they are the same application, because GNUstep stops an application from running more than one instance of itself. >> I guess if there was a generic >> object manager, which would probably just be a service or a view >> available from the project manager service, it would be the Object >> Manager set to show just the views in the project in their visual >> representation. > > By generic Object Manager, I mean something that lets you browse all the core > objects organized into groups/tags with a file manager-like UI as visible in > http://jesseross.com/clients/etoile/ui/concepts/03/workspace_100.jpg > > What you seem to describe by "Object Manager set to show just the views in > the project in their visual representation" is rather a specialized Object > Manager similar to Exposé on Mac OS X. Or am I missing something? Okay, I have been looking for something like that for a while. It helps to clarify a lot of ideas. > >> I've sort of had this discussion with David and thought a bit about this >> myself. I think its important we separate the ideas, so that views are a >> type of object, but they are also just one organisation of the visual >> layout of an object. For example, you may have a contact which is show >> in many views, so there will be a contact object and the many view >> objects. > > Makes sense. > >> To the user, its probably best to show the views in the >> overlay, because thats what they'll remember when they last opened the >> contact in those views, but just show a generic object representation in >> the Object Manager. > > Yes, especially important if the object is opened in several projects at the > same time. > >> Its probably not even a good idea to mix the view >> objects and the more model objects in the Object Manager, otherwise a >> user won't logically understand the difference between them or even be >> able to distinguish them. > > Yes, that's very important. > Well, we can decide to persist each view geometry as a core object, but this > should remain an implementation detail and we should keep these core objects > hidden e.g. when the user browses the entire core object graph. > >> But expanding on this again, objects may not sort of be tied to just one >> project. I would certainly want my contacts (for example) to be >> available in many projects. I guess its the idea of a workspace, that >> has projects and all my "objects" (whatever that means), and I can link >> in or bring into my projects various objects and share them between >> projects. > > Yes, if you cannot share objects, the project concept is kinda useless imo. > That's related to what I wrote at the beginning, where I outlined that a > project is not a repository. > >> 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 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). >> 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. I could imagine having a history of something like the volume control or desktop background could be a little too much information. Hopefully I'll get round to writing some more of these ideas soon. Cheers Chris -------- Christopher Armstrong carmstr...@fastmail.com.au _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
