[Gllug] On Linux desktops...

[Alex Hudson]

On Wednesday 17 October 2001 5:40 pm, you wrote:
> >See that power button on the front of your compter? That's a user
> > interface. The knobs on your cooker are the user interface. 'Graphical'
> > denotes the use of graphs to represent the interface. Ergo....
>
> You mean 'graphics'.

Really? I could have sworn I meant dots connected by lines.. but you 
obviously know better than I :)

A graphical display means a number of things: highly interactive non-raster 
displays, for example, are obviously graphical in a non-picture-oriented 
manner. Tektronix (?sp) is an example of this, as used in early CAD engines.

> >Would you call XEmacs a command line tool? I wouldn't. I wouldn't call
> > pico one either.
>
> No. I would call pico a screen-mode text-based tool. Xemacs, well, it
> depends if you're running under X.

Okay, let's make it a more obvious example for you. We're running lynx (in an 
X terminal or not; doesn't matter). I can move the mouse and obtain a 
pointer. Does it matter that the pointer is a text cursor or mouse cursor? I 
can click on links, I can scroll up and down. Why does that actual _look_ of 
the widgets make it graphical or non graphical? If I invented libxtext, a 
widget set that used graphical widgets shaped like text, does that then make 
it non-GUI?

We're talking about the interface here: not just the looks, the behaviour. 
Emacs, pico, lynx _behave_ as GUI applications.

> Unfortunately, the difference you're expressing - that between a
> line-mode and a screen-mode tool - isn't the difference between a GUI
> and a non-GUI.

In your opinion it's not. I've not heard any argument from you to the 
contrary; except for the fact that the interface is drawn using text. If I 
use the bars + pipes in the ASCII chart, does that make it graphical? What if 
I redefine the look of the higher characters as bitmaps (a la Norton DOS 
utilities, IIRC)?

> >Well, there's a water-tight argument if ever I saw one.... I didn't say
> > that all X-type widgets were better than all text-type ones.
>
> Of course, but it is curious that your example was something that's
> handled very badly by a popular GUI tool and much better by the
> equivalent text tools. It might even suggest that your dismissal of
> text interfaces has not been carefully considered.

Perhaps the general point should have been taken then, rather than pedantry 
on the details :) If you wish to have a better example, take icons. They 
perform far better than textual 'buttons' (in terms of ease of use), and can 
have multiple modes of use (toggle; select; etc) for very little intuitive 
cost. The main Word toolbar is an excellent example.

> That depends on the information, really. Text is pretty dense; which
> is why so many X displays are just tools for accessing big windows
> full of text.

Text isn't information-rich. Text contains what data is there; to add extra 
content (such as grouping, relationship, importance, etc.) is more costly in 
terms of screen real-estate that with graphics. Although, of course, the 
difference isn't always huge, hence my point about text-based GUIs being not 
particularly far removed from bitmap-based GUIs.

Cheers,
				Alex.

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug