Schnittstelle für durchgereichte Interaktionen in Komponentenhierarchie?

[muckelzwerg]

Hey ihr Softwaretechniker

ich hab hier ein Problemchen, bei dem ich eure Hilfe brauchen kann.
Ich arbeite an einer Visualisierungsanwendung. Dort gibt es eine View-Klasse, die verschiedene grafische Objekte verwaltet. Letztlich sind das Flächen, auf denen dann "irgendwas" passiert.
Der View sortiert diese Flächen, ruft ihre Darstellungsmethoden auf und bietet grundlegende Funktionen wie Verschieben, Skalieren etc. an.

Innerhalb der Objekte kann so ziemlich alles passieren. Das können statische Bilder sein, die sich nie ändern, das könnte ein Film sein, oder die Darstellung eines PDF-Dokuments, oder auch sonst jedes Widget, was man sich so allgemein vorstellen kann.

Nun haben alle diese Objekte unterschiedliche Interaktionsmöglichkeiten. Der Film kann starten, stoppen, spulen usw. das PDF kann blättern, scrollen, zoomen ... solche Sachen eben.
Der einfachste Fall ist, dass alle Interaktionen direkt mit Schaltflächen gesteuert werden, die auch gleich beim Objekt gezeichnet werden. Dann muss man nur ein wenig Picking betrieben und ein paar Listener verkabeln.

Aber wenns so einfach wäre ... wärs ja langweilig.

1) Wie verheirate ich den View mit seinen Komponenten, so dass er deren Funktionen aufrufen bzw. nach oben anbieten kann, ohne die Komponenten zu kennen?
Wenn ich von einem anderen Teil der Software die Anweisung "nächste PDF Seite anzeigen" bekomme, muss das irgendwie durchgereicht werden. Und statt "irgendwie" hätte ich ganz gern "sinnvoll".

2.1) Wie biete ich im View dynamische Schaltflächen an, die je nach aktiver Komponente gewechselt werden?
So in etwa, wie die Leiste bei OSX.

2.2) Gibt es eine Lösung für 2.1 bei der ich nicht direkt an Swing etc. gekoppelt bin? Ich habe verschiedene Grafikschnittstellen im Einsatz (Java2D, OpenGL, ...). Nicht jede temporäre Schaltfläche muss in einem Swing Menü landen, sondern wird vielleicht ganz anders dargestellt.
Kann man in einer ersten Schicht die Funktionen ermitteln, die der View sich temporär von der Komponente holt und in einer zweiten Stufe dann erst zuordnen, ob daraus graue Knöpfe in der Menüleiste, oder ein fliegendes Widget irgendwo in der Darstellung, oder ganz was anderes wird?
Quasi eine Art "Patchfeld" für Interaktionen?

Ich bin für jeden Tipp dankbar.

 

[Marco13]

Das klingt schon sehr ähnlich zu den Fragen, die ich mir im Zusammenhang mit Swogl gerade (mal wieder ) stelle. Ein paar Gedanken dazu habe ich schon, aber ... bei mir bezieht sich das auf eine sehr niedrige Ebene (eben Events) und ist vielleicht nicht direkt übertragbar. Vielleicht können wir da ja mal (hier oder per PN) drüber philosophieren.

 

[muckelzwerg]

Gerne hier.
Die meisten kennen bestimmt die diversen "Multitouch-Tabletops". Da werden oft jede Menge Objekte auf den Tisch geworfen, umhergeschubbst, gestreckt, gepinched, gewasauchimmert ...
Diese Funktionen liegen in der höheren Ebene, bei mir ist das der "View".
Bei Dir (Marco) ist das vermutlich die Situation, wenn Du Swing Komponenten auf dem OpenGL Canvas gezeichnet hast und ihre zugehörigen Flächen irgendwie verwaltet werden müssen.
Genau das machen meine Views, auch wenn ich aktuell keine Swing Widgets als Objekte habe.

Solange man jetzt auf das Widget draufklicken kann, damit es was tut, ist alles kein Problem. Da bringt dann jedes Objekt sein eigenes Menü mit.
... möööööp .... leider nicht. Wenn man z.B. Bilder skaliert oder gar streckt, dann wird es mit klassischen Menüleisten etwas eklig.
Also wechselt man z.B. auf Menüs die irgendwie auf der gleichen Fläche schweben, auf der auch das Objekt liegt.
Wenn ich mit einem Bild arbeiten will, dann werden um das Bild herum Schaltflächen angezeigt, egal, wie es skaliert ist.
Diese Schaltflächen liegen aber jetzt außerhalb der Fläche des Bildes. Irgendwer muss die verwalten. Irgendwo muss auch der Code hin, der die Ausrichtung bestimmt usw.
Im Prinzip ist das Menü dann eine Art Dekoration. (geht vielleicht in der Richtung was?)

Ein anderer Fall ist, dass ich z.B: zwei PDF-Dokumente nebeneinander anzeige. Jedes kann geblättert, gescrolled usw werden.
Ich will aber nicht, dass um jedes Dokument die volle Palette an Menüleisten angebracht wird, sondern einige Menüs lieber eine Ebene höher (im View) anbieten. Der View aber hat keine Ahnung, was ein PDF ist, oder welche Menüs man dafür braucht. Er kann sie nur irgendwie blind übernehmen. Wie er das macht, ist die Frage.


Was hast Du denn so für Gedanken/Probleme bei dem Thema?

 

[Marco13]

Die Sache mit den Menüs hat sich mir nicht ganz erschlossen. Es geht nicht um menüs die wirklich innerhalb des (i.a. rechteckigen) Bereichs der dargestellten Dinge sind, sondern wirklich um etwas, was außen dran gehängt wird?

Sooo viele Ähnlichkeiten zu Swogl hat das vielleicht doch nicht, weil dort die Frage nach der Eingabe auf viel niedrigerer Ebene behandelt werden muss (d.h. "Soll dieser MouseEvent an die Swogl-Component weitergeleitet werden, oder von irgendeinem anderen Listener verarbeitet werden?")

Das Decorator-Pattern könnte dort evtl. sinnvoll sein, aber das ist im Moment noch schwer zu sagen. Das Beispiel mit den PDFs klingt irgendwie, als könnte man dort sowas ähnliches wie ein "Plugin"-Konzept verwenden (muss ja nicht gleich OSGi sein ). Aber es könnte eine öffentliche Stelle geben, wo man GUI/Bedienelemente in ganz abstrakter Form "einklinken" kann. Die erscheinen dann wirklich auf der obersten Ebene. Wenn man nun so ein PDF-Ding in den Sichtbereich einfügt, dann sagt das an dieser Stelle bescheid, und übergibt dort seine GUI-Elemente (die in diesem Fall z.B. zwei Buttons sind, mit denen man vor- und zurückblättern kann - davon braucht aber die oberste Ebene nichts mehr zu wissen, die zeigt sie ja nur an). Aber ob das wirklich passt, kann man ohne weitere Infos schwer einschätzen... Und irgendwie klingt es zu einfach, als dass man annehmen sollte, das du da nicht selbst schon drauf gekommen bist, und festgestellt hast, dass das aus irgendeinem Grund nicht passt ...