CometVisu - (interner) Beta-Test

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

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

[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

[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

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

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]

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

[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

[netzkind]

drag&drop auf dem ipad etc.:

eigentlich warte ich auf Fortschritt bei jQuery Mobile | jQuery Mobile

Damit wir uns nicht noch weiteres Framework ans Bein binden...

Grüße,
Julian

[NilsS]

Thema "Edit auf dem ipad": ich fürchte das wird nicht so viel, da es auf allen Touch-Plattformen das Problem gibt dass ein scrollen nicht von einem drag&drop unterschieden werden kann. Das Umsortieren von Elementen dürfte also nicht zuverlässig funktionieren (wenn überhaupt).

evtl. hiermit
Drag Drop Javascript Library for iPad & iPhone

[netzkind]

Ich kann auf den edit Button klicken,jedoch tut sich nix. Das betrifft aber wie gesagt nur die Objekte die mit einer GA zusammenhängen. Das speichern funktioniert.?

Welche Plattform/Browser ist das denn? Gibt es einen Javascript-Fehler, oder passiert einfach nichts? Oder gibt es was im Tracker (den ich mir noch nicht zu Gemüte geführt habe, Asche über mein Haupt) ...

Thema "Edit auf dem ipad": ich fürchte das wird nicht so viel, da es auf allen Touch-Plattformen das Problem gibt dass ein scrollen nicht von einem drag&drop unterschieden werden kann. Das Umsortieren von Elementen dürfte also nicht zuverlässig funktionieren (wenn überhaupt).

Grüße,
Julian

[netzkind]

Auf dem Ipad ist nach "Update every 10sec" Schluss. Es gibt keine Möglichkeit nach unten zu scrollen _ Die Seite wird einfach abgeschnitten.

@Chris:
das ist das gleiche Problem wie ich bei meinem Android-Phone hatte denke ich.
Die zugrundeliegende renderengine und Eingabemethode ist nicht in der Lage Scrollbalken innerhalb der Seite anzubieten, und interpretiert deswegen grundsätzlich und absichtlich ein overflow: auto als overflow: hidden. Man müsste in dem Fall entweder auch die mobile-CSS laden, oder was ipad-spezifisches; ich glaube ersteres ist die bessere Wahl.
Ggf. muss das Javascript in templateengine.js (handleResize?) angepasst werden, dass es die Neuberechnung der Höhe unterlässt - die dann ja keine Rolle mehr spielt. Hier einfach von dem Code für Android inspirieren lassen.

Nachteil (?): die Fußleiste fliegt bei der mobile-Variante aus dem Design raus.

Grüße,
Julian

[netzkind]

EVtl. weiß hier Julian mehr - ist ja sein Kind

Sorry, bei mir war das WE Land unter, ich bin da keinen Schritt weitergekommen.

Ich nehme an, dass es ein Problem mit dem Einlesen der GA ist - deshalb kracht das Javascript und man steht im Regen. Das abzufangen hab ich ja schon auf der Todo - und die werd ich mal versuchen in den Tracker zu übertragen.

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.

Aktuell ist das (ohne Sortierung):

• der widget-Editor zeigt bei egal was die letzte ausgewählte GA, nicht unbedingt die für das Widget eingestellte an..
• 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...
• Bei einem Typ:toggle und einem Mapping: onoff kann ich keinen anderen Style auswählen!?
• Beim einbinden eines Bildes (Typ:image) gibt es ein Feld <text-content>. In der XML Config sind Beispiele drin, in denen dort nichts eingetragen ist und was auch so funktioniert.
• Fehler von get_addresses.php abfangen, und im Fehlerfall input statt select anbieten
• select für dpt verwenden
• flavour for pages

Grüße,
Julian

[vento66]

Naja da habe wir's doch schon von den 9 laufen 3 hier..... aber was mir noch eingefallen ist wegen dem edit, vielleicht liegt es ja auch daran das es nicht das komplette Paket ist.....
Aber der Ansatz, die Visu vom IPad aus zu ändern, kommt schon recht gut.

[makki]

(Der Trick dahinter: Das alle 10 Sekunden ändernde Bild ist nichts anderes als ein Web-Counter. Und wenn man das Delta über 10 Sekunden sieht, weiß man wie viele Visus an sind.)

Verrate doch nicht sowas, der geneigte Betatester weiss sowas (oder eben nicht); deswegen hab ichs auch in der demovisu dringelassen
(obwohl hier auch ein awstats läuft, ist aber immer so anstregend)

Die Standard-Config muss für's (richtige) Release eh noch auf was sinnvolles gebracht werden, was aufgeräumt aussieht aber trotzdem alle Features zeigt.

Ich hab mich ja auch nicht beschwert, das zu finden schaff ich zum Glück ohne DOM/XML-Grundkurs.. war mehr als Hinweis für die (3-4?) progressiven gedacht

Makki