Hi Quentin Thanks for commenting so quickly. I know everyone is busy with FOSDEM arrangements at the moment.
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
