slider: position handle

[XueSheng]

Ich möchte nochmal das Thema "Position slider handle" ausgraben. Aktuell ist es so, dass der slider handle mit einem festen Versatz zum range positioniert wird. Bei Position 0% ragt dieser links aus dem range, bei 100% entsprechend rechts aus dem range. Je nach verfügbarem Platz, entstehen hierdurch unschöne Überlappungen jeglicher Art (Beispiel angefügt).

Wenn ich mich recht entsinne, war letzter Stand der Diskussion, dass man die Position über JS nicht korrigieren kann (oder zu aufwendig?). Daher habe ich mir CSS an dieser Stelle nochmals genauer angesehen.

Mein Vorschlag wäre, dass man die absolute Position des handle (left: valPercent%) entsprechend der handle Breite korrigiert. Dies geht mit Hilfe eines "transform: translateX(-valPercent%)". Dadurch ist auch der fixe margin-left überflüssig.
Als Resultat bewegt sich der handle nur noch innerhalb des range. Mit jedem step wird die relative Position um die (anteilig prozentuale) handle Breite korrigiert, so dass keine Überlappungen mehr auftreten (Screenshot ebenso angefügt).

Soweit ich das überblicke ist die hierzu notwendige Änderung in jquery-ui.js vorzunehmen. Da ich hier keinen eigenen Weg gehen will und selbst keine Ahnung von JS habe, möchte ich das aktuelle Verhalten des sliders zur Diskussion stellen.

Stört euch die aktuelle Positionierung des slider handle (Position min/max) oder bin ich der einzige an dieser Front?

[Chris M.]

Der Slider ist leider JQuery UI - eine Bibliothek die auf den ersten Blick viel Sinn macht. Auf den weiteren Blicken aber immer weniger... Bei der Textify Performance Optimierung hat der Slider sogar eine Extrawurst benötigt

So, Rant beendet, zurück zum Thema:
Mich hat beim Designen auch schon genervt dass der Slider über's Ende hinaus geht.
Aber die Design-CSS (oder gar die custom.css) kann durchaus die vom JQuery übersteuern. Vgl. auch mal den Slider beim Planet-Design. Da hab ich den mal ganz umgeändert...

[peuter]

Ich habe die Sache mal ausprobiert, vor allem weil ich es sonst nicht hätte nachvollziehen können. Fazit: Prima Idee. Das Problem hat mich auch schon immer gestört, ich hatte nur nie eine Idee wie ichs hätte lösen können, aber der von Dir beschriebene Weg scheint eine solche Lösungsmöglichkeit zu sein.

Ich stehe da jetzt nur noch vor dem Problem, das die Breite des handles beim ersten Initialisieren der Slider nicht korrekt gelesen wird (outerWidth ist immer 9.666), daher funktioniert die Sache am Anfang nicht korrekt. Wenn man einen Slider dann bewegt funktioniert alles korrekt. Hier erstmal der Code soweit (muss in die design_setup.js des Metal Designs):

function transformSlider(ui) {
  console.log("slider-handle "+$(ui.handle)+" changed to value "+ui.value);
  if (!isNaN(ui.value)) {
    var handleWidth = $(ui.handle).outerWidth();
    console.log($(ui.handle).text()+"=="+ui.value+" => width "+handleWidth);
    var sliderMax = $(ui.handle).parent().slider("option","max");
    var percent = (sliderMax/100)*ui.value;
    var translate = Math.round(handleWidth * percent/100);
    console.log("moving handle "+translate+" left");
    $(ui.handle).css('transform', 'translateX(-'+translate+'px)');
  }
}

