Re: GNUstep GUI design

[Björn Gohla]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 07 October 2002 00:55, Pascal Bourguignon wrote:
[...]
> > On 2002-10-04 19:42:05 +0200 Yen-Ju Chen <yjchenx@hotmail.com> wrote:
> > [snip]
> >
> > > And as personal opinion, the idea of unix-like tool works very
> > > will in command line
> > > But in gui environment, I doubt it.
> > > Switch between applications is not as convenient as tools.
> > > (takes time to launch, mess up the desktop with too many app, ...)
> >
> > I can imagine a system without a command-line that works. I do not
> > have a commandline for my surronding environment, neither terminal
> > for my desk. I see the future in something like 'interacting
> > objects' and we can consider gnustep applications like objects-tools
> > that we use to do our work (by manipulating objects).
> >
> > I am using a terminal a lot, I can say that it is my primary working
> > environment. But it does not mean that it good or comfortable, it
> > means that there are no suitable GUI tools that can ease my
> > work. Current GUI tools, or applications if you want, do _not
> > cooperate_ together well. Why to use the terminal? Mostly because
> > one can chain his work using scripts and pipes and it is fast. GUI
> > is _still_ not.
>
> MacOS for example.  Amiga, Atari too.
>
> NeXTSTEP/OPENSTEP/GNUstep/MacOSX  have  a  terminal,  so  experimented
> users can  go to a shell  and write scripts  when the task at  hand is
> repeatitive and  do in 3  minute what Mac  users do in 3  hours.  That
> happens more  often than you  would think...  That's the  advantage of
> NeXTSTEP: you have the best of GUI without loosing the CLI.
>
>
> Apple  later tried  to add  scripting to  its MacOS  (AppleScript) and
> they're still developping it in  MacOSX.  However it's not really as a
> workable solution as CLI based.  Why?

i would wildly guess it lacks something like corba but simpler, with bindings 
for many languages.

> I too  have head this idea  that everything in computer  systems is an
> object  and  that  you'll   manipulate  these  objects,  sending  them
> messages, using  specialized editors for  each kind of objects. 

in a way, that is also what the hurd does. all files have a translator 
attached that implements a protocol. in the case of simple files this 
protocol consists of the familiar operations, the directory translator 
implements stuff like link file, unlink file, list contents. but, as they 
write somewhere in their introduction, you could could implement an entire 
windowing api as operations on a file. that way the filesystem becomes the 
uniform interface for everything.

> In a
> way, that's what you do with documents and applications, and Macintosh
> could even  store all  document as an  application thus making  a true
> object (see for example the  self extracting archives) easily with its
> forks (data for  the document, resources for the  application code and
> other resources; this has changed  with powerpc though).  Note that in
> the case of the Oberon system,  you could send messages to any object,
> but you usually did it writting the message statement in a text window
> and  executing it.   Kind of  CLI  to my  taste... ok,  Oberon is  not
> exactly a GUI environment. But still, why?
>
> Another case is the services in  NeXTSTEP.  Here, the data part of the
> "objects"  is represented  by a  selection in  any  application.  This
> selection has a type (text,  picture, whatever), and depending on this
> type, could be sent to this "object" various messages named "Services"
> listed in the services menu.  Granted, these kind of objects where not
> very well encapsulated, since  each application could be considered as
> a set of methods able to act on objects whose data part is stored into
> the  document  files  (speaking  on  a global  level,  not  about  the
> Objective-C objects that  could be stored inside the  files; note that
> in that case you just store the data part of the instances; the method
> code stays in the applications or in the libraries).


[...]

> > It is more than 20 years since a graphical object environment was
> > invented...and we are still using a terminal...
>
> In  conclusion,  that's  why  the  file is  a  sequence  of  character
> paradigm,  and a  system of  small  tools working  on these  character
> streams blissfully  ignorant of any  meaning of these  characters, but
> that you (an inteligent human) can chain and combine easily (thanks to
> redirections, pipes and  scripting), still is superior to  any GUI and
> object system you can find.

well, usually you still need some kind of dataformat, traditionally one 
record per line, fields separated by space or colons. being able to do stuff 
on the commandline is nice in a lot of situations, but when your data has 
more structure you start doing things with sed or perl, and it gets really 
ugly. i wish it were possible to manipulate complex datatypes from the 
commandline.

> > > And interface between application is not as good as tools (pipe).
> >
> > What about drag and drop or pasteboard? They are quite good
> > analogies of what we do every day. It is like moving things around
> > and it is same for files and objects. Only thing that is needed (as
> > I see it) is that developers have to get used to it. With ~step it
> > is really easy as compared to other environments.
[...]

> Now, to finish  with the integration of CLI and GUI,  I would say that
> it's possible to  develop small GUI programs that  integrate well with
> CLI.  This  is the case  with X,  where you can  launch most of  the X
> programs from the  CLI with meaningful options and  dataflow.  Not the
> latest  bloatware though.  Think  about xmessage,  Tk, etc.   See also
> NeXTSTEP copy  and paste commands  that gave access to  the pasteboard
> from the CLI and thus allowed integration of GUI with CLI.

how about reenforcing the mvc paradigm by by default having the document data 
representing object run in a process separate from the view and control 
logic? then access the data model via gnustep-do (and potentially corba and 
the like). that would make it very easy to use complex datatypes even from 
the commandline, and a lot of other languages.

[...]
- -- 
/* Nobody will ever see this message :-) */
panic("Cannot initialize video hardware\n");
        2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
pub  1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger) 
<b.gohla@gmx.de>
     Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5  8129 6C14 3C39 834F 4976
sub  1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9odirbBQ8OYNPSXYRAoMbAJkB9qOlIg3VwAjRMS5taO0BTHWSPACfc2Oj
S6FUI27ntPwE+eWI8GakvWM=
=g5pv
-----END PGP SIGNATURE-----