ubuntuusers.de

[Kwami] CLI versus GUI

kwami.png

kaputtnik macht sich in diesem Beitrag Gedanken über die Vor- und Nachteile der beiden Benutzerschnittstellen GUI und CLI. Neben einer kurzen Einführung zum Begriff „Benutzerschnittstelle“ versucht er die wesentlichen Punkte heraus zu arbeiten.

Hinweis:

Dieser Artikel gehört der Kategorie Kwami an. Er spiegelt damit allein die Meinung des Autors und nicht zwingend die des ubuntuusers.de-Teams wider.

Oft liest man im Forum, dass eine „richtige“ Benutzung von Linux auf der Kommandozeile (CLI = Command-Line Interface) erfolgen sollte. Viele Umsteiger von anderen Betriebssystemen sind jedoch die Benutzung per grafischer Benutzerschnittstelle (GUI = Graphical User Interface) gewohnt und können sich nur schwer mit der Eingabe von Text in einem Terminal anfreunden. Eine Gegenüberstellung der Benutzerschnittstellen GUI und CLI, dabei hat jede Art seine Vor- und Nachteile…

Benutzerschnittstelle

Um ein Programm bedienen zu können, muss es die Möglichkeit bieten, Eingaben entgegen zu nehmen und nach der Verarbeitung der Daten eine Ausgabe zu erzeugen. Am einfachsten für den Programmierer ist eine solche Ein- und Ausgabe per Kommandozeile zu realisieren, da er sich nicht um die Eigenheiten verschiedener Grafikbibliotheken, wie Qt oder GTK, zu kümmern braucht. Er kann sich voll und ganz auf die Verarbeitung der Daten konzentrieren und an beliebiger Stelle im Quellcode einen Text auf die Kommandozeile ausgeben. So liegen die meisten Programme in einer Kommandozeilenversion vor. Eine grafische Schnittstelle für dieses Programm wird erst später, oft durch andere Programmierer, dem eigentliche Programm übergestülpt. Arbeitet man mit „grafischen Programmen“, so nutzt man oft nur ein Frontend, die eigentliche Arbeit machen Konsolenprogramme im Hintergrund. Die Kommunikation zwischen Programm und GUI erfolgt dabei über andere Wege als über das Terminal.

CLI

Vorteile CLI

Exit status vom Programm cd
Exit status:
0 if OK,
1 if minor problems (e.g., cannot access subdirectory),
2 if serious trouble (e.g., cannot access command-line argument).

Verfechter der CLI-Benutzung führen an, dass eine grafische Benutzeroberfläche das eigentliche Geschehen, also was ein Programm gerade macht, versteckt. Man sieht nicht, was im Moment passiert, oder welche Meldungen ausgegeben werden. Grund hierfür ist der unterschiedliche Kommunikationsweg. Grafische Benutzerschnittstellen erhalten bei einem Fehler in der Regel nur einen Exit status in Form einer Nummer zurück.

Wenn also zum Beispiel das Software-Center eine Aktion mit der Mitteilung „Das Paketsystem ist beschädigt“ quittiert, wird dem Benutzer nur ein Fehler mitgeteilt, aber nicht, wie er es möglicherweise lösen kann. Welche Meldungen Programme darüber hinaus in einem Terminal ausgeben können, sieht man sehr gut, wenn man ein grafisches Programm über das Terminal startet. Hier beispielsweise beim Start von Spiele/Widelands:

$ widelands
Set home directory: /home/kaputtnik/.widelands
No version file found
Adding directory:/usr/share/widelands
Version file found with id "build-17" (real "build-17" )
No version file found
Adding directory:/usr/share/games/widelands
Adding directory:.
No version file found
selected language: (system language)
using locale de_DE.UTF-8
SDL_VIDEODRIVER=&
Graphics: Trying Video driver: 0 x11 SDL_VIDEODRIVER=x11
Graphics: Trying opengl
Graphics: Try to set Videomode 1280x960 32Bit
Graphics: Setting video mode was successful
[…]

Bei einem Start über das Menü sieht man von diesen Dingen nichts.

Um auf das Software-Center zurück zu kommen: Wird statt dem Frontend Software-Center das eigentliche Programm APT auf der Kommandozeile ausgeführt, sind die Fehlermeldungen in der Regel viel aussagekräftiger.

Gerade im Forum sind diese Ausgaben gegenüber einem Bildanhang von enormen Vorteil:

  • Es sind Textausgaben, die man beliebig zitieren, kürzen oder auch markieren kann

  • Textausgaben sind immer lesbar und unabhängig von Bildschirmauflösung und Bildformat

Werden vom Helfenden weitere Abfragen gefordert oder eine Lösung per CLI-Befehl gegeben, können sie von jedem einfach kopiert ( Strg + C ) und in einem Terminal eingefügt ( + Strg + V ) werden. Vorgangsbeschreibungen wie

Nutzt Du das Softwarecenter, dann klicke darin auf „Bla“, im Reiter „Blup“ kannst Du unten die Einstellung wie folgt ändern: […] Wenn Du ein anderes Programm benutzt geht es anders, dann klickst Du auf […]

