Re: Ease of Use?

[Karl Gutenberg <GlueSoft gmx de>]

Weluva people,

On Mon, 11 Sep 2000, D-Man wrote:
> I would like to add to this discussion.  I enjoy using GUIs because, as
> Karl said, they provide a way to use a program without being taught
> anything.  Graphics are also nice to look at and interactions between
> programs is sometimes easier with a mouse.  On the other hand, I have
> learned to use the CL (namely bash) and I have found it to be quick and
> powerful.

Let me add that both can benefit from each other. Imagine a menu in your 
panel that shows the top level dirs, with sub-dirs as sub-menus, so you can 
easily browse and then issue "open terminal here" that gives you a shell with 
the current directory there. I think KDE does that and it's very handy. I 
used to have it on AmigaOS too and I added it on Win32 too... (at the context 
menus). It's not there in Gnome yet, AFAIK.

The other way round, when I was bashing in Win32 (or even CMDing) I would 
type "explorer ." and voila, have the GUI view of the directory doing some 
things that I can quicker do with the GUI.

This is a first step of making CL and GUI interchangeable. If you find one 
too limiting, you just switch the context, without having to browse, find 
your location again....

> I think that both GUI's and CLI's have their merits and that both should be
> provided, as Karl suggested.  However, careful design of both is necessary.
>  The Evolution GUI seems to me to be following the StarOffice philosophy:
> "Do everything in one place."  That is why I hated the StarOffice UI so
> much.  It also goes completely opposite the Unix philosophy of "Do one
> thing and do it well."

The StarOffice UI really suffers a lot from this. I doubt if it can and will 
be broken into acceptable pieces too soon. It's actually the weak point of 
the Gnome strategy, very likely you will see a monolithic StarOffice being 
added than a component based GnomeOffice.

It does internally use a Corba compliant component technology, called 
StarOne, based a lot on Java technology. So there IS hope, but it was only 
added late.... so I don't believe it that it's an internally used thing, but 
more of an external interface....

> As far as email clients go, I think Balsa has a rather nice and simple GUI.
> Sometimes, however, I don't have access to a graphical terminal (also with
> my mailbox settings) so I use elm.  elm is nice because it can be used in a
> terminal and has simple commands.

Well, I make sure nobody keeps me from an X. :-) And then, why not run that 
email program on your own X display, but remotely. I mean, that's what X is 
about, right? And Gnome is about allowing me to use my local addressbook with 
that program, right. I should not even note, it's not really part of that app 
or on a different computer....

This last is one of the things that Gnome software could do and KDE will not 
be able to. Not yet at least.  

> I think that Evolution should be broken apart into the different services
> it provides (at least as far as the GUI is concerned).  The calendar and
> the e-mail clients are 2 different applications and should be viewed as
> such.  Karl said that Evolution was a "app architecture tailored to bring
> services to a desktop, like addressbook-server and friends, all indepent of
> the GUI!"  How is the architecture independent of the gui?  Could several
> different GUI's (frontends?) be made to work with evolution?  If so, I
> think that is the way to go (with adding a CLI of course).

Actually, a good software design makes sure that the GUI is just that, the 
GUI and nothing more, not telling you anything, about things are internally 
arranged. When I installed Evolution, I had suddenly a couple of new deamons 
running. One of which was an addressbook deamon, another a calander deamon 
and so on. Each functionality is fully separated from another.

That is allowing independant software developers to use that calendar and add 
their own dates, view them in their own ways, whatever they wish too. I am 
sure that adding your own warning stuff via emails, SMS beepers, will be more 
than trivial, even if the Evolution GUI remains really dump and not 
programmable!

This is good design and the Evolution team is really guilty of it.

As far as the GUI making it all into one. The intention is clear and I agree 
with it that calendar and email go along. I have been working as a indepent 
software vendor for years and Outlook was what made it possible to keep up 
the email volume, allowing me to set timers for replys, control timely tasks 
completions, check my spare time easy....

Actually, with Outlook98 I never really had anything to criticize, but the 
email formats, the quoting style, the line breaking, but never the amount of 
integration, i needed that.

And Evolution aims at two markets. People who need it, corporate employees 
maybe. And people who want a platform to develop custom apps for it. It was 
so that Outlook was actually winning because it made it so easy to be 
extended for a company. Evolution will be even better at that.

> On a more developer-oriented note, what is the best way to make an app with
> both CLI, GUI, and scripting capabilities?

There is more than one way to do it. (Larry Wall, I believe)

There is no best way. It's all a tradeoff. For a CL, you need a flat hierachy 
of the software and make it use as little context information as possible. 
For my apps, I tend to implement functionality as CL interface first. It 
makes testing it easier and I often encounter changes at that stage which are 
easier to handle in a CL, but a GUI requires a bit more work to allow more 
than one selection e.g. where you had not thought of that initially.

> I have heard of libguile, though I haven't used it or looked at the API,
> and I think that it would be a good way to add scripting to GNOME apps. 
> Scheme is a nice, clean language that is not really difficult to learn
> (much simpler than C!).

I admit, I don't know about Guile. And I don't want to. I would prefer to see 
interfaces to all languages instead. That must be possible, right? 

I found Perl deliver all the promises that I need. It gets me to have either 
a simple language, making simple tasks easy. If I want, I can get 
object-oriented and I do a couple of times. And lately, if I want to do 
something, I find a solution at CPAN. Only yesterday, i found something to 
script my Xmms.

What I really would love to see would be to have the choice of what language 
you want to use for a certain scripting task in an app. Let me use your 
scheme stuff for one task and use my Perl stuff for another. With the same 
app....

Yours, Karl

PS: I am really interested to learn, wether Emacs can access the outside 
Gnome world yet...