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.
- Next step would be to tailor the UI in order to better fit the
document orientation paradigm.
what do you mean by that ? the "document icon" on the titlebar ?
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 wrote some notes which needs to be cleaned and completed on this
stuff :
http://www.dromasoftware.com/etoile/mediawiki/index.php?
title=Core_concepts
http://www.dromasoftware.com/etoile/mediawiki/index.php?title=Components
- Last step would be the components architecture (with set of loadable
components to customise skeleton-like applications for advanced tasks
and your own workflow)
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).
I need to read the documentation and the code more attentively however
I admit :-)
Anyway I'm quite sure we could implement LinkBack compatiblity on top
of NSDataLink & co.
good idea :-)
Actually, it could be interesting to send some mails to Nisus, tell
them about NSDatalink, the fact that it's currently going to be
implemented on gnustep, and see why they didn't choose that path.
Perhaps it's simply because they didn't know about it, and then we
could perhaps have some cooperation, or perhaps they have good reasons
that we could be interested in :-)
yep, Gregory Casamento has said on gnustep-discuss he was interested to
contact them also because he is working on NSDataLink & co support for
GNUstep as you told me :-)
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
