Le 7 mars 05, à 20:30, Stefan Urbanek a écrit :
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.
Well, the problem I have with this approach, is that it only really
works for DTP works. Which is fine, and is one important aspect of
using a computer. But sometimes you really just want applications, not
generating documents; other times you want to generate documents, but
the DTP-metaphor is not as easy to implements.. what I mean is, if your
goal is to produce paper, it's easy to imagine how can a
document-oriented environment works -- you have a base DTP app, where
you can embed objects that can be external to the original DTP app.
That is easily doable using NSDataLink, which is a magnitude simpler
solution than OLE (and probably better, imho, because you still works
with applications on a separate object, which is a cleaner separation).
But in fact, that metaphor is only evident with DTP -- for other medias
than "producing paper document" it breaks a bit. For example, if your
goal is to create *images*, then you don't want the embedded component
approach.. hmm.. you would probably want some kind of filtering
pipeline process... If your goal is to create movie, you want base
tools (timeline, etc.), filters..
What I want to highlight is that the classical approach you and Quentin
describes works well for something we know it works -- DTP. For other
media, we need a bit more thinking. And sometimes anyway you really
want an application, because you want to do an action, not produce a
document. So thinking that a document-based environment will just throw
any application concept is imho wrong.
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.
agree.
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.
Nope. If we use NSDataLink, and to take the example of a DTP
application, the DTP app will act completely normally, the user will
use the app and stay in the app. Only when (s)he will want to *edit*
the object, the editing application for this object will be launched.
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" :)
Well, what we want is encourage reusability :-)
The difficulty, as always, is to know how to have a good design for
that -- and it's not easy :-)
The whole NSPasteboard mechanism is rather brilliant though, and is a
good enough to support NSDataLink, NSFilter ... it seems to me as a
good, general, way of handling communication between applications /
exchanging datas.
The only thing I can see we would want is probably a more powerful
NSFilter mechanism, or a similar mechanism (that would be useful for
imaging applications for example, but not only -- NSFilter can be used
to create representations of objects as simple Images, thus enabling
the pasting of objects that are complex, without having an application
to know how to display the original object).
<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).
agree.. that's why NSDataLink is a good approach imho, because it
leverages the existing GNUstep applications and GNUstep mechanism. Go
gregory ! ;-)
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.
Cheers,
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
