Re: Stellwerksimulation im Entstehen
Verfasst: 21.12.2011 23:27:19
Tut es auch.
Du meinst, dass da kein eigenes Fenster aufgeht, sondern die Konfiguration in einer "Sidebar" erfolgt? Sollte sich einrichten lassen, tendentiell würde ich es aber eher nach links in das Fenster packen, wo man auch neue Tischfelder erstellt - oder spricht da was dagegen?MichaelT hat geschrieben: Die Einstellungen der Tischfelder würde ich mir auf der rechten Seite im selben Fenster wünschen.
Drag&Drop habe ich prinzipiell für irgendwann schon vor, nur momentan hat das nicht unbedingt höchste Priorität - das ist halt doch ein bisschen aufwendiger als die jetzige Variante - wenn es auch ein lösbares Problem ist. Was meinst Du mit den zwei Tasten zum Ausrichten, das verstehe ich grade nicht ganz?Die Elemente per Drag&Drop auf den Tisch fallen zu lassen und evtl mit 2 Tasten dann ausrichten (x/y oder ,/. wird für sowas ja gerne genommen) zu können wäre auch noch eine feine Sache.
Nein, aber ich kenne die von mir genannte Anordnung von den "Formdesignern" der Entwicklungsumgebungen wie Eclipse und MS VisualStudio und halte sie für sehr praktisch.BorisM hat geschrieben: Du meinst, dass da kein eigenes Fenster aufgeht, sondern die Konfiguration in einer "Sidebar" erfolgt? Sollte sich einrichten lassen, tendentiell würde ich es aber eher nach links in das Fenster packen, wo man auch neue Tischfelder erstellt - oder spricht da was dagegen?
In dem "Tischfelder" Tab sind über dem Löschen und Bearbeiten Button doch 3 kleinere Buttons. Soweit ich das verstanden habe, spiegelt der mittlere horizontal die Elemente und der rechte vertikal.BorisM hat geschrieben: Was meinst Du mit den zwei Tasten zum Ausrichten, das verstehe ich grade nicht ganz?
Code: Alles auswählen
<g inkscape:label="Ebene 1" inkscape:groupmode="layer" id="layer1" style="display:inline">
<path ... />
</g>
<g inkscape:label="Ebene2" inkscape:groupmode="layer" id="layer2" style="display:none">
<path ... />
</g>
Also prinzipiell sollte das nicht allzu schwer umzusetzen sein das Widget einfach statt in ein eigenes Fenster in eine Seitenleiste zu setzen. Ich sehe nur den Platz als gewisses Problem. Formulardesigner sind darauf ausgelegt dass der der sie bedient weiß was er tut - diese Art der Optionseinstellung finde ich nicht gerade intuitiv. Momentan geht der Parametereditor relativ verschwenderisch mit Platz um, und bietet eben auch die Möglichkeit für längere Bezeichnungen von Feldern bzw. auch die Angabe von Hilfetexten, während im Property-Editor von Formulardesignern meist nur ein kurzes englisches Wort steht. Das dürfte gerade auf kleineren Bildschirmen ein gewisses Problem werden fürchte ich.MichaelT hat geschrieben: Nein, aber ich kenne die von mir genannte Anordnung von den "Formdesignern" der Entwicklungsumgebungen wie Eclipse und MS VisualStudio und halte sie für sehr praktisch.
Du meinst also rotieren wäre besser als spiegeln? Das wäre jedenfalls kein grundsätzliches Problem ein Rotieren zu implementieren, allerdings finde ich es etwas irreführend, weil echtes rotieren wäre es ja nicht, nachdem ein horizontales Gleis nicht vertikal werden kann.Das könnte man auch als "rotieren" betrachten, wenn Du abwechselnd den mittleren und rechten Button drückst. Insbesondere beim Abzweig für eine Weiche kann man das gut erkennen. Die beiden Tasten rotieren also das Element entweder im oder gegen den Uhrzeigersinn.
Das wäre in der Tat eine gute Idee. Ich habe jetzt mir die Klassen nochmal angeschaut und festgestellt, dass QT die Auswahl eines Elements nach ID doch kann - ich hatte in der falschen Klasse gesucht :-) Diese Funktion ist also realisierbar und wird kommen.Und eine weitere Idee:
Inkscape unterstüzt Layer, die in den SVG Dateien als Gruppenelement (<g>...</g>) die darin befindlichen Elemente umfasst. In deiner aktuellen Lösung wird z.B. das Signal und die Signalstellungen in separaten SVG Dateien gespeichert. Wäre es nicht besser das Grundgerüst des Signals in einen eigenen Layer zu packen und die jeweiligen Signalstellungen ebenso?
Erstmal wäre es schön wenn es eine sinnvolle Dokumentation gäbe :-) Für mich ist das Bearbeiten der Doku direkt im CMS einfacher, und momentan, wo sich laufend etwas an der Doku ändert, ist es mir jetzt zu umständlich eine Download-Fassung zu erstellen. Für eine irgendwann in langer Zeit folgende finale Version wäre es aber in der Tat eine Überlegung.Christopher Spies hat geschrieben: es wäre schön, wenn es die Dokumentation auch zum Herunterladen gäbe.
Jede beliebige wird wohl nicht möglich sein - für gewisse Sachen wird man immer Anpassungen an der Software selber brauchen. So findet man zum Beispiel vorallem in der Schweiz, selten aber auch in Deutschland Anzeigen des Achszählerstandes - nachdem meine Züge momentan keine Achsen haben, tut man sich damit etwas schwer :-) Genauso ist es momentan nicht möglich eine Zugmeldeanlage zu erstellen, genausowenig wie Hilfssperren sowie Zählwerke gehen - für die beiden letzten Punkte hab ich aber schon ein Grundkonzept im Kopf, das auf die Umsetzung wartet.Begrüßenswert finde ich auch, dass offenbar die Erstellung beliebiger Stellwerksbauformen möglich sein soll. Folgende Grafiken kann ich dazu noch aus meiner Sammlung beisteuern:
Ich denke an das worauf ich Lust hab, und auf EZMG hab ich momentan mehr Lust als auf WSSB :-)Ronny hat geschrieben:Na, bevor es mit Sowjetstellwerken losgeht, sollte man doch eher an die gute WSSB-Technik denken!
Was dazu führen dürfte dass die Skripte ziemlich schnell erstellt sind im Gegensatz zu WSSB :-) Der Aufwand dürfte sich ziemlich in Grenzen halten - ohne es jetzt genauer analysiert zu haben. WSSB-Technik zu implementieren dürfte dagegen ne Sache sein die extrem aufwendig ist.Ronny hat geschrieben: Ich denke nur an die Einschränkungen dieser Bauform: nur vier einzeln ansteuerbare Weichenantriebe je Bahnhofskopf, feste Größe des Gleisbildes und und und.
Ich sehe nur den Platz als gewisses Problem.
Soweit ich weiß kann man doch auch mit QT Tooltips realisieren -kenne mich mit QT selbst allerdings nicht aus.und bietet eben auch die Möglichkeit für längere Bezeichnungen von Feldern bzw. auch die Angabe von Hilfetexten, während im Property-Editor von Formulardesignern meist nur ein kurzes englisches Wort steht
Das verstehe ich nicht ganz. Gleise können doch auf dem Stelltisch auch vertikal abgebildet werden, oder? Da stimmt vielleicht das Format nicht mehr, aber dafür liese sich ja auch per Layer eine Lösung finden.nachdem ein horizontales Gleis nicht vertikal werden kann.
Das ist letztlich eine Frage der (sinnvollen) Umsetzung. Wenn ich mir deine nächsten Sätze so anschaue, würde ich schon denken, dass ein XML-Parser sinnvoll wäre. Die ganzen Einstellungen (Helligkeit, Texte die dann per SVG dargestellt werden sollen) sind glaube ich nur wirklich gut mit einem Parser gut zu realisieren.Die einzige technisch realisierbare Möglichkeit die ich bisher gefunden habe wäre, die SVG-Datei zuerst in nen XML-Parser zu laden, auf XML-Ebene zu verändern und dann dem SVG-Renderer zu übergeben - das wäre aber ziemlich umständlich.
Klar gehen Tooltips, aber da bekommt man halt nicht unbedingt auf den ersten Blick einen guten Überblick über alle Optionen. Ich kann das halt insofern schlecht einschätzen weil mir natürlich das Arbeiten mit Formulardesignern auch in Fleisch und Blut übergegangen, ich hätte mit diesem Aufbau also kein so großes Problem. Ich frage mich halt wie jemand der dieses Bedienkonzept nicht kennt damit klarkommt - so grundlegende Bedienkonzepte wie Tooltips sind vielen "PC-Profis" natürlich bekannt, aber ich sehe bei viele Leuten die mit PCs nicht so gut klarkommen, dass diese an sich genialen Konzepte häufig schlicht nicht wahrgenommen werden.
Das ist in der Tat ein Argument... Hier wäre aber in meinen Augen die einzige schnell realisierbare Lösung, den Editor nicht automatisch zu öffnen.Ich baue (auch unter Verwendung des Formdesigners) erst das Formular bzw. den Stelltisch zusammen und konfiguriere danach. Daher empfand ich das aufpoppen des Editors, nach jedem neu gesetzen Element, als störend. Deshalb auch die Idee mit dem Eigenschaften in der Sidebar.
Ja, können sie schon, das wird dann aber eine seltsame Art des Drehens, weil das bei jedem Element anders ist. Wenn wir uns die Weichen anschauen gibt es beim S60 genau 4 mögliche Ausrichtungen (von Sonderbauformen von Tischfeldern abgesehen), die sich aber eben nicht durch Drehen, sondern nur durch Spiegeln erreichen lassen. Das durchgehende Gleis ist dabei immer waagerecht.Das verstehe ich nicht ganz. Gleise können doch auf dem Stelltisch auch vertikal abgebildet werden, oder? Da stimmt vielleicht das Format nicht mehr, aber dafür liese sich ja auch per Layer eine Lösung finden.nachdem ein horizontales Gleis nicht vertikal werden kann.
Technisch gesehen - klar, könnte man. Ich frage mich halt wie sich das auf die Performance auswirkt. Momentan lade ich jede SVG-Datei genau ein mal in den SVG-Parser, wird sie weitere Male benötigt wird nur noch auf den selben SVG-Parser zugegriffen. Mit dem Ansatz das ganze zuerst durch den XML-Parser zu jagen müsste ich jede Instanz zuerst in den XML-Parser laden, dort manipulieren, dann wieder als XML abspeichern (wenn auch im RAM und nicht auf der Festplatte), und dann durch einen jeweils eigenen SVG-Parser erneut laden lassen. Bei großen Anlagen dürfte das die Zahl der benötigten SVG-Objekte um mindestens den Faktor 100, eher mehr, erhöhen.Das ist letztlich eine Frage der (sinnvollen) Umsetzung. Wenn ich mir deine nächsten Sätze so anschaue, würde ich schon denken, dass ein XML-Parser sinnvoll wäre. Die ganzen Einstellungen (Helligkeit, Texte die dann per SVG dargestellt werden sollen) sind glaube ich nur wirklich gut mit einem Parser gut zu realisieren.
Dann könnte man auch einen anderen Ansatz bei den SVG Dateien verfolgen und die ganze Farb/Text-Konfiguration (z.B. auch für die Signalstellungen und Helligkeitsstufen) in einer separaten XML Datei vornehmen. Die SVG-Dateien wären dann quasi nur Templates.
Der ganz normale XML-Parser von QT dürfte dafür schon geeignet sein, das wäre das geringste Problem. Trotzdem wäre es mir lieber die SVG-Datei direkt manipulieren zu können.Schau doch vielleicht mal ins Netz, ob da nicht schon verwendbare XML Parser existieren, würde mich wundern wenn nicht.
Das liest sich schon fast so, als bestünde das Programm aus isomorphen Algorithmen und entwickele sich ganz ohne dein Zutun in die gewünschte Richtung weiter .BorisM hat geschrieben:...Momentan entwickelt sich das Programm als eigenständige Simulation weiter ...
Der Download funktioniert leider nicht. Ich erhalte aber keine HTTP404-Seite sondern eine Meldung vom Webbrowser, dass er die Datei nicht finden könne (egal ob Firefox, Internet Explorer oder Opera Mobile).BorisM hat geschrieben:Version 0.0.7.3 ist soeben fertig. Nähere Informationen und Download unter http://www.stellsi.de/node/27.
Darf ich das so lesen, dass es die Simulation auch für andere OS gibt/geben wird (sollte ja mit C++ und Qt möglich sein)? Wenn ja, gibt es das bisher und wenn ja wo?BorisM hat geschrieben:Außerdem wurden viele Fehler beseitigt, u.a. haben jetzt alle Buttons auch unter Windows ihr Icon (bisher wurden leere Buttons angezeigt, was natürlich nicht sehr sinnvoll ist).
Ich selber entwickel das Programm unter Linux - daher kam auch, dass die Windows-Version so viele Bugs hatte, ich habe das zuerst schlicht nicht mitbekommen :-) Ein Freund von mir, der einen Mac nutzt, hat auch schon mal mit dem Mac erfolgreich das Programm compiliert.rayquaza hat geschrieben:Danke für den Hinweis - da ist was schiefgelaufen beim Ändern der Dateiberechtigungen vor ein paar Tagen. Der Fehler ist behoben.BorisM hat geschrieben:Der Download funktioniert leider nicht. Ich erhalte aber keine HTTP404-Seite sondern eine Meldung vom Webbrowser, dass er die Datei nicht finden könne (egal ob Firefox, Internet Explorer oder Opera Mobile).Darf ich das so lesen, dass es die Simulation auch für andere OS gibt/geben wird (sollte ja mit C++ und Qt möglich sein)? Wenn ja, gibt es das bisher und wenn ja wo?
Das freut mich und geht mir teilweise auch so ;-)BorisM hat geschrieben:Ich selber entwickel das Programm unter Linux - daher kam auch, dass die Windows-Version so viele Bugs hatte, ich habe das zuerst schlicht nicht mitbekommen :-)rayquaza hat geschrieben:Darf ich das so lesen, dass es die Simulation auch für andere OS gibt/geben wird (sollte ja mit C++ und Qt möglich sein)? Wenn ja, gibt es das bisher und wenn ja wo?
Ich würde ein Tar-Gz-Archiv zum extrahieren nach /opt vorschlagen. So machen es zum Beispiel Firefox und Adobe Reader sowie die Spiele "Osmos" (closed-source Payware) und "Pokémon Online" (jeweils bei Installation ohne Paketmanager).BorisM hat geschrieben:Ich habe mich aber noch nicht näher damit auseinandergesetzt wie ich das Programm am sinnvollsten in compilierter Form unter Linux verteile, deswegen gibt es die Testversionen momentan nur für Windows.
War ja nicht schwer zu erraten ;-)BorisM hat geschrieben:Wenn ich so schaue in welchen Themen Du aktiv bist hast Du vermutlich Interesse an einer Linux-Version? :-)