und dann in dieselbe Datei am Ende der function templateEngine.bindActionForLoadingFinished(functi on() { folgendes einfügen:

$(".actor.ui-slider-horizontal").on("slidechange", function (event, ui) {
    transformSlider(ui);
  });
  $(".actor.ui-slider-horizontal").on("slide", function (event, ui) {
    transformSlider(ui);
  });

Vielleicht kann mir mal jemand auf die Sprünge helfen, warum die Breite am Anfang nicht stimmt. Da die Breite des Handles, ja von dessen Inhalt abhängt, muss der geänderte Wert dort drin stehen, bevor die Berechnung/Veschiebung der Position stattfindet, daher habe ich versucht den Wert vorher selbst zu ändern, damit die Breite aktuell ist, aber irgendwie ändert das nichts.

[XueSheng]

Aber die Design-CSS (oder gar die custom.css) kann durchaus die vom JQuery übersteuern. Vgl. auch mal den Slider beim Planet-Design. Da hab ich den mal ganz umgeändert...

Danke für den Hinweis. Wenn ich das richtig sehe, nutzt Planet aber eine definierte (fixe) Breite für den handle. Genau das wollte ich ja umgehen, da hier sonst die Abhängigkeiten zu diversen Bildschirmgrößen und slider Varianten zu komplex werden.
Ich versuche sowieso von überflüssigen (fixen) Angaben zu width/height/margin/padding/etc wegzukommen. Ich experimentiere gerade an einem design auf Basis von flexbox. Wenn das Konzept aufgeht, will ich das hier mal vorstellen!

Mein Ansatz wäre daher die relative Position des handle zu korrigieren. Das geht ja auch über CSS, jedoch muss die Prozentangabe vom JS kommen. Genau genommen habe ich weder Ahnung von CSS, noch von JS... daher mache ich das mehr nach dem "trial and error" Prinzip .
Folgende Code Zeilen aus dem jquery-ui.js scheinen den Prozentwert des slider zu definieren (style Angabe im DOM). Als reinen proof of concept habe ich mal die rot markierte Zeile eingefügt (ohne Berücksichtigung von horizontal/vertikal). Beim Verschieben des slider verhält er sich auch wie gewünscht. Nur beim ersten Laden der Visu und beim Anklicken des range, wird der Prozentwert des transform nicht übergeben. Habe auch im ersten Teil des if-clause rumgespielt, aber da scheint der Bock auch nicht begraben.

Kannst Du mir hier weiterhelfen? Ich hoffe der Ansatz ist verständlich dargelegt.

                if ( this.options.values && this.options.values.length ) {
                        this.handles.each(function( i ) {
                                valPercent = ( that.values(i) - that._valueMin() ) / ( that._valueMax() - that._valueMin() ) * 100;
                                _set[ that.orientation === "horizontal" ? "left" : "bottom" ] = valPercent + "%";
                                $( this ).stop( 1, 1 )[ animate ? "animate" : "css" ]( _set, o.animate );
                                if ( that.options.range === true ) {
                                        if ( that.orientation === "horizontal" ) {
                                                if ( i === 0 ) {
                                                        that.range.stop( 1, 1 )[ animate ? "animate" : "css" ]( { left: valPercent + "%" }, o.animate );
                                                }
                                                if ( i === 1 ) {
                                                        that.range[ animate ? "animate" : "css" ]( { width: ( valPercent - lastValPercent ) + "%" }, { queue: false, duration: o.animate } );
                                                }
                                        } else {
                                                if ( i === 0 ) {
                                                        that.range.stop( 1, 1 )[ animate ? "animate" : "css" ]( { bottom: ( valPercent ) + "%" }, o.animate );
                                                }
                                                if ( i === 1 ) {
                                                        that.range[ animate ? "animate" : "css" ]( { height: ( valPercent - lastValPercent ) + "%" }, { queue: false, duration: o.animate } );
                                                }
                                        }
                                }
                                lastValPercent = valPercent;
                        });
                } else {
                        value = this.value();
                        valueMin = this._valueMin();
                        valueMax = this._valueMax();
                        valPercent = ( valueMax !== valueMin ) ?
                                        ( value - valueMin ) / ( valueMax - valueMin ) * 100 :
                                        0;
                        _set[ this.orientation === "horizontal" ? "left" : "bottom" ] = valPercent + "%";
                        [COLOR=#FF0000][B]_set["transform"] = "translateX(-" + valPercent + "%)";[/B][/COLOR]
                        this.handle.stop( 1, 1 )[ animate ? "animate" : "css" ]( _set, o.animate );

                        if ( oRange === "min" && this.orientation === "horizontal" ) {
                                this.range.stop( 1, 1 )[ animate ? "animate" : "css" ]( { width: valPercent + "%" }, o.animate );
                        }
                        if ( oRange === "max" && this.orientation === "horizontal" ) {
                                this.range[ animate ? "animate" : "css" ]( { width: ( 100 - valPercent ) + "%" }, { queue: false, duration: o.animate } );
                        }
                        if ( oRange === "min" && this.orientation === "vertical" ) {
                                this.range.stop( 1, 1 )[ animate ? "animate" : "css" ]( { height: valPercent + "%" }, o.animate );
                        }
                        if ( oRange === "max" && this.orientation === "vertical" ) {
                                this.range[ animate ? "animate" : "css" ]( { height: ( 100 - valPercent ) + "%" }, { queue: false, duration: o.animate } );
                        }
                }

[peuter]

Ich würde da nicht direkt im jquery-ui code ändern, dass muss schließlich immer bei jedem update der lib nachgezogen werden. Ich habe das ganze mal als Vorschlag implementiert, musste ein bischen tricksen, da alle slider handles, die auf nicht sichbaren seiten sind am Anfang width=0 haben und somit die Positionierung nicht klappt, aber mit einem kleinen Trick, der das nachholt, wenn eine solche seite sichtbar wird klappts auch.

Bitte mal prüfen ob das so funktioniert bei euch, siehe:
https://github.com/CometVisu/CometVisu/pull/143

Ich habe das als Design-unabhängigen Fix implementiert, da das Problem nach meinem Verständis in jedem Design auftauchen müsste, richtig?

[XueSheng]

Ich habe das als Design-unabhängigen Fix implementiert, da das Problem nach meinem Verständis in jedem Design auftauchen müsste, richtig?

Je nach Implementierung der designs müssen diese angepasst werden. Für metal hast Du das ja bereits getan.

Ich hatte Deinen ersten Beitrag übersehen (das neue Forum hatte mich auch nicht benachrichtigt).
Deine Anpassungen habe ich mal eingespielt. Allerdings will der slider nicht so richtig. In der Demo config (metal) ändert sich das translateX im Bereich von -1px zu -2px... das passt nicht. Andere Slider bleiben nun auf der Stelle hängen. Wenn Du das nicht nachvollziehen kannst, reiche ich gerne ein paar Beispiele nach!

Nochmal die dumme Frage an dieser Stelle, ob man nicht den gleichen Wert des styles "left: valPercent" für das translateX übernehmen kann? Aus Deinem Code resultiert eine "px" Angabe. Ist hier auch berücksichtigt, dass sich die Breite des handle ändern kann? Eine prozentuale Angabe ist mir hier irgendwie sympathischer (zumindest die Extrema 0% und 100% sind dann optimal abgedeckt).

[Chris M.]

Ich würde da nicht direkt im jquery-ui code ändern, dass muss schließlich immer bei jedem update der lib nachgezogen werden.

Stimmt, in einer Bibliothek ändern geht gar nicht.

Ich habe das ganze mal als Vorschlag implementiert, musste ein bischen tricksen, da alle slider handles, die auf nicht sichbaren seiten sind am Anfang width=0 haben und somit die Positionierung nicht klappt, aber mit einem kleinen Trick, der das nachholt, wenn eine solche seite sichtbar wird klappts auch.

Ich bin schon fast geneigt den JQuery-Slider durch eine eigene Implementierung zu ersetzen... Aber ich komme in der nächsten Zeit eh nicht dazu, also bleiben wir bei diesem Vorschlag

Was mich am aktuellen Vorschlag aber noch etwas stört, ist dass der Code aus dem "Namensraum" heraus leakt - oder anders: dass in templateengine.js und _common.js spezifischer Code für den Slider ist, also für ein Widget. Jeglicher Code der da dazu gehört sollte im Widget selbst, also der slide.js, stehen.
Wenn das nicht möglich ist, dann sollte statt dessen ein generischer Mechanismus geschaffen werden (so wie ich für den Slider schon machen musste, da sich JQuery-UI nicht textifizieren lässt... ) und dieser Mechanismus vom Widget benutzt werden.

Bitte mal prüfen ob das so funktioniert

Werde ich noch ausprobieren.

Ich habe das als Design-unabhängigen Fix implementiert, da das Problem nach meinem Verständis in jedem Design auftauchen müsste, richtig?

Grundsätzlich ist das ein Thema das jedes Design treffen kann.

[peuter]

Deine Anpassungen habe ich mal eingespielt. Allerdings will der slider nicht so richtig. In der Demo config (metal) ändert sich das translateX im Bereich von -1px zu -2px... das passt nicht. Andere Slider bleiben nun auf der Stelle hängen. Wenn Du das nicht nachvollziehen kannst, reiche ich gerne ein paar Beispiele nach!

Habs nachvollziehen können, waren noch diverse Fehler in der Berechnung, die ich jetzt hoffentlich alle gefixt habe (alles im o.g. Pull Request). Die Demo-Config kann ich aber nicht richtig testen, denn die funktioniert nur mit dem "normalen" Backend und nicht mit openHAB, was dazu führt, dass es beim Versuch des Sendens der Werte ans Backend in der slideStart-Funktion natürlich zu zu einem fehler kommt, daher die slideChange-Funktion nicht aufgerufen wird und daher dann das transformSlider auch nicht, bzw. erst wenn man den Slider "loslässt" und somit fertig positioniert, das führt zu unschönem springen des handles. Aber wie gesagt, wenn ein funktionierendes Backend da ist, sollte dieses Problem nicht auftreten.

Nochmal die dumme Frage an dieser Stelle, ob man nicht den gleichen Wert des styles "left: valPercent" für das translateX übernehmen kann? Aus Deinem Code resultiert eine "px" Angabe. Ist hier auch berücksichtigt, dass sich die Breite des handle ändern kann? Eine prozentuale Angabe ist mir hier irgendwie sympathischer (zumindest die Extrema 0% und 100% sind dann optimal abgedeckt).

Die px Angane ist der prozentuale Anteil an der aktuellen Breite des handles im Verhältnis zur Position. D.h. ist der Slider bei 0% (ganz links) wird auch um 0% der handle-Breite verschoben und wenn der Slider bei 100% (ganz rechts), wird der handle um 100% der handle-Breite verschoben (-1px, da sonst der rechte Rand des drunterliegenden Bars sichtbar wurdem fand ich unschön)

Was mich am aktuellen Vorschlag aber noch etwas stört, ist dass der Code aus dem "Namensraum" heraus leakt - oder anders: dass in templateengine.js und _common.js spezifischer Code für den Slider ist, also für ein Widget. Jeglicher Code der da dazu gehört sollte im Widget selbst, also der slide.js, stehen.

Stimmt habs nochmal überarbeitet, ist jetzt alles in der slide.js. Auch habe ich die CSS-Regeln der anderen designs angepasst (margin-left entfernt) und beim Planet-Design die ganze Funktion abgeschaltet, denn dieses Design braucht das ja nicht.

[XueSheng]

Die px Angane ist der prozentuale Anteil an der aktuellen Breite des handles im Verhältnis zur Position. D.h. ist der Slider bei 0% (ganz links) wird auch um 0% der handle-Breite verschoben und wenn der Slider bei 100% (ganz rechts), wird der handle um 100% der handle-Breite verschoben (-1px, da sonst der rechte Rand des drunterliegenden Bars sichtbar wurdem fand ich unschön)

Die -1px sollte nicht notwendig sein. Die range ist nur sichtbar, wenn der slider einen border-radius besitzt und der range nicht! Dann überlappt der range mit der rechten border. Da sollte man eher dem range auch einen border-radius verpassen und die Korrektur von -1px vermeiden. Wenn man z.B. den handle innerhalb des range darstellen möchte, sieht es dann nämlich auch sehr unschön aus, wenn der handle mit dem rechten Rand überlappt. Wenn man diesen Versatz natürlich problemlos design spezifisch gestalten kann, wäre das auch kein Problem.

Bei dem aktuellen Stand sind mir jetzt noch zwei Sachen aufgefallen:

1. Beim Verschieben des handle, wird translateX nicht aktualisiert. Schiebt man den handle von ganz links nach ganz rechts (oder umgekehrt), dann schiebt man den handle aus dem range! Lässt man den handle los, springt er natürlich wieder zurück. Lässt sich das korrigieren?
2. Bei meinen slidern mit Wert (z.B. 0-100%) besitzt translateX bei left: 0% (!) einen negativen Wert (z.B. -6px), anstatt 0px. Hast Du das auch bemerkt? Ansonsten muss ich da nochmal tiefer forschen.

An dieser Stelle auch nochmal ein großes Dankeschön für die Arbeit, die Du in die Cometvisu steckst!

[Chris M.]

Ich hab die Ändernung nicht im Detail reviewt(*), beim Ausprobieren (config=metal&forceReload=true) ist mir aber aufgefallen, dass die Handler nicht mehr zusammen passen (der oberste ist bewegt, die anderen werden per Bus-Roundtrip auf 100% gesetzt):
forum4.png

--
(*) Ich hab nur auf https://github.com/CometVisu/CometVisu/pull/143/files nach offensichtlichen Dingen geschaut. Dabei ist mir aufgefallen, dass u.a.bei src/designs/discreet/basic.css die ganze Datei im Diff ist. Nach kurzem Check war mir klar, dass das ein DOS<->Unix-Thema ist. Die neue Version ist nun endlich konformant zu https://github.com/CometVisu/CometVi...i/Coding-style Aber es wäre besser, wenn so ein Aufräumen getrennt von Entwicklungen stattfindet. Es hilft halt beim Checken, wenn der Diff übersichtlich ist

[peuter]

So neue Fixes sind commited:
- Das Problem in der Metal-Demo-Config (Flavour-Seite) sollte behoben sein,
- auch der Slider auf der Startseite der Demo-Config verhält sich nun korrekt (sollte Problem 1. vonXueSheng)
- diesen -1px Pfusch habe ich wieder rausgenommen

XueSheng
Probier mal ob dein 2. Problem mit den negativen Werten mit der neuen Version auch noch existiert, ich habe die Hoffnung, dass das hiermit auch gelöst ist. Habs aber nicht getestet.

Chris M.
Das mit dem geänderten Style, wodurch die ganze Datei im Diff ist habe meine IDE selbstständig gemacht, habe das erst gemerkt als ich mir den Pull Request auf Github angesehen habe. Ist klar dass dadurch das Reviewen erschwert wird, war keine Absicht.

[Chris M.]

So neue Fixes sind commited:

Ich hab's gemerged (die Hilf-Funktion hab ich vorher noch in die AMD hinzeingezogen um den globalen Namensraum nicht zu belasten)

Was mir aber noch aufgefallen ist:
Wenn ich in der Demo-Config (also Design Pure) einen Handler nehme (der z.B. in der Mitte steht) und den per Maus schnell aus dem Bereich herausziehe, dann wird der kurz über die Grenzen hinausgezogen und springt gleich auf die Max-Lage zurück (= optisch nicht hübsch). Danach geht das in dieser Richtung nicht mehr - erst wenn der Handler wieder in der Mitte steht...
Und was besonders interessant ist: in der Metal-Demo scheint das nicht zu passieren...

Das mit dem geänderten Style, wodurch die ganze Datei im Diff ist habe meine IDE selbstständig gemacht

Hatte ich mir schon gedacht
Ist aber mal ein guter Zeitpunkt, dass ich mal alle Dateien durch's Dos3Unix jage

[peuter]

Was mir aber noch aufgefallen ist:
Wenn ich in der Demo-Config (also Design Pure) einen Handler nehme (der z.B. in der Mitte steht) und den per Maus schnell aus dem Bereich herausziehe, dann wird der kurz über die Grenzen hinausgezogen und springt gleich auf die Max-Lage zurück (= optisch nicht hübsch). Danach geht das in dieser Richtung nicht mehr - erst wenn der Handler wieder in der Mitte steht...
Und was besonders interessant ist: in der Metal-Demo scheint das nicht zu passieren...

Das war mir auch aufgefallen. Ich war da zuerst auf der falschen Fährte, dass das Design-abhängig ist und bin daher nicht weiter gekommen. Ich vermute jetzt aber, dass das daran liegt, ob der Slider handle einen Wert hat (wie in der metal-demo) oder keinen (wie in der demo). Wird wohl daran liegen, dass das slide-event nicht beachtet, wird wenn kein format definiert wird. Ich schaue mir das nochmal genauer an.

[peuter]

Ja da lag ich mit der vermutung wohl richtig =>
https://github.com/CometVisu/CometVisu/pull/144

Durch diesen Fix wird der transformSlider Aufruf in der slideChange Funktion überflüssig, der ja nur alle 250ms stattfindet und daher für die unschöne Optik des Überspringens des Max-Werts verantwortlich war.

[Chris M.]

Sieht gut aus! Danke!