CometVisu - (interner) Beta-Test

[vento66]

Ausserdem sollten alle Elemente dim info swich etc. die selbe Höhe haben. Jetzt im Moment sind die Texte und Dimmer in einer anderen Höhe. Auch sollte bei den Schaltern der Text nicht oben, sondern mittig ausgerichtet werden.

So jetzt genug der Kritisiererei

Hut ab vor dem was hier bis jetzt entstanden ist!

[vento66]

Ich meinte das Verhalten der Slider, man kann den Penöpel nicht greifen, sondern man muss auf eine freie stelle auf den Slider drücken. das verschieben des Sliders wenn er vom PC bedient wird ist ok.

Ist es auch möglich einen Platzhalter zu definieren? Ich hab bei mir jetzt mal 3 Slider aus dem DMX Spielwahn auf eine Seite gepackt. Da wäre es ganz schön wenn diese 3 Slider untereinander angeordnet werden also

<dim></dim>
<placeholder></placeholder>
<dim></dim>
<placeholder></placeholder>
<dim></dim>

[netzkind]

Ja, mit der Umsetzung des Designs bin ich auch noch nicht 100%ig zufrieden. Hier hätte ich gehofft, dass jemand der CSS im Schlaf rückwärts kann und ein Auge für's Design hat etwas aushelfen kann.

Ich sprech das Design noch mal mit der hauseigenen Designerin ab - mal schauen ob ein Print-Gestalter performantes Interface-Design hinbekommt

Grüße,
Julian

[Chris M.]

Und das mit dem Sliden ist auf den I-Geräten nicht wirklich ein sliden.

Welches Sliden? Das der Slider oder das beim Seitenwechsel?

Woher stammen die Unterschiedlichen Ansichten zwischen Laptop und Ipad?

Anhand der Screenshots würde ich sagen, dass das etwas mit der zur Verfügung stehenden Breite zu tun hat - auf dem zweiten Screenshot stehen in der Breite mehr Pixel zur Verfügung, weshalb der Text in der ersten Box nicht umgebrochen wird, dadurch weniger Höhe benötigt, und deshalb alles nachfolgende anders floatet als auf dem Ipad.

Sehe ich auch so.

@Chris: Fürs erste sollten wir aber vielleicht den für "text"-widgets zur Verfügung stehenden Platz vergrößern, da dort der Text auch an der Stelle sein darf an der üblicherweise das Eingabeelemente (Switch, Dim) liegt. Dann würde das Beispiel auf dem Ipad nicht mehr umbrechen.

Ja, mit der Umsetzung des Designs bin ich auch noch nicht 100%ig zufrieden. Hier hätte ich gehofft, dass jemand der CSS im Schlaf rückwärts kann und ein Auge für's Design hat etwas aushelfen kann.

Von der grundlegenden Richtung bin ich zufrieden - denn Ziel war zum einen ein dunker Hintergrund und andererseits das Vermeiden nach QC auszusehen. Außerdem sollte es minimalistisch und edel aussehen. Optimiert auf Touch-Bedienung ist ja eh klar. Und ein paar schöne Akzentfarben gibt es ja auch schon (auch wenn die wohl kaum jemand entdeckt haben dürfte...)
Aber bei der konkreten Umsetzung sind halt noch Schwächen vorhanden

[netzkind]

Hi Micha,

Bin gerade mal ein bisschen am Spielen! Tolle Arbeit bisher! Woher stammen die Unterschiedlichen Ansichten zwischen Laptop und Ipad? Die Config ist doch die selbe Das find ich noch etwas seltsam, da die Visu da schnell unübersichtlich wird, weil man die Buttons eigentlich immer auf der selben Stelle erwartet.

Anhand der Screenshots würde ich sagen, dass das etwas mit der zur Verfügung stehenden Breite zu tun hat - auf dem zweiten Screenshot stehen in der Breite mehr Pixel zur Verfügung, weshalb der Text in der ersten Box nicht umgebrochen wird, dadurch weniger Höhe benötigt, und deshalb alles nachfolgende anders floatet als auf dem Ipad.

Um das gradezurichten würde ich spontan sagen: da wir dem Ipad nicht mehr Pixel geben können, müssten wir dem Laptop welche wegnehmen - also eine künstliche Begrenzung des Anzeigebereichs. Dadurch würde nicht mehr der ganze Bildschirm ausgenutzt, und das ist auch cheese.

