Diskussionsthread EDOMI-Releases/Updates

[vento66]

Ansonsten hab ich hier noch Tastaturen rumliegen, da kann ich den Enter Tank ausbauen, und Dir gegen ein geringes Entgelt zuschicken

[saegefisch]

Günstige Nachfüll-Enter - prima! Habe bislang meine Tastaturen ausgetauscht, wenn der Tastatur-Puffer wieder leer war. Think green!
Aber hey: kein no-name-Enter... sind die auch Original? Kürzlich gelesen, dass die Tasten manchmal haken, wenn man keine Originale verwendet. Vielleicht ist das enter auch einfach nur eingetrocknet. Aber das kann ja hier nicht mehr geschehen - wo wir jetzt manuell die Beschreibungs-Texte umbrechen müssen...

[starwarsfan]

Man könnte sich auch DasKeyboard zulegen. Durch die Ninja-Caps wird der Enter-Puffer nie leer...

[saegefisch]

WTF...Cooles Teil... der Lambo unter den Tastaturen... aber für manchen mit edomi sicher ungeiegnet; man kann ja nicht einmal per LBS den Füllstand der Enter-Taste ermitteln. Wir brauchen dringen mal ein neues Produkt-Siegel:"Designed for eodmi-use"...aber das wird jetzt OT... naja, oder das Siegel mit Versions-Angabe... <grübel>

[wintermute]

der Lambo unter den Tastaturen

Kokolores! State-of-the-Art ist und bleibt die Model M...

[saegefisch]

Auf dem 2. Bild sieht man auch gut, wie gerade das Y aufgefüllt wird... und wenn wieder jemand die falschen Buchtstaben nachfüllt oder keine Original-Buchstaben zur Hand waren, dann konnt es leicht passieren, dass dort nur noch Z kamen... (die Bildunterschrift versucht ein anderes Licht auf den Sachverhalt zu werfen)
Aber ich fand Model M immer nur hilfreich zur ausdrucksstarken Meinungsverstärkung oder zur Selbstverteidigung...aber als Tastatur...neeee. Liegt nicht die Erdscheibe auf drei Tastaturen Model M?

oh je,. gleich gibt's Haue...für so ewtas gibt es doch den Smalltalk-Threat...

[gaert]

Bei uns ist gerade wieder erhöhte Chemtrail-Dichte vorhergesagt. Daher kann ich nicht vor die Tür. Verdammt.

[Sonnengruesser]

Kurze Frage ob das so sein muss
Ich hab im Logikeditor einen großen LBS, der in der normalen zoomstufe nicht ganz auf dem Bildschirm Platz hat. Wenn ich jetzt rauszoome, dann wird der LBS verkleinert, aber die verbundenen LBS inkl. Verbindung bleiben an ihrem Platz. Sieht dann ein wenig eigenartig aus (rechts unten im Bild).
Ich verwende Chrome und die aktuelle Edomi Version.
Bug oder Feature?

Sorry, Bedienerfehler! Das passiert nur, wenn man den Browser-zoom verwendet. Mit dem Schieberegler rechts oben ist alles OK. Ich vermute mal dafür kann Edomi nix...

[saegefisch]

colorcalc(value,mode)

Hallo Christian,

dankenswerter Weise hast Du ja kürzlich die Funktion colorcalc ermöglicht. Nun möchte ich folgendes erreichen:
KO-Wert: 252830|333333|0|-80

Hintergrund-Farbe:
A) -webkit-linear-gradient({split(3)}deg,#{split(0)} 0%,#{colorcalc('split(1)',split(2))} 100%) -> Funktioniert nicht
B) -webkit-linear-gradient({split(3)}deg,#{split(0)} 0%,#{colorcalc('333333',split(2))} 100%) -> Funktioniert (so soll es aussehen, aber halt vollständig dynamisch)

Alternativer Versuch mit KO-Wert inkl. der Delimiter und dafür in Formel weg lassen: 252830|'333333'|0|-80
C) -webkit-linear-gradient({split(3)}deg,#{split(0)} 0%,#{colorcalc(split(1),split(2))} 100%) -> Funktioniert, aber mit falschem Ergebnis

Eine wunderbar generische HG-Farbdefinition in der Form A) war Ziel, als ich meine damalige Anfrage zur Funktion stellte.
Benutze ich die Formel in A) falsch oder den KO-Wert? Oder will ich mal wieder etwas zu viel?

VG,
Carsten

Nachtrag: Kann es sein, dass # und ' in einem KO bei der Interpretation zu Fehlern führen? Denn just versuchte ich für noch mehr Flexibilität (für eine Menü-Hintergrund) im Design-KO den Farbwert mit führendem # zu übergeben, damit man alternativ auch "transparent" oder "rgba(0,0,255,0.5)" einsetzen kann. Also KO-Wert #252830|333333|0|-80 und in der Farbdefinition "{split(0)}" statt "#{split(0)}". Führt dann aber zu falschen Farben (wie oben in Beispiel C).
Workaround für den Nachtrag: Statt #<Farbe> im KO tatsächlich rgb(0,0,255) oder rgba(0,0,255,0.5) verwenden. Da ich aber ohne Transparenzbedarf die Hex-Werte schöner finde: Gibt es einen Weg, um im KO das führenden # mit zu geben oder geht es technisch nicht?

[gaert]

Das kann so nicht funktionieren, denn colorcalc() bezieht sich ja stets auf den KO-Wert - und dieser ist hier (bedingt durch die Verkettung diverser Parameter) kein gültiger Farbwert...

Du bräuchtest hierfür eine weitere colorcalc-Funktion, die einen beliebigen Wert als Grundlage verwenden kann - als sowas wie colorcalc(Farbe1,Farbe2,Mode). Ich werd's mal uff Liste packen...

EDIT:
Ungeachtet dessen sollte es (quasi zufällig) dennoch funktionieren, da die Funktion nur die ersten 6 Zeichen berücksichtigt und den Rest ignoriert. Aber die Funktion split() enthält noch einen Bug (je nach Interpretation): Ein Wert wie 000001 wird in 1 konvertiert - dies ist hier natürlich nicht wünschenswert...

Ich werde die split()-Funktion (und andere) entsprechend abwandeln - Du kannst dies ja jetzt schonmal testen:

Die Funktion str_split() in www/shared/js/main.js wie folgt ändern:

    function str_split(x,pos,sep) {    
        if (!sep) {sep="|";}
        var n=x.split(sep);
        if (pos<n.length) {
            return numberOrString(n[pos]);
        } else {
            return null;
        }
    }

ersetzen mit:

    function str_split(x,pos,sep) {  
        if (!sep) {sep="|";}
        var n=x.split(sep);
        if (pos<n.length) {
            return n[pos];
        } else {
            return null;
        }
    }

Anschließend natürlich Cache löschen bzw. Seite refreshen etc...

EDIT2:
Ach ja: richtig ist natürlich diese Version (also ohne ''):
-webkit-linear-gradient({split(3)}deg,#{split(0)} 0%,#{colorcalc(split(1),split(2))} 100%)

[saegefisch]

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

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

-webkit-linear-gradient({split(0)}deg,#{split(1)} 0%,#{colorcalc(split(2),split(3),split(1))} 100%)

[gaert]

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

[gaert]

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

[saegefisch]

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

[gaert]

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

    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;
    }