CometVisu - (interner) Beta-Test

[makki]

@Matthias: wie sollte so ein color-picker aussehen?
Beispiel - schnell gefunden (zeigt jetzt zwar RGB aber das bisschen Rechnerrei machts kraut wirklich nicht fett)

Makki

[mkeil]

zum thema slider: ich habe die slider mal auf iphone und andoid getestet und sie funktionieren nicht.

ich habe evtl einen fix dafür ausfindig gemacht. und würde den lokal testen und mich dann wieder melden

[MatthiasS]

Bevor man hier mit Farbkreis startet, kann man ja die Farben auch auf einem Slider verteilen (und auf einem anderen die Sättigung und auf dem letzten die Helligkeit).

Warum habe ich bei solchen "Machtworten" ein Déjà-vu?

Und richtig, man kann. Blöd, wenn man muss.

[Chris M.]

@Chris:
schau dir bitte mal https://sourceforge.net/tracker/?fun...6&atid=1251141 an (speziell Kommentar).

Wie ist denn deine Meinung dazu,

Wenn ich das richtig verstehe, spinnt jQuery bei einem style-Attribut in einer XML-Datei?!?

Dann ist meine Meinung, dass jQuery da einen Bug hat...

können wir das irgendwie umsetzen?

Klar. Das kostet uns nämlich nichts (an Laufzeit). Nur über den neuen Namen bin ich mir noch nicht klar. "Design" finde ich schlecht (genau so wie "Flavour"), da es zu Verwirrungen mit dem Visu-Design kommen kann, da dort diese Namen schon besetzt sind.

Muss da nochmal nachdenken, oder gibt's hier inspirierende Vorschläge?

[Chris M.]

Klingt schlüssig, dafür ist so ein HSV-Farbkreis sicher besser,[...]
(aus HTML bin ich ja irgendwann kurz nachdem es imagemaps gab ausgestiegen - heute kann man vermutlich den Farbkreis aus einem Werte-Array anzeigen lassen?!)

Für einen Feature-Request reicht mir diese Sonderlocke aber ehrlichgesagt derzeit nicht

Bevor man hier mit Farbkreis startet, kann man ja die Farben auch auf einem Slider verteilen (und auf einem anderen die Sättigung und auf dem letzten die Helligkeit).
Das einzige was dann noch fehlt ist die Umrechnung von/zu RGB.

Wem langweilig ist, kann gerne mal ein Custom Widget daraus machen (wie man ein Custom Widget macht, habe ich mit dem Design-Toggle ja schon mal vorgemacht)

[netzkind]

@Chris:
schau dir bitte mal https://sourceforge.net/tracker/?fun...6&atid=1251141 an (speziell Kommentar).

Wie ist denn deine Meinung dazu, können wir das irgendwie umsetzen?

Grüße,
Julian

[makki]

Und wenn die Szenenpresets passen, DANN kommt NBF.

Klingt schlüssig, dafür ist so ein HSV-Farbkreis sicher besser, aber den muss man eigentlich nicht dem Nachbarn zeigen können sondern kanns auch im HS-Monitor o.ä. einstellen Am besten ist es natürlich beides zu haben..
(aus HTML bin ich ja irgendwann kurz nachdem es imagemaps gab ausgestiegen - heute kann man vermutlich den Farbkreis aus einem Werte-Array anzeigen lassen?!)

Für einen Feature-Request reicht mir diese Sonderlocke aber ehrlichgesagt derzeit nicht - es gibt viel wichtigere Basisfunktionen in einer schnellen, schmucken und hübschen Visu.. IMHO genug erreicht, wenn das persistente Gerücht vom Tisch ist, das sowas wie Slider im Browser nicht performant gehen würde sondern man dafür so nen Plempel wie CF&Apps braucht (Man beachte bitte, das die aktualisierung des Sliders mal schon so gute 30-100ms zwischen Bustelegramm und sichtbarkeit dauert! ich muss die Webcam dranbauen..)

Inkl. einem "entfreaktem" Editor - was Julian gut IMHO gelungen ist, da seit ihr IMHO auf dem richtigen Weg!

Makki

[MatthiasS]

Ja und Ja. Aber auch um ein Preset zu definieren, braucht es halt eine Eingabemöglichkeit. Manche Leute wissen wahrscheinlich aus dem Kop, dass ein blassblautürkis 153,172,184 ist, ich brauche dazu einen (vernünftigen) Farbwähler. Und wenn die Szenenpresets passen, DANN kommt NBF.

[makki]

Gibt es Meinungen dazu?

Ich denke es geht hier auch um zwei gaaanz verschiedene Blickwinkel: der eine ist usability in der Realität, da wird man eher Szenen, Presets, Sequenzen abrufen oder statis betrachten.
Der andere ist coolness, auch gerne "NBF" genannt
Slider gehören für mich ehrlichgesagt insgesamt zu letzterem, brauchen würde ich die in der Praxis so gut wie garnicht..

