[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep GUI design
From: |
Björn Gohla |
Subject: |
Re: GNUstep GUI design |
Date: |
Mon, 7 Oct 2002 20:55:35 +0200 |
-----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-----