Hallo,
ich kann einige frustrierende Gedanken ein wenig verstehen, kann sie indes in der Intensität nicht immer vollständig nachvollziehen, denn bei möglichen neuen Ideen stoße ich nach wie vor an aktuelle CHDK-Grenzen, deren Überwindung uns weiterhin Raum zur Weiterentwicklung (und auch für komplexere Skripte) schenkt.
Denn neue (mittlerweile auch noch umfassendere) Skripte/Anwendungen benötigen eher schon wieder erweiterterte neue Grundlagenstrukturen. Aktuell wünsche ich mir beispielsweise bei den Lua-Parametern die Möglichkeit, mehrere (Flag-)Parameter als eine „Gruppe“ behandeln/definieren zu können, und innerhalb dieser Gruppe festlegen zu können, wie viele dieser Parameter (hier in der Funktion als Flags) gesetzt sein MÜSSEN, bzw. wie viele Flags davon maximal gesetzt sein DÜRFEN. Beispielsweise in der Umsetzung:
para_group(4;0;1)
mit der Bedeutung: Die nächsten 4 Parameter werden als Gruppe behandelt, es müssen davon mindestens 0 Flags gesetzt sein, und darf höchstens 1 Flag als true gesetzt sein. Und damit nicht zwei Flags gesetzt sein können, müsste innerhalb der Parametereinstellung des Skripts dann CHDK automatisch eine eventuell bereits vorher gesetzte Flag löschen, sobald der User innerhalb der definierten Parametergruppe eine andere Flag als true setzen würde.
Wünschenswert wäre auch, ähnlich wie bei „disable, off, on, nur bei Shooting“ solche und andere Optionswahlmöglichkeiten auch innerhalb von Lua-Skriptparametern realisieren zu können. Man könnte beispielsweise für einen Parameter solche vier Optionen als Text zum Durchklicken hinterlegen, und unsichtbar im Hintergrund dem Skriptparameter(Parametervariable) den Rang der Option zuweisen. Also falls der User die Option „off“ wählt, würde an den Skriptparameter der Wert „2“ übergeben, während bei der Einstellung für den User einzig jeweils ein Optionstext zu sehen ist. Das Händling der zugehörigen Werte erfolgt im Hintergrund.
z. B. für Lua-Parameter a:
para_option a („disable“; „off“; „on“; „nur bei Shooting“)
Um mir aktuell mit gegebenen Mitteln zu behelfen, denke ich daran, einfach viele Optionen als Einzelparameter untereinander zu schreiben und dann in der zugehörigen Doku darauf hinzuweisen, das Skript verwendet einzig die erste (!) gesetzte Flag. Dieses Workaround würde zwar prinzipiell funktionieren, wäre aber für den User arg unübersichtlich und verwirrend. Zudem gerate ich dann mit der maximal möglichen Parameteranzahl an eine viel zu frühe Grenze. Neue Ideen sind halt gerne komplexer als viele aktuell bestehenden Skripte. Kann sein, dass die Anzahl (!) neuer Skripte weniger wird, aber dafür nimmt eher deren Komplexität zu. Nicht nur in der Programmierung, sondern bereits im Vorfeld der Erkenntnisgewinnung.
Auch wünsche ich mir, bei den Parametern Textzeilen einfügen zu können, um dem User Parametergruppen deutlich zu benennen und zu kennzeichnen.
z. B.
para_text „Kamerasettings“
para_text „Helligkeitssteuerung“
para_text „Zeitsteuerung“
Das würde die Übersichtlichkeit der Parameterjustierung verbessern.
Manche von uns sind daher vielleicht aktuell von der nachlassenden Kadenz weiterer Skripte etwas frustriert, während andere hingegen eher vom (zeitlichen) Umfang der Erkenntnisgewinnung zur Umsetzung neuer Ideen überschüttet sind, und im Kampf der Umsetzung „nur“ an hoffentlich verrückbare Grenzen stoßen, die wohl mittels weiterer Entwicklungen überwindbar sind. Auch wenn vielleicht nicht alle Fortschritte so eindeutig sichtbar sind, so herrscht indes kein Stillstand. Komplexe Skripte benötigen Zeit.
Ob man das alles nun als demotivierend, oder besser als motivierend auffassen soll, ist eine Frage der Perspektive, und vielleicht auch der Tagesform
Viele Grüße,
Sinter