On Mon, 2005-03-07 at 17:52 +0100, Quentin Mathé wrote: > Le 4 mars 05, à 23:59, Nicolas Roard a écrit : > > >> - First step would be to add basic document orientation without > >> changing GNUstep applications UI interaction model. > > > > Wouldn't it be taking care of by NSDocument ? > > Partially, NSDocument is just a facility to manage documents but he > hasn't be written with document orientation in mind, however we could > probably extend it with" rich document bundle support" to add such > semantic without extra work on developers side. >
No it was not, as you state. To make document oriented applications reality, we need to move focus from NSApplication to NSDocument as a core environment class. <snip> > hmm no, document orientation involves probably to change UI (a bit like > what IBM/Apple tried to do with OpenDoc) in order to really get > benefits of the paradigm in my opinion. > > Possible UI evolution : > - document components layout > - document components interaction (may be ?) > - document window owner changed on the fly when you switch application > context (initially we could start with a "Document editor" application, > may be the Workspace, which permits to layout your components, and when > you double-click on a component it is opened in whatever default editor > application bound to this component…) > - etc. > I will stop on the last bullet - the document window. Let me explain: Current state: - user launches an "application" - user uses the application to "create a document" - user uses the application to "open a document" - Edit, save, close - Use another application to edit different document - Use "import" feature to include product of one application into the another. How it should be in a document based environment: - user "creates a document container" (from the environment) - user adds "document parts" to the container - user uses "document part editors" to edit components of the document - "part editors" can save the parts "document part" can be a text, diagram, spreadsheet,... and it is edited in a window. Difference is, that the window is not owned by an application, but by an environment or document manager. To make transition easier say we keep applications. We only change them to editors of those "document parts". From the beginning, only a kind of "binder" application would be necessary. And this is important: to move from application focused environment to the document focused environment we should go step-by-step to allow users adapt to the new paradigm. Only then it will be accepted. I would rather keep away from hanging the menu depending on selected object, like it is done by OLE. This will bring only confusion, as users are focused on the application. You will break their thoughts and make them ask "where i am?" Context (document) sensitive changes can be done only when it is clear that the environment is document oriented and that there are no applications, but document part editors. > > yes. That part is not handled by NSDatalink. Personally I think that > > such a OLE-like technology it's not _that_ useful for having a > > document-based UI -- NSDatalink or something similar will work > > reasonably the same, yet is magnitude simpler to have. > > But of course, an OLE-like architecture (even better hopefully ;-) > > also has its place and would be nice to have. It would be interesting > > to have a look to KParts too.. > > Well, such components idea is only partially related to document > orientation : it would just improves the felling you get by the fact > your won't be using monolithic applications, then your workflow would > be way more less bound to applications (I mean the application concept > and the packaged features of your applications). > With process and application oriented operating environments you will gain a little with this component architecture - you can not easily compose those components to cooperate on a single task, then decompose them. But what can you do currently is to have many small applications that can edit pieces of a document. Call those applications "components" :) <snip> Again, if you decide to go in the directon of document orientation, then go there slowly and try to use anything that is currently available (like start by breaking applications and making them cooperate). Regards, Stefan Urbanek p.s.: I have related problem with StepTalk, where i wanted to finally create "the application glue". It can be solved by a helper tool that will create a separate process holding current state of a scripting environment. Process = object memory = scripting environment = user task = user context = user thoughts. Similar attitude can be used in document oriented environment, i think. -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