Eine perfekte Visu braucht also beides: coolness damit man sie haben will und usability, damit man sie dann auch benutzen kann wenn man dann verstanden hat, warum man garkeine Slider braucht


Zu dem "ziehen" auf den touch-geräten gäbs schon spezielle events, die das equivalent zu mousedown usw handeln, wie das in der Praxis&mit den jQuery-UI aussieht weiss ich aber natürlich nicht.. (Beispiel hier)

Makki

[Chris M.]

Da ist man mal einen Tag arbeiten und dann muss man sich durch drei neue Seiten Thread lesen. Ts, ts, ts.

Da bei mir jetzt bis Donnerstag der Terminkalender randvoll ist, werd ich erst kurz vor dem WE dazu kommen das abzuarbeiten. Ich würde es begrüßen wenn ein anstehendes Release entsprechend getimed wird das die Bugfixes es noch reinschaffen.

OK, peilen wir mal nächsten WE an. Da hab ich zwar Familien-Rally - aber wenn hier alle so fleißig wie jetzt arbeiten, werde ich wohl nicht mal selbst das Release machen müssen...

Die zugrundeliegende renderengine und Eingabemethode ist nicht in der Lage Scrollbalken innerhalb der Seite anzubieten,

Da hatte ich eh schon drüber nachgedacht ein eigenes Scroll-Widget dafür zu nehmen (das ein absolut positioniertes DIV verschiebt). Da sollte sich dann auch leichter das Design anpassen lassen (wie z.B. einen Knopf der für Finger dick genug ist - das ist auf meinem aktuellen Touch z.Zt. grenzwertig).

Gibt es Meinungen dazu?

• Bei dem Thema RGB LEDs kam mir folgender Gedanke. Wäre es evt. sinnvoll den schönen Farb- (Grau-)verlauf hinter dem Slider noch jeweils in einer R,G & B Variante anzubieten!? Würde hier direkt helfen die jeweils richtige LED anzufassen...

Ich hab mal drei Farbverläufe für den RGB Mischer erstellt.

Eine Farbe mir RGB einstellen, das ist fast nicht möglich. Ich würde vorschlagen, den HSL-Farbraum zu wählen, weil man da Farben leicht einstellen kann:

Das mit dem Hinterlegen finde ich gut. Allerdings sollte man prüfen, ob man nicht besser mit einem Grau-Durchsichtigkeits-Verlauf-Bild arbeiten kann, dass man auf einen entsprechend gefärbten Hintergrund legt. Das wäre universell einsetzbar.

Thema Farbraum:
Das ist eigentlich nicht Aufgabe der Visu-Darstellung sondern der Logik-Engine. Die Visu hat einfach ein paar Slider (oder hier eher ein Slide-Feld) die Werte übertragen, die hat eigentlich keine Ahnung, was Farbe ist.

Aber: gerade wegen dynamischer Darstellung, sehe ich hier durchaus eine Ausnahme der Regel. Und das Umrechnen der Farbräume (zumindest ohne Farbprofile - die werden 99,9% der User (im Gegensatz zu mir ) eh nicht haben) braucht nun auch nicht wirklich Rechenleistung.
=> Ich denke das lösen wir am besten mit einem eigenen Widget.

[NilsS]

@Julian
Ist glaube ich eher uninteressant was das an last verursacht bei hsfusion sind das auch einige die Telegramme die da zusammen kommen

[MatthiasS]

Ist ja gut

Im Ernst, ich bin der Meinung, die zwei PROs erschlagen jedes beliebige Kontra. Farbe ist DAS Thema, und da muss man das optimale (für den user) einbauen.

[netzkind]

Also wenn der Rechenaufwand da ein Kontra ist, dann weiß ich auch nicht Das kann ja sogar der HS, Modul ist ja schon fertig. Die Rechnung ist trivial.

Ich denke da an realtime-Feedback an den User "während die Dimmer noch laufen". Wenn man das ggf. laufend in HSV zurückrechnen muss um die Darstellung zu bekommen - keine Ahnung, ich hab die Formeln noch nicht angeschaut.

Auch ist nicht jedes Kontra ein KO-Kriterium, so schien es mir grade aufgefasst worden zu sein

Grüße,
Julian

[vento66]

Vielleicht bisschen formatierung noch machen

Nun ja da bin ich noch etwas mit den Editor auf Kriegsfuss....

[MatthiasS]

Also wenn der Rechenaufwand da ein Kontra ist, dann weiß ich auch nicht Das kann ja sogar der HS, Modul ist ja schon fertig. Die Rechnung ist trivial.

Wer LEDs einbaut und sich beschwert, dass die Farbe nicht mit dem Auswähler exakt zusammenpasst, dem ist nicht zu helfen.

Wenn aber die Funktionalität abhängig gemacht werden muss vom Layout, dann ist das Projekt jetzt schon an einem Punkt, an dem andere schon früher waren