Excuse me for not replying to emails concerning the document architecture now. Why? I need to think :o) Thank you very much for your for your feedback. I will come back with some diagrams soon, I hope.
Stefan Urbanek On Tue, 2005-03-08 at 21:25 +0100, Quentin Mathé wrote: > Le 7 mars 05, à 21:30, Stefan Urbanek a écrit : > > > On Mon, 2005-03-07 at 17:52 +0100, Quentin Mathé wrote: > > > >> 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. > > True, but we need to think now how it should extend step by step > NSDocument (API and code level). > > >> 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) > > Yes, but do you think the "environment to create document containers" > should be the Workspace or a special "application" ? > > > - user adds "document parts" to the container > > - user uses "document part editors" to edit components of the document > > - "part editors" can save the parts > > The last point is not simple to solve, especially until we have thin > applications with their core implementation separated in a framework, > no ? > > > "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. > > How do you think it is possible to do that, by keeping UI (menus > especially) tailored to the current editor context ? > Especially when you take in account we haven't a deployment OS with a > single address space and we should take in account DO performance which > can be problematic with "heavy data" oriented applications (Image > editor to take an example). > Do you mean "Document manager" is just a display and eventually layout > process ? > > I think we could improve this in the future, by discarding "Document > manager" and keeping the document window owned by the editor > application and having a popup menu in the top of the window where you > can choose "Applications filter" to view the document. Then when you > would change the current "Applications filter", with an AppKit hack we > would migrate the document window in another application process (the > window is technically speaking owned by the window manager) and > redisplay the content in accordance with the new application (using > NSDataLink & co to display the document parts). > > Few "unrealistic" proposals for more long term plan… To take in account > the idea to have applications broken in set of components, and the fact > it would be nice to share documents content directly in memory when > possible (hmm for example, to avoid reloading a whole big image when > you move to a new application context)… Anyway this last point is > probably too much work (on model/data protocols etc.) and way too > complicated for not so many benefits with currents computer systems. > There are various possible models : > 1) For each document : > - we have a separate process (document window owner) > - we load/unload applications bundles in this process on the fly > > 2) For each document : > - we have a separate process (document window owner) > - we launch/terminate applications in separate processes on the fly > - we have a connection like DO, StepTalk etc. (with a "data source" > protocol) to allow transparent talk between documents processes and > applications processes, and especially having applications nib UI > loaded in document process > > 3) For each document : > - we have background model/data process > - we have applications in separate processes where documents are > opened (the applications are document window owner) > (- we can move document window to other applications with > "Applications filter" popup menu) > > Theses three solutions (not really true for 3) would permit better > document orientation (from programming code point), moreover to produce > the illusion documents could be opened and owned by Workspace (or other > your specific application choices) and "moved" cleanly technically > speaking in the application context you want to use for editing or > viewing. > > Theses various solutions would allow to have "opened stored objects" > like folder windows, document windows managed in a similar way with > their own process. > Anyway there is already many work to do to achieve the first goals you > outlined. > > The conclusion… > The main problem is the outdated conception of today OS with separated > address spaces, no objects semantic support, no real persistency > mechanism and poor distributed use support. The ideas you describe in > <http://stefan.agentfarms.net/IMG/pdf/OgmaSVOC-2.pdf> with domain > objects which are door to enter in pool of objects would make this > stuff far more easier, but we are not not going to write yet another OS > now ;-) > Then we could have to think about smart workarounds to implement such > possibilities, but first steps should be doable without too much "brain > fighting". > > > 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. > > What do you mean precisely when you talk about "binder" application, a > "Document manager" application where you layout and eventually connect > your documents parts ? > In this case, NSDataLink would allow this, we would double-click the > document part we want to edit in order to launch a separate editor > application (like classic GNUstep applications) where the part could be > edited like traditional document. > > > 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. > > Even when full document oriented UI implementation is achieved, I'm > still not sure "document context" sensitive changes are really the > thing to do. > … otherwise NSDataLink provides a class with linked parts inspector > iirc, that would avoid to shuffle the menu like OLE. > If it's not the case it would be probably interesting to add such > "Quick inspection" feature. > > > 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" :) > > True, thin applications with framework based backends combined with > NSDataLink stuff and some NSDocument improvements would permit to > implement this idea. > > > 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). > > That's what we will try to do, at least when current basic stuff will > compile and work. > > > 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. > > I have read your presentation where you talked about StepTalk to glue > applications in your workflow… but I hadn't any ideas on how > collaboration between objects would be established in what you > proposed, then the things are a bit more clear now. > However I don't precisely understand what you mean with this equation : > Process = object memory = scripting environment = user task = user > context = user thoughts. > > Quentin. > > -- > Quentin Mathé > [EMAIL PROTECTED] > > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev > -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
