Fenstergöße inkl. Titelleiste/Deko unter Linux?

[fhoech]

Hallo,

ich habe folgendes Problem: Unter Linux scheint es nicht möglich, mit wxFrame.GetSize() die Größe des Fensters mit Titelleiste und sonstiger Fensterdekoration zu bekommen (unter Mac/Win funktioniert das). Der gelieferte Wert entspricht immer wxFrame.GetClientSize() und damit dem Fensterinhalt (openSUSE 11, GNOME, Python 2.6, wxPython 2.8.9.1).

Gibt es eine andere Möglichkeit?

[Leonidas]

Gibt es eine andere Möglichkeit?

Vielleicht den Window Manager direkt via EWMH/NetWM befragen. Funktioniert aber nicht immer, da einige Window Manager schlicht keine Fensterdekoration haben.

[fhoech]

Ok, danke. Wenn das mit NetWM allerdings nicht immer funktioniert, muss ich mich evtl. nach einer anderen Lösung umschauen.

Vielleicht muss ich auch die ursprüngliche Frage anders formulieren. Mir gehts konkret darum, dass ich ein Fenster in die nutzbare Client Area des Desktops einpassen möchte, durch Verringern der Höhe/Breite (und Anzeige von Scrollbars), aber nur falls das Fenster für den Desktop zu groß ist (die Größe des Fensters ergibt sich im Moment aus den per Sizern positionierten enthaltenen Controls, und je nach Bildschirmauflösung kann das Fenster etwas zu hoch sein, so das Controls "abgeschnitten" werden wenn ich die Größe nicht anpasse).

[Leonidas]

Die Standardantwort unter Unix lautet da immer: schreib einen eigenen Window Manager. Positionierung der Fenster ist nunmal Sache des WMs und der WM muss nicht die Hints (das H aus EWMH) der Applikation befolgen. Oder du nutzt/schreibst einen vor, der das eben tut.

Achja, dass NetWM nicht bei allen Window Managern tut liegt natürlich daran, dass einige es schlicht nicht unterstützen. Das hat weniger mit der Fensterdekoration zu tun, das hab ich vorhin falsch formuliert.

[fhoech]

Die Standardantwort unter Unix lautet da immer: schreib einen eigenen Window Manager

Ok, das kommt nicht in Betracht fürchte ich

Gibts da wirklich keine Möglichkeit, zu sagen "Mach das Fenster auf keinen Fall größer als die nutzbare Client Area des Desktops?" (davon abgesehen ist es sowieso unglücklich, dass ein Window Manager überhaupt größere Fenster zulässt - dafür gibt es imho keinen wirklich sinnvollen Anwendungszweck, aber das ist ein anderes Thema)
Ich kann mir einfach nicht vorstellen, dass das so ein ausgefallenes Problem ist. Ich könnte natürlich auch eine feste Fenstergröße vorgeben, z.B. Höhe des Fensters max. 500 Pixel, das sollte in den meisten Fällen auch noch auf einen 800x600 Desktop passen, aber irgendwie ist das unschön.

[lunar]

Gibts da wirklich keine Möglichkeit, zu sagen "Mach das Fenster auf keinen Fall größer als die nutzbare Client Area des Desktops?"

Nein. Genau genommen gibt es unter X11 nicht mal eine Möglichkeit, überhaupt die Größe des Fensters zu bestimmen. Die Anwendung kann dem Fenstermanager nur Empfehlungen schicken. Es gibt zwar die Möglichkeit, zu verhindern, dass das Fenster vom Fenstermanager verwaltet wird, aber das ist imho mit den normalen Toolkits nicht ohne weiteres möglich.

Die Frage aber ist, warum du das überhaupt tun willst? Der Nutzer hat doch Dekoration und Größe im Blick und kann sie seinen Wünschen entsprechend anpassen. Und wenn Vollbild gewünscht ist, dann verwendet er hat die entsprechenden Funktionen seines Fenstermanagers.

[fhoech]

Die Frage aber ist, warum du das überhaupt tun willst?

Usability. Wenn ich ein Fenster habe, bei dem unten Controls zu fehlen scheinen (in Wirklichkeit ist aber nur das Fenster etwas zu hoch), so muss der User extra hergehen und die Fenstergröße anpassen, dann das Fenster hochschieben. Wenn es da eine Möglichkeit gäbe, von Anfang an eine Fenstergröße vorzugeben, die keine Controls "abschneidet" (dafür dann halt an geeigneten Stellen Scrollbalken), die dem User das manuelle Anpassen erspart, hätte ich die natürlich verwendet (und unter Mac OS und Windows funktionierts ja auch). Ok, nun weiss ich ja dass es ohne weiteres unter Linux nicht geht. Evtl. werd ich einfach von wxDisplay.GetClientSize() einen gewissen Betrag für diverse Titel-, Kontroll- und Taskleisten abziehen, dann passt es zumindest in den meisten Fällen unter GNOME, KDE und Konsorten.

