Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
5 Antworten auf „Positionierung von Dialogen allgemein“
Der Standardfall tritt ja acuh nur ein, wenn nichts anderes definiert ist.
Ich würde dann als „Lösung“ vorschlagen, eine Utility-Klasse im Rahmenwerk vorzusehen, die öffentlich zur Verfügung steht und zur Positionierung von Dialogen verwendet werden kann.
Potentiell könnte man auch einen RahmenwerkDialog als Basisklasse implementieren, den dann alle anderen Plugins erweitern müssten, das erhöht aber die Abhängigkeit und ist nicht in allen Fällen machbar, weil die vorhandenen Dialoge eventuell andere Klassen erweitern.
(Ich überlege trotzdem mal, diese Variante optional zusätzlich vorzusehen).
Letzteres hatten wir schon einmal, das wurde allerdings schnell wieder verworfen. Relativ viele Leute arbeiten mit zwei Monitoren, dann landet der Dialog bei dieser Standardstrategie immer auf den Rahmen der beiden Monitore, was – nun ja, sehr unschön ist.
Ich meine, schon Anwendungen gesehen zu haben, die die Positionierung in Abhängigkeit der Mausposition vornehmen (GIMP??). Ein Gedanke, der mir beim Lesen Ihrer Anmerkungen kam, war, ob ein sinnvoller Kompromiss wäre, als Standardstrategie die Mitte des Monitors zu verwenden, auf dem gerade die Maus ist? Geht das technisch?
Ansonsten muss dann das Ergebnis dieser Anforderung auf jeden Fall allgemeingültig dokumentiert werden, damit die „anderen“ Plug-in-Programmierer diese Funktionalität einfach übernehmen können und nicht neu erfinden müssen.
Der Standardfall tritt ja acuh nur ein, wenn nichts anderes definiert ist.
Ich würde dann als „Lösung“ vorschlagen, eine Utility-Klasse im Rahmenwerk vorzusehen, die öffentlich zur Verfügung steht und zur Positionierung von Dialogen verwendet werden kann.
Potentiell könnte man auch einen RahmenwerkDialog als Basisklasse implementieren, den dann alle anderen Plugins erweitern müssten, das erhöht aber die Abhängigkeit und ist nicht in allen Fällen machbar, weil die vorhandenen Dialoge eventuell andere Klassen erweitern.
(Ich überlege trotzdem mal, diese Variante optional zusätzlich vorzusehen).
Und welche Funktionalität würde die Utility-Klasse dann haben?
Beispielsweise:
Positionierer.positioniereDialog(Dialog,Strategie)
mit Strategie:
– Zentriert auf dem Monitor
– Zentriert zur Workbench
– an der Cursorposition
– relativ zum Parent
usw.
(Ohne jetzt tiefergehend darüber nachzudenken). Die Alternative wäre dann wie gesagt, die Basisklasse, die die „Strategie“ übergeben bekommt.
Okay, verstanden. Dann würde ich die Utility-Klasse bevorzugen, auch weil ich Ihre Bedenken im Hinblick auf die Basisklasse teile.
Letzteres hatten wir schon einmal, das wurde allerdings schnell wieder verworfen. Relativ viele Leute arbeiten mit zwei Monitoren, dann landet der Dialog bei dieser Standardstrategie immer auf den Rahmen der beiden Monitore, was – nun ja, sehr unschön ist.
Ich meine, schon Anwendungen gesehen zu haben, die die Positionierung in Abhängigkeit der Mausposition vornehmen (GIMP??). Ein Gedanke, der mir beim Lesen Ihrer Anmerkungen kam, war, ob ein sinnvoller Kompromiss wäre, als Standardstrategie die Mitte des Monitors zu verwenden, auf dem gerade die Maus ist? Geht das technisch?
Ansonsten muss dann das Ergebnis dieser Anforderung auf jeden Fall allgemeingültig dokumentiert werden, damit die „anderen“ Plug-in-Programmierer diese Funktionalität einfach übernehmen können und nicht neu erfinden müssen.