Benutzer:Sloyment/GUI-Idee

Aus Laboratorium

Wechseln zu: Navigation, Suche

Die folgenden Überlegungen zielen darauf ab, eine universelle grafische Oberfläche als freie Software zu entwickeln, und zwar in zweifacher Hinsicht:

  • Das GUI sollte stark skalieren und somit vom Embedded-System bis zum superbunten Wahnsinn und quer durch alle gängigen Systeme eine einheitliche Bedienung ermöglichen.
  • Es sollte sowohl für Windows- als auch Mac- bzw. Gem-User ohne großes Umdenken benutzbar und in den verschiedenen Anwendungsbereichen einheitlich gestaltet sein.

Inhaltsverzeichnis

Konsole, Netzwerk, X

Für verschiedene Einsatzgebiete bieten sich verschiedene Lösungsansätze:

  • Dort, wo wenig Resourcen zur Verfügung stehen und normalerweise die Konsole zum Einsatz käme, sollte ein sparsames GUI zum Einsatz kommen. Wie GEOS auf dem C64 oder GEM auf dem Atari ST gezeigt haben, kann ein benutzbares GUI auch mit sehr geringem Resourcenverbrauch realisiert werden. In diesem Anwendungsbereich wird auch nicht viel grafischer Schnickschnack benötigt. Es reicht im Wesentlichen, waagerechte und senkrechte Linien zeichnen, Icons anzeigen und Text ausgeben zu können. Ein solches GUI könnte sogar im Bios oder im Bootloader eingebaut sein.
  • Wo bereits ein GUI vorliegt, z.B. X11, eventuell mit GTK oder QT, oder Windows oder Mac, wäre es unsinnig, diese Funktionalität nicht zu nutzen. Der Fokus liegt hier eher im Bereich Window-Managing. Wo eigene Programme zum Einsatz kommen, sollten die nativen Toolkits über Wrapper-Libs verwendet werden.
  • In einer weiteren Idee geht es um Netzwerkfähigkeit eines Programmes. Hierbei lassen sich manche Programme per Browser steuern. Das Look-and-Feel solcher Oberflächen ist aber oft grausam. Hier könnte ein Fernsteuerungs-Standard helfen, bei dem z.B. ein clientseitig laufendes Universal-Steuerungsprogramm das GUI per XML herunterlädt und ggf. cachet...

Verschachtelte Fenster

Es soll mehrere Ebenen verschachtelter Fenster geben:

  • Der Bildschirmhintergrund stellt keinen Schreibtisch dar, sondern einen Fußboden. Dies ist gedanklich also eine Ebene höher. Analog zur Taskleiste bei Windows gibt es eine Tischleiste, was sich gleich erklären wird.
  • Arbeitstische sind Fenster 1. Ordnung. Ihre Verwendung bestimmt der Benutzer. D.h. der Benutzer kann jederzeit Arbeitstische erstellen (d.h. Fenster auf) oder zerstören (d.h. Fenster zu). Es können Blanko-Tische erstellt werden oder aber vordefinierte, auf denen z.B. Gimp startet. Deren Konfigurationen könnten z.B. als Tisch-Icons auf dem Fußboden dargestellt werden.
  • Auf den Arbeitstischen können Unterfenster, die offene Dokumente (wie z.B. ein HTML-Dokument) oder Maschinen (z.B. XMMS) darstellen, abgelegt werden. Ihre Menü-, Werkzeug- und Statusleisten werden dann an den jeweiligen Arbeitstischen angebaut. Die offenen Dokumente bzw. Maschinen können beliebig von einem Arbeitstisch zum anderen verschoben werden. Jeder Arbeitstisch verfügt gewöhnlich über eine Krempel-Leiste, in der alles darauf abgelegte sich wiederfindet. Diese kann man aber bei Nichtgefallen auch abstellen.

Aus Windows-Sicht

Bei Windows bringt gewöhnlich jede Anwendung ihr eigenes Hauptfenster mit. Wer dieses Verhalten gewohnt ist, startet einfach jede Anwendung auf einem eigenen Tisch. Das hat sogar einen Vorteil: Das „Hauptfenster“ (der Tisch) ist schon da, während das Programm noch lädt, und der Splash-Screen liegt auf dem Tisch und flattert nicht wild in der Gegend rum. Die Krempelleiste hat unter Windows kein Äquivalent und kann bei Nichtgefallen entfallen.

Aus Mac- bzw. Gem-Sicht

Unter Gem bzw. auf dem Mac ist die Menüleiste am oberen Bildschirmrand, und es gibt nur eine Fenster-Verschachtelungsebene. Wer das mag, startet alle Anwendungen auf dem selben Tisch und stellt diesen in den Modus „ganzer Bildschirm“ (wie mit Alt+F11 bei IceWM). Die Krempelleiste hat auch hier kein Äquivalent und kann bei Nichtgefallen entfallen.

Tabbed Browsing

Bei Firefox werden die einzelnen Dokumente in sogenannten Tabs dargestellt. Diese Darstellung kann man auch auf den Arbeitstischen haben, indem man die einzelnen Dokumenten-Fenster maximiert. Die Krempelleiste entspricht dann der Tab-Leiste beim Browser. Man könnte sich auch einen Tisch bauen, der als Browser fungiert und auf dem diverse Betrachter und Downloader bei Bedarf geladen werden.

Multi-User-Benutzeroberfläche

Die meisten Benutzeroberflächen gehen davon aus, daß genau ein Benutzer einen Computer benutzt. Wenn man aber auch mal als Root oder als Test-User oder per SSH auf einem anderen Rechner arbeiten möchte, muß man zur Konsole greifen oder wird von den skurilsten Programmen plötzlich zur Eingabe des Root-Paßwortes aufgefordert.

Als Lösung könnte man während der Sitzung zusätzliche Benutzer einloggen bzw. wieder ausloggen, die dann z.B. ihr eigenes Startmenü bekommen, eigene Tische bauen können usw. Sinnvoll wäre auch, sich so ausloggen zu können, daß die gestarteten Programme weiterlaufen und beim Wiedereinloggen deren Oberflächen wieder erscheinen.

Startet das GUI mit einem Dummy-User, der vollends in einer Sandbox agiert, so erübrigt sich auch ein Einloggmanager wie XDM u.a.

Persönliche Werkzeuge