Neue Ruby-Erweiterung: ModelHistory
-
So die Damen und Herren ,
wie der Name schon sagt dreht es sich hier um eine Ruby-Erweiterung für Sketchup. Sie dient dazu, den Modell-Erstellungsprozess in groben Zügen zu dokumentieren - und das so automatisch wie möglich. Die Erweiterung ist natürlich noch nicht fertig ("'natürlich', azuby, ist sie nicht fertig, wer hätte das auch erwartet ?"), aber ich wollt hier schon einmal ein bisschen Ausschau halten, ob es zu diesem Thema vielleicht ein paar Wünsche oder Anregungen gibt. Bebilderung und Datum sind schon eingebaut.
azuby
-
Folgende Werte Werte in die History mit aufgenommen:
- Component instances
- Compontents
- Construction lines
- Construction points
- Description
- Dimensions
- Edges
- Faces
- Groups
- Images
- Layers
- Materials
- Pages
- Points
- 3d polylines
- Sectionplanes
- Styles
- Texts
- Title
Ich bin mir momentan bei den mengenbezogenen Werten noch nicht sicher, ob ich nur die Mengen oder auch andere Werte mit sichere. Was wäre denn besser?
Fällt euch noch mehr ein, was interssant sein könnte und/oder ihr euch wünscht?
azuby
-
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
Advertisement