Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
im oberen Bereich ist ein schwarzer Streifen im Hintergrund, der passt nicht.
1) das ist schwierig. Wir können entweder die Größen so anlegen dass sie sich dynamisch anpassen - dann hat man auf der Seite aber lauter ungleichgroße Boxen und das ganze schaut ziemlich wild aus.
Oder wir könnten speziell für Widgets bei denen wir davon ausgehen dass der User es in "riesig" nutzen will einen Container schaffen der nicht 48% der Breite nutzt, sondern 98%. @Chris: was meinst du, ich würde hier einfach den Creator duplizieren, neuer Name ("image_fullwidth" bspw), darin eine andere CSS-Klasse (widgetFullwidth bspw.) und das dann in den CSS definieren. Dann muss der User (Admin) aber wissen welche Größe er nutzen will - normal oder xtra-large.
Was mir sowieso nicht an den images und iframes schmeckt: sobald man die gleiche Visu auf Handheld/Smartphone UND 15"-Visu nutzen will schauts auf einem von beiden nach Rübenacker aus. Das aber muss jeder User für sich entscheiden, da ist kein automatisches Mittelchen gegen gewachsen.
2) hab ich bei mir grade gefixt, schafft es bei Gelegenheit dann ins SVN.
Matthias hat hier gezeigt, wie eine Visu aussehen kann. Ganz mein Geschmack.
Das ist jetzt ein Vergleich von Äpfeln mit Birnen.
Die CometVisu ist zur Zeit eine reine Text-Visu. Die von Matthias eine 2D-Visu.
Die Erweiterung der CometVisu auf 2D (und sogar 3D!) war bereits angedacht, als die noch nicht mal existierte... Aber wir machen hier einen Schritt nach dem anderen und daher wird es noch bisschen Dauern bis 2D (und 3D) implementiert ist - auch wenn es nicht schwierig ist. (Gerade weil es leicht ist, ist's noch nicht gemacht - es gibt momentan noch dringenderes. Und alles was jetzt schon da ist, wird dabei im Zweifel erst mal unbrauchbar und muss nachgezogen werden...)
Ich sag da aber mal frech: wenn du weißt wie man mit HTML, CSS und Javascript umgeht siehst du ja schon an den Sourcen (/var/www/visu/) was du für ein eigenes Design machen musst.
Das überlasse ich mal Euch. Bit und Byte-schieben ist nicht mein Ding.
... gibt es Möglichkeiten ein eigenes Design zu entwerfen? Es gibt da einige Ecken und Kanten, die ich verändern würde, *duck und wech*
Selbstverständlich ist das möglich - es ist sogar vorgesehen.
Aktuell gibt's zwei Designs, "pure" und "discreet". Diese leben - so wie es sich gehört - im Unterverzeichnis "designs".
Dein eigenes Design kannst Du dort leicht erstellen, einfach einen eigenen Namen ausdenken und dort ein entsprechendes Verzeichnis erstellen und da drinnen die basic.css und mobile.css erstellen.
Zum einfacheren Testen, hab ich übrigens ein Custom-Widget geschrieben, wo man zur Laufzeit das Design ändern kann...
Solltest Du jedoch eine grundsätzlich andere Struktur wollen, dann müsstest Du eine neue structure_*.js statt der structure_pure.js erstellen. Dieser Wechsel ist jedoch z.Zt. nur angedacht und wird noch nicht unterstützt.
Auch wenn ich es gut finde, wenn weitere Designs entstehen (für die Public Beta hätte ich gerne noch eines mit dunkler Schrift auf hellem Hintergrund), so muss Dir klar sein, dass noch nicht alle internen Strukturen fest stehen und daher das Design leicht kaputt gehen könnte (auch wenn wir probieren dass in Grenzen zu halten)
Apropos interne Strukturen - hier stehen zeitnah ein paar wichtige Änderungen an:
Das verteilen der neuen Werte auf die Widgets mit den GAs in den CSS-Klassen möchte ich auf ein Subscriber-Modell mit dezentralen Funktionen umstellen (so lassen sich leichter neue Widgets einbauen, der colorChooser würde als erstes davon profitieren)
=> Betrifft nur JS-Entwickler
Die Addressen in der Konfig-XML möchte ich von Attributen zu Elementen umstellen (so lässt sich auf mehrere GAs gleichzeitig hören, wie bei KNX üblich)
=> betrifft jeden, da die visu_config.xml angepasst werden muss!
Die Datentypen möchte ich in Transferfunktionen umwandeln. Wahrscheinlich passe ich dazu den Attribut-Namen in der Konfig an, damit es wieder konsistent ist
=> betrifft jeden, da die visu_config.xml angepasst werden muss!
Jetzt wäre noch ein optimaler Zeitpunkt die Struktur in der Konfig-Datei zu säubern. Gibt es hier Wünsche?
Sollen wir vorher (=jetzt) ein kurzes Zwischenrelease machen?
... gibt es Möglichkeiten ein eigenes Design zu entwerfen? Es gibt da einige Ecken und Kanten, die ich verändern würde, *duck und wech*
Na klar gibt es die! Ich sag da aber mal frech: wenn du weißt wie man mit HTML, CSS und Javascript umgeht siehst du ja schon an den Sourcen (/var/www/visu/) was du für ein eigenes Design machen musst.
Falls das nicht der Fall ist mein Vorschlag: verrat uns welche Ecken und Kanten du siehst, wie du sie anders umsetzen würdest - und wir arbeiten dann gemeinsam daran die Visu insgesamt besser zu machen. Dazu gibt es ja auch noch einen eigenen Usability-Thread der aber grade in Hibernation ist
(oder ich ändere mein altes Tail-in-PHP passend ab und veröffentlich das als generisches Backend...)
Na, ich glaub ned das das was ist ist ja auch highly dependant vom log das wiederum das Perl-biest schreibt und die Performance geht total vor die Hunde..
Das wird schon irgendwie werden, ich wollte nur mal nebenbei drauf hinweisen - mit Plug&Play wird das so schnell nicht, aber dafür liefe es theoretisch auch auf ner Fritzbox.
Letztlich ist es IMHO ein mehrstufenplan:
a) erstmal in einer deterministischen Umgebung sauber am laufen haben. Am Beispiel apt-cache geschrottet sieht man schon wie easy das ist
b) es darf ja jeder mitspielen, er muss halt Zeit haben und schon wissen was er tut.. ich verteile die packerl ja sogar schon für die Bastelkinder mit Dockstar (*)
c) langsam ausbauen, andere Backends (ausser pywiregate und vielleicht einen HS-tunneler) sehe ich da so schnell aber nicht..
@manu: natürlich geht das. Das ist jetzt auch beim HS nicht wirklich ein Problem.
Makki
*: das mit dem Cross-compilen in Freakfrei werde ich aber wohl nie kapieren, deswegen ist die Dockstar gerade meine Build-Umgebung für den ARMen experimente
Das ist genau die Auswirkung des Fehlers - das create des colorChoosers wird nicht gefunden, da der cholorChooser nicht geladen wurde.
Jetzt könnte man natürlich dieses Fehlerbild abfangen und zumindest ohne colorChooser weiter machen oder zumindest eine Fehlermeldung anzeigen.
Aber eigentlich muss man den Fehler bekämpfen. Evtl. ist's auch ein FF Bug...
Eine Hauptfrage ist dann noch, ob eibread/write in bcusdk/eibd-clients kommen und der eibd endlich ein neues release erfährt oder nicht - 1 Jahr warte ich darauf aber auch bestimmt nicht, just zur Info: wir arbeiten hier seit fast 2J nicht mehr mit dem Release 0.0.4 des eibd! Wer hier die neuen Packerl verteilt, mittlerweile auch für so manch armel, das bin glaube ich nur ich..
Weswegen andere dann auch regelmässig auf der Nase landen, das spielt hier aber gewaltig mit rein, weil die entscheidene GroupCacheLastUpdates ist im "aktuellen" 0.0.4 halt bei weitem garnicht drin.
Da sollten wir mal auf MKögler zugehen - gerade die CometViso ist ohne ziemlich witzlos (oder ich ändere mein altes Tail-in-PHP passend ab und veröffentlich das als generisches Backend...)
Kann das Wiregate diese auf den Bus senden und gleichzeitig lesen zum Anzeigen in der CometVisu.
Ja, geht selbstverständlich. Kenne den HS nicht, aber fände das befremdlich, wenn so was das nicht gehen würde...
In der Visuconfig werden die zugehörigen KNX Adressen angesprochen, ich vermute, dass die Werte zum anzeigen dann jeweils aus dem Cache des eibd kommen!?
Im Zuge der Entwicklung der Logikengine könnte sich das vermutlich ändern, aber das ist noch in Arbeit.
habe mal eine Frage zum senden der Temperatursensoren. Kann das Wiregate diese auf den Bus senden und gleichzeitig lesen zum Anzeigen in der CometVisu.
Kann es leider nicht Probieren, da ich nicht Zuhause bin.
Aber ich meine das der HS dieses auch nicht konnte. Bzw da war es so wenn ich über den HS mit Hilfe der ETS Gruppenadresse gesendet habe diese auf der Visu nicht angezeigt wurden.
Nebenbei, zum .deb-Packaging hab ich nun länger gegrübelt - das aktuelle 0.5.1-1 ist die Variante "make it just work" - und mir folgendes ausgedacht: Es wird in zwei Pakete aufgeteilt (ähnlich eibd & eibd-config-wg):
- cometvisu:
Sauber, FHS/lintian-konform. Der Anwender muss aber definitiv wissen was er tut.
Sich also Webserver&convinience eben selber konfigurieren. Dafür kann es guten gewissens auf SF und anderweitig verteilt/empfohlen werden.
Ein INSTALL-file kann das würzen, wo ich das wichtigeste zusammenschreiben würde (es ist halt im Detail einiges: Webserver, gz, ..)
Das sollte die depends usw. liefern und die Files auf die Platte packen, ist aber eben sicher nicht 100% Plug&Play.
Dafür bekommt kein Power-User Bluthochdruck..
Eine Hauptfrage ist dann noch, ob eibread/write in bcusdk/eibd-clients kommen und der eibd endlich ein neues release erfährt oder nicht - 1 Jahr warte ich darauf aber auch bestimmt nicht, just zur Info: wir arbeiten hier seit fast 2J nicht mehr mit dem Release 0.0.4 des eibd! Wer hier die neuen Packerl verteilt, mittlerweile auch für so manch armel, das bin glaube ich nur ich..
Weswegen andere dann auch regelmässig auf der Nase landen, das spielt hier aber gewaltig mit rein, weil die entscheidene GroupCacheLastUpdates ist im "aktuellen" 0.0.4 halt bei weitem garnicht drin.
zurück zum Thema:
+ cometvisu-wg.deb (o.ä.) - depends on cometvisu und "schmutzig" aber funktioniert dafür halt "All-inklusive" aus der Box, mit Webserver-config, depends on eibd+nmu77, rotate der gz's vom lighty usw. (wurde heute eingebaut) - in einfach (solange die Ausgangsplattform eben deterministisch, also ein WG oder ein ziemlich guter Nachbau auf Basis Debian stable ist )
Makki
P.S.: Wir werden hier übrigens mittelfristig definitiv auf squeeze (Debian 6.0, =seit Anfang August eingefrorenes testing) gehen. Ja, die Debian-Jungs sind recht langsam, aber dafür funktionierts halt dann auch 100% wenns soweit ist..
Hoi
was mir noch aufgefallen ist in dem Design bei dem discreet auf dem Knopf steht:
Der schwarze Balken hinter der Überschrift (Übersicht) bleibt stehen während man nach unten scrollt.
Kleinigkeit genau...
Und in der Hauptseite, denke mal index.html:
Code:
line 33 column 5 - Warnung: discarding unexpected </div>
Ich hatte mich mal mit den scriptaculous/prototype.js sortable Sachen gespielt: navida.de
Toll was es aktueller Stand heute so alles gibt.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: