Multiple Document Interface

[axeljaeger]

Mit der neuen Betaversion von Gimp gab es wieder mal schöne Diskusion über die etwas ungewohnte Benutzeroberfläche von Gimp. Die von Photoshop sei ja so viel besser, bei Gimp habe man tausende Fenster offen, die keinen rechten Platz hätten und immer rausgesucht werden müssten. Weiter geht es dann immer mit der Diskusion, was denn besser sei, der Windowsway, oder doch lieber die Macintoshidee.

Als Argumente für den Macintosh höre ich immer, grundsätzlich ein SDI-Interface verwendet wird. Jedes Dokument erscheint in einem neuen Fenster und die Fenster sind mit anderen Fenstern des Betriebssystems gleichberechtigt. Das soll "logischer" sein, als MDI, wo die Dokumentenfenster in einem großen Fenster "eingesperrt" sind. So hat man alles, was zu einer Anwendung gehört, in einem Fenster.

Ich kann nachvollziehen, das ein MDI, wie es etwa in Microsoft Office 97 eingesetzt wurde, dem gesunden Menschenverstand wiederspricht. Ich hab noch nie jemanden gesehen, der wirklich die Dokumentenfenster in dem großen Fenster hin- und herschiebt. Man arbeitet immer mit maximiertem Dokumentenfenster und macht das Fenster höchstens mal kleiner, wenn man ein anders Dokument auswählen möchte, weil das Fenstermenü irgendwie umständlich ist. Deswegen ist dieses Interface ja auch in Microsoft Office 2000 rausgeflogen ;-)

Was aber an dem Appleweg so toll sein soll, kann ich nicht verstehen: Neben dem Fehlen von vielen Maustasten, finde ich vor allem merkwürdig: Ich will also Photoshop ein Bild bearbeiten und will natürlich möglichst viel vom Bild sehen, also mach ich das Fenster groß (richtig groß, also maximiert). Dann hab ich da aber zig Fenster, die mein Bild überdecken (Navigator, Ebenen, Farben, Toolbox). Warum ist das da innovativ, das die Fenster das Dokument verdecken?

Ich hab noch nicht so viel mit Photoshop auf dem Mac gemacht, ich hab nur in der Schule Macs zur Verfügung, aber die Macversion sieht der der Windowsversion sehr ähnlich, die ist nämlich entgegen den üblichen Windowsprogrammen nicht in der Lage, Dockwindows eindocken zu lassen. Die kleinen Fenster sind zwar magnetisch, überdecken aber auch das maximierte Dokumentfenster.

Das einzige, was Gimp da jetzt für meine Begriffe von der Oberfläche unterscheidet, ist, dass die Toolfenster bei Photoshop always on top sind, bei Gimp nicht (kann man aber z.B. bei KWin einstellen).

Der Königsweg ist bei den beiden oben angesprochenen Lösungen offenbar nicht dabei, aber besonders in der Linuxwelt gibt es ja eine weitere Lösung, die mittlerweile auf beide anderen Plattformen übergeschwapt ist: Tabs. Jetzt frage ich mich: Ist das der Königsweg? Das, was Microsoft Office macht, ist ja auch nur eine Art von Tabs, nämlich mit der Taskleiste als Tabbar. Ob es jetzt eine Buttonleiste oder Tabs sind, ist ja egal, ist ja nur Optik. (Deswegen ist auch die Unterscheidung in KDevelop zwischen Tabbed und MDI Unsinn, weil bei MDI eine Toolbar eingeblendet wird, wo jedes offene Dokumentenfenster seinen Knopf hat) Wenn das SDI von Apple so toll ist, frage ich mich, warum ausgerechnet Apple selber in Safari das Tabbed Webbrowsing eingebaut hat.

