Pfeif' aufs Menü

« | 21 Mar 2020 | »

Eine mittlere Katastrophe bei der Implementierung von GUI Frameworks ist das “Menü”.

Ich meine damit diese Zeile, wo Datei und Bearbeiten usw. steht, auch “Pull-down-menu” genannt.

Wieso können nicht alle Frameworks und Plattformen das gleichartig umsetzen?

---

• Ein übliches Windows und MacOS erklären “das Menü” zur Chefsache und lassen diese Ressource vom System verwalten.
• Windows CE ist sich nicht schlüssig und bietet je nach Plattform-Baukasten unterschiedliche Methoden an.
• X11 und diverse UI Frameworks nehmen es selbst in die Hand und zeichnen die Menüzeile auf das Hauptfenster.
• Und bei Smartphone Apps gibt es Pulldown-Menüs de facto gar nicht mehr.

Wie soll man da jetzt eine Kapselung hinbekommen, die alle diese Fälle intelligent abstrahiert um “plattformübergreifend” agieren zu können?
Das schlimmste ist, dass auch noch das Koordinatensystem der Fenster durcheinander gebracht wird.

Windows

Die “MenuBar” ist eine spezielle Zusatzressource eines Fensters. Ist ein Menü vorhanden, liegt es in der Non-Client-Area. Das bedeutet Kindfenster “sehen” es nicht und die Client-Area beginnt mit den Koordinaten (0, 0) direkt unter dem Menü.

MacOS

In MacOS haben die Fenster selbst kein Menü, sondern dieses integriert sich in die Menüzeile, die oben am Bildschirm eingeblendet ist. In sofern gibt es für ein Programmfenster keinen Unterschied, ob ein Menü da ist oder nicht, denn wenn eines existiert, wird es außerhalb verwaltet.

X11

Das X Window System kennt bekanntlich überhaupt nichts und somit muss ein UI Framework sich sein Menü selbst zeichnen. Man ist also völlig frei, wo man das tut, aber meistens wird die “Windows” Variante gewählt, wo die Menüzeile unter der Titelzeile des Fenster eingeblendet wird.
Und das verschiebt natürlich alle anderen Controls des Fenster um die Höhe der Zeile nach unten.

Und was machen UI Frameworks?

Die können und wollen sich nicht auf Plattform-Spezialitäten verlassen und verzichten auf vom System verwaltete Menüs und zeichnen gleich alles selbst.
Und das immer! (OK, “meistens” um genau zu sein.)

Um alle Elemente sauber zu positionieren, müssen sie wieder eigene Container-Konstellationen einführen, damit sich das Menü oben und der Rest darunter automatisch einrichtet.

Jetzt kommt noch hinzu, dass eben die Frameworks ob ihrer “Selbstverwaltung” das übliche Verhalten der Plattform nicht korrekt nachbauen.

Wie oft musste ich schon erleben, dass Menüs unter Windows nicht durch die ALT Taste aktiviert werden konnten? Und so etwas macht mich echt sauer, wenn jedes Programm anders bedient werden muss bzw. sich nicht an etablierte Standards hält.

Implementierung im GATE Projekt

Ja, wie gesagt, ein Chaos.

Am meisten zu schaffen macht mir Windows CE, in dem Menüs kein durchgängig standardisierter Bestandteil der API sind.
Windows CE Desktop-Style-Apps könnten mit CommandBar_Create() arbeiten, doch das würde Windows Mobile (das ja auf CE basiert) nicht unterstützen.

Dafür hat man dann die AYGShell Erweiterung erfunden, die es ermöglichen soll, ein paar Features (darunter auch Menüs ) portabel zu gestalten.

Doch auch hier muss man mit eigenen Fenstern agieren, sie richtig positionieren und dann auch noch Resource-Dateien einbinden … also kurz gesagt: Pfui!

Aber auch GTK macht mir das Leben hier nicht gerade leichter, wo ich für das Menü eigens Platz schaffen muss und die anderen Kind-Elemente in einem Layout-Container unterbringen muss.

Hier liegt dann das Problem, dass ein Fenster mit Menü sich anders verhalten muss (z.B. beim Ändern der Größe) als ein Fenster ohne Menü.

Nun gut, jetzt mögen manche sagen:

Selbst schuld!

Denn GTK hat ja sein eigenes Container-Management für diese Zwecke, doch dieses lässt mir leider nicht den Spielraum, den ich eben haben möchte. Auch anders herum, wenn GTK das führende Verhalten wäre, müsste man die gesamte Container-Logik wieder auf die WinAPI portieren … also auch kein Spaß.

Mobile Apps lasse ich jetzt mal außen vor.

Diese unterscheiden sich derartig vom Aufbau von Desktop Apps, dass es bisher noch niemandem gelungen ist, Desktop-Features dort hin zu übernehmen.
Das macht man eher umgekehrt, nämlich dass mobile Apps mit ihren primitiven Funktionen dann auf dem Desktop erscheinen … aber das ist eine andere Geschichte.

Fazit

Seit Windows 3.1 kenne ich Menüs und seit meinen ersten Visual Basic Tagen nutze ich diese.

Es ist eine extrem effiziente Möglichkeit eine Vielzahl von Funktionen gut zu strukturieren und unsichtbar zu lagern, die nur bei Bedarf angezeigt werden.

Während man bei mobilen Apps mit ihren 2 bis 10 Features keine Menüs braucht, sind sie bei professionellen Anwendungen einfach unverzichtbar.
Da muss man eben die Möglichkeit haben durch X Hierarchien das Feature Nr. 217 schnell zu finden.

Und eben deshalb bleibt es mir nicht erspart, Menüs in vollem Umfang auf allen Plattformen zu unterstützen.

Wie auch immer … manchmal nervt die Implementierung eben sehr!