Integration der "neuen" Icons vom knx-uf-iconset

[JuMi2006]

Wäre im Fall von "Browser mag keine SVGs" ein automatischer Fallback auf einfarbiges PNG denkbar?
Ich glaube die 2.3er wird gerade durch den günstig-Sektor noch ne Weile halten. Priorität natürlich hinter dem Release.

Grüße

[netsrac]

Nunja, ich bin mir beim SVG auch immer noch nicht sicher, was die Performance angeht. Man hört so viele unterschiedliche Dinge und bevor man es praktisch getestet hat, wird man nicht wissen, wie rund es läuft :-)

Könnte man sich vorstellen, dass man es mischt und statische PNGs so wie jetzt hat und nur, wenn man andere Farben will, diese aus einem SVG erstellt werden?!

Wenn man davon ausgeht, dass Imagemagick und PHP installiert sind, dann könnte man auch alle icons durch ein PHP Script laden und so alle fehlenden Icon Varianten dynamisch erstellen und in einem lokalen Cache hinterlegen.

Aber so wie's im Moment ist, scheint es ja für die meisten Leute zu funktionieren.

Gruß, Netsrac

[Chris M.]

Mal überlegen, evtl. gibt's da mit meinem neuen Spielzeug <canvas> eine dynamische Lösung...

[netsrac]

Bin gespannt :-)

[Chris M.]

Erste Tests sehen positiv aus

Es muss jetzt nur noch stabil integriert werden. Vor'm asynchronen Laden hab ich jetzt schon bammel

[mfd]

Als kurze Zwischenbemerkung:
Ich habe euch nicht vergessen mit der SVG-Geschichte.

Aber ich würde gerne erstmal das Set möglichst "komplettieren" bevor ich eine neue Baustelle aufmache.
Außerdem glaube ich nicht, dass damit alles einfacher wird. Zwar wird dann keiner mehr schreien "ich brauche noch Farbe xyz" aber dafür "könntest du machen, das bei dem Minus-L-Joghurt-Icon die Pfeile sich auch in die passende Richtung drehen..."
Wie oben schon erwähnt, ich sehe das auch -> "nach dem kommenden Release".

Thema Android 2.3 ACK an JuMi2006 und Chris M.
Auch ich fahre noch auf 2.3 und finde andere Sachen viel hakeliger als nicht vorhandene Icons (Cache/Slider/Zurück-Button usw.)

[Chris M.]

So, mir Revision 1714 können jetzt die Icons auch in der Visu umgefärbt werden

Umgefärbt wird dabei jeder Pixel, der nicht 100% transparent ist. Ein paar Ziel-Farben sind per Namen definiert (mit den Werten so wie im Generator-Skript), aber die ganze Freiheit gibt's wenn man in der Config-Datei beim Icon als "color"-Attribut die Farbe als Hex-Wert angibt, wie z.B. #ff0000 für ein sattes rot.

Damit ein Icon umfärbt werden kann, muss es etwas anders definiert werden als bisher. Es müsste z.B. aussehen wie

'weather_winter' :               { '*' : { 'white' : '*/white', 'ws' : '*/white', 'antimony' : '*/blue', 'boron' : '*/green', 'lithium' : '*/red', 'potassium' : '*/purple', 'sodium' : '*/orange', '*': { '*' : recolorNonTransparent('icon/knx-uf-iconset/128x128_white/weather_winter.png' )}}},

Achtung: ich habe die Definitionen im iconhandler NICHT angepasst, da das ein Skript sicher besser kann.
=> Hier können unsere Skript-Gurus wieder einsteigen , und am besten nach etwas öffentlichen Test auch die nun vorhanden Varianten wieder auf eine reduzieren.

D.h. aber auch: ohne jetzt was am Code zu ändern, wird man diesen Effekt erst mal nicht sehen können...

(Mein Test mit Chrome, Firefox, Android 2.3 und iPad waren alle erfolgreich)

[netsrac]