Schreibt doch mal eure Ideen dazu hier rein. Ich bin besonders interessiert an innovativen neuen Ideen, wie man ein Benutzerinterface aufteilen kann. Der IDEAl-Mode von KDevelop 3 ist meiner Meinung nach recht genial: Die Dockwindows sind da nicht dauerhaft eingeblendet, rund um das Fenster sind aber Buttons angeordnet, mit denen man kurz ein Dockwindow einblenden, dort was aussuchen kann und dann "minimiert" sich das Dockwindow wieder.

[samsara]

Mein Hauptproblem mit Gimp und OOo ist, dass die Toolboxen eigene, durch Alt+Tab anwaehlbare Einheiten darstellen. Meiner Praeferenz nach sollte man mit Alt+Tab die Anwendung anwaehlen, aber nicht die einzelnen Toolboxen. Es gibt ja noch die naechsthoehere Hierarchie-Ebene der Virtual Desktops.

Es haengt auch von der Bildschirmaufloesung und -groesse ab: wenn ich statt an einem Laptop an einem grossen flatscreen arbeiten wuerde, kaemen mir die free-floating windows à la Gimp schon eher entgegen, da man schneller aus einem Dokument/Bild ins andere pasten kann.

Mit der Moeglichkeit, den Fokus immer auf das von der Maus ueberschwebte Fenster zu legen, bin ich auch noch nicht so richtig warm geworden, obwohl das die Nutzung eines DE sehr viel effizienter machen kann (wie ich bei anderen Benutzern erlebt habe, die besseren Gebrauch davon machen).

Gruss,

Samsara

PS: Was an Gimp eigentlich stoert, ist der Rechtsklick ins aktuelle Fenster (vielleicht nur Gewoehnungssache?) und dass man den title bar des aktuelle zu bearbeitenden Bilds neu anklicken muss (bzw. Fokus geben), nachdem man eine Tool-Option geaendert hat (Zauberstab!!!) oder das Tool wechselt .

[peschmae]

Was mich an Gimp stört ist, dass der Bildschirm damit schon voll ist. Meiner ist halt nur 800x600 Pixel gross - da hat kaum mehr ein Bild platz, wenn ich mal Gimp gestartet habe.

Photoshop kenne ich nicht wirklich - schon gesehen natürlich, aber nie wirklich damit gearbeitet.

Was mir sehr zusagt ist das UI von Paint Shop Pro 7 (8 hab ich noch nicht ausprobiert). Jetzt mal nur in Bezug auf Bildbearbeitung. Eine dünne Werkzeugleiste links am Bildschirm, eine oder zwei oben. Das braucht nicht viel Platz. Die Toolboxen wie z.B. die Ebenenpalette können sich automatisch zur Titelleiste zusammenziehen (ich weiss, unter Linux gibts WMs, die können das auch, aber leider nicht automatisch (wenn die Maus weg ist), nicht selektiv (nur die Toolboxen) und nicht so klein) - da bleibt noch Platz fürs Bild.

http://www.designer-info.com/p_psp7form.jpg (hab keins mit minimierten Toolboxen gesehen)
wenn du das vergleicht - z.B. mit dem da:
http://www.gimp.org/icons/gimp_in_action1.jpeg - kleines Bild, grosses Gimp

Ist natürlich auch Gewohnheitssache - aber an Gimp und dessen Kontextmenü konnte ich mich bisher noch nicht gewöhnen. Auch mir fehlt das Menü am oberen Bildschirmrand - da kann man viel effizienter einen Menüpunkt anpeilen, als via Kontextmenü imo.

Du sagst, letztlich laufe es darauf heraus, dass Tabs dasselbe sind wie SDI - jedes Fenster ein Eintrag in der Taskleiste. Stimmt so für mich überhaupt nicht.
Einerseits arbeite ich meistens ohne Taskleiste (mit Enlightenment) - und wenn, dann ist der Platz in der Taskleiste recht klein - da sind nämlich noch Desktop-Umschalter, Uhr, ICQ, Programmstarter, etc
Hat nun aber ein Programm Tabs, dann hat das Programm seine eigene Leiste - der Weg zum Dokument geht dann via Programm -> Dokument.

