Re: For the AdaOS folks

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Adrien Plisson <aplisson-news@stochastique.net> wrote:
 
: development. they don't want to lose their investment, so they target 
: what is widely used:

I don't think there is a technical OS-related problem.
Windows has a lot under the hood. You can have a document centered
approach. You can forget about applications if you wish and instead
combine frames on one and the same virtual sheet of paper, where each
frame's content is managed by different modules. I.e. you choose data,
not programs (OO vs. application).
You can have "smart" drag and drop.

But all this isn't usually in the *showcase* when people are told
how they can use Windows. (One neighbor/collegue showing another, etc.)
So it is hardly known that there is OLE, COM, COM+, DCOM, ActiveX, I
forget the most recent name of the same OO concept. Have you ever seen
anyone recently moving a file with a mouse from one folder to another,
and not using File->Save As?
 I think it is just a lack "social visibility" of features that make
the "modern" features less used.

Example: You want to load a document in a text editor.
Typical solution: File->Open etc.
Possible solution: drag the file icon from the folder onto the editor window
Windows merges: The File->Open dialog *is* a folder view, with a slightly
  different look. Clever, eh?
(Programmer's IDE solution: the file in question is loaded *automatically*
  when you instruct the computer to show you the declaraion of some
  identifier.)

Unfortunately, the traditional appearance of file open folders etc.
doesn't invite people to quickly abandon the use of a specialised file
centered dialog window. They could because all the functionality *and*
*more* is already provided by the OS shell.

Secondary effect: programmers who do no know the OO side of folders and
icons (etc.)  start copying the traditional ways (File->Open). But they
do not copy the possibilities hidden in the object model of folders,
frames, etc.

For example, the File->* dialog in stand-alone Gimp 1.x was terribly
outdated technically. Why? Now Gimp is frequently associated with the
GNOME, and GNOME stands for GNU Network Object Model Environment, but
where are the system objects in Gimp's file manipulation dialogs? Do
they look like system folders, the same as hopefully in all other GNOME
programs? And then, why do we need File->* dialogs at all when there
is a system component for file manipulation?

The GNOME pages (Human Interface Guidelines) still speak of associations
between files and applications. Pity because there is so much more under
the hood than files and applications. The components view deserves
more attention I think. Maybe Mono will help to achieve this.

-- Georg