Also ich gehe davon aus, dass ein aktiver Entwickler eines Fenster-Managers (sei es nun von KDE, Gnome, etc...) mehr Ahnung hat als du (und auch als ich). Schließlich befassen die sich durch die Entwicklung auch wesentlich mehr damit. Von daher sind Kommentare deinerseits wie "scheiße", "gähn" nun wirklich fehl am platz.

> Window Tabbing (KWin specific)
> Oh man, ist doch auch scheiße. Außerdem kann man es ja in Gtk+ einbauen, wenn man es wirklich braucht.

Du willst also wirklich dass eine Anwendung über die anderen mit ihm gruppierten Anwendungen bescheid wissen muss, damit er das Tabbing im Fenster ermöglichen kann? Und wenn eine Anwendung das Fenster anzeigt und verwaltet, was machen dann die anderen dazu gruppierten Anwendungen? Jeder will ein eigenes Fenster zeichnen und die Tabs verwalten?

Oder schlägst du vor dass es jeweils nur die erste Anwendung in der gruppierung macht? Was ist wenn man die Reihenfolge der Anwendungen in den Tabs ändert? Muss dann plötzlich die neue erste Anwendung das zeichnen und verwalten der Tabs übernehmen? Wie du siehst wäre es ein erheblicher Mehraufwand um diese Funktion zu ermöglichen.

Anscheinend hast du Window-Tabbing auch noch nie richtig benutzt. Ich verwende es oft und finde es sehr praktisch.

> Window rules like always show a close button even if the window is not closeable
> Wieso kann man das nicht bei Gtk+ einbauen?

Denk doch mal nach. Eine Anwendung will keinen Beenden-Knopf haben und die Anwendung zeigt den Rahmen und die Knöpfe auch selbst an. Warum sollte die Anwendung also eine Regel von außerhalb berücksichtigen, wo sie es doch selbst schon verbietet? Natürlich könnte es der Entwickler der Anwendung berücksichten, aber es ist kein muss. Bei einem unabhängigen Fenster-Manager kann die Anwendung das eben nicht verbieten, weil der Fenster-Manager hier in erster linie die Regel von außerhalb berücksichtigt.

Wie oben schon erwähnt scheinst du einfach nicht die nötige Erfahrung zu haben um die Argumente wirklich widerlegen zu können. Nichts für ungut. Aber da sollte man sich doch mit dem Ton dann zurückhalten.

Können wir bei den Original-Argumenten FÜR die Einführung bleiben? Immerhin will die GTK-Seite Features neu einführen, und da muss man sich der Kritik stellen.

Es ist ja schon interessant dass der Vorschlag aus der GNOME-Ecke kommt, und die Argumente hauptsächlich aus "Das behebt Fehler xy in unserer Anwendung/unserem Toolkit" bestehen. Keine andere Gruppe von Desktop-Entwicklern hat bisher eine Notwendigkeit für den Kram gesehen.

Deswegen frage Ich hier frei nach Ockam's Razor: Welchen *Mehrwert* bringt das alles? Mehrwert der für die ganze Free-Desktop-Welt entsteht, und nicht nur Fehler in Compiz und GNOME kaschiert die sowieso besser gefixt gehören?

Du gibt bei einigen Sachen an, dass man's einbauen kann, das ist sicherlich richtig, heisst aber, dass verschiedene Fenstermanager erstmal (bis es eingebaut ist, und bugfrei) erstmal inkompatibel sind. Merke, dass diese Inkompatibilitäten im Moment nicht auftreten.

Wenn du Kwin-Tabs scheisse findest, ist das Deine Meinung -- und die steht dir sicherlich zu. Aber stichhaltige Argumente sind schon was Anderes.

Ich denke, dass die Ziele, die Canonical mit den CSD verfolgt womöglich Sinn machen, nur ist die Implementation falsch und sorgt sowohl kurzfristig als langfristig für die Probleme, die Martin in seinem Blog beschreibt. Wenn man solche Funktionen will, kann man besser eine Art Service vom Fenstermanager anbieten (ähnlich wie es die neue Notificationarea Funktion macht, die Funktionalität wird dabei von der App angeboten, die Präsentation (Aussehen, Bedienung) von Fenstermanager. Damit hat man die Sachen die man einführen will (Bedienungselemente in der Fensterdekoration), ohne die Probleme von CSD.

Nein, es ist nicht stark veraltet, nicht einmal ein bißchen. Die gtkmm-Entwickler verfolgen strikt die GTK+-Releases und sind immer am Tag des Releases en-par mit den GTK+-Releases. Und selbstverständlich wird es gtkmm auch für GTK+ 3 geben.

Informier dich also, bevor du hier rumlügst!

March 29, 2010: gtkmm 2.20.0 and glibmm 2.24.0 released, as per the GNOME schedule. gtkmm 2.20.0 wraps new API in GTK+ 2.20 and is API/ABI-compatible with gtkmm >= 2.4. It is a version of the gtkmm-2.4 API with API additions.

so ein unsinn! wozu ein toolkit für c++, wenn man sich an java orientiert?? dann soll man gefälligst in java programmieren. ich mag es aber weitaus lieber, wenn ich c++ig in c++ programmieren kann und nicht java in c++ packen muss.

C++-style Iteratoren:
QList ::iterator i;
for (i = list.begin(); i != list.end(); ++i)
*i = (*i).toLower();

Java-style foreach:
QLinkedList list;
QString str;
foreach (str, list)
qDebug() < < str;

Also ich finde Java-style foreach einfacher zu lesen. C++ hat einfach einen grauenhaften Syntax. Daß Qt versucht, dem Programmierer das Leben so angenehm wie möglich zu machen, finde ich gut.

Ich habe mehrere 100000 Zeilen Code in diversen Sprachen (C++, C#, Java) geschrieben. Einfacherer Syntax führt zu weniger Fehlern und in dieser Hinsicht ist meiner Meining nach Java deutlich besser als C++. Qt ist nicht Java, aber wenn manche Dinge ähnlich einfach wie in Java machen kann, finde ich das definitv einen Vorteil. "C++'ig" ist für mich alles andere als ein Qualitätsmerkmal.

> Kommt halt nichts gutes bei raus wenn man versucht C mit allen Mitteln objektorientierter zu machen.

Du meinst, so wie "C with classes", aka C++? Wo du recht hast, hast du recht. Auch wenn du hier leicht off-topic bist.

Nein, es ist nicht hacky. Es ist Objektorientierung implementiert. Punkt. Hacky wäre es, wenn es falsch oder schlecht implementiert wäre.