Object[1] - something containing data, stored either by ObjectKit or
DataKit. These represent data in the system, i.e. parts of documents.
They are maintained by the environment.
What about 'Content'? We are already using the term Object in a
programming context -- it would be good if we didn't have to always
differentiate between the two when talking to others or explaining
things.
Component - something which manipulates objects. A component either
transforms the object, or provides a view of the object. Components
each exist in their own address space, and may present a UI.
Filter - a component which has no user interface of its own. Filters
transform one object into a different object (or the same object, in
the case of the null filter).
What do we call Components that do present a UI then? If I said Filter,
you would know exactly what I meant, but if I said Component, you
wouldn't know whether there was a UI or not.
Right now it looks like:
Component
|
/ \
Filter ?
Component seems like an abstract, which is used as a term for both
Filter (without UI) and ? (with UI). The big difference between the two
(in my mind) is that the Filter uses a pre-defined value to modify the
content somehow, while the ? lets the user enter their own values and
interactively modify their content (ex: Photoshop filters, OS X Font
selection), or even to change the mode in how they interact with
content (ex: Photoshop tools palette). We should probably give the ? a
name so that it can be differentiated from Filter in a concrete way.
Ideas: Palette, Module.
Widget - a widget has its own internal state and UI, but does not
interact directly with objects. A clock or a CD player would be an
example of a widget. These are things that don't really fit with the
component / document model. They could be called applications, but I
don't want to call them that, because it would engender confusion with
application-based environments. Unlike OS X, there is a clear use for
widgets[2].
If we were looking at the Project-based Desktop or Narcoleptic
Electron's proposal, Widgets would be things that existed outside of
any projects, perhaps in a shelf like space -- like Dashboard. I just
got Alex's email and he proposes Applet. I think that might be a better
term. Additional ideas: Utility, Desktool.
Application - a program from a legacy environment. I would suggest
that GNUstep applications run in Étoilé run with the old GNUstep
theme, not Nesedah, to provide a visual clue that they are not full
members of the Étoilé environment.
There is some validity to this (things that work different should
appear different), but I would personally rather design a new theme
than use the GNUstep one. Something that was a bit more integrated into
Nesedah (just as modern), but maybe using a different color. Or, maybe
not...
Since we are the designers of this system, we can say what can happen
and what can not. As such, maybe we don't want legacy applications on
the system at all, to make things easier on the user. Imagine you get
used to making a new Document via the Workspace, then you make a new
Document to edit images and realize, "Oh, wait, I can't do that, I need
to start Gimp (or whatever) to do that". The user has to switch
contexts in their mind and backpedal, and has to remember what can be
made via Workspace and what requires an app. It seems like a lot of
extra work for the user. I would use use legacy apps maybe as a
temporary solution, but by a 1.0 launch, all support for them should be
gone, having been replaced by Components.
J.
