GUI vs. Command Line? (was: Re: [linux-l] Re: mutt interface)

[olafBuddenhagen at gmx.net]

Hallo,

Und damit wären wir bei meinem Lieblingsthema... :-)

On Thu, Feb 15, 2007 at 03:10:24PM +0100, Sven Guckes wrote:
> * Volker Grabsch <vog at notjusthosting.com> [2007-02-15 13:28]:

> > Was *mich* eher stört, ist dass man sich ~b, ~H, etc. merken muss,
> > da fände ich eine Eingabemaske benutzerfreundlicher.
> 
> und? alles was man sich dabei spart ist die eingabe von wenigen
> zeichen wie tilde plus buchstabe.  na, toll!

Stimmt nicht ganz, es ist noch Einges mehr was man sich spart.
Syntaxfehler zum Beispiel. Versehentliches Löschen anderer Teile des
Ausdrucks durch falsche Tastenkombinationen oder so. (Passiert mir bei
Mutt tatsächlich sehr häufig, da ^u sich nicht wie üblich verhält.)
Wälzen von Dokumentation.

> ich finde es weitaus praktischer das ganz schnell uber eine
> eingabezeile eintippen zu koennen.

Ich denke Du musst Mutt-Benutzer nicht von den Vorzügen eines
Kommandozeilen-Interfaces überzeugen :-)

Natürlich ist eine Kommandozeile meistens viel effizienter. (Außer in
einigen speziellen Situationen, wie Mehrfachauswahl oder Browsen durch
komplizierte Informationsbestände...) Sie bedeutet aber auch eine sehr
viel höhere Einstiegshürde. Mann muss sich erstmal ordentlich einlesen
und einüben, bevor man damit arbeiten kann. (Als Einsteiger sowieso,
aber auch als erfahrener Benutzer, wenn man mal eine Operation braucht,
die man bisher nicht benutzt hat.) Man fühlt sich zunächst einmal
ziemlich verloren. GUIs sind bei der Einarbeitung klar im Vorteil.

Aber warum muss es unbedingt entweder-oder sein? Warum nicht Beides
verknüpft? Warum kann ich nicht eine Kommandozeile haben, und
gleichzeitig eine Maske, die es ermöglicht, die Kommandozeile
"zusammenzuklicken"? Um darauf ausweichen zu können, wenn man garade
nicht weiterweiß? Und sich dabei nach und nach einzuarbeiten; ganz
nebenbei zu lernen, wie man die Sachen in Zukunft effizienter machen
kann?

> ich glaube (ja, das ist eine glaubenssache) dass es meist ausreicht
> die eingabe mit ein wenig hilfe zum kontext zu unterstuetzen:
> 
>     see also: man muttrc - PATTERNS
> 
> oder sogar mehrere zeilen mit kontexthilfe:
> 
>     ~f from | ~c cc | ~t to | ~C cc+to | ~s subject | ~b body
>     ~D:to-be-deleted | ~F:flagged | ~N:new| ~T:tagged | ~=:dupes

Das ist natürlich auch ein wichtiger Aspekt. Tatsächlich ist bei PINE
die deutlich sichtbare und übersichtliche, kontextsensitive
Kommandoleiste eine tolle Sache; macht PINE zu dem
einsteigerfreundlichsten Programm das ich kenne. (Zu schade dass es in
so vielen anderen Hinsichten Mist ist -- und vor allem unfrei...)

> > Vielleicht ist am Ende wirklich ein Fork nötig, aber dann hat man,
> > solange der Fork entwickelt wird, schonmal was Brauchbares in der
> > Hand.
> 
> muttngng?  bitte nicht!

Ich würde es selbstverständlich muttrik nennen ;-)

> es gibt schon eine menge viele patches - aber keine roadmap und auch
> kein entwicklertreffen.
> 
> und es gibt auch so schon eine menge verschiedenener pakete fuer
> dieselbe versionsnummer.  allein bei debian gibt es fuenf zusaetzliche
> patches.

Warum eigentlich? Offenbar geht es in keinem der Zweige wirklich voran
-- nicht weil es an Patches fehlt, sondern weil keine brauchbaren
Maintainer vorhanden sind. Ein weiterer Fork kann da durchaus sinnvoll
sein -- vorausgesetzt es macht diesmal jemand, der das ernsthaft und
dauerhaft in Angriff nimmt...

Im Übrigen kann man einen Fork durchaus später wieder zusammenführen,
wenn sich das anbietet. Insbesondere für radikale Veränderungen kann es
sehr nützlich sein, zunächst freie Hand zu haben, bevor man sich
überlegt, wie man das mit dem vorhandenen in Einklang bringt...

> davon abgesehen sind tags in den mails kein widerspruch zur
> einsortierung von foldern, sondern eine *weiteres* suchkriterium.

Nicht wirklich. Klar könnte man Tags einfach als netten Zusatz
betrachten. Aber die volle Leistungsfähigkeit zeigt sich eben erst, wenn
man auf traditionelle Orner ganz verzichtet, und nur noch Alles über
Tags macht. Das erfordert aber, wie schon geschrieben, eine Menge
Anpassungen.

Im Prinzip könnte man das ja alles konfigurierbar machen. Aber stark
konfigurierbare Interfaces haben leider einige sehr wesentliche
Nachteile: Der Code selbst wird gebloated; und eine effiziente
konsistente UI kann man vergessen -- UI-Entscheidungen beeinflussen sich
nun mal gegenseitig, und wenn man sich nicht darauf verlassen kann, dass
bestimmte Sachen so und nicht anders funktionieren, kann man an anderer
Stelle die Möglichkeiten nicht ausschöpfen.

-Olaf-