entfallen, wenn einem gesagt wird, in welcher Konfigurationsdatei man welche Änderungen vornehmen soll. Statt sich durch unzählige Menüs zu klicken, ist es manchmal einfacher, den entsprechenden Wert in einer Konfigurationsdatei zu ändern. Bei dem Versuch einen Großteil des Systems über Konfigurationsdateien zu konfigurieren, kommt man jedoch sehr schnell an die Grenzen der CLI, da viel Wissen erforderlich ist.

Nachteile CLI

Um eine Einstellung in einer Konfigurationsdatei ändern zu können, muss ich

  1. wissen, wo die Konfigurationsdatei liegt und wie sie heißt

  2. wie der Wert, die Einstellungsoption, in dieser Datei bezeichnet ist und welche Werte ich Ihr geben kann

Sich dieses Wissen anzueignen ist mit viel Aufwand verbunden. Gerade für Konsolen-Programme sind solche Angaben zwar sehr gut in den Man-Pages dokumentiert, diese liegen jedoch oft nur in englischer Sprache vor. In der Regel eignet man sich aber die gängigsten Optionen und Parameter eines Befehls mit der Zeit an. Ein

sudo apt-get update 

ist schnell zu merken, erfordert aber Schreibarbeit. Schreibarbeit ist mit der Gefahr von Syntaxfehlern bzw. Schreibfehlern verbunden und können bei potenziell gefährlichen Befehlen das System beschädigen. Obiger Befehl ist dabei ein vergleichsweise kurzer (und ungefährlicher) Befehl, der mit Hilfe der History schnell wieder hervor zu holen und zu korrigieren ist. Bei einem

ffmpeg -f x11grab -s 1680x1050 -i :0.0 -s 840x525 -vcodec libx264 -b 4000k -vpre medium -an AUSGABEDATEI 

sieht die Suche nach Schreibfehlern und deren Korrektur schon etwas anders aus.

GUI

Vorteile GUI

cli_vs_gui_tooltip.jpg
Tooltip in der GUI KFind

Eine grafische Benutzeroberfläche versucht alle Optionen und Kommandos sinnvoll zu sortieren und in Gruppen aufzuteilen. Oft werden dabei mehrere Konsolenprogramme in einer Oberfläche verschmolzen. Als Beispiel sei hier GParted genannt, welches für unterschiedliche Arbeiten auch unterschiedliche Programme bzw. Bibliotheken benutzt:

Die GUI bietet die Möglichkeit die entsprechenden Optionen gleich mit (mehr oder weniger) verständlichem Text zu versehen und per Mausklick zu (de)aktivieren. In der Regel stehen die Programme in der richtigen Sprache zur Verfügung und bieten weitere Hilfen per Tooltip bzw. umfangreichem Hilfesystem an.

Zudem lassen sich die Auswirkungen verschiedener Optionen meistens per Klick testen. Die GUI vermindert dabei die Gefahr von Schreibfehlern, da Optionen und Kommandos fest im Programmcode hinterlegt sind.

Nachteile GUI

Eine GUI wird quasi ausschließlich mit der Maus bedient. Ist Schreibarbeit nötig, muss ständig zwischen Maus und Tastatur gewechselt werden, was unnötige Bewegungsabläufe erfordert.

Die Bedienung eines GUI-Programms muss genauso erlernt werden, wie die eines Terminalprogrammes. Auch wenn Optionsschalter beschrieben sind, heißt es noch lange nicht, dass man deren Auswirkungen auch versteht. Ein Grundlagenwissen ist auch hier erforderlich.

Die Auswertung und Darstellung eines vom Terminalprogramm zurück gegebenen Fehlercodes obliegt dem Programmierer der grafischen Benutzerschnittstelle, was er aber aufgrund von nicht reproduzierbaren Fehlern nicht immer berücksichtigen kann.

Mein Fazit

Ob man GUI oder CLI präferiert muss jeder für sich selber entschieden. Ich persönlich habe die Trennlinie zwischen CLI und GUI auf die Grenze zum System gelegt: Bei allen Arbeiten die einen Eingriff mit Rootrechten erfordert bevorzuge ich CLI. Für die Arbeit mit Konfigurationsdateien nutzte ich nano, ein Terminalprogramm. Für das produktive Arbeiten benutzte ich ausschließlich GUI, es sei denn für ein Programm wurde noch keine GUI geschrieben…

Bei Fehlern oder Problemen mit einem grafischen Programm sollte man aber immer schauen, ob der Start in einem Terminal bessere Fehlermeldungen hervor bringt.

Über den Autor

kaputtniks Computerhistorie begann mit dem VC20 und damit einhergehend erste Erfahrungen mit Basic. Später folgten Rechner mit MSDOS, Windows for Workgroups, IBM os2 Warp und Windows 2000. Im Dezember 2007 kam Ubuntu Gutsy Gibbon zuerst auf den Laptop und dann auf den Desktoprechner. Inzwischen nutzt er Arch-Linux, einmal im Monat wird zwecks Buchführung das parallel installierte Windows 7 gestartet.