Die augenfälligste Neuerung ist der Wegfall der Fensterdekorationen am oberen Rand eines Fensters.
Dass die Menüzeile bei verschiedenen Programmen weg ist, finde ich durchaus angenehm. Die verschwendet eh Platz, wenn das Fenster sowieso nicht aktiv ist. Dass die Änderungen für (u.A.) den Schließen-Knopf pro Anwendung gemacht werden muss ist klar. Chromium ist da ein gutes Beispiel, die hatten schon lange keine eigenen Dekorationen im maximierten Zustand, aber trotzdem die Buttons.
Gnome-Music: Momentan benutze ich Rhythmbox und bin auch sehr zufrieden damit. Solange die Kommandozeilenbefehle zum Umschalten der Lieder vorhanden bleiben, bin ich zufrieden.
Gnome-Photos: Ähm... der momentane Standardviewer ist Müll, ich benutze immer noch gthumb. Damit kann ich wenigstens per Tastenkombination benutzerdefinierte Kommandos ausführen.
Was ist eigentlich aus Gnome-Boxes geworden? Irgendwann hatte ich das mal (automatisch) installiert und war ein netter, einfacher virt-manager-Ersatz, zumindest für den Heimdesktop. Jetzt hat meine distri es nicht mehr... wurde es als "unfertig" deklariert oder so?
Abgesehen davon ist mir neulich ein tolles Feature in Nauti.... "Files" aufgefallen: Wenn man einfach drauflostippt, läuft eine *rekursive* Suche durch den Verzeichnisbaum. Sehr geil
Alles in allem bin ich also recht zufrieden mit Gnome, abgesehen davon, dass Brasero bei mir ohne Meldung keinen Brennvorgang startet (stattdessen nehme ich k3b) und dass die gthumb-Ersätze und "Web" Müll sind.
und eine Kopfzeile eingeführt, die Client-seitig gezeichnet wird und den Bedienelementen auch bei maximiertem Fenster Platz bietet. Noch sind längst nicht alle Anwendungen auf die neue Kopfzeile umgestellt, da dies in jeder Anwendung separat implementiert werden muss.
Das klingt so, als würde das Zeichnen der minimieren, maximieren und schließen Buttons bei Gnome 3 Anwendungen nicht mehr vom Fenstermanager, sondern von der Anwendung selbst erledigt werden müssen.
Im günstigsten Fall führt das dann unter anderen Desktop Oberflächen oder Window Managern dazu, dass sowohl der Fensterbereich der Anwendung, als auch die Fensterleiste die vom WM kommt, derartige Buttons haben. Haben dopppelt vorhanden sind.
Und im schlimmsten Fall führt das Schließen der Anwendung über die Buttons in der Fensterleiste des WM dazu, dass die Anwendung nicht mehr ordentlich beendet wird, weil man hier vielleicht auch noch den Klebstoff unter der Haube dazwischen wegrationalisiert hat.
Und im schlimmsten Fall führt das Schließen der Anwendung über die Buttons in der Fensterleiste des WM dazu, dass die Anwendung nicht mehr ordentlich beendet wird, weil man hier vielleicht auch noch den Klebstoff unter der Haube dazwischen wegrationalisiert hat.
Also vergleichbar einem
kill -9 pid
Und dann wäre da noch die Frage, wie man nun andere GUI Toolkit fremde Anwendungen, also z.B. qt Anwendungen schließt, wenn der WM von Gnome 3 keine derartigen Schließen Buttons mehr zeichnet und das nun die Anwendung übernehmen soll?
z.B. qt Anwendungen schließt, wenn der WM von Gnome 3 keine derartigen Schließen Buttons mehr zeichnet
Man kann wohl ziemlich sicher davon ausgehen, dass das nur dann gemacht wird, wenn die Anwendung explizit die Gnome-variante der GTK-Bibliothek verwendet.
AFAIK werden unter X Window die Fensterumrandungen vom WM gezeichnet und nicht vom GUI Toolkit. Und von wo soll der WM das wissen, dass es keine GTK Anwendung ist?
Da müßte man schon den WM und die GTK lib spezial darauf anpassen, so dass diese mitteilt (ich bin eine GTK 3) Anwendung und er WM dann bei allen anderen, die keine Meldung dieser Art bringen, den Fensterrahmen wie gehabt zeichnet.
Insofern nein, man kann nicht mit ziemlicher Sicherheit davon ausgehen. Das wäre nur der Fall, wenn die Fensterleiste auch vom GUI Toolkit gezeichnet werden würden.
AFAIK werden unter X Window die Fensterumrandungen vom WM gezeichnet und nicht vom GUI Toolkit.
Der WM selbst könnte natürlich auch das GUI Toolkit verwenden, bin da nicht so sicher wie das genau gemacht wird, aber was ich meine ist eben die Anwendung die das GUI Toolkit nutzt.
Im Prinzip ist es momentan AFAIK so:
Die Anwendung bekommt einen Fensterbereich, darin kann sie reinzeichnen. Dies kann unter Zuhilfenahme einwes GUI Tookits wie QT oder GTK usw. geschehen.
Um den Fensterbereich malt nun der WM die Fensterleiste und den Rahmen, auch hier wäre es denkbar, dass dieser selbst wieder ein GUI Toolkit dafür verwendet.
Eine QT Anwendung würde also mit QT ihren Fensterbereich zeichnen, aber der WM Manager, der z.B. GTK+ benutzt, würde die Rahmen dann mit GTK+ malen. Richtig?
Bei Chrom(e|ium) klappt das schon seit Jahren wunderbar. Warum sollte das jetzt anders werden? Abgesehen davon: Sobald Wayland kommt muss sowieso jeder Fenstermanager den Kram selber implementieren.
Gnome-Music:
Momentan benutze ich Rhythmbox und bin auch sehr zufrieden damit. Solange die Kommandozeilenbefehle zum Umschalten der Lieder vorhanden bleiben, bin ich zufrieden.
Gnome-Photos:
Ähm... der momentane Standardviewer ist Müll, ich benutze immer noch gthumb. Damit kann ich wenigstens per Tastenkombination benutzerdefinierte Kommandos ausführen.
Was ist eigentlich aus Gnome-Boxes geworden? Irgendwann hatte ich das mal (automatisch) installiert und war ein netter, einfacher virt-manager-Ersatz, zumindest für den Heimdesktop. Jetzt hat meine distri es nicht mehr... wurde es als "unfertig" deklariert oder so?
Abgesehen davon ist mir neulich ein tolles Feature in Nauti.... "Files" aufgefallen: Wenn man einfach drauflostippt, läuft eine *rekursive* Suche durch den Verzeichnisbaum. Sehr geil
Alles in allem bin ich also recht zufrieden mit Gnome, abgesehen davon, dass Brasero bei mir ohne Meldung keinen Brennvorgang startet (stattdessen nehme ich k3b) und dass die gthumb-Ersätze und "Web" Müll sind.
Zumindest in Debian gibt es Gnome-Boxes. Es wird auch aktiv entwickelt, wie ein Blick auf https://git.gnome.org/browse/gnome-boxes/ belegt.
ich lehne mich entspannt zurück, genieße das Popcorn und schmunzele erstaunt über die merkwürdigen Ideen der Gnome 3 Entwickler.
Das klingt so, als würde das Zeichnen der minimieren, maximieren und schließen Buttons bei Gnome 3 Anwendungen nicht mehr vom Fenstermanager, sondern von der Anwendung selbst erledigt werden müssen.
Im günstigsten Fall führt das dann unter anderen Desktop Oberflächen oder Window Managern dazu, dass sowohl der Fensterbereich der Anwendung, als auch die Fensterleiste die vom WM kommt, derartige Buttons haben. Haben dopppelt vorhanden sind.
Und im schlimmsten Fall führt das Schließen der Anwendung über die Buttons in der Fensterleiste des WM dazu, dass die Anwendung nicht mehr ordentlich beendet wird, weil man hier vielleicht auch noch den Klebstoff unter der Haube dazwischen wegrationalisiert hat.
Hm, hier ist wohl beim Satzumbau etwas verschluckt worden:
Ich meine natürlich, dass die Buttons dann doppelt vorhanden sind.
Also vergleichbar einem
Und dann wäre da noch die Frage, wie man nun andere GUI Toolkit fremde Anwendungen, also z.B. qt Anwendungen schließt, wenn der WM von Gnome 3 keine derartigen Schließen Buttons mehr zeichnet und
das nun die Anwendung übernehmen soll?
AFAIK werden unter X Window die Fensterumrandungen vom WM gezeichnet und nicht vom GUI Toolkit.
Und von wo soll der WM das wissen, dass es keine GTK Anwendung ist?
Da müßte man schon den WM und die GTK lib spezial darauf anpassen, so dass diese mitteilt (ich bin eine GTK 3) Anwendung und er WM dann bei allen anderen, die keine Meldung dieser Art bringen, den Fensterrahmen wie gehabt zeichnet.
Insofern nein, man kann nicht mit ziemlicher Sicherheit davon ausgehen.
Das wäre nur der Fall, wenn die Fensterleiste auch vom GUI Toolkit gezeichnet werden würden.
Ich muss mich hier korrigieren:
Der WM selbst könnte natürlich auch das GUI Toolkit verwenden, bin da nicht so sicher wie das genau gemacht wird, aber was ich meine ist eben die Anwendung die das GUI Toolkit nutzt.
Im Prinzip ist es momentan AFAIK so:
Die Anwendung bekommt einen Fensterbereich, darin kann sie reinzeichnen. Dies kann unter Zuhilfenahme einwes GUI Tookits wie QT oder GTK usw. geschehen.
Um den Fensterbereich malt nun der WM die Fensterleiste und den Rahmen, auch hier wäre es denkbar, dass dieser selbst wieder ein GUI Toolkit dafür verwendet.
Eine QT Anwendung würde also mit QT ihren Fensterbereich zeichnen, aber der WM Manager, der z.B. GTK+ benutzt, würde die Rahmen dann mit GTK+ malen. Richtig?
Bei Chrom(e|ium) klappt das schon seit Jahren wunderbar. Warum sollte das jetzt anders werden? Abgesehen davon: Sobald Wayland kommt muss sowieso jeder Fenstermanager den Kram selber implementieren.
Wo denn?
Hier ist immer noch der WM für die Fensterleiste verantwortlich:
http://fds-team.de/cms/user-images/silverlight-chrome-linux-1223x809.png
https://myits.luc.edu/techconnect/wp-content/uploads/2010/05/Google-Chrome-Linux.png
Die Fensterrahmen + die Buttons werden AFAIK auch schon jetzt vom WM selbst gezeichnet.
Wayland ändert ein paar andere Dinge.