[gelöst][fhemweb.js] Direkthilfe; hier: Position des Hilfetextes

Begonnen von Ellert, 26 August 2018, 20:05:00

Vorheriges Thema - Nächstes Thema

Ellert

Ich finde es ist eine gute Idee die Hilfetexte beider Auswahl anzuzeigen.

Mir ist jedoch aufgefallen, dass die Texte vom Auswahlfeld weit entfernt angezeigt werden, so dass meisten gescrollt werden muss, um sie lesen zu können.
Ich denke, die Texte werden dadurch leicht übersehen und der Komfort der Hilfeanzeige nicht wahrgenommen.

Gibt es eine Mehrheit dafür, dass die Anzeige der Direkthilfe unmittelbar unter den Auswahlfeldern positioniert werden sollte?

Schön wäre es auch wenn der Text wieder verschwindet, wenn er nicht mehr benötigt wird, z.B. bei Mausklick ausserhalb des Hilfetextbereiches.

Ellert

Mit dem anliegenden Patch wird die Hilfe unter der jeweilligen Auswahlbox angezeigt, der Text verschwindet per Doppelklick auf ihn, siehe Bild.

Ich würde mich freuen, wenn die Idee Eingang in die offizielle Version finden würde.

rudolfkoenig

Ich habe Einwaende gegen Double-Click: ich will nicht anfangen neue Bedienmethoden einzufuehren.
Und ich bin auch nicht sicher, dass das Einschieben der Hilfe an unterschiedlichen Positionen eine gute Idee ist, ich kann mich aber anpassen, falls sich dafuer eine Mehrheit findet.

Ellert

Es muss nicht Doppelklick sein, man sollte markieren und kopieren können, und man sollte die Anzeige schliessen können.

PatrickR

Ich finde die Hilfe direkt unter der Auswahlbox auch besser. Bei dem Doppelklickthema wäre vermutlich ein x oder Ähnliches intuitiv. Kann aber zugegebenermaßen nicht abschätzen, ob ein Wegklicken überhaupt nötig ist.

Patrick


Von unterwegs gesendet.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

Ellert

Den Textbereich zu schliessen ist nicht unbedingt notwendig, ein Reload tut es auch.

Ellert

Die Direkthilfe scheint noch nicht sehr bekannt zu sein, trotzdem gibt es schon 4 Befürworter, daher noch ein Patch, der auch die Möglichkeit bietet, den Textbereich zu schliessen.

rudolfkoenig

Diese Loesung verschiebt die Felder, wenn man nichts findet.
Ich habe jetzt nach langem Experimentieren eine andere Variante eingebaut, und auch die Suche nach dem Text etwas geaendert.

Ich betrachte es trotzdem als experimental: sobald die ersten Beschwerden zu nicht gefundenen Hilfetexten kommen, wandert das Ganze wieder nach unten, wo es unauffaellig ist. Wer es dann noch braucht, der soll ein Monitor passender Groesse anschaffen :)

Ellert

Die Suche nach li-Tags ist schon sehr speziell, es werden kaum noch Einträge gefunden und wenn, dann nicht komplett angezeigt.
Beispiel FHEMWEB widgetOverride
Es werden die Widgets nicht angezeigt.
Beispiel global
Es wird zu jedem Attribut nur "archivedir" angezeigt.

Die Suche nach li-Tags bricht bei verschachtelten Listen ab.

Eine Sprungmarke zu nehmen, finde ich vorteilhafter, weil:
- in Antworten direkt zu einer bestimmten Stelle der Commandref verlinkt werden kann
- innerhalb der Commandref Bezüge hergestellt werden können
- die Verwendung von li-Tags einen ggf. einen Umbau der Hilfetexte erfordert, Sprungmarken sind mit weniger Aufwand eizufügen.
- da die nächste Sprungmarke das Ende des Hilfetextes markiert, kann der Autor das Texteende selbst bestimmen, ohne die Formatierung zu beeinflussen
- li-Tags lassen vermutlich weniger Spielraum bei weiteren Formatierungen, wie z.B. die Nutzung von dl,dt u. dd-Tags, die speziell für Beschreibungslisten vorgesehen sind.

Was spricht gegen Sprungmarken?

rudolfkoenig

ZitatWas spricht gegen Sprungmarken?
Dass kaum/keine set/get Befehle gefunden werden. Keiner sagt was gegen die generelle Verwendung von Sprungmarken, ich finde es nur nicht geeignet zum Auffinden/Auftrennen der Doku fuer diesen Zweck.