Im aktuellen SVN-Stand nutzen wir noch min-height um die Höhe der Anzeigeelemten auf ein Mindestmaß zu setzen. Das könnte minimale Verbesserungen bringen.

@Chris: Fürs erste sollten wir aber vielleicht den für "text"-widgets zur Verfügung stehenden Platz vergrößern, da dort der Text auch an der Stelle sein darf an der üblicherweise das Eingabeelemente (Switch, Dim) liegt. Dann würde das Beispiel auf dem Ipad nicht mehr umbrechen.

Grüße,
Julian

[vento66]

@Chris

Bin gerade mal ein bisschen am Spielen! Tolle Arbeit bisher! Woher stammen die Unterschiedlichen Ansichten zwischen Laptop und Ipad? Die Config ist doch die selbe Das find ich noch etwas seltsam, da die Visu da schnell unübersichtlich wird, weil man die Buttons eigentlich immer auf der selben Stelle erwartet.

Und das mit dem Sliden ist auf den I-Geräten nicht wirklich ein sliden. Makki hatte da schon mal was gebaut (oder bauen lassen) mit dem das besser funktoniert hat.

Aber auf dem Laptop ist die Performance ausgezeichnet!

[makki]

Ne, so in der Art geht das bei SF nicht - das geht viel leichter!

Umso besser, bin schon subscribed

Makki

[Chris M.]

Featurewunsch: eMail an die Devel-Liste bei commits (hier? so in der Art geht das wohl auch bei SF)

Ne, so in der Art geht das bei SF nicht - das geht viel leichter!

Mailingliste dafür (openautomation-svn@lists.sourceforge.net) ist eingerichtet (bzw. braucht wohl noch wenige Stunden bis der Prozess durch ist). Infos zum Subscriben auf der SF Projekt-Homepage.

[Chris M.]

Jetzt weiß ich auch wieso ich das Changelog immer übersehe: Changelog, AUTHORS, README etc. sind nicht unterhalb von visu, wie ich es eigentlich erwarten würde (gekapselt, alles an einem Ort) - sondern eine Ebene drüber.

Die sind schon richtig (s.u.) gekapselt - im trunk unter CometVisu

Wenn ich das direkt in /var/www so auschecken würde so dass die visu unter "/var/www/visu/" liegt, hätte ich so Changelog, Readme etc. in /var/www - und damit in einem ganz anderen Kontext.

Ein Fehler meines Betrachtungswinkels?

Dabei hatte ich mir gedacht, dass man .../trunk/CometVisu/visu in sein Web-Server-Verzeichnis (bzw. ggf. ein Unterverzeichnis) auscheckt und so nur das auf dem Server hat, was auf den Server gehört.
So hab ich's zumindest auf meinem WireGate und bin eigentlich ganz glücklich diesbezüglich damit.

Das Problem (und das hatte ich bei dieser Entscheidung absolut übersehen) ist, dass nun das ChangeLog "weg" ist. D.h. wenn ich was entwickle und in's SVN hochlade, muss ich immer getrennt das ChangeLog anfassen und das getrennt hochladen. So geht da auch die SVN interne Referenzzählung diesbezüglich kaputt (nicht schlimm, aber auch nicht schön).

Hat jemand einen guten Vorschlag wie wir damit umgehen sollen?
So lassen? (Aber wie dann mit ChangeLog umgehen?)
Alles in ein Verzeichnis (d.h. visu aufgeben und nach .. verschieben)? Aber wie geht man dann am besten mit der Live-Entwicklung um? Und ist das Verzeichnis nicht dann arg unaufgeräumt (d.h. Meta-Infos nicht sauber getrennt)?

[makki]

Wenn ich das direkt in /var/www so auschecken würde so dass die visu unter "/var/www/visu/" liegt, hätte ich so Changelog, Readme etc. in /var/www - und damit in einem ganz anderen Kontext.

Naja, ich glaub das machen die meisten auf SVN-Basis wie sie lustig sind, fürs .deb schiebe ich das alles momentan manuell um (von ./ in /var/www/) - ist aber glaube ich normal

