discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep GUI design


From: Stefan Urbanek
Subject: Re: GNUstep GUI design
Date: Sun, 06 Oct 2002 20:09:36 +0100

Hi all,

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.

It is more than 20 years since a graphical object environment was 
invented...and we are still using a terminal...

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.

It can be achieved via service, but takes time,
especially for something like the communication between MusicBox and Encod.
MusicBox need to tell Encod which track to encode,
the song/artist/album, the place to store the encoded song, etc.

Why? Well, maybe I do not understand what has a player to do with encoding.
(just asking)

The best situation I think is that MusicBox, Encod, and GSBurn
make all the basic funcation (playlist, encoding, burning) into bundles.
Any application just pick up these bundles,
assemble them, intergrate the interface between bundles,
build the GUI, then you have anything you want.

Not a bad idea. Another very similar solution may be a framework providing 
encoding or burning mechanisms with something like back-end bundles for 
specific codecs or devices. Then the application does not have to know and care 
about particular bundles. Framework will provide a list of capabilities that 
will an application present to the user.

[skip]

Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]