Ich habe die Suche wieder umgestellt auf /<a[^"]*"'+val/, und es wird alles bis zum naechsten <a ausgegeben, ist aber auch nicht perfekt.
Die richtige Loesung waere das Einfuehren von Tags, was die Browser nicht anzeigen, bedeutet aber den Umbau saemtlicher Hilfetexte, was wiederum illusorisch ist.

Bin knapp vor dem Entfernen des Features: wenn man es nicht richtig kann, dann sollte man es lassen.



Ellert

Ich verspreche mir von der Direkthilfe weniger Fragen mit Bezug auf Attribute, weil die Infos gleich angezeigt werden.
Daher fände ich es Schade, wenn die Direkthilfe wieder ausgebaut werden würde.

Es muss nur deutlich gemacht werden, dass vor jeden 1. Parameter in attr, set, und get, der in der Commandref beschrieben wird, eine Sprungmarke zu setzen ist, also für Attribut das  "widgetOverride" die Sprungmarke

<a name="widgetOverride"></a>


Ellert

Mir ist gerade aufgefallen das alle a-Tags das Ende des Hilfetextes markieren

var o1 = data.indexOf('<a', 1); müsste wieder zu var o1 = data.indexOf('<a name', 1); werden.

rudolfkoenig

Das reicht nicht, es gibt auch viele <a href="..."> Tags, z.Bsp. <a href="#dummy">dummy</a>

Habe ich schon erwaehnt, dass es nicht vollkommen ist?

Ellert

Ok, es war kein Versuch es zu perfektionieren, ich müsste dann die Referenzierungen innerhalb der Commandref herausnehmen. Denn der Hilfetext
endet ja nicht bei einem < a href= ...>, das wäre aber Schade.
Danke für die Geduld.

Ellert

Der Hilfetext in einem DOIF sieht typischerweise so aus
Zitat<a name="cmdpause"></a>
<b>Zwangspause für das Ausführen eines Kommandos seit der letzten Zustandsänderung</b>&nbsp;&nbsp;&nbsp;<a href="#DOIF_Inhaltsuebersicht">back</a><br>
<br>
... weiterer Text ...

nächstes Attribut
<a name="repeatsame"></a>
Es gibt immer einen Link zum Inhaltsverzeichnis. Das bedeutet der Hilfetext wird nur bis dort angezeigt.

Daher darf "<a href..." nicht als Ende des Hilfetextes betrachtet werden, sondern nur "<a name...".

Und wenn ein Hilfetext an einer bestimmten Stelle enden soll, muss dort sowas wie <a name="irgendetwas das niemals eine Sprungmarke ist"></a> angeben, damit ein vorzeitiges Ende erkannt wird.

Ellert

#15
Da die Vorhandene Textgestaltung sehr vielfältig ist und das Erkennen des Endes eines Bereiches schwierig ist, könnte man darauf verzichten das Ende zu erkennen.
Der angezegiteText beginnt an der richtigen Stelle, kann aber beliebig weiter gescrollt werden.

Vielleicht ist das eine akzeptierbare Lösung.

Ich habe ein Bild und die angepasste fhemweb.js angehängt.

Ellert

@rudolfkoenig
Kann ich davon ausgehen, dass die akttuell implementierte Lösung erstmal Bestand hat?

Dann könnte ich diesen Zustand als Grundlage für Anpassungen der Commandref (DOIFtools, DOIF) nutzen.

rudolfkoenig

ZitatKann ich davon ausgehen, dass die akttuell implementierte Lösung erstmal Bestand hat?
Da ich keine geniale Idee/Loesung habe, habe ich nicht vor was zu aendern => ja.

KernSani

Ich krame diesen Thread mal wieder hervor . irgendwie ist das Feature an mir vorbei gegangen und ich kann auch den Original-Thread nicht finden. Ich finde es aber gut und habe es bei mir eingebaut. Was ich jetzt noch gut fände:
* wenn das auch für Readings funktionieren würde. Spontan würde ich an ein mouseOver denken
* wenn es mehr Modul-Autoren unterstützen würden :-)

Guten Rutsch!

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Ellert

Zitat von: KernSani am 28 Dezember 2018, 00:24:27
... und ich kann auch den Original-Thread nicht finden ...
Ist nur in den FHEM Code changes zu finden, dies ist der daraus entstandene Thread.

HomeAuto_User

Hallo,

ich greife mal das Thema erneut auf weil nun schon die Fälle aufgetreten sind, das User sich melden weil der falsche Punkt angezeigt wird.
Grund hierfür ist, das in unterschiedlichen Modulen der gleiche <a name="Wert"> genutzt wird um dahin zu springen.

