Wie z.B. die Ablehnung von Programm-kontroliierten Fensterleisten? Zwecks Prävention von inkonsistentem Aussehen und Verhalten?
Hm, wenn diese Art der Gestaltung unbedingt gewollt ist, einige Manager können Tabbing schon. Brauchen dann nur noch allgemeine Unterstützung für frei definierbare Buttons neben den Tabs, die evtl. per D-Bus oder per X-Kram mit dem Programm reden, und fertig.
Und schon hat man etwas, was nicht nur einem Programm zugute kommt, sondern von allen genutzt werden kann.
Ach ja, diese "Erfindung" hat mich 2 min gekostet. Voll patentwürdig, sowas! Wie kann ich das hier nur der Allgemeinheit schenken, ich Kommunistensau! Die armen Patenttrolle müssen nun hunger darben...
Also wer in die Fensterleiste dynamische Knöpfe auf Basis von D-Bus implementiert gehört mMn ausgepeitscht.
Selbst wenn man den "X-Kram" verwendet stellt sich immer noch der Konflikt mit der vorhandenen Funktionalität von GTK+ (ClientSideblah) und der Fensterleiste selbst.
Wie soll das Teil eingebaut werden, was, wenn kein Platz mehr ist? Rollbalken in der Fensterleiste? Das Fenster einfach verbreitern?.
Was ist mit der optischen Aufbereitung? Genauso wie der Rest, sodass der Nutzer nix merkt, oder modifiziert, dass er was merkt (bpsw. dünne Linie drum herum)?
... Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.
>Also wer in die Fensterleiste dynamische Knöpfe auf Basis von D-Bus implementiert gehört mMn ausgepeitscht. >Selbst wenn man den "X-Kram" verwendet stellt sich immer noch der Konflikt mit der vorhandenen Funktionalität von GTK+ (ClientSideblah) und der Fensterleiste selbst.
Welche alternative Implementierung schlägst du vor? Die Jungs aus Redmond lassen die Programme einfach selbst in den Titelleistenbereich zeichnen. Da ist die Konsistenz mit dem Desktop aber unter Linux nicht gegeben, weil jeder seinen Desktop anders einstellt (und andere WMs verwendet). Meiner Ansicht nach wäre ein Weiterreichen der Tabs/Buttons an den WM (von mir aus über D-Bus oder sonstwie, X-Kram wäre schlecht wegen Wayland) eine gangbare Lösung, die sich dann auch gut in den Desktop integrieren würde (wenn der WM mitspielt). Natürlich müsste man das ganze in irgendwelchen Klassen mit Fallback-Option kapseln (KTabIrgendwas).
> Wie soll das Teil eingebaut werden, was, wenn kein Platz mehr ist? Rollbalken in der Fensterleiste? Das Fenster einfach verbreitern?. Soweit ich weiß gibt es Mindestgrößen für Fenster. Die muss halt passend berechnet werden.
> Was ist mit der optischen Aufbereitung? Genauso wie der Rest, sodass der Nutzer nix merkt, oder modifiziert, dass er was merkt (bpsw. dünne Linie drum herum)? Das würde ich dem WM überlassen. Meine Präferenz wäre ein eher integrierter Look.
> ... Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt. Die Titelleiste ist bei Browsern heutzutage IMO reine Platzverschwendung (Besonders unter Gnome3). Chrome hat angefangen die klassische Struktur eines Fensters über den Haufen zu werfen, und es lässt sich tatsächlich klasse bedienen (besonders auf einem Netbook). Mozilla ist unter Zugzwang. Was ohne eine Lösung für Tabs und Buttons in der Titelleiste passiert, ist Wildwuchs den wir jetzt schon beobachten können: Chromium zeichnet seine eigenen Rahmen, FF, Opera und andere machen gar nix (dafür dann Addons wie Oxygen-FF). Am Ende wird daraus ein Argument gegen Linux: Es ist zu konservativ und verschwendet Platz mit Titelleisten
Noch nebenbei (Off-Topic): Der Firefox ist immer noch lange nicht so schnell wie Chrome (meiner subjektiven Wahrnehmung nach) - zumindest nicht unter Linux. Die gute Performance von Chromium ist ein schöner Nebeneffekt von Chrome OS (von dem ich BTW nichts halte)
>> Welche alternative Implementierung schlägst du vor?
Bei D-Bus ist es nicht so einfach. Sowohl das Programm und der WM müssen sich verstehen, das erfordert dann Anpassungen an zwei Programmen, statt an einem. Was ist, wenn der WM das nicht unterstützt? Dann fehlt ein Element (der kluge Entwickler baut natürlich einen Fallback ein).
"Undekorierte" Fenster verstehen alle WM (vom WM undekoriert, dafür vom Toolkit). Die GTK+-Lösung ist also die bessere Variante, verglichen mit D-Bus. Wenn das Toolkit die Deko zeichnet, dann ist es egal, welchen WM du benutzt (solange NETWM und EWMH eingehalten werden).
D-Bus ist z. B. ein architektonischer Grund, warum die GNOME-Shell nur mit Mutter funktioniert (um auch mal einen Nachteil aus der Praxis aufzugreifen).
>> Soweit ich weiß gibt es Mindestgrößen für Fenster. Die muss halt passend berechnet werden.
Andersrum, wenn das Fensterleiste zu schmal ist für den Knopf. Zudem gibt es auch Maximalgrößen für Fenster, oder Fenster die nicht in Ihrer Größe veränderbar sind.
>> Das würde ich dem WM überlassen. Meine Präferenz wäre ein eher integrierter Look.
Schon klar, aber: wieder Inkosistenz.
>> Die Titelleiste ist bei Browsern heutzutage IMO reine Platzverschwendung (Besonders unter Gnome3).
Das kommt darauf an, wie du sie benutzt. Viele WM erlauben es Fenster-Regeln zu verwenden, dann haben diese z. B. gar keinen Rahmen. Und für Tabbed-Windowing brauchst du den dann doch meistens. Die meisten gängigen WM haben keine (oder keine intuitiven) Tastenkombinationen fürs Minimieren & Co., sodass auch hier wieder eine Titelleiste von Nöten ist (viele Ex-WindowsUser verwenden grundsätzlich nur Knöpfe).
Wie ich Eingangs schon erwähnte:
>>Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.< <
> Bei D-Bus ist es nicht so einfach. Sowohl das Programm und der WM müssen sich verstehen, das erfordert dann Anpassungen an zwei Programmen, statt an einem. Was ist, wenn der WM das nicht unterstützt? Dann fehlt ein Element (der kluge Entwickler baut natürlich einen Fallback ein). Der Fallback war in meiner Idee bereits vorgesehen. Das Toolkit stellt eine Abstraktionsschicht bereit, die den WM benutzt oder eben das Fallback.
> "Undekorierte" Fenster verstehen alle WM (vom WM undekoriert, dafür vom Toolkit). Die GTK+-Lösung ist also die bessere Variante, verglichen mit D-Bus. Wenn das Toolkit die Deko zeichnet, dann ist es egal, welchen WM du benutzt (solange NETWM und EWMH eingehalten werden). Damit wird aber der WM völlig ausgehebelt und die Benutzerpräferenzen(Button-Reihenfolge, Stil etc) nicht beachtet. Das Ergebnis ist sowas wie Chrome, dass sich überhaupt nicht in die Fensterverwaltung integriert. Das ist dann zwar konsistent zum Rest des Programms, aber nicht zum Desktop.
>Andersrum, wenn das Fensterleiste zu schmal ist für den Knopf. Zudem gibt es auch Maximalgrößen für Fenster, oder Fenster die nicht in Ihrer Größe veränderbar sind. Das soll der WM gefälligst regeln. In Redmond darf jedes Programm so viel Zeichenbereich in der Titelleiste beantragen wie nötig und es funktioniert.
> Das kommt darauf an, wie du sie benutzt. Viele WM erlauben es Fenster-Regeln zu verwenden, dann haben diese z. B. gar keinen Rahmen. Und für Tabbed-Windowing brauchst du den dann doch meistens. Die meisten gängigen WM haben keine (oder keine intuitiven) Tastenkombinationen fürs Minimieren & Co., sodass auch hier wieder eine Titelleiste von Nöten ist (viele Ex-WindowsUser verwenden grundsätzlich nur Knöpfe). Unter KDE kannst du für alles und jeden eine Tastenkombination deiner Wahl einstellen. Tabbed Windowing find ich nett, hat aber für mich fast keine Bedeutung, da ich praktisch kein bisschen mehr Übersicht dadurch gewinne. Es ist dann zwar ein Fenster statt 3 aber immer noch 3 Einträge in der Fensterliste. Wenn ich Ordnung haben will geh ich auf ne weitere Arbeitsfläche. Ja, Fensterregeln sind nett aber den Schliessen-Button brauche ich noch. In Gnome3 ist die Titelleiste, die nur noch als Verschiebe-Anfaser und Platzhalter für den Schliessen-Knopf fungiert, total oversized. Chrome macht sehr schön vor, dass der Platz dort (je nach Anwendung natürlich) deutlich sinnvoller genutzt werden kann.
>>Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.< < Da magst du Recht haben. Den Streitpunkt bisher ist, wer denn nun Tabs und Buttons in der Titelleiste zeichnen soll: Das Programm oder der WM. Wie bereits gesagt, in Redmond tritt der WM dem Programm Platz in der Leiste ab, wo es dann sein Zeug zeichnen kann. Integration ist kein Problem, da in Redmond jeder Fensterrahmen gleich aussieht. Ganz davon abgesehen, dass das unter X nur durch gößere Tricksereien möglich sein würde, stellt jeder seine Fensterdekoration ganz unterschiedlich ein, und alle WMs verhalten sich unterschiedlich und es würde ein größeres Chaos geben, da bin ich mir sicher. Wenn der WM Tabs und Buttons in der Leiste zeichnet, sieht das bestimmt gut integriert in den Desktop aus, ist aber ein großer Aufwand für die WMs und kann Bedürfnisse der Anwendungen u.U. nur teilweise erfüllen. Wenn wir den kompletten Rahmen und die Knöpfe vom Toolkit zeichnen lassen, werfen wir praktisch den WM samt seiner Dekoration und den Benutzereinstellungen über Bord. Für was haben wir ihn dann?
Es gibt unter X11 wohl keine geeignete Lösung, die alle Bedürfnisse erfüllt und halbwegs einfach zu implementieren ist. Du hast recht, es wäre alles ein riesiger Hack ohne viel Sinn. Ich weiß nicht, ob sich das unter Wayland ändern wird, lassen wir uns mal überraschen.
Ich denke nicht, dass sich das außerhalb von Spezialgebieten - wie Browsern - durchsetzen kann. Vor allem bei unmaximierten Fenstern ist das bisherige Verfahren um ein Vielfaches besser (weil mehr Platz): jetziges Verfahren: Navigationsleiste = volle Bildschirmbreite (- ein paar px Fensterrahmen). neues Verfahren: Bildschirmbreite - Fenstertitel - Fenstersymbol - Fensterknöpfe - Fensterrahmen.
> Ich denke nicht, dass sich das außerhalb von Spezialgebieten - wie Browsern - durchsetzen kann. In wie weit ist ein Browser noch ein Spezialgebiet? Der Browser ist schon lange eine Mainstream-Anwendung, die manche Benutzer durchgehend verwenden. Auch andere Programme wei z.B der Dateimanager oder die Virtualisierungssoftware lassen sich Browserartig aufziehen, mit Tabs und so (wird ja teilweise schon gemacht). Auch Projekte wie Chrome OS zeigen, wie wichtig der Browser heute schon ist. (Damit wird Microsofts Ur-Angst, dass Applikationen nicht mehr Windows sondern einen Browser (a la Netscape) benötigen, was u.A. zur Entwicklung des IE geführt hat, nun wirklich berechtigt)
> neues Verfahren: Bildschirmbreite - Fenstertitel - Fenstersymbol - Fensterknöpfe - Fensterrahmen. So was macht nur der IE, denn das ist nun wirklich Usability-Schrott. Die Tableiste kommt extra, und enthält praktisch schon den Fenstertitel und den Schliessen-Button (wenn's nach den Gnome-Entwicklern ginge ist das auch der einzige den man braucht). Wegen einem Symbol und zwei, drei Knöpfen und einem Redundanten Text eine ganze Leiste zu reservieren ist Verschwendung. Das Hauptaugenmerk soll ja auf dem Inhalt liegen. Das einfach durchzusetzen hat sich bisher nur Google getraut.
Ja, der Browser mag im Vergleich zu der Menge an anderen Applikationen eine Spezialanwendung sein, allerdings eine die ständig gebraucht wird, die (annähernd) jeder benutzt, die als Basis für andere Applikationen dient (und verstärkt dienen wird) und die mit der Titelleiste unglaublich Platz verschwendet. Es mag zu viel sein, für einen Typ von Anwendung einen riesigen Grafikhack zu implementieren, aber man darf Browser niemals aus dem Blickwinkel verlieren, und man wird sich damit abfinden müssen, dass die Entwickler sich nun mit der Zeit kreative Lösungen für das Problem überlegen werden.
Das "Spezialanwendung" bezog sich auf diesen Anwendungsfall.
>> So was macht nur der IE, denn das ist nun wirklich Usability-Schrott.
So arbeitet jeder WM standarmäßig, das hat nichts mit dem IE zu tun.
>> unglaublich Platz verschwendet.
Tatsächlich, hab mir mal von SF die die Rahmenhöhe ausgeben lassen: 24 Pixel!
Worin liegt der Vorteil alles in die Titelleiste zu verschieben, wenn man diese auch einfach weglassen kann? Dann spart man sich die paar Pixel und Fenster-Aktionen sollten sich nach wie vor über Pager und/oder Fensterliste abspielen lassen (oder Tastenkombinationen). Im Vollbildmodus wird das ja schon längst praktiziert.
>> So arbeitet jeder WM standarmäßig, das hat nichts mit dem IE zu tun.
Ich glaube hier liegt ein Missverständnis vor. Ich meinte die Tatsache, dass der IE9 alles in eine(!) Leiste packt: Tabs, Adressfeld, Menüs, Minimieren-Maximieren-Schließen. Da sieht man dann weder die URL noch den Titel eines Tabs, wenn man genug davon offen hat.
>>Worin liegt der Vorteil alles in die Titelleiste zu verschieben, wenn man diese auch einfach weglassen kann? Dann spart man sich die paar Pixel und Fenster-Aktionen sollten sich nach wie vor über Pager und/oder Fensterliste abspielen lassen (oder Tastenkombinationen). Im Vollbildmodus wird das ja schon längst praktiziert.
Wenn man FF in Vollbild schaltet (F11) wandern die Schließen-Maximieren-Minimieren Buttons in rechts oben in die Tab-Leiste. Ob man jetzt die Buttons nach unten oder die Tabs nach oben verschiebt kommt insgesamt aufs gleiche raus. Nur ist der WM nur bei letzterem beteiligt.
Ja, ich weiß die Buttons sind nicht unbedingt notwendig aber v.A. Windows-Umsteiger bedienen ihre Fenster sehr gerne darüber (und andere Leute auch). Ich habe Chrome schon mehrmals erwähnt und tue es hier noch mal: Chrome blendet einfach den Fensterrahmen und die Titelleiste aus und zeichnet die drei Buttons selbst in die Tab-Leiste. Unter X11 ist das IMO der einfachste gangbare Weg mit dem gewünschten Ergebnis - Bis auf Desktopintegration aber das will Chrome sowieso nicht.
"Wie soll das Teil eingebaut werden, was, wenn kein Platz mehr ist?" Na, genauso wie sonst überall, wenn kein Platz mehr ist: Entweder [ Knöpfe oder ein [\/] Knopf, vgl. Tableiste des Toolkits Deiner Wahl.
"optischen Aufbereitung" ? Hm, was soll hier aufbereitet werden? Schau z.B. mal die KWin-Lösung an, http://www.undefinedfire.com/kde/window-tabbing-merged/ Da noch links und rechts Knöpfe ermöglichen, und schon ist das super aufbereitet, nicht?
Das ist doch was völlig anderes. Das sind getabbte Fenster, nicht Tabs des Browsers in der Fensterleiste. Zudem geht das ganze über Tabs hinaus, wie z. B. der Firefox-Knopf o. ä.
Wie habe ich mich erschreckt als ich den Screenshot mit der Adress- und Tableiste in einer Zeile gesehen habe. Das hat MS schon eingebaut und es ist schrecklich. Da kann kein Mensch arbeiten. Müssen die Mozilla-Leute immer allen hinterherrennen und die UI kopieren? Ich erwarte mal etwas innovatives, ein wirklich gutes Konzept. Aber offensichtlich kommen die guten Ideen inzwischen bei Google.
Man bräuchte doch nur einen Linux-Gecko-Browser so wie Epiphany-Gecko einmal einer war, der einigermaßen an die Linuxverhältnisse angepasst ist. Galeon etwa gibt es immer noch in Debian Squeeze, eine Art GTK-GUI für Gecko/Xulrunner. Ein wirkliches Linux-Problem sind diese "Mozilla-Designideen für Windows" also im Grunde nicht.
"vorhanden technischen Probleme unter Linux"
Wie z.B. die Ablehnung von Programm-kontroliierten Fensterleisten? Zwecks Prävention von inkonsistentem Aussehen und Verhalten?
Hm, wenn diese Art der Gestaltung unbedingt gewollt ist, einige Manager können Tabbing schon. Brauchen dann nur noch allgemeine Unterstützung für frei definierbare Buttons neben den Tabs, die evtl. per D-Bus oder per X-Kram mit dem Programm reden, und fertig.
Und schon hat man etwas, was nicht nur einem Programm zugute kommt, sondern von allen genutzt werden kann.
Ach ja, diese "Erfindung" hat mich 2 min gekostet. Voll patentwürdig, sowas! Wie kann ich das hier nur der Allgemeinheit schenken, ich Kommunistensau! Die armen Patenttrolle müssen nun hunger darben...
Also wer in die Fensterleiste dynamische Knöpfe auf Basis von D-Bus implementiert gehört mMn ausgepeitscht.
Selbst wenn man den "X-Kram" verwendet stellt sich immer noch der Konflikt mit der vorhandenen Funktionalität von GTK+ (ClientSideblah) und der Fensterleiste selbst.
Wie soll das Teil eingebaut werden, was, wenn kein Platz mehr ist? Rollbalken in der Fensterleiste? Das Fenster einfach verbreitern?.
Was ist mit der optischen Aufbereitung? Genauso wie der Rest, sodass der Nutzer nix merkt, oder modifiziert, dass er was merkt (bpsw. dünne Linie drum herum)?
... Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.
>Also wer in die Fensterleiste dynamische Knöpfe auf Basis von D-Bus implementiert gehört mMn ausgepeitscht.
>Selbst wenn man den "X-Kram" verwendet stellt sich immer noch der Konflikt mit der vorhandenen Funktionalität von GTK+ (ClientSideblah) und der Fensterleiste selbst.
Welche alternative Implementierung schlägst du vor? Die Jungs aus Redmond lassen die Programme einfach selbst in den Titelleistenbereich zeichnen. Da ist die Konsistenz mit dem Desktop aber unter Linux nicht gegeben, weil jeder seinen Desktop anders einstellt (und andere WMs verwendet). Meiner Ansicht nach wäre ein Weiterreichen der Tabs/Buttons an den WM (von mir aus über D-Bus oder sonstwie, X-Kram wäre schlecht wegen Wayland) eine gangbare Lösung, die sich dann auch gut in den Desktop integrieren würde (wenn der WM mitspielt). Natürlich müsste man das ganze in irgendwelchen Klassen mit Fallback-Option kapseln (KTabIrgendwas).
> Wie soll das Teil eingebaut werden, was, wenn kein Platz mehr ist? Rollbalken in der Fensterleiste? Das Fenster einfach verbreitern?.
Soweit ich weiß gibt es Mindestgrößen für Fenster. Die muss halt passend berechnet werden.
> Was ist mit der optischen Aufbereitung? Genauso wie der Rest, sodass der Nutzer nix merkt, oder modifiziert, dass er was merkt (bpsw. dünne Linie drum herum)?
Das würde ich dem WM überlassen. Meine Präferenz wäre ein eher integrierter Look.
> ... Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.
Die Titelleiste ist bei Browsern heutzutage IMO reine Platzverschwendung (Besonders unter Gnome3). Chrome hat angefangen die klassische Struktur eines Fensters über den Haufen zu werfen, und es lässt sich tatsächlich klasse bedienen (besonders auf einem Netbook). Mozilla ist unter Zugzwang. Was ohne eine Lösung für Tabs und Buttons in der Titelleiste passiert, ist Wildwuchs den wir jetzt schon beobachten können: Chromium zeichnet seine eigenen Rahmen, FF, Opera und andere machen gar nix (dafür dann Addons wie Oxygen-FF). Am Ende wird daraus ein Argument gegen Linux: Es ist zu konservativ und verschwendet Platz mit Titelleisten
Noch nebenbei (Off-Topic): Der Firefox ist immer noch lange nicht so schnell wie Chrome (meiner subjektiven Wahrnehmung nach) - zumindest nicht unter Linux. Die gute Performance von Chromium ist ein schöner Nebeneffekt von Chrome OS (von dem ich BTW nichts halte)
>> Welche alternative Implementierung schlägst du vor?
Bei D-Bus ist es nicht so einfach. Sowohl das Programm und der WM müssen sich verstehen, das erfordert dann Anpassungen an zwei Programmen, statt an einem. Was ist, wenn der WM das nicht unterstützt? Dann fehlt ein Element (der kluge Entwickler baut natürlich einen Fallback ein).
"Undekorierte" Fenster verstehen alle WM (vom WM undekoriert, dafür vom Toolkit). Die GTK+-Lösung ist also die bessere Variante, verglichen mit D-Bus. Wenn das Toolkit die Deko zeichnet, dann ist es egal, welchen WM du benutzt (solange NETWM und EWMH eingehalten werden).
D-Bus ist z. B. ein architektonischer Grund, warum die GNOME-Shell nur mit Mutter funktioniert (um auch mal einen Nachteil aus der Praxis aufzugreifen).
>> Soweit ich weiß gibt es Mindestgrößen für Fenster. Die muss halt passend berechnet werden.
Andersrum, wenn das Fensterleiste zu schmal ist für den Knopf. Zudem gibt es auch Maximalgrößen für Fenster, oder Fenster die nicht in Ihrer Größe veränderbar sind.
>> Das würde ich dem WM überlassen. Meine Präferenz wäre ein eher integrierter Look.
Schon klar, aber: wieder Inkosistenz.
>> Die Titelleiste ist bei Browsern heutzutage IMO reine Platzverschwendung (Besonders unter Gnome3).
Das kommt darauf an, wie du sie benutzt. Viele WM erlauben es Fenster-Regeln zu verwenden, dann haben diese z. B. gar keinen Rahmen. Und für Tabbed-Windowing brauchst du den dann doch meistens. Die meisten gängigen WM haben keine (oder keine intuitiven) Tastenkombinationen fürs Minimieren & Co., sodass auch hier wieder eine Titelleiste von Nöten ist (viele Ex-WindowsUser verwenden grundsätzlich nur Knöpfe).
Wie ich Eingangs schon erwähnte:
>>Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.< <
> Bei D-Bus ist es nicht so einfach. Sowohl das Programm und der WM müssen sich verstehen, das erfordert dann Anpassungen an zwei Programmen, statt an einem. Was ist, wenn der WM das nicht unterstützt? Dann fehlt ein Element (der kluge Entwickler baut natürlich einen Fallback ein).
Der Fallback war in meiner Idee bereits vorgesehen. Das Toolkit stellt eine Abstraktionsschicht bereit, die den WM benutzt oder eben das Fallback.
> "Undekorierte" Fenster verstehen alle WM (vom WM undekoriert, dafür vom Toolkit). Die GTK+-Lösung ist also die bessere Variante, verglichen mit D-Bus. Wenn das Toolkit die Deko zeichnet, dann ist es egal, welchen WM du benutzt (solange NETWM und EWMH eingehalten werden).
Damit wird aber der WM völlig ausgehebelt und die Benutzerpräferenzen(Button-Reihenfolge, Stil etc) nicht beachtet. Das Ergebnis ist sowas wie Chrome, dass sich überhaupt nicht in die Fensterverwaltung integriert.
Das ist dann zwar konsistent zum Rest des Programms, aber nicht zum Desktop.
>Andersrum, wenn das Fensterleiste zu schmal ist für den Knopf. Zudem gibt es auch Maximalgrößen für Fenster, oder Fenster die nicht in Ihrer Größe veränderbar sind.
Das soll der WM gefälligst regeln. In Redmond darf jedes Programm so viel Zeichenbereich in der Titelleiste beantragen wie nötig und es funktioniert.
> Das kommt darauf an, wie du sie benutzt. Viele WM erlauben es Fenster-Regeln zu verwenden, dann haben diese z. B. gar keinen Rahmen. Und für Tabbed-Windowing brauchst du den dann doch meistens. Die meisten gängigen WM haben keine (oder keine intuitiven) Tastenkombinationen fürs Minimieren & Co., sodass auch hier wieder eine Titelleiste von Nöten ist (viele Ex-WindowsUser verwenden grundsätzlich nur Knöpfe).
Unter KDE kannst du für alles und jeden eine Tastenkombination deiner Wahl einstellen. Tabbed Windowing find ich nett, hat aber für mich fast keine Bedeutung, da ich praktisch kein bisschen mehr Übersicht dadurch gewinne. Es ist dann zwar ein Fenster statt 3 aber immer noch 3 Einträge in der Fensterliste. Wenn ich Ordnung haben will geh ich auf ne weitere Arbeitsfläche. Ja, Fensterregeln sind nett aber den Schliessen-Button brauche ich noch. In Gnome3 ist die Titelleiste, die nur noch als Verschiebe-Anfaser und Platzhalter für den Schliessen-Knopf fungiert, total oversized. Chrome macht sehr schön vor, dass der Platz dort (je nach Anwendung natürlich) deutlich sinnvoller genutzt werden kann.
>>Das Ganze verursacht mehr Probleme oder Umstände, als gelöst werden. Von daher bin ich froh, dass sich das unter X11 nicht durchsetzt.< <
Da magst du Recht haben. Den Streitpunkt bisher ist, wer denn nun Tabs und Buttons in der Titelleiste zeichnen soll: Das Programm oder der WM. Wie bereits gesagt, in Redmond tritt der WM dem Programm Platz in der Leiste ab, wo es dann sein Zeug zeichnen kann. Integration ist kein Problem, da in Redmond jeder Fensterrahmen gleich aussieht. Ganz davon abgesehen, dass das unter X nur durch gößere Tricksereien möglich sein würde, stellt jeder seine Fensterdekoration ganz unterschiedlich ein, und alle WMs verhalten sich unterschiedlich und es würde ein größeres Chaos geben, da bin ich mir sicher. Wenn der WM Tabs und Buttons in der Leiste zeichnet, sieht das bestimmt gut integriert in den Desktop aus, ist aber ein großer Aufwand für die WMs und kann Bedürfnisse der Anwendungen u.U. nur teilweise erfüllen. Wenn wir den kompletten Rahmen und die Knöpfe vom Toolkit zeichnen lassen, werfen wir praktisch den WM samt seiner Dekoration und den Benutzereinstellungen über Bord. Für was haben wir ihn dann?
Es gibt unter X11 wohl keine geeignete Lösung, die alle Bedürfnisse erfüllt und halbwegs einfach zu implementieren ist. Du hast recht, es wäre alles ein riesiger Hack ohne viel Sinn.
Ich weiß nicht, ob sich das unter Wayland ändern wird, lassen wir uns mal überraschen.
Ich denke nicht, dass sich das außerhalb von Spezialgebieten - wie Browsern - durchsetzen kann. Vor allem bei unmaximierten Fenstern ist das bisherige Verfahren um ein Vielfaches besser (weil mehr Platz): jetziges Verfahren: Navigationsleiste = volle Bildschirmbreite (- ein paar px Fensterrahmen). neues Verfahren: Bildschirmbreite - Fenstertitel - Fenstersymbol - Fensterknöpfe - Fensterrahmen.
> Ich denke nicht, dass sich das außerhalb von Spezialgebieten - wie Browsern - durchsetzen kann.
In wie weit ist ein Browser noch ein Spezialgebiet? Der Browser ist schon lange eine Mainstream-Anwendung, die manche Benutzer durchgehend verwenden. Auch andere Programme wei z.B der Dateimanager oder die Virtualisierungssoftware lassen sich Browserartig aufziehen, mit Tabs und so (wird ja teilweise schon gemacht). Auch Projekte wie Chrome OS zeigen, wie wichtig der Browser heute schon ist. (Damit wird Microsofts Ur-Angst, dass Applikationen nicht mehr Windows sondern einen Browser (a la Netscape) benötigen, was u.A. zur Entwicklung des IE geführt hat, nun wirklich berechtigt)
> neues Verfahren: Bildschirmbreite - Fenstertitel - Fenstersymbol - Fensterknöpfe - Fensterrahmen.
So was macht nur der IE, denn das ist nun wirklich Usability-Schrott. Die Tableiste kommt extra, und enthält praktisch schon den Fenstertitel und den Schliessen-Button (wenn's nach den Gnome-Entwicklern ginge ist das auch der einzige den man braucht). Wegen einem Symbol und zwei, drei Knöpfen und einem Redundanten Text eine ganze Leiste zu reservieren ist Verschwendung. Das Hauptaugenmerk soll ja auf dem Inhalt liegen. Das einfach durchzusetzen hat sich bisher nur Google getraut.
Ja, der Browser mag im Vergleich zu der Menge an anderen Applikationen eine Spezialanwendung sein, allerdings eine die ständig gebraucht wird, die (annähernd) jeder benutzt, die als Basis für andere Applikationen dient (und verstärkt dienen wird) und die mit der Titelleiste unglaublich Platz verschwendet.
Es mag zu viel sein, für einen Typ von Anwendung einen riesigen Grafikhack zu implementieren, aber man darf Browser niemals aus dem Blickwinkel verlieren, und man wird sich damit abfinden müssen, dass die Entwickler sich nun mit der Zeit kreative Lösungen für das Problem überlegen werden.
Das "Spezialanwendung" bezog sich auf diesen Anwendungsfall.
>> So was macht nur der IE, denn das ist nun wirklich Usability-Schrott.
So arbeitet jeder WM standarmäßig, das hat nichts mit dem IE zu tun.
>> unglaublich Platz verschwendet.
Tatsächlich, hab mir mal von SF die die Rahmenhöhe ausgeben lassen: 24 Pixel!
Worin liegt der Vorteil alles in die Titelleiste zu verschieben, wenn man diese auch einfach weglassen kann? Dann spart man sich die paar Pixel und Fenster-Aktionen sollten sich nach wie vor über Pager und/oder Fensterliste abspielen lassen (oder Tastenkombinationen). Im Vollbildmodus wird das ja schon längst praktiziert.
Ich sehe keinen, außer das man Zeit verschwendet.
>> So arbeitet jeder WM standarmäßig, das hat nichts mit dem IE zu tun.
Ich glaube hier liegt ein Missverständnis vor. Ich meinte die Tatsache, dass der IE9 alles in eine(!) Leiste packt: Tabs, Adressfeld, Menüs, Minimieren-Maximieren-Schließen. Da sieht man dann weder die URL noch den Titel eines Tabs, wenn man genug davon offen hat.
>>Worin liegt der Vorteil alles in die Titelleiste zu verschieben, wenn man diese auch einfach weglassen kann? Dann spart man sich die paar Pixel und Fenster-Aktionen sollten sich nach wie vor über Pager und/oder Fensterliste abspielen lassen (oder Tastenkombinationen). Im Vollbildmodus wird das ja schon längst praktiziert.
Wenn man FF in Vollbild schaltet (F11) wandern die Schließen-Maximieren-Minimieren Buttons in rechts oben in die Tab-Leiste. Ob man jetzt die Buttons nach unten oder die Tabs nach oben verschiebt kommt insgesamt aufs gleiche raus. Nur ist der WM nur bei letzterem beteiligt.
Ja, ich weiß die Buttons sind nicht unbedingt notwendig aber v.A. Windows-Umsteiger bedienen ihre Fenster sehr gerne darüber (und andere Leute auch). Ich habe Chrome schon mehrmals erwähnt und tue es hier noch mal: Chrome blendet einfach den Fensterrahmen und die Titelleiste aus und zeichnet die drei Buttons selbst in die Tab-Leiste. Unter X11 ist das IMO der einfachste gangbare Weg mit dem gewünschten Ergebnis - Bis auf Desktopintegration aber das will Chrome sowieso nicht.
>> Ich glaube hier liegt ein Missverständnis vor.
Stimmt, du hast mich missverstanden
Aber gut. Solange X11 kein monolithischer Blob ist, wird sich keine optimale Lösung finden.
"Wie soll das Teil eingebaut werden, was, wenn kein Platz mehr ist?"
Na, genauso wie sonst überall, wenn kein Platz mehr ist: Entweder [ Knöpfe oder ein [\/] Knopf, vgl. Tableiste des Toolkits Deiner Wahl.
"optischen Aufbereitung"
? Hm, was soll hier aufbereitet werden? Schau z.B. mal die KWin-Lösung an, http://www.undefinedfire.com/kde/window-tabbing-merged/
Da noch links und rechts Knöpfe ermöglichen, und schon ist das super aufbereitet, nicht?
Pardon, Größer- und Kleiner-Zeichen aufgegessen, sollte sein:
Entweder [<][>] Knöpfe oder ein [\/] Knopf
Das ist doch was völlig anderes. Das sind getabbte Fenster, nicht Tabs des Browsers in der Fensterleiste. Zudem geht das ganze über Tabs hinaus, wie z. B. der Firefox-Knopf o. ä.
Wie habe ich mich erschreckt als ich den Screenshot mit der Adress- und Tableiste in einer Zeile gesehen habe. Das hat MS schon eingebaut und es ist schrecklich. Da kann kein Mensch arbeiten. Müssen die Mozilla-Leute immer allen hinterherrennen und die UI kopieren? Ich erwarte mal etwas innovatives, ein wirklich gutes Konzept. Aber offensichtlich kommen die guten Ideen inzwischen bei Google.
Och, wie süüüüüüüß! Auch so originell und gar nicht wie Chrome! Das ist klasse! Reizüberflutuuuuuuuuuung! Jaaaaaaaaaaa! Kopfschuuuuuuuuss!
Ich bleibe dann bei Rekonq, oder eben Midori für GTK.
Man bräuchte doch nur einen Linux-Gecko-Browser so wie Epiphany-Gecko einmal einer war, der einigermaßen an die Linuxverhältnisse angepasst ist.
Galeon etwa gibt es immer noch in Debian Squeeze, eine Art GTK-GUI für Gecko/Xulrunner.
Ein wirkliches Linux-Problem sind diese "Mozilla-Designideen für Windows" also im Grunde nicht.