CometVisu - (interner) Beta-Test

[luigi4711]

Jetzt ist eure Demovisu über

http://wiregatexxx/visu_svn/visu

erreichbar
Der Visueditor steht unter

http://wiregateXXX/visu_svn/visu/edit_config.html

zur Verfügung

Hi Micha,
kurzer Hinweis zur Anleitung, die URLs sollten so aussehen (ohne 'visu'):

http://wiregatexxx/visu_svn

http://wiregateXXX/visu_svn/edit_config.html

Gruß
luigi

[vento66]

Warum sollte das so sein?
Es wird ja nur der neue Visu Ordner in den Visu_svn Ordner kopiert.
1. Ist das nichts für normale User. die installieren das Cometvisu Packet und fertig.
2. Der Aufruf Visu ruft halt die Visu auf, das wäre alles zu viel rumgebastel die alle dann in Visu_svn umzubenennen und dann in den selben Ordner wie die normale Visu zu legen. Ausserdem zerschiest man sich dann eher auch mal die visu_config.xml Da die dann bei jedem svn update überschrieben wird.

Der geneigte User kann sich dann die Dateien aus Visu_svn nach /var/www/visu kopieren

[netzkind]

Hi Micha,

die Doku ist glaube ich nicht ganz konsistent.
vi auf /var/www/visu_svn/visuconfig.xml - ich glaub der Dateiname hat ein underscore in der Mitte, also visu_config.xmk

Und die aufzurufende URL wie beschrieben wäre das Verzeichnis /var/www/visu_svn/visu/ - nach der aktuellen Version der Anleitung dürfte es dieses Verzeichnis aber garnicht geben, sondern der Aufruf müsste sein wie von luigi beschrieben.

Grüße,
Julian

[vento66]

Äh sorry, jetzt ists klar Du meinst Die anleitung von hier. Die kann ich leider nicht mehr ändern. Die auf Sourceforge ist ja eigentlich die um die es geht oder? Dort habe ich das so angepasst das alles oberhalb von /trunk in den visu_svn Ordner kopiert wird

[netzkind]

Ah, jetzt versteh ichs.
Wer den Link nicht parat hat:
https://sourceforge.net/apps/mediawi...n_the_WireGate

Ich persönlich bin ein Freund davon das /visu ins co gleich mit reinzunehmen, aber da gehen die Geschmäcker auseinander.

So wie du es schreibst ist es jedenfalls in sich konsistent. Vielleicht bisschen formatierung noch machen, aber sonst Öffentlichkeitstauglich.

Grüße,
Julian

[luigi4711]

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

Die Hintergrundfarbe hab ich etwas anders gewählt, als bei dem monochrom, sowie die Ausrichtung des Background Image nach rechts verschoben, damit auch bei größeren Fenstern der farbige Teil am rechten Stand steht.

.widget .ui-slider 
{ 
  width: 30%; 
  float: left; 
  margin-left: 10px; 
  margin-left: 1em; 
  margin-top: 0.5em; 
  border-color:  #010101 #282828 #282828 #010101; 
  background: url(images/gradient_green.png) #424242 right center repeat-y; 
}

Änderungen gegenüber dem Original widget sind die Farbe (#424242) und 'right center"

Vorschlag:
Würde eine doppelt hohe Box den Flow der Visu brechen!? Falls möglich, wäre es schön in einem doppelt hohen Kasten die drei Slider zusammen unterzubringen.

Vorschlag für mögliche Slider Varianten:

1. monochrom (schon da)
2. R, G, B jeweils als einzelner Slider für einzelfarbige LEDs
3. RGB als Dreierpack in einer doppelt hohen Box für RGB LEDs
4. RGBW als Viererpack für RGBW Stripes

Disclaimer: Ich bin nicht fit, was HTML/CSS angeht, wenn Fehler drin sind, bitte verbessern.

luigi

[MatthiasS]

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:

HSV-Farbraum

Siehe auch:

https://knx-user-forum.de/hsfusion/8...rbauswahl.html

[netzkind]

Ich finde die Idee eines Farbwähler gut.

Pro:
- weniger Abstraktionsschicht im Hirn des Users nötig
- schneller konkrete Farben anspringen

Kontra:
- größeres Eingabeelement nötig um auch bei Touch vernünftig zu sein; eventuell als "popup"
- der User bekommt schneller mit dass Farbwiedergabe der LED und der Visu stark voneinander abweichen (es sei denn seine RGB-LED und seine Visu sind farbkalibriert und frei von Fremdlicht)
- mehr Rechenaufwand in der Visu um von HSV auf RGB, RGBW, ... umzurechnen - und vice versa

Man müsste das hier aber per JS/CSS mit zwei Grafiken oder einem Sprite umsetzen können, denke ich: https://secure.wikimedia.org/wikiped...20061023114256

Grüße,
Julian

[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

[vento66]

Vielleicht bisschen formatierung noch machen

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

[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

[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.

[NilsS]

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

[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.

[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