Bsp Meldung / Beschwerde: https://forum.fhem.de/index.php/topic,58397.msg986472.html#msg986472
Damals wurde mit diesem Patch (https://svn.fhem.de/trac/changeset/17747/trunk) das ganze eingeläutet wenn wir es richtig nachvollzogen haben.

Solange dort nicht eine Anpassung erfolgt, so wird es in Zukunft immer diesen Konflikt geben. Modulentwickler und User werden sich nie die Mühe machen alle <a name="Wert"> Sprungmarken anzusehen ob Ihr wert schon vorhanden ist. Derzeit reden wir komplett von über 3000. Wäre es nicht besser, wenn man das Modul beim auslesen ergänzt um dann nur im passenden Modul den Abschnitt zu sehen?

Wenn wir es so lassen, wird das Problem stillschweigend hingenommen und in Zukunft schiebt der eine die Schuld auf den anderen.

Für eine Lösungsfindung kommt ja in Frage:
- Option entfernen komplett (wäre aber für viele Benutzer unschön)  :(
- Erweiterung der Option auf den Modulname zusätzlich  ;)
- Festlegung oder Entscheidung wie dieses in Zukunft gehandhabt wird.  ::)
- weitere Möglichkeiten erörtern ...  :o

MfG
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

rudolfkoenig

Da ich das Problem nicht sofort verstanden habe, auch weil es mAn mit dem Thema dieses Threads nur sehr indirekt was zu tun hat, versuche ich es anders zu formulieren:
- in der HTML Doku gibt es etliche nicht eindeutige Sprungmarken
- wenn man vom Inhaltsverzeichnis am Anfang des Commandrefs zum Text springen will, dann landet man u.U. an der falschen Stelle
- der Loesungsvorschlag lautet, beim Zusammenstellen des Commandrefs aus den einzelnen Modulen die Sprungmarken mit einem Stichwort wie "module" zu egaenzen, und diese ergaenzten Sprungmarken im Inhaltsverzeichnis zu verwenden.

Sidey

Ja, wenn das Stichwort module den Namen des Moduls darstellt, dann könnten Module die gleichen Attributnamen als Sprungmarken definieren.

Die Anzeige der inline Hilfe müsste dann ebenso bei der Suche nach einem Hilfeeintrag auch den Modulnamen mit verwenden.

Gesendet von meinem Moto Z (2) mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

HomeAuto_User

Hallo Rudi,

Zitat von: rudolfkoenig am 01 November 2019, 16:06:52
Da ich das Problem nicht sofort verstanden habe, auch weil es mAn mit dem Thema dieses Threads nur sehr indirekt was zu tun hat, versuche ich es anders zu formulieren:
- in der HTML Doku gibt es etliche nicht eindeutige Sprungmarken
- wenn man vom Inhaltsverzeichnis am Anfang des Commandrefs zum Text springen will, dann landet man u.U. an der falschen Stelle
- der Loesungsvorschlag lautet, beim Zusammenstellen des Commandrefs aus den einzelnen Modulen die Sprungmarken mit einem Stichwort wie "module" zu egaenzen, und diese ergaenzten Sprungmarken im Inhaltsverzeichnis zu verwenden.

danke für dein Statement und sorry wenn ich das Problem nicht dem richtigen Faden zuwies. Wir brauchten schon lange, den Ansatz zu finden oder wo es damals im Forum diskutiert wurde bzw. aufkam.
Du hast es mit deinen Punkten auf den Punkt kurz und knapp gebracht.

Zitat- der Loesungsvorschlag lautet, beim Zusammenstellen des Commandrefs aus den einzelnen Modulen die Sprungmarken mit einem Stichwort wie "module" zu egaenzen, und diese ergaenzten Sprungmarken im Inhaltsverzeichnis zu verwenden.

Genau richtig  :D
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

rudolfkoenig

Ich wollte das gerade angehen, ist aber leider komplizierter, als gedacht: diese Sprungmarken werden nicht nur aus dem (generierten) Inhaltsverzeichnis referenziert, sondern auch um aus einem Doku-Abschnitt Text in einem anderen Abschnitt zu referenzieren (z.Bsp. <a href="telnet">). Es gibt ueber 3700 solche Referenzen alleine in der englischen Version, die ich jetzt nicht alle manuell pruefen und korrigieren will.

Sonst: in der englischen Variante gibt es 4591 Sprungmarken,  davon nur 4233 unterschiedlich.
Auf dem Podium der Mehrfach-Sprungmarken steht disable (16-mal), Leerstring (15-mal) und ein Leerzeichen (13-mal).
Man kommt aus dem Staunen nicht raus.

Wenn jemandem eine saubere Methode fuer die Problembehebung einfaellt, der soll sich bitte melden.

Nestor

Could this not be solved by prefixing all hyperlink section names with module name + underscore (simple global regex replacement)?

For example the links to ping or statistics module are completely wrong:
https://fhem.de/commandref.html#ping
https://fhem.de/commandref.html#statistics


rudolfkoenig

As I wrote in my last entry, there are a lot (4591) href references to anchors.
To solve the problem, the href in the module documentation must be changed, if it references a module.

This may be automated (partially?), but I do not want to touch foreign modules, if possible.
It would be interesting to know, how many modules need to be changed, but for this purpose, the automation needs to be implemented first... :)