Ein grosser Vorteil von Tabs oder ähnlichem (MDI mag ich nicht so, ausser für Bildbearbeitung) ist auch, dass - wie samsara schon gesagt hat - in der Alt+Tab-Liste nur eine Instanz des Programms auftaucht - das ist viel übersichtlicher so.
Ich habe z.B. mit Kate oder Galeon oft 10 oder mehr Dokumente bzw. Webseiten geöffnet - ein Alt+Tabtabtabtabtabtabtab brächte mich dann vielleicht zur gesuchten Webseite - jetzt mache ich Alt+Tab+Klick.
Hätte ich eine Taskleiste, wäre die übervoll...

Die Unterscheidung in KDevelop zwischen MDI und Tabs macht imho schon Sinn - Tabs sind nämlich immer automatisch Maximiert - genau das was ich will, nix anderes.
Den IDEAl-Mode von KDevelop3 kenne ich noch nicht, da mir noch kein entsprechendes Sid-Paket über den weg gelaufen ist. Leider. Aber das wird im Februar dann bestimmt besser.

Imho gibt es das generell ideale Benutzerinterface nicht - es kommt immer auf die Zielgruppe und auf die Anwendung an, was Sinn macht und was sich die Leute gewohnt sind.

MfG Peschmä

[anda_skoa]

Original geschrieben von axeljaeger
mit denen man kurz ein Dockwindow einblenden, dort was aussuchen kann und dann "minimiert" sich das Dockwindow wieder.

Ich kann das nicht ausstehen. Hatte das auch aktiviert, weil alle so davon geschwärmt haben, aber es soll sich doch bitte nur auf meinen Request minieren und nicht automatisch.

Das automatisch verschwinden ist echt lästig, wenn man zB ein Header und ein Source File aus dem Classbrowser öffnen möchte, muss man dafür zweimal das Fenster aufmachen.
Auf diese Weise am Anfang einer clean-session mehrere Dateien zu öffnen ist purer Masochismus.

Die Aufteilung und die Idee ansich ist aber super, nur das Verhalten ist verbesserungsbedürftig :)

Ciao,
_

[axeljaeger]

Original geschrieben von anda_skoa
Das automatisch verschwinden ist echt lästig, wenn man zB ein Header und ein Source File aus dem Classbrowser öffnen möchte, muss man dafür zweimal das Fenster aufmachen.
Auf diese Weise am Anfang einer clean-session mehrere Dateien zu öffnen ist purer Masochismus.

Ganz zufrieden bin ich damit auch noch nicht, zumal wenn man wie ich einen recht langsamen Rechner hat. Mein Tipp an dich: mit Shift + F12 kann man zwischen Header und Source einer Klasse hin- und herspringen. Man kann ja auch oben in der Toolbar aus einer Klasse eine Methode auswählen. Die wollen einen wohl weg von dem Denken mit verschiedenen Dateien hin zum Denken von verschiedenen Klassen bringen.

Edit: Man könnte das mit dem IDEAl-Mode ja so machen, dass das Dock nicht verschwindet, wenn man eine Action im Dock auswählt, sondern erst, wenn man was im Editor anstellt. Oder noch besser: Richtig Applemäßig: Das Dock "fliegt" automatisch rein, wenn man die Maus an den Rand bewegt und fliegt wieder weg, wenn man es verlässt.

[peschmae]

@anda_skoa: Wo hast du Kdevelop3 her?

Selber kompiliert?

An Debian-Packages hab ich bisher noch nichts laufendes gefunden (bei Orth fehlt KDevelop auf den Servern, ist aber in der Liste und bei den anderen (neueren) CVS-Paketen geht jede Menge apps nicht)


Jetzt wollte ich gerade die Sourcen ziehen - aber da gibts ja welche bei KDevelop selbst. :)
Die waren aber bei apt-get.org nicht drin. :o


MfG Peschmä

[anda_skoa]

Original geschrieben von peschmae
@anda_skoa: Wo hast du Kdevelop3 her?

deb http://people.debian.org/~njordan stable main

Paket heißt jetzt kdevelop3, früher gideon

Ciao,
_

[peschmae]

Danke, jetzt stimmt sogar die Zeile in meiner Sources.list - hab die Kurve irgendwie nicht gekriegt und die vier Dateien halt von Hand installiert. Aber jetzt hätten wir wohl auch gleich den Update-Service eingebaut :)

MfG Peschmä

P.S. jetzt muss ich definitiv mal richtig C++ lehrnen (fortfahren)

[axeljaeger]

Jetzt möchte ich nochmal das andere angesprochene Thema aufgreifen: Wie sieht mit den Toolwindows und Hilfsdocks aus? Ich finde da den Windowsweg am besten: Da werden die Docks richtig verankert und verkleinern den MDI-Bereich so, das die maximierten MDI-Windows nicht überdeckt werden. Was spricht für den Adobe-Weg, die Dockwindows über und nicht neben den Dokumentfenstern zu machen?

[peschmae]

Imho nichts wirklich.

Ausser halt wenn die Dockwindows gross sind - sonst würden sie die Arbeitsfläche zu stark verkleinern. Aber dann macht man sie am besten wie bei PSP - mit optionalem auto-Fensterheber.

MfG Peschmä

[samsara]

Vielleicht sollte sich ein Gimp-Entwickler mal diesen thread ansehen - hat da jemand Kontakt?

Gruss,

Samsara

[peschmae]

Ich glaube nicht, dass Gimp beim Gnomeschen-Usability-Wahnsinn mitmacht. :p

Das ihnen die Gui nicht gefällt, haben denen wohl schon viele Leute gesagt.

MfG Peschmä

[samsara]

Original geschrieben von peschmae
Das ihnen die Gui nicht gefällt, haben denen wohl schon viele Leute gesagt.

Aber wir haben hier einige konkrete Vorschlaege zur Verbesserung gemacht, die man vielleicht umsetzen koennte... z.B. den Fokus auf das zuletzt bearbeitete Bild zuruecklegen, nachdem man ein anderes Werkzeug ausgewaehlt hat oder eine Werkzeugoption geaendert, und die Maus nicht mehr ueber dem entsprechenden (tool) Fenster schwebt. Ob die X-Architektur das erlaubt, kann ich leider noch nicht beurteilen.

Gruss,

Samsara

[axeljaeger]

Ich hab mal selber versucht, eine mit Photoshop vergleichbare GUI mit dem Designer und Qt zu erstellen. Das Problem: Es passt einfach nicht. Wo bei Adobe die ganzen Docks übereinanderpassen, ist bei Linux/KDE mit Keramik einfach kein Platz, weil die Tabbars mindestens dreimal so hoch sind, wie die von Photoshop. Adobe verwendet ja wohl ein eigenes Toolkit, das speziell dafür ausgelegt ist. Würde man bei Gimp etwas platzsparende Widgets verwenden, wäre mit schön geholfen. Wenn ich mir bei Gimp 1.3 diese Riesenbuttonbox ansehe, sehe ich da eine Riesenplatzverschwendung. Man braucht meiner Meinung nach nicht für Rotieren, Skalieren und perspektivisch Verzerren jeweils eienn Knopf. Ein Dropdown-Knopf "Transformationen" würde da z.B. schon platz sparen. Wenn es 2 Reihen Knöpfe wären, ok, aber bei mir sind es 5 Reihen.

[anda_skoa]

Original geschrieben von axeljaeger
weil die Tabbars mindestens dreimal so hoch sind, wie die von Photoshop.

Falls du die Tabs im Sinne von QTabWidget meinst, wenn du als Shape "triangular" benutzt sind sie wesentlich kleiner als "rounded"

Beim neuen Gimp soll ja eine Trennen von GUI von Kern erfolgt sein, die die Entwicklung alternativer GUIs erlauben soll. (hab ich zumindest so verstanden)

Ciao,
_

[oracle2025]

