I’ve been using MindNode as a quick outliner. If I output to OPML it opens up in FTA fine and follows the defined structure.
In MindNode you have the ability to capture Notes in a Node. The notes are in the exported OPML file but currently aren’t being displayed in FTA.
The Note is an attribute of the Outline item. In MindNode it’s listed as “_note”, which I think is not standard but widely used?
I’m not sure how best it should be displayed. It’s not really a child node but another item of the node similar to “text”. Maybe as code-block, assuming the Markdown elements in foldingtext-markdown are there.
Here’s an example of the output with a “_note” node, . It looks like it’s creating a data attribute, like data-status or data-priority. Maybe this is something that users can define custom data elements and set basic display rules ( that may be a messy can of worms…)
<outline text="Testing "><outline text="Test Christina’s Role in Train"><outline text="Works"><outline text="Copy role to LO Test and apply to SECTEST User" _note="Don’t import. Hand build based on Christina’s structure "><outline text="Works"><outline text="Modify existing filter roles to follow pattern. "><outline text="Note necessary changes"></outline></outline>
Here’s how this same section is encoded after I save the OPML file out with the FTML extension. “_note” is imported in as part of an li element, not the P element that holds the text from the mind map: <ul> <li id="X1xekLnuZZg"> <p>Test Christina’s Role in Train</p> <ul> <li id="QyblJI3_-Zl"> <p>Works</p> <ul> <li id="X1zxJ8nu-bg" data-_note="Don’t import. Hand build based on Christina’s structure"> <p>Copy role to LO Test and apply to SECTEST User</p> <ul> <li id="QyXxyL2_-Zl"> <p>Works</p> <ul> <li id="QyNl1UhdW-g"> <p>Modify existing filter roles to follow pattern. </p> <ul> <li id="X1SlJLhu-Ze"> <p>Note necessary changes</p>
_note attributes are indeed quite widely used for the old item+note pattern which has been around for a while in apps like Lotus Agenda, Microsoft Outlook, OmniOutliner etc.
OPML read/write is not complex to script, and I could certainly adapt an existing script to do that for you in the interim, while Jesse decides how to handle it.
( I can see why it is becoming a data attribute at the moment (that is what adherence to the formal OPML spec would naturally lead to) but its clearly not going to be the most useful long term destination for these paragraphs).
The simplest FTML interpretation of a _note attribute would be as a sequence of one or more children of the node to which they are attached.
( Each note para as one successive sibling <p> )
Would that work for you ? I guess one could also flag those notes (for the purposes of further export, or for stylesheet variation in how they are shown, with the (invisible) attribute data-type="note".
If that seems the right approach we could:
Write an interim OPML → FTML applescript
Suggest an OPML reading (and possibly writing?) tweak to Jesse at:
I agree that the best long term solution would be to have a two-way implementation, one for importing and one for exporting to OPML (a specific status code display element attached to a data-type=note value would seem to be the best option since not everyone would need something like this).
Child nodes seem like a good starting place.
Would you share the script you were thinking of modifying? I was intending on learning how to script some of these files anyways – modifying existing ones always seems a good start. Are you running scripts from inside Atom with Coffee? Or using Jave or Apple script?
( Atom plugins are written in Coffeescript or Javascript )
To avoid multiplication of directions,
I tend to write these things by pairing two parts, a reader and a writer, with the reader translating into an interlingua, and writer translating out of it. A nested Javascript object works well as the interlingua, and has the advantage that it can be easily be serialized / deserialized to and from a JSON string.
For an interim external script which read OPML and pasted/saved as FTML,
the reading part (OPML to JSON/Javascript) could be adapted from:
( In the meanwhile I’m advised that we could also pop up a panel in FTA to edit a date-note attribute, leaving it in place for later re-export, or creating it in FTA with a view to an OPML afterlife – I’ll see if can make some progress towards the rudiments of an OPML Mode in that form )
