Statusanzeige im Multitrigger

[Chris M.]

Weh o weh... da scheint doch irgendwas mit Tabs und Spaces gemischt zu sein. Ich prüfe das dann auch nochmal.

Bitte zu Tabs auch beachten: SourceForge.net: CometVisu/CodingStyle - Open Automation

[chriss1980]

Endlich

Was lange währt... usw.

Einrückung ist korrigiert, die Anmerkungen von Jan sind umgesetzt (Default-Verhalten und das Attribut im XML optional) und die Änderung in Revision 663 im SVN.

Ich hoffe, dass der Commit okay ist - falls nicht, bitte reverten und mir kurz bescheid geben. Bei mir läuft die Statusanzeige problemlos.

Schöne Grüße
Christian

ps: Ich hätte das auch gerne im Wiki dokumentiert, allerdings habe ich keine Editierrechte (Benutzer cschleiffer)

[netzkind]

Nachdem es jetzt kein Trigger mehr ist (fire&forget, es gibt keinen Status), sondern ein Switch mit Trigger-Option, sollte man ihn auch umbenennen. Wobei das wieder alte Configs unbrauchbar macht. Das sollte man noch mal überdenken.

Wenn man die Trigger vor dem Hintergrund von writeonly vielleicht auch ganz wegwerfen könnte...

Grüße,
Julian

Gesendet von meinem GT-I9100 mit Tapatalk

[Chris M.]

Nachdem es jetzt kein Trigger mehr ist (fire&forget, es gibt keinen Status), sondern ein Switch mit Trigger-Option, sollte man ihn auch umbenennen. Wobei das wieder alte Configs unbrauchbar macht. Das sollte man noch mal überdenken.

Nennt man's "Multitrigger" weil's ein Trigger mit Switch-Option ist?
Oder nennt man's "Multiswitch" weil's ein Switch mit Trigger-Option ist?

Schwierig.

Wenn man die Trigger vor dem Hintergrund von writeonly vielleicht auch ganz wegwerfen könnte...

Was nach der Logik auch die normalen Trigger überflüssig machen würde.

Wobei ich mir gerade nicht sicher bin, ob der "Status" beim Switch mit Writeonly nicht alleine durch einen Click geändert wird, also zwischen Pressed und Unpressed geschaltet wird.

=> Interessantes Thema. Aber das Konzept sollte stehen, bevor wir's umsetzen.

[netzkind]

Ich meinte damit alle Trigger. Vielleicht kann man es auch als Widget-Option machen, ob der Button einen state-change haben soll.

Damit können wir dann gleich ein wenig aufräumen, was es Neueinsteigern in der Config leichter machen KÖNNTE. Denk ich mir zumindest so, wenn die Auswahl an Widgets übersichtlicher ist.. und wir eliminieren code-duplication.

Grüße,
Julian

Gesendet von meinem GT-I9100 mit Tapatalk

[greentux]

Triggerswitch oder Switchtrigger?

[netzkind]

Button?

[Chris M.]

Damit können wir dann gleich ein wenig aufräumen, was es Neueinsteigern in der Config leichter machen KÖNNTE. Denk ich mir zumindest so, wenn die Auswahl an Widgets übersichtlicher ist.. und wir eliminieren code-duplication.

Wir haben eh schon einige Inkompatabilitäten der Config-Syntax, d.h. einem Aufräumen stehe ich positiv gegenüber.
(Wie man ein Konvertierungs-Skript von Alt auf Neu macht, können wir uns später überlegen)

Code-Duplication sollte man natürlich vermeiden, aber bitte nicht um jeden Preis. D.h. hier muss man einfach abwägen.

[greentux]

Oder mal ne Umfrage machen, wer denn ein convert Script bräuchte.
Ich mein, mit den nun langsam verfügbare werdenden Widgets, möchte man vl. auch seine Visu völlig anders aufbauen. Dann fängt man eh neu an.

[Chris M.]

Auch eine gute Idee.

Wird aber sicher noch ein paar Monate brauchen bis es relevant wird.

[greentux]

Da wären wir ja schon bei der interessanten Frage...
Next release 6 Monate nach dem letzten?
Also ein ausgereifteres, noch ohne 2/3D. Ich weiß, das wolltest Du eigentlich "der Industrie" überlassen. Ich denke aber, die ist noch nicht soweit...

[Chris M.]

Next release 6 Monate nach dem letzten?
Also ein ausgereifteres, noch ohne 2/3D. Ich weiß, das wolltest Du eigentlich "der Industrie" überlassen. Ich denke aber, die ist noch nicht soweit...

Das nächste Release gibt's wenn's fertig ist

Im Ernst: Von irgendwelchen Terminen, weil die irgendwie vom letzten abhängen ("jedes halbe Jahr" o.ä.) halte ich wenig - dazu sind wir viel zu klein.
Rein aus meiner Sicht will ich noch 3D einbauen (dauert nicht mehr lang) und dann steht v.a. an, das ganze wieder rund zu machen. Gerade der Editor muss dazu den Umgang mit 2D und 3D lernen.(*)

Bei einer konzentrierten Aktion kann das ziemlich schnell gehen (1-2 Monate), wenn's einfach weiter läuft kann durchaus noch mindestens ein halbes Jahr drinnen sein.


--
(') Hintergrund: mit 2D und 3D muss die Syntax deutlich angefasst werden, vgl. <layout>-Element. Danach ist's hoffentlich stabiler. Die Kleinigkeiten die wir gerade als Inkonsistenz bei den anderen Widgets finden bestätigt IMHO sogar diese These.

[greentux]

Ja, aber dieses "wenns fertig ist" muss ja von irgendwas abhängen.
Entweder mal irgendwann festlegen, was noch rein soll und stabilisieren oder immer weiter neue Sachen anfangen.
Ich weiß schon, das das nicht so hip ist

[makki]

Schwierig, schwierig
Also für so einen config-break könnte man durchaus im Package einen 5-Zeiler machen, obs das wirklich bringt=??

Warum ich das aber trotzdem machen würde: Es gibt nichts frustrierenderes als eine Visu 10x zusammenzuklicken, wir alle wissen das dies eine überflüssige ABM ist..

Nächstes Release: IMHO wenns rund ist und es ordentlich neues gibt; seien es neue CV-Plugins die aber auch noch reifen müssen, 3D von Chris und das alles eben mit Editor, sonst ist es (Gebetsmühle) eine Freakshow für die man kein Release braucht; wer XML's gern im Texteditor bearbeitet kann IMHO auch svn bedienen lernen (oder findet linknx oder mh praxistauglich..)

"Einfache" und "komplexe" Widgets, durchaus auch teilw. redundant finde ich ehrlichgesagt garnicht so falsch (solange die Code-Komplexität kein Bein stellt), man darf nicht vergessen das es vermutlich 90% gibt die nicht so tief drin sind und eben den einen oder den anderen Ansatz in ihrer Denke leichter umsetzen können.
Was solls, es führen immer mehrere Weg nach Rom..

Makki

[greentux]

XML und SVN passt dann doch nicht so recht. Ein Release wird hoffentlich deutlich stabiler als die Version, die man im SVN findet...

Aber ja, vl. sollten man die Sachen zusammengetragen werden, die fürs nächste release notwendig sind.