Hm, ich glaube nicht das es einen Königsweg für dieses Thema geben kann,


Fürs browsen im Internet sind z.B. Tabs sinnvoll, beim Programmieren ist das zumindest bei mir überhaupt nicht der fall, da finde ich es viel praktischer links eine Dateiliste zu haben, so wie bei kate oder gvim.

Und für Bildbearbeitung finde ich das gimp interface eigentlich äussert praktisch. Allerdings habe ich auch "Focus follows Mouse" eingestellt. (was fast unvermeidlich ist bei Gimp) Meistens hab ich da mehrere Ansichten auf das gleiche Bild offen in unterschiedlichen zoomstufen, und gleichzeitig noch irgendeinen Bildbetrachter im Hintergrund.
Und falls ich direkten Zugriff auf ein Menü brauche dann "reisse" ich es einfach ab.
Und sollte mir ein Fenster im Weg sein, dann schicke ich es mit der mittleren Maustaste in den Hintergrund, oder klappe es mit doppelclick nach oben.

Insofern glaube ich das es am meisten Sinn macht je nach Anwendungszweck eine andere MDI-SDI Philosophie zu haben.

[peschmae]

Ich denke das gilt auch sonst für die GUI-Elemente unter Linux (KDE, Gnome) - die Sachen sind schon grösser, und manchmal stört das eben - wenn man zuwenig Platz hat nämlich.
So finde ich es durchaus sinnvoll, wenn z.B. die Toolwindows eine sehr kleine Titelleiste haben (wie bei Photoshop) während die "normale" App eine grössere Titelleiste haben darf...


Original geschrieben von anda_skoa
Beim neuen Gimp soll ja eine Trennen von GUI von Kern erfolgt sein, die die Entwicklung alternativer GUIs erlauben soll. (hab ich zumindest so verstanden)


Ja, allerdings hab ich von Seiten der Gimp-Entwickler auch gelesen, dass in etwa 50% des Codes Gui-Code sei - die andern 50% könnte man dann wiederverwenden - aber das ist dann so oder so immer noch ein Riesenaufwand.

MfG Peschmä

[oracle2025]

Original geschrieben von peschmae
Ich denke das gilt auch sonst für die GUI-Elemente unter Linux (KDE, Gnome) - die Sachen sind schon grösser, und manchmal stört das eben - wenn man zuwenig Platz hat nämlich.
So finde ich es durchaus sinnvoll, wenn z.B. die Toolwindows eine sehr kleine Titelleiste haben (wie bei Photoshop) während die "normale" App eine grössere Titelleiste haben darf...

Und das funktioniert auch bei Gimp(unstable) unter Gnome/Metacity.

[axeljaeger]

@anda_skoa:
Ich hab jedenfalls bei Karamba keinen Unterschied zwischen den Tabshapes gesehen.

[anda_skoa]

Wahrscheinlich hängt das vom Style ab.

Wenn ich im Designer ein TabWidget mache und im Property Editor umschalte, werden sie wesentlich kleiner.
Die einzelnen Arbeitslätter in KSpread benutzen auch die "triangle" geformten.

Ciao,
_

[peschmae]

Original geschrieben von oracle2025
Und das funktioniert auch bei Gimp(unstable) unter Gnome/Metacity.

Muss ich mir mal anschauen.
Benutze normalerweise den E und manchmal noch KDE.

MfG Peschmä

[axeljaeger]

Interessant: Das Tabshape triangular bei Plastik ist gar nichr tianglular, sondern einfach nur halb so hoch. Die normalen triangles, wie sie normalerweise bei Tabellenkalkulationen sind, finde ich recht hässlich. Ich hoffe, das die GimpToolwindows bald auch mit KDE gehen. Aber IMHO wird durch große Styles und die Verwendung von Standardwidgets zu viel Platz verschwendet

[peschmae]

ja. Bei anderen Programmen stört das nicht oder kaum (Browser oder so) - aber bei Gimp halt schon.

MfG Peschmä