Das SVN/CometVisu/changelog gehört ja in /usr/share/doc/cometvisu/changelog, aber mein Gott, das wurschtelt man 1x in debian/rules..
Was ich sagen will: das ist mein (packaging)-Problem, legt das wohin es passt, was hier "richtig" ist weiss ich ned, solange es sich selten ändert - egal

Makki

[netzkind]

[...] auch die ChangeLog-Datei auf Stand bringen. Sonst wird's später einfach unnötig mühsam beim Release.

Jetzt weiß ich auch wieso ich das Changelog immer übersehe: Changelog, AUTHORS, README etc. sind nicht unterhalb von visu, wie ich es eigentlich erwarten würde (gekapselt, alles an einem Ort) - sondern eine Ebene drüber.

Wenn ich das direkt in /var/www so auschecken würde so dass die visu unter "/var/www/visu/" liegt, hätte ich so Changelog, Readme etc. in /var/www - und damit in einem ganz anderen Kontext.

Ein Fehler meines Betrachtungswinkels?

Grüße,
Julian

PS:
echte neue Features trag ich trotzdem gerne ab sofort ins Changelog ein!

[makki]

Haben wir die Möglichkeit fürs Packaging das Changelog automatisch aus den SVN-Kommentaren zu erzeugen?

Klingt nach guter Idee, schau ich mir mal an!
Problem allerdings: ins SVN commited man mal gerne und schnell (ich zumindest ins eigene), von einem changelog erwarte ich eher "Feature/Fix xy" als "Feature XY, Fix Z, Fix A, Fix B"

Ich versuch mir mal was auszudenken, das Changelog fürs .deb ist ja eh (eigentlich) separat, wenn man nach einem festen Prefix parsen kann..? Aber ich schau mir mal an wie die grossen Jungs das machen.

Makki

[makki]

@all: wenn man im SVN mehr als kosmetische Korrekturen macht, bitte neben den SVN Kommentaren (was sehr gut läuft!) auch die ChangeLog-Datei auf Stand bringen.

!

Featurewunsch: eMail an die Devel-Liste bei commits (hier? so in der Art geht das wohl auch bei SF)
solange täglich was passiert ja kein Thema, aber ich denke es ist sowohl für die Entwickler als auch die "Consumer" einfacher wenn man "bepushed" wird; ich monitore ja so einige Projekte und würde mir das bei manch anderen wünschen! (statt alle 1-10 Wochen mal zufällig zu schauen..)

Zu den Releases hab ich dann übrigens auch schon konkrete Ideen: man kann quasi vollautomtisch neue Releases (also nicht svn sondern .tar.gz als File) per crontab von dpkg "watchen" lassen und builden - das wäre der optimalzustand (ich bin ja ansich ein sehr fauler Mensch )

FHS les ich mir nochmal durch, auch aktuell ist natürlich bei weitem nicht alles optimal und ich bin auch kein Packaging-Gott, aber ein paar Sachen glaub ich weiss ich schon darüber (warum es sicher nicht in /usr/local landet z.B. )
Ich will ja, das sowas ganz wirklich "upstream" in die IMHO beste und verbreitetste Distribution gehen kann!
Sooo unrealistisch ist das mittelfristig auch nicht, es muss sich halt jemand drum kümmern..

Makki

[netzkind]

Hi Chris,

@all: wenn man im SVN mehr als kosmetische Korrekturen macht, bitte neben den SVN Kommentaren (was sehr gut läuft!) auch die ChangeLog-Datei auf Stand bringen. Sonst wird's später einfach unnötig mühsam beim Release.

Haben wir die Möglichkeit fürs Packaging das Changelog automatisch aus den SVN-Kommentaren zu erzeugen?

Grüße,
Julian

[Chris M.]

Slider:
Min/Max werte um z.B. Warmwassertemp von 25-55°C regeln zu können.

Style und Mappings evaluiren.
also nicht statisch value="1" sondern value="0-19"

Ist jetzt drinnen (die Doku im Wiki muss noch aktualisiert werden...)

@all: wenn man im SVN mehr als kosmetische Korrekturen macht, bitte neben den SVN Kommentaren (was sehr gut läuft!) auch die ChangeLog-Datei auf Stand bringen. Sonst wird's später einfach unnötig mühsam beim Release.