Ankündigung

Einklappen
Keine Ankündigung bisher.

Diskussionsthread EDOMI-Releases/Updates

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • coliflower
    antwortet
    Zitat von saegefisch Beitrag anzeigen
    Konntest Du schon eingrenzen, ob es an edomi oder Deinem Endgerät liegt (Auslastung)?
    Am Endgerät kann es nicht liegen, da es vor dem Update auf 1.58 das genannte Verhalten nicht present war.
    Das Endgerät ist ein MBP 2017, 2,9 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3 ...
    Safari Version 11.1 (13605.1.33.1.2)

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    coliflower : kann ich nicht bestätigen, sorry. 1.58 geht bei mir unverändert (Chrome, Win10). Konntest Du schon eingrenzen, ob es an edomi oder Deinem Endgerät liegt (Auslastung)?

    Zu iOS 11.3: Sieht tatsächlich so aus, dass Safari sich nun anders verhält. Allerdings nur vertikal, die Slider meiner alten Visu sind alle horizontal, da geht es unverändert. Ansonsten wohl noch ein Argument mehr für die Dregregler.

    Einen Kommentar schreiben:


  • coliflower
    antwortet
    bei mir reagiert edomi seit 1.58 auf der adminseite sehr langsam ... wenn ich zB auf den LBS rechtsklicke, dann dauert es 3 sekunden bis das menü aufgeht ... usw. :-(((
    konnte das jamand auch beobachten ?

    cash gelöscht, browser refreshed und neugestartet, mbp neu gestartet, edomi neu gestartet ....

    Einen Kommentar schreiben:


  • sepplo815
    antwortet
    Hi,
    ich glaube das Problem kommt daher, dass man seit iOS11.3 die Anzeige (falls die VISU größer ist als die Auflösung des iOS Geräts) "verschieben" kann.
    Vorher war das ja nicht möglich.

    GRuß
    Seppl

    Einen Kommentar schreiben:


  • baumhaus123
    antwortet
    Jepp, kann ich bestätigen, same here.

    Einen Kommentar schreiben:


  • Brick
    antwortet
    Ooohhh… hab ich auch. Ist bei Slidern tatsächlich nervig …

    Einen Kommentar schreiben:


  • gaert
    antwortet
    Das wäre durchaus eine Erklärung - Apple ändert gerne mal grundlegende Dinge in Safari und anderswo... Ich werde mal mein iPad bei Gelegenheit updaten und dann ein Untersuchungsverfahren einleiten

    Einen Kommentar schreiben:


  • pamo
    antwortet
    Zitat von Teutone Beitrag anzeigen
    gaert Hallo Christian, mir ist aufgefallen, das jetzt seit der letzten Version 1.58 in meinen PopUp Menü die Slider nicht mehr sauber funktionieren. Ich habe für die Raffstores jeweils ein PopUp mit 2 Slidern und nun ist es so, das beim Wert setzen durch Schieben des Sliders (ohne Button im Moment) sich das ganze PopUp Fenster mitbewegt. Vorher bliebt das Fenster beim schieben auf dem Slider wo es war. Woran liegt das? VG Nico
    Habe gerade das Update auf iOS 11.3 gemacht. Nun ist die komplette Visu nicht mehr fix und lässt sich hoch und runter verschieben.
    Hat das sonst noch jemand? Hat Apple etwas am Safari geändert?

    Einen Kommentar schreiben:


  • gaert
    antwortet
    Ich weiß es nicht?! An der Visu habe ich in 1.58 nix geändert...

    Einen Kommentar schreiben:


  • Teutone
    antwortet
    gaert Hallo Christian, mir ist aufgefallen, das jetzt seit der letzten Version 1.58 in meinen PopUp Menü die Slider nicht mehr sauber funktionieren. Ich habe für die Raffstores jeweils ein PopUp mit 2 Slidern und nun ist es so, das beim Wert setzen durch Schieben des Sliders (ohne Button im Moment) sich das ganze PopUp Fenster mitbewegt. Vorher bliebt das Fenster beim schieben auf dem Slider wo es war. Woran liegt das? VG Nico

    Einen Kommentar schreiben:


  • gaert
    antwortet
    Keine Ursache Wenn Du testen möchtest - das gleiche Spiel wie in #340, nur eine andere Funktion...:

    Code:
        function colorcalc(value,op,koValue) {                              
            if (koValue===undefined) {var koValue=ko;}
            r="";
            for (var t=0;t<3;t++) {
                var n=parseInt(koValue.substr(t*2,2),16);
                var c=parseInt(value.substr(t*2,2),16);
                if (op==0)         {var e=parseInt(n+c);}
                else if (op==1)    {var e=parseInt(n-c);}
                else if (op==2)    {var e=parseInt(n*c);}
                else if (op==3)    {var e=parseInt(n/c);}
                else             {var e=parseInt(n);}
    
                if (isNaN(e)) {
                    if (isNaN(n)) {
                        r=r+"00";
                    } else {
                        n=n.toString(16);
                        if (n.length==1) {n='0'+n;}
                        r=r+n;
                    }
                } else {
                    if (e<0) {e=0;}
                    if (e>255) {e=255;}
                    e=e.toString(16);
                    if (e.length==1) {e='0'+e;}
                    r=r+e;
                }
            }
            return r;
        }

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    Lieben Dank, Christian! Ich denke, das wird noch gute Dienste leisten.

    Einen Kommentar schreiben:


  • gaert
    antwortet
    So, erledigt. Demnächst gibt's dann also (zunächst nur bei colorcalc) einen optionalen 3. Parameter, der quasi den KO-Wert übersteuert.

    Einen Kommentar schreiben:


  • gaert
    antwortet
    Gute Idee - werde ich mal notieren und dann sehen wir weiter...

    Einen Kommentar schreiben:


  • saegefisch
    antwortet
    das heißt: solange die Hauptfarbe an 1. Stelle steht (=split(0)) und 6-stellig ist, müsste es doch funktionieren, wenn der split korrgiert wird?

    Ganz ehrlich: Dann wäre ja alles prima und das wäre für mich eine verständliche Einschränkung der Funktion. Ist ja auch ohne Nachteile; eine Reihenfolge im Sinne "primäres Merkmal muss an 1. Stelle" ist ja nachvollziehbar und meist auch intuitiv gegeben. >>> Da müsste dann nix uff die Liste... da reicht ein Hinweis in der Hilfe und vielleicht das Verwendungsbeispiel von mir.

    Werde Deinen Patch mal versuchen; muss erst mal schauen, habe bislang noch nie was in edomi gepatcht...

    ---
    NACHTRAG: Prima, Christian, Danke! Mit dem Patch geht es!

    Daher wie schon oben notiert: Aus meiner Sicht sollte die vorhandene Funktion dann nicht geändert werden. Aber ein Hinweis und gerne auch das Beispiel in der Hilfe ist sicher sinnvoll.

    Ein zusätzliche Funktion, die losgelöst vom KO mit 2 Eingangs-HEX geht, ist sicher auch mal von Nutzen, aber dann sollte die Originalfarbe als Eingansgparameter als 3. Parameter optional möglich sein (mit = stand-alone ohne KO-Bezug | ohne = wie bisher auf das KO).

    Das wäre vielleicht auch bei weiteren Funktionen ein interessantes Konstrukt (bei manchen geht es ja schon heute): Wenn als letzter Parameter ein Eingangswert übergeben wird, bezieht er sich darauf, fehlt er, wirkt es wie bisher auf das KO. Das wäre ganz universell und als abschließender Optional-Parameter bleibt es fast immer, wie es ist, aber die Funktionen hätten damit alle auch die zusätzliche Möglichkeit der stand-alone-Nutzung, z.B. für die Verwendung mit split().

    So geht es jetzt
    KO-Wert: 252830|333333|0|-80
    Code:
    -webkit-linear-gradient({split(3)}deg,#{split(0)} 0%,#{colorcalc(split(1),split(2))} 100%)
    Mit dem optionalen 3. Parameter sähe dann für das Beispiel so aus und würde ermöglichen, die Originalfarbe auch an anderer Stelle zu haben, z.B: v.ln.r
    KO-Wert: -80|252830|333333|0|
    Code:
    -webkit-linear-gradient({split(0)}deg,#{split(1)} 0%,#{colorcalc(split(2),split(3),split(1))} 100%)
    Zuletzt geändert von saegefisch; 07.04.2018, 13:33.

    Einen Kommentar schreiben:

Lädt...
X