Das Ziehen mit der rechten Maustaste ist ein „Seiteneffekt“ davon, dass das ja auch nur ein „Viewer“ ist (siehe verlinkten Thread). Und dort ist z.B. die linke Maustaste mit „Rotieren“ belegt. Der Problematik bzw. der Fragestellung bin ich mir mehr als bewußt. Im Moment wird das recht pragmatisch gelöst, durch die MouseControls Klasse, die eben ein MouseControl
erstellen kann, das die Default-Interaktionen kapselt.
Darüber hinaus gehend ist die Frage ja dann: Wie gibt man dem Benutzer (d.h. in diesem Fall dem Entwickler, der diese Library verwendet) die Kontrollmöglichkeiten, die er haben will?
Erste Andeutungen von Ansätzen zu dieser Verallgemeinerung und Konfigurierbarkeit sieht man schon in DefaultMouseControl: Es gibt dort Predicate<MouseEvent>
-Instanzen, die überprüfen, ob ein Event eine bestimmte Aktion auslösen soll. Der Gedanke ist, „sowas“ dann irgendwie zu exponieren, damit der Entwickler den Fall, dass man mit der Linken Maustaste verschieben kann, GROB (!) mit sowas lösen kann wie
viewer.setMouseControl(
MouseControls.createTranslating(
InputEventPredicates.buttonDown(1)));
Aber wie auch schon an anderer Stelle angedeutet: Das reicht nicht. Was ist, wenn der Benutzer sagen will: „Ich will dass bei gedrückter mittlerer Maustaste die Ansicht rotiert wird, und wenn zusätzlich SHIFT gedrückt ist, soll doppelt so schnell rotiert werden!“ ? Ab einem bestimmten Punkt (d.h. ab einem gewissen Bedarf an Konfigurierbarkeit) ist man wohl genötigt, die etwas patzig wirkende Antwort zu geben: „Setz’ das MouseControl auf null
, und häng’ dir deinen eigenen MouseMotionListener dran, der macht, was du willst“.
Wie weit ich (VOR dieser Antwort) die Konfigurationsmöglichkeiten noch aufbohren werde, muss ich noch überlegen. Allgemeiner kann man ja sagen, dass „Inputs“ mit „Aktionen“ verbunden werden sollen - eigentlich ganz analog zu Key Bindings, aber … eben auch für MouseEvents. Genaugenommen tauchte diese Frage für mich schon in „stärkerer“ Form bei Swogl auf - ein paar Gedanken dazu gibt’s in diesem Thread. Eine Lösung hatte ich in der letzten Version von Swogl (die jetzt schon wieder Jahre alt ist ) auch eingebaut. Die hatte Ähnlichkeit zu dem Predicate<MouseEvent>
-Ansatz. Ich hoff(t?)e, das mal irgendwann „generisch“ lösen zu können, so dass vielleicht dieses „Maus-Auf-Aktion-Mapping-Konfigurier-Ding“ als eigenständige Lib existieren könnte. Aber da muss noch mehr Hirnschmalz reingesteckt werden.
Danke für den Hinweis mit dem „gaaaaanz tief reinzoomen“. Tatsächlich steht in meiner TODO-Liste auch schon
Viewer: Limit scaling to prevent rendering errors
Ab einem bestimmten Punkt ist der Abstand zwischen zwei „Achsen-Ticks“ einfach kleiner als das, was durch double
noch aufgelöst werden kann. Dann gibt es erstmal „nur“ Renderartefakte, aber dass es später dann noch mit einer Exception abkachelt, war mir nicht bewußt - das schiebt das „TODO“ ein ganzes Stück weiter nach oben Mal schauen, wie ich da ein sinnvolles „Limit“ einbauen kann.
EDIT2: Was mich (als ich das „TODO“ geschrieben habe) davon abgehalten hatte, das gleich einzubauen: Es ist nicht so trivial. Um den Punkt x=0 kann man seeehr weit reinzoomen, so dass man z.B. nur noch das Intervall 0 - 0.000000000001 auf der x-Achse hat. Aber um den Punkt x=10000000000 geht das nicht - da kann man froh sein, wenn man das Intervall 10000000000 - 10000000000.1 noch aufgelöst bekommt. Tricky, tricky…
EDIT: Ach ja, die Method References… Obwohl die eigentlich total cool sind, gehen sie mir noch nicht so „flüssig“ von der Hand, und ich ertappe mich immer wieder, wie ich „x → foo(x)“ verwende, oder schlicht alte Gewohnheiten (wie das SwingUtilites.invokeLater) beibehalte…