2021-04-24 create high-level API for comfortable model object access\\although the current low-level API is very handy to deal with Freeplane mindmaps, a more general object-oriented interface could help building transparency concerning input file formats of structured data. so, e.g. the same API concept could be used to retrieve data from a mindmap or an excel file. +freeplane id:74B199E8 sc:0 chg:2024-03-10 origin:FREEPLANE
2022-03-04 FIX: save changes certain character representation\\when using the map's "save" method, Python currently replaces every\\  - "&apos;" with "'" (single quote)\  - "&#xa;" with "&#10;"\\this does not cause any problems within the Freeplane editor, but it changes the file at locations where no change was expected. having the potential to confuse the developer / user. fortunately, Freeplane neutralizes the conversion as soon as the mindmap is saved from the editor.\\the location within the code where this transformation hapens is to find and a solution is to be found so that only actually changed portions appear as changed within the XML file in the first place.  {11.10.2024: sgjohnson1981 creates an isue for this in https://github.com/nnako/freeplane-python-io/issues/7} +freeplane id:7FA27327 sc:10 chg:2024-10-11 origin:FREEPLANE
x 2022-09-27 remove freeplane.mm from source code tracking +freeplane id:FF04B844 sc:100 chg:2024-03-10 origin:FREEPLANE
x 2022-09-27 scan and replace every private string within repo\\in order to securely hide any private information from the world, strings like "Nnamdi", "Kohn", "Peter", "taboo" and further passwords and personal numbers are to be identified and replaced by neutral content. within the whole repository (current files as well as git history). this will change many commit hashes. +freeplane id:3A2B9FDF sc:100 chg:2024-03-10 origin:FREEPLANE
x 2022-09-27 ensure commit author always to be "nnako"\\sometimes, commits were made under a different author name. this is to be corrected before publishing the repo to the outer world. +freeplane id:693914D3 sc:100 chg:2024-03-10 origin:FREEPLANE
x 2022-09-27 move "freeplane" module into "src" folder\\in order to meet the configuration and PyPi demands, the structure of the repo is to be adjusted. +freeplane id:4F7CF774 sc:100 chg:2024-03-10 origin:FREEPLANE
x 2022-09-27 publish current version on PyPi +freeplane id:23A0ADB4 sc:100 chg:2024-03-10 origin:FREEPLANE
x 2022-09-27 rework API to be concise\\choose a good way for naming methods and attributes for users to easily get the concept and use the library. maybe, it makes sense to adapt the Python API to the already existing Groovy API as it is used within Freeplane itself. +freeplane id:31E64C83 sc:100 chg:2024-03-10 origin:FREEPLANE
2022-09-27 modularize "freeplane" module\\currently, there is only one monolithic file containing all classes together with their methods and attributes. this is not a good concept. it would be better to e.g. create each class within its own file:\  - mindmap.py\  - node.py\  - nodestyle.py\  - ... +freeplane id:312F5FF9 chg:2024-03-10 origin:FREEPLANE
x 2022-09-27 publish repository on GitHub\\a repo on GitHub was already prepared. it is named "freeplane-python-io" although the PyPi package will be named "freeplane-io" or even "freeplane" +freeplane id:57CF151E sc:100 chg:2024-03-10 origin:FREEPLANE
x 2019-03-15 FIX: use lxml module instead of xml module +freeplane id:4974B4B7 sc:100 chg:2024-03-10 origin:FREEPLANE
2019-03-15 access password protected nodes +freeplane id:8A83AECD chg:2024-03-10 origin:FREEPLANE
2022-07-08 create a framework for testing this library\\maybe based on pytest or unittest, a framework is to be created in which tests can be added +freeplane id:E81DF9D7 chg:2024-03-10 origin:FREEPLANE
2022-07-27 implement functionality to use Freeplane node attributes for storage\\common usage is to create / use a "token child" node as the key and its child as value(s). in case the user rather wants to store thise attributes within native Freeplane node attributes, this has to be implemented. +freeplane id:060B6647 chg:2022-09-27 origin:FREEPLANE
2022-07-27 FIX: implement correct handling for single and list-type values\\currently, when using this function, only the 1st child of a respective first token node (key) will be used to store a single value. the user might want to:\\- store multiple values (list) as children of the same token node\- store each value as a child of its own token parent\- append to the already existing token list or remove it entirely\- handle update coloring in all these cases\- ... +freeplane id:60C3E08B sc:90 chg:2022-09-27 origin:FREEPLANE
2022-10-04 FIX: update comments in code base\\currently, there are no much functions / methods documented within the code base. in order to re-use documentation already provided within the project mindmap, these comments are to be transferred into the code. prior to that, the function signatures are to be transferred into the mindmap. +freeplane id:6744697A sc:10 chg:2024-03-10 origin:FREEPLANE
x 2022-12-19 FIX: create workaround for parse error caused by "NBSP"\\as the Freeplane editor mixes XML and XHTML within its file format ".mm", standard XML parsers show problems when parsing these files as soon as there was an "&nbsp;" used somewhere. "&nbsp;" is not defined as valid XML content but "&#160;" would be. this is the case within Freeplanes "richcontent" elements which hold plain XHTML content. one way would be to manually remove / replace all occurrences e.g. using Notepad++ before handling over the file for XML parsing. This would not be the best way.  {19.12.2022: here are some links where to continue search for a solution:\https://stackoverflow.com/questions/19974909/xml-non-breaking-space\https://stackoverflow.com/questions/31210655/nbsp-text-not-handled-by-the-lxml\https://bugs.launchpad.net/lxml/+bug/1936579\https://github.com/freeplane/freeplane/issues/896} +freeplane +parsing id:CB477A7D sc:100 chg:2024-03-10 origin:FREEPLANE
2024-02-11 integrate text evaluation features into eval_content()\\HINTERGRUND\\In Mindmaps lassen sich alle Knoten prinzipiell auf verschiedenste Arten auswerten. Die einfachste Art ist ein reines Auslesen des textuellen Inhalts des "core"-Attributes eines Knotens und Rückgabe dieses Strings an einen Aufrufer. In unterschiedlichen Projekten wurden nun spezifische weitere Auslese- und Auswertungs-Features umgesetzt. Beispielsweise ein Token-basiertes Features, bei dem vor der Rückgabe das dynamische Ersetzen von fest definierten Tokens erfolgt. Dies ist z.B. im Projekt "mm2xls" umgesetzt, wobei die festen Token "<requirement>" und "<solution>" verwendet werden. Ein anderes Feature im gleichen Projekt ermöglicht das Ausführen von Python-Code, das direkt im Core-Attribut definiert ist, oder aber in einem core-linked Knoten vorliegt. Ein weiteres Feature, das bisher nur händisch umgesetzt wird, sind "flexible Token", wobei der Platzhalter (Token) in dem Knoten-Core-Text enthalten ist, die Bedeutung aber über die in den Kind-Knoten enthaltenen oder von dort core-verlinkten Knoten definiert wird.\\AUFGABE\\Es sollen alle solche Auswertungs-Features für Knoten-Texte aus den Projekten extrahiert werden und über eine einzelne, parametrierbare Funktion get_content() bereitgestellt werden. Die Auswahl der Auswertungskonzepte soll dabei entweder automatisch erfolgen können, oder aber über z.B. eine Bitleiste oder eine Aktionsliste vorgegeben werden können. So können dann auch priorisierte Kaskaden wie "erst flexible Token ersetzen, dann den resultierenden String als Python-Skript ausführen" realisiert werden. +freeplane +evaluation id:8lLOawY sc:10 chg:2024-03-10 origin:FREEPLANE
2024-03-10 merge textual content of children\\HINTERGRUND\\Aufeinanderfolgende Knoten sollen unter bestimmten Umständen zusammengefasst werden, um z.B. aus (z.T. core-referenzierten) Einzel-Strings zusammengesetzte Sätze zu bilden. So können auch komplexere Inhalte aus der gesamten Wissensbasis hierhin verknüpft werden.\\AUFGABE\\Es soll ein Feature bereitgestellt werden, das es ermöglicht, bei Vorhandensein spezifischer Noten-Strukturen (Zeilen oder auch Tabellen) diese in Gesamt-Strings umzuwandeln, die dann weiter ausgewertet werden können. +freeplane +evaluation id:6cM6Vdv sc:10 chg:2024-03-10 origin:FREEPLANE
2024-03-10 re-synchronize merged textual content into mergeable nodes\\HINTERGRUND\\Aus Mindmaps können z.B. Ketten von Knoten zusammengefasst werden, bevor eine weitere Verarbeitung der zusammengefassten Inhalte (Strings) erfolgt. Kommt es nun zu einer Rück-Synchronisation eines solchen Strings zurück in die Quell-Mindmap, so soll vermieden werden, dass die zuvor in der Quell-Mindmap bestandenen Strukturen mit "statischen" Strings überschrieben werden.\\AUFGABE\\Es soll bei einer Rück-Synchronisation von Texten zurück in eine Mindmap die bestehenden Knoten-Strukturen erhalten bleiben bzw. die Rück-Synchronisation unter Berücksichtigung der bestehenden Strukturen erfolgen. Auf diese Weise können MERGE (Erzeugung von Text-Blöcken aus Knotenstrukturen) und RESYNCHRONISATION (Erzeugung von Knotenstrukturen aus Textblöcken) verlustfrei und zyklisch erfolgen. +freeplane +evaluation id:7LTkqga sc:10 chg:2024-03-10 origin:FREEPLANE
2024-10-26 provide methods for arrowlink handling\\HINTERGRUND\\Anfrage aus GitHub zum Ermitteln von Knoten, die via einkommenden und ausgehenden ArrowLinks verbunden sind. +freeplane +arrowlinks id:146eCZKT origin:TODOTXT