Hi Christopher, Le 1 févr. 2011 à 00:43, Christopher Armstrong a écrit :
> Hi Quentin > > Thanks for commenting so quickly. I know everyone is busy with FOSDEM > arrangements at the moment. I hoped to reply this week, but this is going to be next week I think. FOSDEM presentations have kept me more busy than I planned :-) > On Mon, 31 Jan 2011 15:03 +0100, "Quentin Mathé" <[email protected]> > wrote: >> On p. 3 >> >> - "Project A container for holding a set of views. The project remembers >> the position and stacking order of views on the screen." >> >> I'd say a project is much more than that… Projects are expected to track >> the various "elements" involved in a project (people, documents, >> discussions etc.). >> We'll probably have a COProject class as a specialized core object group >> to describe all that. Initially a simple COGroup to which all these >> elements are members of could be good enough. > > Yes I agree with this too. I don't know why I didn't put this down in > the first place, although I was trying to keep this bit simple. I should > probably expand the definition to something like. > > A project is the repository for a set of related objects, > including views, contacts, documents, discussions, music, > video, lists and other pieces. > >> - "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. 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. > > 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. 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. 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. > > 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. How a person is to distinguish between an object they share > between projects and one they "cloned" into another project I don't > know. That starts to get into the territory where you could fork the > common base of a project in the same way one branches a repository tree, > which seems too complicated to begin with for a first cut of the > architecture and difficult to support. > >> - "Service A service is a GNUstep application that displays the contents >> of documents in views on the screen. A service has one instance in the >> user’s workspace, but may be displaying multiple documents and views." >> >> This describes viewing/editing services well, but I see Étoilé Services >> as a generalization of the OpenStep service concept. >> Each service is bound to a name and one more data types. For example: >> >> 'spellchecker' bound to /path/to/a/spellchecker.bundle and public.text >> 'musicmanager' boun to /path/to/melodie.app and >> org.etoile-project.music-library >> >> The name would also have a contract which describes the inputs and ouputs >> the service must support and few other stuff probably. > > Ok, that gives me something to expand on this then. > >> >> -- >> >> On p. 5 >> >> A minor remark… Creating and Opening projects would also be possible from >> the generic Object Manager, since it can be used to instantiate, organize >> and open any kind of objects. >> >> ... >> For Closing a project, I suggest to also add a menu entry. >> > > Ok. > >> >> On p. 6 >> >> - "The user goes to the template chooser and selects a template to >> instantiate as a new document." >> >> Just a side note here… I'd love to have project templates too. This would >> come naturally if we have a COProject model class. In this way, we treat >> and manage "projects" as "documents" and the whole screen is really a >> "compound document". I think this makes things simpler and more >> consistent. At the UI level and in the user-oriented terminology we use, >> however we might not want to insist too much on stating that "projects" >> are "documents". >> > Yes I guess this could work. A project could dictate a set of document > templates, or even the default layout of a new document of a particular > type created within that project. See my notes below. > > >> >> What you don't discuss, but seems really important to me is to have per >> project defaults/preferences. With that, projects would be much more than >> persistent workspaces, they can be customized to better fit the project >> activities. > > Actually my idea behind templates and the arrangement of auxilliary > windows for a document was to store the preferences for each document, > not at the project level. I guess we could have three to four levels of > customisation of auxilliary windows (in decreasing order of > prioritisation) > > Document Level > > Document Template Level > > Project Level > > Project Template Level > > 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). > > This would expand the definition of a view to: > > A view is the visual representation of an object in the project. > > Cheers > Chris > -- > Christopher Armstrong > carmstrong ^^AT^ fastmail dOT com /Dot/ au > > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
