sidearea im texteditor

[gaenseklein]

der texteditor soll eine sidearea bekommen, in denen infos angezeigt und ggfs interaktiv gemacht werden können. siehe grafik in #47

[gaenseklein]

infos können zum großen teil über parser.lineswithhtml gezogen werden, datenstrukturen müssen noch extra behandelt werden. infos dazu in parser.dataobjects speichern sinnvoll? (linestart, lineend bspw.) beachten, was passiert, wenn zwei konkurrierende infos da sind (bspw. in einer section) - mehrere spalten bereithalten?

lösungsansatz: nach parsen wird extra-funktion aufgerufen create-sidebar. diese erstellt aus den infos von lineswithhtml und dataobjects ein zweidimensionales array - für jede zeile ein array. anschließend wird aus diesem array html-code in die jeweilige zeile der sidearea eingefügt. um das ganze zu beschleunigen kann später die selbe taktik wie beim partiellen rendern benutzt werden falls es zu langsam wird. (siehe #33 )

[gaenseklein]

infos aus lineswithhtml und dataobjects zu holen dauert zu lang. hab die infos direkt beim parsen jetzt in eigenem object-array abgespeichert, das sollte deutlich perfomanter sein. aus diesem neuen array kann dann die sidearea erstellt werden.

[gaenseklein]

einfache sidebar funktioniert jetzt, aber verschachtelung ist noch nicht gut implementiert oder abgefangen.

[gaenseklein]

@jochmann Sidebar ist jetzt eingefügt und verschachtelungsproblem ist auch gelöst. war n bisken knifflig aber jetzt scheints gut zu laufen. Gucks dir mal an. Was ich in der gif von dir (siehe #47 ) nicht verstehe ist das > zeichen in der sidebar und das links daneben dieser pfeil nach unten. willst du damit die zeile markieren, in der sich der cursor befindet oder was soll das sein? Des weiteren: Sollen die Elemente in der Sidebar mit irgendwas verknüpft sein? oder ist das eine reine graphische Darstellung? (Bspw. klick drauf markiert gesamten Text des Elements...)

[jochmann]

das gif ist mittlerweile abgelöst vom PDF mit mehreren verschiedenen Screen-Ansichten. Dort sollte beim Durchklicken manches klarer werden. Die Designvorgaben sollten sich auch nach diesem Dokument richten, statt nach dem gif, was einen UI-Stand dokumentiert, den ich danach weiter entwickelt habe.

Das Zeichen in der Sidebar soll tatsächlich eine Anzeige sein, in welcher Zeile sich der Cursor befindet - es bring außerdem ein dropdown-menü mit sich, wo du die sections auswählen kannst, die du an den Beginn dieser Zeile einfügen kannst.

Grundsätzlich ist die Logik im UI, dass Icons Leute zum Anklicken einladen sollen. Was ein Icon hat, ist ein Menü-Element. Die Elemente ohne Icon dienen trotzdem als kontextuelle Schaltfläche: wenn du dort fokussierst (oder klickst) werden die dort relevanten Menü-Elemente eingeblendet. Klick auf die Sidebar öffnet dementsprechend die dort versteckten Kontext-Menüs. Ausgerechnet der Outliner ist aber noch die größte Baustelle in meinem UI-Konzept. Da weiß ich noch nicht, ob wir zum Start lieber drauf verzichten.

Hattest du dich schon auf das PDF (kam per Mail) bezogen?

On 4. Dec 2018, at 03:43, gaenseklein notifications@github.com wrote:

@jochmann https://github.com/jochmann Sidebar ist jetzt eingefügt und verschachtelungsproblem ist auch gelöst. war n bisken knifflig aber jetzt scheints gut zu laufen. Gucks dir mal an. Was ich in der gif von dir (siehe #47 https://github.com/gaenseklein/slidenotes/issues/47 ) nicht verstehe ist das > zeichen in der sidebar und das links daneben dieser pfeil nach unten. willst du damit die zeile markieren, in der sich der cursor befindet oder was soll das sein? Des weiteren: Sollen die Elemente in der Sidebar mit irgendwas verknüpft sein? oder ist das eine reine graphische Darstellung? (Bspw. klick drauf markiert gesamten Text des Elements...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/51#issuecomment-443949559, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBMogKfeHXhIUQF7hwPZxKIsT4SZzks5u1eFRgaJpZM4Y0QE1.

[gaenseklein]

oh man, ich hab die pdf bekommen, aber nicht gesehen, weil ich nicht in das postfach geguckt hab. (da kommt immer nur trello-spam) hätte ich die gestern abend gehabt wäre manches kopfgrübeln schon erledigt gewesen und schon mehr umgesetzt. egal, vieles davon ist ja bereits entweder umgesetzt oder halt so gut vorbereitet, dass es schneller umgesetzt werden kann. (kontext-menü, buttons... ) generell: gerne als issue die einzelnen aufgaben posten (oder als gruppen zusammengefasst). auf die pdf und die von der sidebar unabhängigen aufgaben gehe ich aber ansonsten in einem anderen issue ein.

Die Sidebar wird klickbare Elemente enthalten - ok. Das ist gut im Vorhinein zu wissen, damit ich an der entsprechenden Stelle direkt die wichtigen Infos/Verknüpfungen mit gebe damit das später leicht eingebaut/erweitert werden kann. was da genau passiert können wir ja später sehen.

Das Zeichen in der Sidebar als Anzeige, in welcher Zeile sich der Cursor befindet ist kein Problem. Die Logik mit der Buttonanzeige finde ich gut und setze ich um. Die Kontext-Menüs werde ich eh technisch unabhängig von der Sidebar positionieren müssen, da sonst die Sidebar nicht mehr funktioniert bzw. synchron ist mit dem Text. Da das ja Drop-Down-Menüs sind und wir dafür Javascript verwenden können sollte das kein Problem sein. Abgesehen davon ist die Sidebar eh absolut positioniert.

Den Outliner würde ich auch auf später verschieben, ist aber auch nicht Teil der Sidebar, also anderes issue sonst verliere ich den überblick.

Also dann, setze ich mich mal ran das umzusetzen.

[gaenseklein]

Cursorzeichen und Zeichen für Drop-Down-Menü sind jetzt eingefügt. war mehr arbeit als gedacht, aber steht jetzt. habe leider kein passendes utf-8 zeichen für das drop-down-menü gefunden - das wäre aber imho super gut, weil ich da nicht mit images arbeiten will.

[jochmann]

up-arrowhead (und dann in css mit z-transform um 180° drehen) wäre eine Möglichkeit: ⌃ (#8963)

Ansonsten brauchen wir aber ohnehin einige icons für diverse Schaltflächen. Da könnte es sich lohnen, mit einem svg-sprite zu arbeiten. Justus soll dir dafür die assets vorbereiten.

On 5. Dec 2018, at 06:46, gaenseklein notifications@github.com wrote:

Cursorzeichen und Zeichen für Drop-Down-Menü sind jetzt eingefügt. war mehr arbeit als gedacht, aber steht jetzt. habe leider kein passendes utf-8 zeichen für das drop-down-menü gefunden - das wäre aber imho super gut, weil ich da nicht mit images arbeiten will.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/51#issuecomment-444366690, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBJsEooxLjHKCkWBtP80ryIYEcIA5ks5u112ogaJpZM4Y0QE1.

[jochmann]

log dich bei trello ein und schalte alle notifications und emails aus. das ist kein spam, sondern du bist dort als nutzer registriert und hast die notifications an. die für uns anderen sinn machen, weil wir ja regelmäßig damit arbeiten.

On 5. Dec 2018, at 01:25, gaenseklein notifications@github.com wrote:

oh man, ich hab die pdf bekommen, aber nicht gesehen, weil ich nicht in das postfach geguckt hab. (da kommt immer nur trello-spam) hätte ich die gestern abend gehabt wäre manches kopfgrübeln schon erledigt gewesen und schon mehr umgesetzt. egal, vieles davon ist ja bereits entweder umgesetzt oder halt so gut vorbereitet, dass es schneller umgesetzt werden kann. (kontext-menü, buttons... ) generell: gerne als issue die einzelnen aufgaben posten (oder als gruppen zusammengefasst). auf die pdf und die von der sidebar unabhängigen aufgaben gehe ich aber ansonsten in einem anderen issue ein.

Die Sidebar wird klickbare Elemente enthalten - ok. Das ist gut im Vorhinein zu wissen, damit ich an der entsprechenden Stelle direkt die wichtigen Infos/Verknüpfungen mit gebe damit das später leicht eingebaut/erweitert werden kann. was da genau passiert können wir ja später sehen.

Das Zeichen in der Sidebar als Anzeige, in welcher Zeile sich der Cursor befindet ist kein Problem. Die Logik mit der Buttonanzeige finde ich gut und setze ich um. Die Kontext-Menüs werde ich eh technisch unabhängig von der Sidebar positionieren müssen, da sonst die Sidebar nicht mehr funktioniert bzw. synchron ist mit dem Text. Da das ja Drop-Down-Menüs sind und wir dafür Javascript verwenden können sollte das kein Problem sein. Abgesehen davon ist die Sidebar eh absolut positioniert.

Den Outliner würde ich auch auf später verschieben, ist aber auch nicht Teil der Sidebar, also anderes issue sonst verliere ich den überblick.

Also dann, setze ich mich mal ran das umzusetzen.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/51#issuecomment-444311125, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBG3_OmkISOneLAUBspmSHTqIOOcIks5u1xKEgaJpZM4Y0QE1.

[gaenseklein]

mit dem icon in der sidebar geht es mir darum, dass ich eigentlich nur text in der sidebar verwenden darf, damit die zeilensynchronisation zwischen sidebar und textarea stimmt. ein drop-down-dach wäre daher einfach eine elegante lösung gewesen. aber ich habe ein bischen rumexperimentiert und denke, ich kann das icon als hintergrundgrafik nehmen. dann hat es keine auswirkungen auf die größe der zeile. müssen wir mal sehen, wie sich das auswirkt. schade, dass es solch ein viel verwendetes zeichen noch nicht als utf-8-zeichen gibt. wäre sehr elegant gewesen imho.

[jochmann]

ich verstehe nicht, wieso text in der sidebar einen funktionalen unterschied zu icons hat, deren größe über rem definiert werden. hintergrundgrafik als zeichen für knopf-element ist aus accessibility-sicht nicht wünschenswert. all die schaltflächen sollten der gleichen logik folgen. die sidebar ist doch einfach ein div, das in der gleichen Höhe definiert ist, wie das Textfeld daneben?

On 7. Dec 2018, at 00:15, gaenseklein notifications@github.com wrote:

mit dem icon in der sidebar geht es mir darum, dass ich eigentlich nur text in der sidebar verwenden darf, damit die zeilensynchronisation zwischen sidebar und textarea stimmt. ein drop-down-dach wäre daher einfach eine elegante lösung gewesen. aber ich habe ein bischen rumexperimentiert und denke, ich kann das icon als hintergrundgrafik nehmen. dann hat es keine auswirkungen auf die größe der zeile. müssen wir mal sehen, wie sich das auswirkt. schade, dass es solch ein viel verwendetes zeichen noch nicht als utf-8-zeichen gibt. wäre sehr elegant gewesen imho.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gaenseklein/slidenotes/issues/51#issuecomment-445065283, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6hBKiAoEUgNFDPJHsCcMBRhoiNH8bvks5u2aUVgaJpZM4Y0QE1.

[gaenseklein]

ich verstehe nicht, wieso text in der sidebar einen funktionalen unterschied zu icons hat, deren größe über rem definiert werden. hintergrundgrafik als zeichen für knopf-element ist aus accessibility-sicht nicht wünschenswert. all die schaltflächen sollten der gleichen logik folgen. die sidebar ist doch einfach ein div, das in der gleichen Höhe definiert ist, wie das Textfeld daneben?

nein, die sidebar ist ein komplexes konstrukt aus divs und spans. die divs sind so hoch wie die jeweilige zeile zu der sie gehören und wird gefüllt mit spans und brs. die brs definieren dabei die fiktiven zeilen, wie sie pro zeile in der textarea dargestellt werden und die spans definieren die einzelnen elemente dieser fiktiven zeile (bspw. der outline zum "chart"-objekt und die anzeige "chart"). das abstand-zählen nach rechts geschieht hier ebenfalls über text. eine sidebar sieht eigentlich so aus:

<div><span class="multilinestart">........</span></div>
<div><span class="multilinemiddle">chart</span></div>
<div><span class="multilineend">........</span></div>

durch monospace-schriftart und color:transparent werden die punkte versteckt, aber der abstand stimmt. ziel des ganzen ist, dass die sidebar synchron mit der textarea/dem textarea-hintergrund ist. die cursor-markierung und dropdown-menü ist momentan ein einfaches a-element, wird aber eben bald ausgetauscht durch eben ein span und da drinne ein a und dann noch ein span... das a-element hätte dann eben ein beliebiges zeichen in color:transparent (jetzt grad noch black) und dann als background-image eben das image. dann stimmt "span.innerText" mit der logik überein, nach der ich den abstand für die outliner berechne. und genau da liegt die krux: wenn ich direkt ein img-tag nehme stimmt innerText nicht mehr (ein image hat kein innerText) und ich muss das anders berechnen. da die logik aber so wie sie ist funktioniert würd ich es natürlich gerne dabei belassen.

[jochmann]

huiuiuiuiui. krass, das hatte ich mir nicht angesehen. das scheint mir noch nicht die eleganteste Lösung zu sein, ich verstehe gar nicht, warum du überhaupt abstand nach rechts brauchst. geht das nicht einfach, die Inhalte rechtsbündig zu setzen und den Container halt links neben das Textfeld? Und nur die Umbrüche im Textfeld zu zählen, und mit <br>gleichzuziehen?

die sidebar ist schon ein eigenes Element nur für die Anzeige der Inhalte der Zeilen und nicht etwa Teil des gerenderten Feldes, was auch oberhalb vom Textfeld die Änderungen an der Schriftart anzeigt??

ansonsten: nimm das Textsymbol #8963 ⌃, wrappe es wiederum in einen span und den drehst du mit text-transform um 180grad per CSS. Voilá, optischer Pfeil nach unten.

[gaenseklein]

nein, die sidebar ist ein relativ komplexes gebilde, was momentan ca. 150 zeilen code braucht. (hab noch test-sachen drinne und bin auf 163 und denke, dass das noch ein wenig zu entschlacken geht) wenn du sie ansehen willst - ab zeile 1190 im aktuellen code (slidenotes.js) und die funktion heißt emdparser.prototype.generateSidebar

abstand nach rechts brauche ich für die verschachtelung von mehreren multi-line-elementen (liste in layout bspw., aber selbst eine verschachtelte liste ist bereits verschachtelt) daher verändert sich der abstand-nach-rechts. inhalte rechtsbündig hatte ich als ersten ansatz - das funktioniert sehr gut (und viel einfacher) bis halt die verschachtelung auftaucht. dann kann ich es nur so lösen, dass innere elemente links, also außen in der verschachtelung dargestellt werden - was nicht dem entspricht, was der user erwartet und auch unübersichtlicher ist.

ich hab aber glaub ich ne lösung für den fall dass du keine background-grafik willst - indem ich erst text nehme (egal welches zeichen nur eindeutig) und das am ende des codes wenn die sidebar fertig ist durch ein 1em-breites image ersetze mit dem bild deiner wahl. dann ist innerText an der wichtigen stelle (abstandsberechnung) richtig und wenn das bild genauso groß ist wie der innerText (1em oder auch ein vielfaches davon, je nach wunsch - muss nur immer gleich breit und hoch sein wie der entsprechende innerText) kommt es auch nicht zu einer verschiebung.

[gaenseklein]

cursorline ist jetzt da und wird durch images ersetzt im nachhinein. gibt noch css-fehler und deswegen will ich das auch nochmal umschreiben und anders lösen. aber die funktion steht schonmal.

[gaenseklein]

cursorline ist jetzt eigenes div (nicesidebarsymbol) und schwebt über der sidebar mit position absolute. dadurch kann sie grafisch unabhängig gestaltet werden ohne die sidebar durcheinander zu bringen. nicht die eleganteste lösung aber praktikabel. issue ist abgearbeitet - bitte in browsern testen. im firefox und chrome funzt es jetzt wie erwartet. wenn in ein paar tagen nichts anderes kommt schließe ich das issue.

[gaenseklein]

die sidebar ist ein performance-killer. evtl. komplett neu schreiben? dazu muss mir aber ne bessere logik einfallen. oder sie analog zu #33 partiell machen. stand momentan:

einfache Seite:

Inhalt besteht aus titel, einer 4-zeiligen liste, einer chart und einem codeblock: Parsen von 135 Zeichen und 15 Elementen brauchte: 2ms - Rendern brauchte:12ms Davon: pures rendern:3Ms sidebar:7Ms highlight:1Ms

simpletest.md

Timecheck: Parsen von 4114 Zeichen und 188 Elementen brauchte: 21ms - Rendern brauchte:99ms Davon: pures rendern:35Ms sidebar:59Ms highlight:3Ms

proofofconcept.md

Timecheck: Parsen von 17509 Zeichen und 298 Elementen brauchte: 11ms - Rendern brauchte:452ms Davon pures rendern:34Ms sidebar:208Ms highlight:170Ms

[jochmann]

ich würde auf jeden Fall noch mal an die Logik ran.

Dropdownmenü funktional von den Kontext-Anzeigen trennen: Vielleicht reicht es, die cursorposition abzufragen, dazu die Höhe der Textarea und entstehende Zeilen, und dann den Positionszeiger auf die entsprechende Höhe (position absolute) zu setzen und das dropdownmenü in den verbleibenden Platz oben oder unten anheften.

Kontext-Anzeige evtl auch im Design noch mal neu denken. Verschachtelung möglichst auflösen oder in Containern denken, die auch nach links ausweichen können. Müssen wir mal zusammen skizzieren.

[gaenseklein]

Dropdownmenü funktional von der Kontext-Anzeige trennen macht Sinn. Das Problem ist nur, dass du ja willst, dass die Kontextanzeigen nach links hüpfen bzw. eingerückt werden. Und da wirds wieder komplizierter, deswegen macht es schon Sinn, dass es (zusätzlich) in der Sidebar berechnet wird. Aber losgelöst davon ist natürlich schick, wenn wir die Sidebar nicht anzeigen lassen wollen aber das Dropdownmenü schon. Macht momentan noch Probleme in der Berechnung, wenn Cursor in leerer Zeile steht (dann wird top-Position mit -1 angegeben) aber das sollte behebbar sein.

Design der Kontext-Anzeige neu denken? Verschachtelung möglichst auflösen? Container, die nach links ausweichen? Da fehlt mir Input, was du damit meinst.

[gaenseklein]

Dropdownmenü ist jetzt losgelöst von der Sidebaranzeige