Man muss an dieser Stelle aus meiner Sicht deutlich unterscheiden zwischen „Neues Fenster“ und „Neues Rahmenwerk mit SImulationsvariante“.
Wenn ein neues Fenster geöffnet wird, betrifft das im Wesentlichen die UI, d.h. alle Fenster greifen auf die gleichen Daten zurück und damit auf die gleiche Datenverteilerverbindung. Die Fenster würden auch (wie Perspektiven und Ansichten) beim Neustart wiederhergestellt werden. (Ist das für eine Simulation erforderlich?)
Für ein Rahmenwerk mit einer Simulationsvariante würde ich tatsächlich eine neue Applikation starten (was aus einem anderen Rahmenwerk heraus auch möglich ist). Das wäre unter anderem auch zu empfehlen, da (in der Regel?) alle Datenverteileranmeldung mit Standardangaben erfolgen (DataDescription(Atg, Aspect)) ohne explizit eine Simulationsvariante anzugeben. Nur wenn die „Grundverbindung“ mit der gewünschten Simulationsvariante hergestellt wurde, würde diese hier auch zum tragen kommen.
Und wozu kann ich denn die Action „Neues Fenster“ verwenden? Welchen Vorteil bietet bei Mehr-Monitor-Betrieb ein neues Fenster auf einem zweiten Monitor gegenüber einem entsprechend groß gezogenem Fenster auf zwei Monitoren?
Aus meiner Sicht erleichtert es die Bedienung, da ich Ansichten in den Fenstern verteilen kann, ohne auf die Begrenzungen der Monitore zu achten.
Denkbar wären auch mehrere Fenster, die unterschiedliche Aufgabenbereiche abdecken und die ich einfach durch Minimieren und Maximieren oder ALT-Tab umschalten kann.
Würden Sie dann Ihre damalige Idee, die Standard-Action „Neues Fenster“ bei der Überarbeitung des Rahmenwerks verwendbar zu machen, umsetzen? Oder funktioniert das gar schon?
Die Aktion sollte sich wieder integrieren lassen, in der Form, wie alle anderen Aktionen im Rahmenwerk eingebunden sind (explizit im Code erzeugt).
Ob es eventuell sowieso schon geht habe ich explizit noch nicht überprüft.
Über die in Menüs und Symbolleisten verfügbaren Aktionen sollte man aber generell noch einmal nachdenken. Momentan sind alle entweder händisch hinzugefügt bzw. aus den „plugin.xml“-Dateien werden alle Actions-Sets eingelesen und deren Aktionen integriert.
Aie Erweiterungspunkte „ActionSet“ und „Action“ sind seit Eclipse 2.1 auf deprecated gesetzt und wurden durch das Konzept Commands und Handlern ersetzt.
In einer reinen Eclipse 4 Anwendung gibt es keine Actions mehr in der bisherigen Form.
Zu den beiden kritischen Punkten:
ad 2.: Hier wäre mein Gedanke eben in der Richtung der von Ihnen seinerzeit in die Diskussion eingebrachten Action „Neues Fenster“ (ÄM-38): Ich stelle mir das in Gedanken so vor, dass ein neues Rahmenwerksfenster aufgeht, das farblich deutlich unterscheidbar ist, in der Statuszeile und evtl. auch in der Titelzeile steht unübersehbar die Simulationsvariante. Beim Starten des neuen Fensters erfolgt eine Anmeldung am Datenverteiler, bei der im Login-Dialog die (dann bekannte) Simulationsvariante gewählt werden kann.
ad 1.: Die Frage ist berechtigt, aber das bringt eben die ganze Komplexität der Simulation im Basissystem mit sich. Das Rahmenwerk kann (und muss) hier maximal unterstützen, zum Beispiel durch farbliche Kennzeichnung der Fenster, deutlicher Angabe der Simulationsvariante und ähnlichem. Die Beherrschung der Komplexität muss der Anwender erbringen. Und dabei bleibt ihm überlassen welche Daten und welche Parameter er in einer Simulationsvariante ändert. Nach meiner persönlichen Einschätzung ist er gut beraten, das sehr sparsam zu tun.
Prinzipiell gebe ich Ihnen recht: Ein Rahmenwerk kann wahrscheinlich nie sinnvoll nur in einer Simulationsvariante betrieben werden. Es muss immer ein Rahmenwerk mit der SV 0, also der Realität, daneben liegen. Denn von dem aus muss ja die Simulation über das entsprechende Plug-in gesteuert werden. Anders kann das ja eigentlich nicht beherrscht werden.
Beim Start des Rahmenwerks kann natürlich die Standardoption des Datenverteilers für die Definition der Standardsimulationsvariante angegeben werden, dann erfolgt die Kommunikation der Plugins auf der Basis dieser Variante, solange nicht intern explizit andere Vorgaben erfolgt sind.
Zur Visualisierung der übergebenen Standardsimulationsvariante wäre eventuell ein entsprechendes Element für die Statusleiste sinnvoll, das bei Bedarf in diese eingebaut werden könnte.
Dann sollten diese Überlegungen bitte angestellt werden.
Das heißt, in Eclipse 4 gibt es nur noch die Commands?
Man muss an dieser Stelle aus meiner Sicht deutlich unterscheiden zwischen „Neues Fenster“ und „Neues Rahmenwerk mit SImulationsvariante“.
Wenn ein neues Fenster geöffnet wird, betrifft das im Wesentlichen die UI, d.h. alle Fenster greifen auf die gleichen Daten zurück und damit auf die gleiche Datenverteilerverbindung. Die Fenster würden auch (wie Perspektiven und Ansichten) beim Neustart wiederhergestellt werden. (Ist das für eine Simulation erforderlich?)
Für ein Rahmenwerk mit einer Simulationsvariante würde ich tatsächlich eine neue Applikation starten (was aus einem anderen Rahmenwerk heraus auch möglich ist). Das wäre unter anderem auch zu empfehlen, da (in der Regel?) alle Datenverteileranmeldung mit Standardangaben erfolgen (DataDescription(Atg, Aspect)) ohne explizit eine Simulationsvariante anzugeben. Nur wenn die „Grundverbindung“ mit der gewünschten Simulationsvariante hergestellt wurde, würde diese hier auch zum tragen kommen.
Gut, das habe ich jetzt verstanden. Dann würde in das geforderte Konzept die Idee, die im zweiten Absatz skizziert ist, einfließen.
Und wozu kann ich denn die Action „Neues Fenster“ verwenden? Welchen Vorteil bietet bei Mehr-Monitor-Betrieb ein neues Fenster auf einem zweiten Monitor gegenüber einem entsprechend groß gezogenem Fenster auf zwei Monitoren?
Aus meiner Sicht erleichtert es die Bedienung, da ich Ansichten in den Fenstern verteilen kann, ohne auf die Begrenzungen der Monitore zu achten.
Denkbar wären auch mehrere Fenster, die unterschiedliche Aufgabenbereiche abdecken und die ich einfach durch Minimieren und Maximieren oder ALT-Tab umschalten kann.
usw.
Würden Sie dann Ihre damalige Idee, die Standard-Action „Neues Fenster“ bei der Überarbeitung des Rahmenwerks verwendbar zu machen, umsetzen? Oder funktioniert das gar schon?
Die Aktion sollte sich wieder integrieren lassen, in der Form, wie alle anderen Aktionen im Rahmenwerk eingebunden sind (explizit im Code erzeugt).
Ob es eventuell sowieso schon geht habe ich explizit noch nicht überprüft.
Über die in Menüs und Symbolleisten verfügbaren Aktionen sollte man aber generell noch einmal nachdenken. Momentan sind alle entweder händisch hinzugefügt bzw. aus den „plugin.xml“-Dateien werden alle Actions-Sets eingelesen und deren Aktionen integriert.
Aie Erweiterungspunkte „ActionSet“ und „Action“ sind seit Eclipse 2.1 auf deprecated gesetzt und wurden durch das Konzept Commands und Handlern ersetzt.
In einer reinen Eclipse 4 Anwendung gibt es keine Actions mehr in der bisherigen Form.
Zu den beiden kritischen Punkten:
ad 2.: Hier wäre mein Gedanke eben in der Richtung der von Ihnen seinerzeit in die Diskussion eingebrachten Action „Neues Fenster“ (ÄM-38): Ich stelle mir das in Gedanken so vor, dass ein neues Rahmenwerksfenster aufgeht, das farblich deutlich unterscheidbar ist, in der Statuszeile und evtl. auch in der Titelzeile steht unübersehbar die Simulationsvariante. Beim Starten des neuen Fensters erfolgt eine Anmeldung am Datenverteiler, bei der im Login-Dialog die (dann bekannte) Simulationsvariante gewählt werden kann.
ad 1.: Die Frage ist berechtigt, aber das bringt eben die ganze Komplexität der Simulation im Basissystem mit sich. Das Rahmenwerk kann (und muss) hier maximal unterstützen, zum Beispiel durch farbliche Kennzeichnung der Fenster, deutlicher Angabe der Simulationsvariante und ähnlichem. Die Beherrschung der Komplexität muss der Anwender erbringen. Und dabei bleibt ihm überlassen welche Daten und welche Parameter er in einer Simulationsvariante ändert. Nach meiner persönlichen Einschätzung ist er gut beraten, das sehr sparsam zu tun.
Prinzipiell gebe ich Ihnen recht: Ein Rahmenwerk kann wahrscheinlich nie sinnvoll nur in einer Simulationsvariante betrieben werden. Es muss immer ein Rahmenwerk mit der SV 0, also der Realität, daneben liegen. Denn von dem aus muss ja die Simulation über das entsprechende Plug-in gesteuert werden. Anders kann das ja eigentlich nicht beherrscht werden.
Ergänzung:
Beim Start des Rahmenwerks kann natürlich die Standardoption des Datenverteilers für die Definition der Standardsimulationsvariante angegeben werden, dann erfolgt die Kommunikation der Plugins auf der Basis dieser Variante, solange nicht intern explizit andere Vorgaben erfolgt sind.
Zur Visualisierung der übergebenen Standardsimulationsvariante wäre eventuell ein entsprechendes Element für die Statusleiste sinnvoll, das bei Bedarf in diese eingebaut werden könnte.