Trotzdem danke für die Infos, man lernt nie aus

[lunar]

Welches Toolkit verwendest du? Normalerweise bestimmt nämlich der Layout-Manager die Größe und orientiert sich dabei am Anfang an der Minimalgröße aller enthaltenen Widgets, das Fenster hat also beim Start die kleinstmögliche Größe. So zumindest funktioniert das bei Qt4.

Ich zumindest habe bei einer GUI noch nie eine absolute Größe vorgegeben.

[fhoech]

Welches Toolkit verwendest du? Normalerweise bestimmt nämlich der Layout-Manager die Größe und orientiert sich dabei am Anfang an der Minimalgröße aller enthaltenen Widgets, das Fenster hat also beim Start die kleinstmögliche Größe. So zumindest funktioniert das bei Qt4.

Ja. Nur das (im konkreten Fall) ab einer Auflösung von <=1024x768 das Fenster selbst in der Minimalgröße noch knapp 60 Pixel zu hoch ist (unter GNOME, also Toolkit GTK, unter KDE ist es sogar noch mehr). Darum dachte ich mir eben, "kein Problem, schau ich halt nach wie viel Platz ich habe (per wxDisplay.GetClientSize) und verkleinere das Fenster ein wenig, und zeige Scrollbalken, damit der User an den gesamten Inhalt kommt".

Ich zumindest habe bei einer GUI noch nie eine absolute Größe vorgegeben.

Genau, das möchte ich eigentlich auch nicht. Das Problem besteht ja ironischerweise dann, wenn ich KEINE absolute Größe vorgebe.

[Rebecca]

Du koenntest optionale Kommandozeilenparameter fuer die Groesse anbieten.

[fhoech]

Ja. Aber inzwischen denke ich, wenn ich von den Werten, die mir wxDisplay.GetClientArea() liefert einfach einen gewissen Betrag abziehe, um für evtl. vorhandene Titelleiste und Deko einen gewissen Sicherheits-Spielraum zu haben, funktioniert es gut genug.

[lunar]

Ja. Nur das (im konkreten Fall) ab einer Auflösung von <=1024x768 das Fenster selbst in der Minimalgröße noch knapp 60 Pixel zu hoch ist (unter GNOME, also Toolkit GTK, unter KDE ist es sogar noch mehr).

Du hast also ein Fenster, dass selbst bei minimaler Größe noch mehr als 700 Pixel benötigt? In diesem Fall würde ich überlegen, die GUI mit Tabs oder Stacked Widgets neu zu implementieren, oder gleich standardmäßig Scrollbalken zu implementieren. Denn selbst auf größeren Bildschirmen möchte der Nutzer vielleicht nicht unbedingt ein Fenster rumliegen haben, das permanent 700 Pixel groß ist. So sehe ich die Sache ...

[fhoech]

oder gleich standardmäßig Scrollbalken zu implementieren

Die Scrollbalken zeigen sich bei mir erst, nachdem ich das Fenster verkleinere (ok, soweit logisch).

Denn selbst auf größeren Bildschirmen möchte der Nutzer vielleicht nicht unbedingt ein Fenster rumliegen haben, das permanent 700 Pixel groß ist. So sehe ich die Sache ...

Ja, da stimme ich dir zu, allerdings handelt es sich hier um eine GUI für Kalibriersoftware, die man startet, Einstellungen festlegt, die Kalibrierung durchlaufen lässt und wieder schließt, und die meisten Anwendungszwecke für Kalibrierung liegen in der Bildbearbeitung, wo man typischerweise mit Auflösungen von mindestens 1024x768 unterwegs ist.
Ich hab mir auch lange überlegt, ob ich die Settings auf mehrere Tabs verteilen soll, allerdings sehe ich es auch als Vorteil, dass man alles im Blick haben kann wenn die Desktopfläche groß genug ist (unter Windows reichen je nach Theme knapp 720 Pixel in der Höhe aus für alles inkl. Titelleiste/Deko, unter Mac OS X, GNOME und KDE brauchts vor allem bei letzterem ein gutes Stück mehr, auch wieder je nach Theme).
Die Widgets sind bereits recht kompakt angeordnet, aber da kann ich sicherlich auch noch etwas tun. Hier mal ein paar Screenshots, wie es jetzt ausschaut bei 1024x768er Auflösung (habe mich entschlossen, die Scrollbars nur für den mittleren Bereich zu verwenden, ob das Banner nötig ist darüber kann man natürlich streiten denn es verbraucht ja kostbare Höhenpixel ):

Unter GNOME
Unter KDE4
Unter Windows XP