Integration der &quot;neuen&quot; Icons vom knx-uf-iconset

Hört sich erstmal super an - aber wasbedeutet, dass jeder Pixel der nicht 100% transparent ist umgefärbt wird.

Wenn ein Pixel nun 50% Transparenz hat, hat er das auch noch nach dem Einfärben dann 100% der Zielfarbe, oder bleibt die Transparenz erhalten.

Bei meinen ersten Versuchen mit Imagemagick hatte ich dieses Problem und die Icons sahen so am Rand nicht schön aus.

Ich kann morgen mal das Script anpassen und einen Alternativen Iconhandler zum Testen erstellen.

Danke und Gruß...netsrac

[Chris M.]

Hört sich erstmal super an - aber wasbedeutet, dass jeder Pixel der nicht 100% transparent ist umgefärbt wird.

Wenn ein Pixel nun 50% Transparenz hat, hat er das auch noch nach dem Einfärben dann 100% der Zielfarbe, oder bleibt die Transparenz erhalten.

Es wird nur die Farbe geändert, die Transparenz bleibt.

Aber wenn das Icon nachträglich skaliert wird (per CSS bzw. styling), dann kann sein, dass der Browser das beim canvas nicht genau so macht wie das Skalieren eines Bildes.
Das ist aber ein Browser "Feature", da kann die Visu nichts für.

Wenn das stören sollte, dann sollten wir eher mehrere Icon-Größen gleichzeitig anbieten...

[netsrac]

Hi Chris,

ich habe mal das Script geändert und einen neuen iconhandler.js erstellt. Leider stribt die Visu damit. Die Console zeigt folgenden Fehler an:

[16:31:45.494] TypeError: i.clone is not a function @ http://bla.net/visu/structure/pure/_common.js:448

Ich habe Dir den angepassten Iconhandler mal ins SVN gestellt:

iconhandler.js.recolor

Einfach mal damit den iconhandler.js ersetzen und testen.

Gruß, Netsrac

[Chris M.]

Die Datei getestet in Chrome: funktioniert bei mir...?!?

Was Du immer beachten solltest: wenn Du Source-Dateien änderst kann es notwendig sein, denn App-Cache (also die Datei cometvisu.appcache) anzupassen. Am einfachsten oben die Timestamp im Kommentar aktuallisieren, sollte ausreichen.

[jensgulow]

Habe dasselbe Problem wie netsrac - die sache mit dem cometvisu.appchache brachte keine Veränderung. Gibt es noch andere Ansätze dieses potentielle cache-Problem anzugehen?

[Chris M.]

OK, jetzt kann ich's nachstellen.

Mit meiner Test-Config ist's nicht aufgetreten, aber jetzt mit der Demo-Config schon...
=> Schau ich mir an.

Nachtrag: Mit Revision 1720 sollte das nun behoben sein. ABER: habe gerade gesehen, dass <icon>-Elemente ohne "color"-Attribut noch scheitern
=> Erste Tests sollten nun gehen, die Demo-Config aber noch nicht...

[Chris M.]

habe gerade gesehen, dass <icon>-Elemente ohne "color"-Attribut noch scheitern
=> Erste Tests sollten nun gehen, die Demo-Config aber noch nicht...

Mit Revision 1722 sollte es jetzt auch ohne color-Attribut funktionieren, d.h. auch die Demo-Config mögen.

=> Bitte testen.

[jensgulow]

Hallo,

habe mal die neue Variante ausprobiert. Führte bei mir zu überraschenden Ergebnissen:

snapshot 1 ist die Variante, welche bisher benutzt wurde (funktioniert in Revision 1722 als iconhandler.js wie bisher).

snapshot 2 ist die Variante mit der iconhandler.js.recolor.

Hier werden die icons deutlich vergrößert. Außerdem bekommen gleich alle gleichnamigen icons (und auch noch einigen anderen) diesselben Farben und Klassen (hier class=blink) übergeben.

Bin deshalb wieder zurück auf die herkömmliche Variante.

LG

Jens