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]
