View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000156 | GeoSetter | User Interface | public | 2008-01-25 08:17 | 2013-12-11 09:00 |
| Reporter | heiko | Assigned To | Friedemann | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.3.0 release | ||||
| Target Version | Fixed in Version | ||||
| Summary | 0000156: Button "später speichern" | ||||
| Description | durch die diversen Änderungen und natürlich meine persönliche Konfiguration müssen alle Bilder nochmals gespeichert werden (z.B. Erzeugungsdatum automatisch setzen). Dieser Vorgang dauert pro Ordner im Durchschnitt 2 Min. Wie wäre hier ein Button "Später speichern". Alle Änderungen werden in eine Liste geschrieben und dann z.B. beim Programmende oder über einen weiteren Button wirklich gespeichert. Auf diese Art könnte man alle Änderungen an allen Bildern vornehmen den "Endgültig Speichern" Button drücken und dann den Rechner stundenweise arbeiten lassen. Dies wäre natürlich nicht nur jetzt bei automatisch geänderten Daten angenehm, sondern auch nach einem längeren Urlaub. | ||||
| Tags | No tags attached. | ||||
|
|
Zur Klarstellung des Featurewunsches diese Frage : Diese Speicherfunktion wird aber immer innerhalb der aktuellen Laufzeit des Programms ausgeführt, oder ? Andernfalls müsste der Arbeitsstand ja beim beenden von Geosetter in einer Datei gesichert wedern, damit nach einem erneuten Start von Geosetter auf diesem Stand weitere Änderungen vorgenommen werden können. Das halt ich persönlich für oversized. |
|
|
ja, das war schon so gemeint, dass man irgendwann dann mal den "Endgültig Speichern" Button drückt und GeoSetter dann den Rest der Nacht arbeiten läßt :-). GeoSetter wird dabei nicht beendet; sollte GeoSetter doch beendet werden, dann sind auch die ganzen "Zwischenspeicherungen" weg. |
|
|
Die Idee finde ich gar nicht soooooo schelcht ;-) Ich könnte als Option anbieten, dass man die angesammelten Operationen in GeoSetter ausführt, oder aber das ganze als Batch-Datei speichert. Wenn ich aber gerade so darüber nachdenke, wird es vielleicht doch ein wenig kompliziert. Erst hatte ich gedacht, ich müsste mir ja nur die ExifTool-Aufrufe merken. Was wäre aber, wenn man in einem Verzeichnis einige Bilddaten ändert, dann das Verzeichnis wechselt und dann wieder zurückwechselt? Da die Änderungen an den Bildern noch in der Queue stecken, sieht man die ungeänderten Daten. Wenn man diese nun erneut ändert, wird es kompliziert... Na gut, man könnte dann bei einer Datenänderung eine Nachricht anzeigen, dass bereits Datenänderungen für die Bilddatei in der Warteschlange vorliegen und ob diese verworfen werden sollen. Ich würde mir ungerne alle Bilddaten über den Verzeichniswechsel hinaus merken wollen. Das ist erstens kompliziert und zweitens evtl. speicherintensiv... |
|
|
also ich selbst könnte ganz gut mit der kleinen Lösung leben. Ich würde ein Verzeichnis, in dem Daten geändert wurden einfach sperren; ein entsprechendes Symbold im Browser sollte das Sperren dann natürlich symbolisieren. Ausführen würde ich die gesammelten Aktionen dann in GeoSetter, so dass dann auch ein Speicherreport vorhanden ist (man weiß ja nie). Wenn man dann in geänderten Verzeichnissen doch noch Änderungen machen will, dann muss eben erst einmal komplette gespeichert werden. Das würde ich aber als gar nicht so sonderlich schlimm empfinden, da man dann auch mal ne Stunde was anderes machen kann und nicht im 2 Minuten Rythmus ein neues Verzeichnis bearbeiten muss. Umso länger ich drüber nachdenke ist deine Variante fast besser: wenn man das 2. mal in ein Verzeichnis mit geänderten Daten kommt dass diese dann verworfen werden. den Deluxe Weg könnte ich mir so vorstellen: nur die Änderungen + vollqualifizierten Dateiname in ne verkettete Liste schreiben (ich glaub das heißt bei dir Collection :-)). Beim Verzeichniswechsel die aus den Bildern gelesenen Daten durch die Daten aus der Liste aktualisieren und dann anzeigen. Werden dann weitere Änderungen gemacht entsprechend die Liste wieder aktualisieren. Beim "Alles speichern" Butten dann aus der verketteten Liste die ExifTool Aufrufe generieren. Vom Speicher her habe ich nicht mal wirklich Bedenken. Ich würde mal von ca. 500 Byte pro Datensatz ausgehen. Wo ich eher Probleme sehe ist dass es kompliziert und vor allem langsam wird. Vielleicht hat da ja jemand anderers auch noch ne Meinung dazu? |
|
|
Nun ja, ichhab ja einen 4Kern-Hobel und suche nach Auslastung. Also, wenn alle Änderungen an einem Verzeichnis voll Bilder erzeugt sind, und man wechselt das Verzeichnis, dann könnte ein Dialog kommen, der abfragt, ob diese Änderungen verworfen oder gespeichert werden sollen. Im letzteren Fall startet man einen Batch-Job in einem separaten Thread mit dem von Heiko (Änderungen + vollqualifizierten Dateiname) beschriebenen Inhalt und führt die Speicheroperationen aus. Parallel dazu kann sich Geosetter ja schonmal um das neue Verzeichnis kümmern. Problem : Der User wechselt nur mal eben so zum Nachschauen in ein anderes Verzeichnis, startet dadurch den Speicher-Job und kommt sofort wieder in das Verzeichnis zurück, in dem gerade die Änderungen gespeichert werden. Was tun wir dann ?? Aber dauert das Speichern wirklich immer solange (Stunden!!) ? Lohnt sich diese Komplexität wirklich, denn Heiko könnte in einem Jahr ein neues Notebook erhalten, das 4x schneller ist ? |
|
|
@drose: versteh ich das richtig? du willst mir ein neues Notebook spendieren :-) das speichern dauert natürlich nicht Stunden. Die Pausen wenn das Speichern auch nur 2-3 Minuten pro Verzeichnis dauert sind eben lästig, und da kam mir eben in den Kopf, dass man das alles in einem Rutsch erledigen könnte und dann einfach bevor man ins Bett geht den "alles speichern" Button drückt. wie gesagt, mir selbst würde durchaus die "kleine" Version reichen. Ich denke mal die Entscheidung muss schlußendlich Friedemann treffen ob dieses Feature überhaupt rein kommt und wenn ja in welcher Form. Ich kann den Aufwand nicht abschätzen, so dass ich nicht sagen kann welche Variante in Bezug auf den Aufwand denn die bessere wäre. |
|
|
@heiko : Nee, da muß ich Dich leider enttäuschen. Ausserdem hatte ich den konjungtive verwendet, um Dir nicht zuviele Hoffnungen zu machen. Aber die Hoffnung stirbt bekanntlich zuletzt ;-)) |
|
|
Ich warte mit einer Programmänderung am besten noch ein wenig, denn vielleicht beschenkt Ihr Euch ja dann gegenseitig mit neuer Hardware und ich bin aus dem Schneider :-) Ich muss mir das überlegen. An erster Stelle was dieses Thema angeht steht sicherlich erstmal die Parallelisierung des Speicherungsprozesses (0000136). Das werde ich sicherlich demnächst mal angehen. Dann sehe ich mal weiter ;-) |
|
|
entspricht der Process Queue der aktuellen Beta |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-01-25 08:17 | heiko | New Issue | |
| 2008-01-25 10:57 | drose | Note Added: 0000320 | |
| 2008-01-25 11:25 | heiko | Note Added: 0000321 | |
| 2008-01-25 11:28 | heiko | Note Edited: 0000321 | |
| 2008-01-25 19:30 | Friedemann | Status | new => assigned |
| 2008-01-25 19:30 | Friedemann | Assigned To | => Friedemann |
| 2008-01-25 19:56 | Friedemann | Note Added: 0000322 | |
| 2008-01-25 19:56 | Friedemann | Status | assigned => feedback |
| 2008-01-25 23:10 | heiko | Note Added: 0000325 | |
| 2008-01-26 12:10 | drose | Note Added: 0000331 | |
| 2008-01-26 17:12 | heiko | Note Added: 0000333 | |
| 2008-01-27 19:50 | drose | Note Added: 0000341 | |
| 2008-01-27 20:02 | Friedemann | Note Added: 0000342 | |
| 2013-12-11 09:00 | heiko | Note Added: 0001993 | |
| 2013-12-11 09:00 | heiko | Status | feedback => resolved |
| 2013-12-11 09:00 | heiko | Resolution | open => fixed |
