Neue Ruby-Erweiterung: ModelHistory
-
Ich möchte Objekte, denen Namen gegeben wurden, über die Ruby-Konsole ansteuern können, also mittig im Fenster zeigen können. Dazu müßten zu den Namen die »Koordinaten« abgefragt werden. Und ob sich damit eine Sketchup-Scene/Seite über die Konsole einstellen läßt, muß ich noch auskundschaften. Vielleicht weißt Du, azuby, dazu mehr. Respekt vor Deiner Arbeit!
[N Lindenthal]
-
Das geht sicherlich, hat vielleicht was mit Views zu tun, denke ich. Damit habe ich noch nichts gemacht. Gehört aber auch nicht zur History.
ModelHistory soll eine Mischung aus Projektanalyse-, Reporting- und Versions-Tracking-System sein. Also wo ich mir angucken kann, wie die relevanten Daten des Modells zu einem bestimmten Zeitpunkt aussahen und wie fleißig ich war mit der Erstellung neuer Flächen, Kanten, ... Es geht also um die kontinuierliche Arbeit an ein und derselben Datei. Die eigentliche Versionsverwaltung des gesamten Modells, so sie denn gebraucht wird, kann ich nicht leisten. Dazu bediene man sich bitte eines CVS oder SVN.
Momentan plane ich noch, eine ToDo-Liste mit einzubauen, damit man gucken kann, wann man welche Aufgaben gestellt hat und wann oder ob sie erledigt oder verworfen wurden. Da kann dann der Chef kommen, ein leeres Projekt mit 2578 ToDos aufsetzen und sagen: "Nu mach mal. Und schick mir das Projekt wöchentlich zu, damit ich dir eins verpassen kann, wenn du zu langsam bist."
Die "Projektdokumentation" wird in eine XML-Datei ausgelagert mit dem Vorteil für den Anwender, dass er sie auch mit anderen Programmen angucken kann. Z. B. könnte man dem Chef auch nur die XML-Datei schicken, weil der ein bestimmten Programm hat, was direkt über eine Schnittstelle mit einem Projektmanagement-System verbunden ist. Und dann geht die Bezahlung über erledigte ToDos
azuby
-
Zum Appetit-Machen mal ein vorläufiger Screenshot.
azuby
-
Es scheint, dass die Entwicklung jetzt eine wichtige Hürde genommen hat - und zwar das fehlerfreie Lesen der Daten aus und Schreiben der Daten in die XML-Datei. Aufgrund der Menge an Informationen schleichen sich hier hin und wieder Flüchtigkeitsfehler ein, bei denen der Programmierer dann über "Bugs" flucht.
Aktuell sind etwa 1.300 Zeilen programmiert, wobei Redundanz dabei ist und einige Daten auch nur HTML-, CSS- und Javascript-Content sind.
Auf die ToDo-Liste hat sich nun noch ein Feature geschlichen, und zwar die Ansicht der History in Form eines Storyboards. Vielleicht lässt sich auch eine Animation dynamisch erstellen, mal gucken.
Weiterhin sind in der Ansicht Versionsnummern hinzugekommen, damit man die Einträge (die grauen Balken) nicht zählen muss. Der oberste Balken hat als Indikator, damit man weiß, dass es sich dort um die aktuell im Modell angezeigten Daten handelt (auch wenn das Modell in der Form noch nicht in der History ist), eine farbliche Hervorhebung erhalten.
azuby
-
So, wieder aktueller Stand.
Ich hab mir das mit der Versionsverwaltung noch einmal durch den Kopf gehen lassen. Ich plane eine Option, die man antickern kann, um zu sagen, ob man die Modelldatei selbst (also die .skp-Datei) mit in die History packen will oder nicht. Momentan wird (neurdings) mit hineingepackt, aber sowas kann ja dann ausarten, wenn das Modell größer wird. Es entstehen somit zwei "Arten" von History-Punkten
1.) solche mit nur den statistischen Daten und einem Bild
2.) solche wie 1.) und zusätzlich mit der .skp-DateiBei der Auflistung der History-Punkte ist bei den Versionen, die mit .skp-Datei gespeichert wurden, ein Link zu sehen, drauf steht "Rollback", was soviel heißt wie "Schmeiß alles weg, was neuer ist als dieser History-Punkt" Die Funktionalität dahinter muss noch implementiert werden, sie wird dann natürlich destruktiv sein müssen -> Rollback ist mit Vorsicht zu genießen. Immer.
Das Storyboard ist momentan relativ spartanisch, es werden die Bilder der Versionen angezeigt, um einen Überblick über den Fortschritt der Arbeit zu erhalten. Außerdem werden die Bilder in einer Animation gezeigt - nice to have. Wenn man vor dem Speichern der .skp-Datei das Modell immer wieder auf die gleiche Position bringt, dann bekommt man ein hübsche Animation, bei der man dem Modell beim Wachsen zugucken kann. Dazu am bestenn eine Seite/Page/Scene anlegen und auf diese vor dem Speichern wechseln. In diesem Zusammenhang die momentane Reihenfolge der Useraktionen:
(- auf "Preview"-Page wechseln)- Modell speichern
- History-Punkt setzen per Klick auf Toolbar-Button, Menu-Eintrag, Kontextmenu-Eintrag
Die graphische Auswertung der Modelldaten wurde geprüft, ihr steht nichts im Wege, außer der Mathematik
Die aktuelle Ansicht (also dass, was in dem Bild/Anhang ein paar Beiträge zuvor zu sehen ist), kann jetzt als HTML-Datei rausgeschrieben werden, damit man es verschicken und anderen Leuten zeigen kann. Hier muss ich bezüglich der Bilddaten noch einen Bugfix machen, da momentan die Pfade absolut gesetzt sind.
Es wurden außerdem diverse andere Bugs gefunden und beseitigt
edit: Vermutlich komme ich die nächsten Tage nicht dazu, an der Ruby-Erweiterung zu arbeiten. Die Pflicht (in Form von Uni-Aufgaben) wartet und ich hab sie sträflichst missachtet.
azuby
-
Das Vorhaben hört sich nützlich an.
[N Lindenthal]
-
Verblüffend. Weder hier noch im Ruby-Subforum Vorschläge zur Verbesserung Hm tja OK, scheint wohl entweder so allumfassend zu sein, dass nichts mehr fehlt oder so abwegig, dass man nicht auf den Gedanken kommt, es könnte was fehlen.
off topic
@N Lindenthal
Bin durch Zufall gerade auf Folgendes gestoßen: Wähle mal in irgend einem Modell ein Element aus, bewege dich davon dann weg und gib dann in der Ruby-Konsole folgendes ein:[code]Sketchup.send_action 'viewZoomToSelection:'[code]So, gehen wir mal davon aus, du hast Gruppen und Komponenten im Modell, die einen Namen haben. Dann muss nur noch durch die Elemente des Modells iteriert werden, bei jedem geprüft, ob es eine Gruppe oder Komponente ist und wenn ja dann noch der Name gecheckt werden. Wenn man eine gefunden hat, wo der Name passt, dann sendet man einfach das Kommando von oben.azuby
-
Ich verknüpfe mal die beiden Threads:
http://www.sketchucation.com/forums/scf/viewtopic.php?p=8333#p8333azuby
-
Danke, azuby.
Leider momentan zu viel anderes um die Ohren. Aber so schnell wie möglich komme ich wieder.
[N Lindenthal]
-
@azuby said:
… off topic
@N Lindenthal
Bin durch Zufall gerade auf Folgendes gestoßen: Wähle mal in irgend einem Modell ein Element aus, bewege dich davon dann weg und gib dann in der Ruby-Konsole folgendes ein:[code]Sketchup.send_action 'viewZoomToSelection:'[code]So, gehen wir mal davon aus, du hast Gruppen und Komponenten im Modell, die einen Namen haben. Dann muss nur noch durch die Elemente des Modells iteriert werden, bei jedem geprüft, ob es eine Gruppe oder Komponente ist und wenn ja dann noch der Name gecheckt werden. Wenn man eine gefunden hat, wo der Name passt, dann sendet man einfach das Kommando von oben.azuby
weiter OT (bald öffne ich den verständlichen Faden)
Das ausgewählte Objekt kommt nach vorne ('viewZoom…'). Nun muß also '…ToSelection:' durch den Namen des Objekt ausgetauscht werden. Azuby eröffnet den Lichtblick.Die Objektnamen kenne ich ja schon vorher, denn deshalb haben die Elemente von mir ihre Namen erhalten. Wie schreibe ich denn nun den Elementnamen in der Rubyzeile? (Sketchup.send_action 'viewZoomTo"Block":' funktioniert nicht [das Element heißt »Block«])
[N Lindenthal]
-
def zoom_to name selection = Sketchup.active_model.selection selection.clear Sketchup.active_model.entities.each do |e| if e.kind_of?(Sketchup;;Group) or e.kind_of?(Sketchup;;ComponentInstance) selection.add e if e.name == name end end Sketchup.send_action 'viewZoomToSelection;' end
Getestet folgendermaßen:
- Datei "irgendwas.rb" in Tools-Verzeichnis angelegt
- Code reinkopiert
- Datei gespeichert
- Sketchup geöffnet
- den Typen in der Mitte des Bildschirms im "Entity Info"-Fenster "Horst" als Namen gegeben
- in die Ruby-Konsole eingegeben: zoom_to "Horst"
- ein Viereck gemalt
- Viereck mit Kanten zusammen markiert
- Viereck im "Entity Info"-Fenster "Karl" als Namen gegeben
- in die Ruby-Konsole eingegeben: zoom_to "Karl"
Auffällig: Der Betrachtungswinkel ist möglicherweise nicht schön.
azuby
-
Öj! Azuby, Du kannst ausbilden. Das klappt bei mir.
Nur »Horst« hatte ich »May« genannt.
Über die Betrachtungsrichtung habe ich auch schon nachgedacht. Es gibt ja wohl zu einer Zeit nur 1 Achsensystem. Dieses eine Achsensystem müßte man abfragen können und für die Zeigerichtung/-neigung angeben können. Aber das kommt später. Ab nun weiß ich, daß mein Vorhaben gelingen wird. Leider in diesem Faden OT.
[N Lindenthal]
-
Und es geht weiter:
Man kann jetzt die gesamte History eines Modells löschen. Man kann bei History-Punkten, die mit .skp-Datei gespeichert wurden, die .skp-Datei löschen. Man kann, sofern ein History-Punkt mit .skp-Datei gespeichert wurde (und die Datei nicht gelöscht wurde) sich das Modell dieses Zeitpunktes anzeigen lassen. Man kann auch - weil ja so ein zurückliegendes Modell keine eigene History hat - über eine Funktion "Load newest" wieder zum neusten zurückkehren. Außerdem wird jetzt farblich an den Einträgen signalisiert, wo noch Aufgaben zu erledigen sind.
Alle Aktionen, die nur teilweise bestimmte History-Punkt-Daten verändern, sind noch nicht vollständig implementiert. Das betrifft also "Rollback" und "Remove history point", außerdem alles, was mit Tasks/Todos zu tun hat.
azuby
-
Und heute kann man Rollback nutzen. Außerdem kann man einzelne History-Punkte nun löschen.
Wenn ich Muße habe, dann kommt wohl noch die Funktion hinzu, alle History-Punkte zu löschen, die zeitlich vor einem gewählten Punkt liegen - wenn man meint, die ganz alten Dinger braucht man nicht mehr.
Als nächstes werde ich mich um die Funktionalität kümmern, von der Oberfläche aus Aufgaben hinzuzufügen, anzuzeigen und als "erledigt" markieren zu können.
azuby
-
Wo kann ich denn das ModelHistory-Rubyskript laden, um es nachzuvollziehen?
[N Lindenthal]
-
Noch nirgendwo. Ich überlege momentan, wie ich damit umgehe. Es steckt wirklich eine ganze Menge Arbeit drin.
azuby
-
Vor dieser engagierten, sachorientierten Arbeit, die auch Zeit kostet, habe ich alle Achtung. Am besten fände ich eine Bezahllösung, damit auch später, wenn sich der Erfindergeist an anderen Punkten konzentriert, weitergepflegt werden könnte.
[N Lindenthal]
-
Was so die letzten Tage hinzugekommen ist: Die farbliche Hervorhebung der "grauen Balken" istjetzt dreifach: Wenn der Punkt keine Aufgaben hat, ist keine farbliche Umrandung. Wenn der Punkt Aufgaben hat und mindestens eine davon ist noch nicht erledigt, gibt es einen roten Rahmen. Wenn der Punkt Aufgaben hat und sie sind alle erledigt, dann ist der Rahmen grün. Weil es natürlich ein bisschen blöd ist, die ganzen Punkte immer auf- und zuzuklappen, werden im Tab "Tasks" untereinander jeweils alle roten und dann alle grünen Tasks gelistet. Über diesen beiden Listen befindet sich das Eingabefeld für neue Tasks. Rote Tasks haben außerdem je Task "Mark solved" Tasks werden momentan schon aus der XML-Datei ausgelesen, das Eingeben und "solved"-Markieren ist noch nicht implementiert.
azuby
-
Die Oberfläche ist jetzt mit den Systemfarben des Anwenders gestaltet, damit seid ihr dieses hübsche Pink los Für nahezu alle Aktionen gibt es vernünftige Buttons, keine Links. Man kann Task jetzt wirklich als "Solved" markieren, man kann neue Tasks hinzufügen und man kann diese neues Tasks ebenfalls als "Solved" markieren und sie zusätzlich auch löschen. Das geht freilich nur beim aktuellen Arbeitsgang, Tasks von History-Punkten lasse ich nicht zu, entfernt zu werden, weil ich darin keinen Sinn sehe. Um Änderungen an Tasks permanent abzuspeichern, muss man einen neuen History-Punkt setzen. Ich überlege noch, ob ich das wahlweise auch so bereitstelle, dass die Änderungen sofort weggeschrieben werden - eigentlich aber eher nicht, denn sollte Sketchup irgendwann mal zulassen, dass man informiert wird, wenn der Nutzer ein Modell speichert, kann man dann ja den History-Punkt automatisch setzen und damit sicherstellen, dass die als "Solved" markierten Tasks in der aktuell gespeicherten Datei tatsächlich auch solved wurden.
Genau.
azuby
-
Heute kam dann noch auf dem linkesten der Tabs (siehe auch den neuen Screenshot im englischsprachigen Thread) ein Update-Button hinzu, das gab's als erstes Feedback schon bei einer heutigen Live-Demonstration. Außerdem gab es noch die Anfrage - auch heute - ob man nicht für die Balken ebenfalls im linken Tab, also für die History-Punkte, noch einen kurzen Kommentar reinschreiben könnte, damit man bei geschlossenen Tabs schneller sieht, um was es dort damals ging. Gesagt, getan. Wenn man jetzt "Set history point" klickt (oder im Menü wählt), bekommt man ein kleines Fenster, in das man einen kurzen Kommenatr eintragen kann.
Die Grafik-Versuche sind fortgeschritten, langsam wirds. Bei den Options gibt es zumindest schon mal ein paar Sachen zum Anklicken, funktionieren aber nocht nicht.
Ach ja, wen es interessiert: Es sind momentan etwa 2300 Codezeilen, immer noch mit bisschen Redundanz. Die Dateigröße liegt noch unter 100 KB - verglichen mit anderen Rubyskripten ein absolutes Schwergewicht
azuby
Advertisement