I’ve been struggling to repair these three mysterious attributes that have appeared in one file across all containers. To the best of my recollection, they popped into the file following a command-option drag and drop from Bookends. The drag and drop worked as expected, bringing all the attributes of the reference into my reference file.
But I noticed later (not immediately because I was working with the notes) that these three attributes now appear in every non-prototype container in this particular file. You see them shaded because I trouble-shot to the best of my ability (which isn’t great in Tbx-I happily work within my capabilities. I went into the user attributes and deleted each of these; however, they only shaded in the containers rather than disappeared, which is my intent.
If I should use the dropdown menu to change the prototype to something else (e.g. reference, these phantom attributes go away, but when I return to the ‘none’ prototype, they return.
This doesn’t get in the way of my work. It just bothers me that these attributes appeared like this and I can’t make them go away. If anyone on the forum has encountered a similar problem and has a tip for me (or a question to help get me closer to solving this minor irritant), I’d be grateful.
Again. I’m not a power user. I just do what I need to do and seek out answers here on the forum and in The Tinderbox Way (favorite source) or the Help Files within the app
Also, I can’t be certain that it was a Bookends drag and drop as the preceding event. It’s just that it’s the only novel move I made before the phantom attributes appeared.
It looks to me like you have inadvertently changed the default value of $DisplayedAttributes, or perhaps the value of $DisplayedAttributes in a prototype which is shared by all your containers.
If you can share the file here, or even a small piece of the file, that would likely solve things in a jiffy.
If not, pick a container and see what prototype it uses. Now, look at the prototype; what is its value of $DisplayedAttributes?
To see if your document has a default value for $DisplayedAttributes, open the Inspector (Cmd+1) and open the Document Inspector’s system tab. As shown below, type ‘DisplayedAttributes’ in the top search box and hit Return and the details for the $DisplayedAttributes will be shown. Below is this for a new v9.x Tinderbox document
Most likely in your document the Default value box will contain the text data-done;id;type.
However, if as above, none of the 3 attributes (putative $data-done, $id, &type) exist. Whilst $DisplayedAttributes holds a list of names of attributes to display in the Displayed Attributes table. The styling of attribute names and info in the table is described here. From that we see that:
a label in grey indicates a table item defined for a non-existent attribute, e.g. occurring when a note with Displayed Attributes is imported form another TBX document
As @holland notes, it’s unclear how this setting got made. But if, as described above, the document’s $DisplayedAttributes has been given an erroneous default value, deleting it should set everything right.
Aside: the reason notes using prototypes don’t have the effect described is because they have been customised to use non-default Displayed Attributes. The prototype’s custom value overrides inheritance of the document default value. So such prototypes and any note using those prototypes, won’t show the ‘wrong’ attributes that you describe.
A last note, ‘data-done’ is not valid as an attribute name in Tinderbox. The naming rules for Tinderbox user attributes are described here.
That may be enough to fix the issue, but otherwise @eastgate’s suggestion of sharing a file with the issue would help us all help you.
Gratitude for gently guiding me toward a clearer understanding of where my phantom attributes originated. I now realize that I might have done one other cut and paste that could have caused the problem. I also realize, in hindsight, that my biggest error was not trying out a new technique with a TEST file. Your kind and knowledgeable guidance (@mwra & @eastgate) led me toward an experiment I should have tried at the outset. But hey, trying something new, making mistakes and failing are all part of the learning process, right?
So, I’m attaching a test file that I created upon reading your speculations and guidance. With this experiment, I have learned that Bookends was not the culprit (thus I changed the name of this post so as to not sully the name of a truly amazing app in my workflow). I also recalled, upon reflection, that I had done one other out-of-the ordinary move with the larger file: I had cut and pasted into Tinderbox a portion of an outline from the Bike app (using the opml copy). I’ve explained it all within the attached file. Other readers can ignore. Phanthom attribute test JHolland.tbx (271.3 KB)
If you have further questions after looking at the file, go ahead and ask.
I’m still left with my central question: Is it possible to get rid of the phantom attributes without going through every container and deleting them one by one.
Again, I’m so appreciative of your replies that have given me more insights to learn from once I can repair the present miscue.
If we examine the data that BIKE provides in its OPML, we see entries like this:
<outline id="do-" type="task" text="Learn the keyboard shortcuts"/>
Tinderbox knows what to do with the text, but not with the type or id. So it makes new string attributes for these, and makes sure you know about them in case you need them!
Ah ha moment. I just needed to go one step further than I had in my understanding. And sometimes you have to read something two or three times before it clicks. And I’ve gained a new understanding this morning about some of the deeper workings of Tbx.
I grasp two things now: 1) how and why the phantom appeared, and 2) how easy it is to make it disappear. I just needed to develop some understanding of the inner workings. And I won’t be doing that opml cut and paste in the future
You might find this useful know you know the OPML angle: OPML Import.
Frustratingly, OPMLis a standard … but one which most apps using it extend in undocumented ways which makes figuring out uncertainties all the harder. Whilst type is an OPML element attribute in the OPML standard, id and data-done are not, though it seems Tinderbox did it’s best to make them. data-done is a further problem for Tinderbox as ‘data-done’ does not conform to Tinderbox attributer naming rules so cannot be created.
If Bike allows it (not necessarily possible), you could try editing its OPML export template to remove those unwanted attributes from the OPML element tags.
I dug a bit further. Bike has no documentation on its OPML export and the templates appear internal. I don’t have the app so can’t examine the app package. We can see from it’s export that the OPML is OPML-compatible but doesn’t follow the standard, adding extra content.
A lot of lightweight Outliner apps do this as on the surface it provides easy interoperability. But bad-forces out good, as devs slowly ‘enhance’ the standard for their own need and new entrants, wanting easy access to other apps users copy the changes. The standard is left far behind, so edge cases like above occur where unnecessary info, which ought to be optional for export, is just dumped into the OPML.
It’s a reason OPML is a format I’d not recommend unless writing it for your own purposes. Otherwise is works until it doesn’t and then its the receiving app’s fault when the eye of suspicion should fall on the originator.
In researching this I read Bike’s online documentation and searched their support forum. I’m sure the app’s great in its primary purpose, I just have trust issues around Bikesunderstanding and use of OPML—though I doubt that’s intentional. The dev’s been around a goodly while and made some interesting apps.
Reading between the lines, I think that Bike is actually being sensible here. It identifies what it considers the type of each item to be in the imported string attribute $type; for example, tasks have type “task”. In Bike, these display a checkbox.
If the checkbox is ticked, Bike also adds a value $data which contains the time at which the checkbox was ticked.
Just using plain-old Copy is going to be fine most of the time, but I don’t think Bike is particularly abusing OPML here, and I think on the whole Tinderbox is doing a pretty good job of importing a bunch of data it couldn’t really expect.
I appreciate your follow-up commentary as they all help me to gain a better understanding of inter-app workflows (those to accept without question, those to avoid and those to enter into with caution). I think your comment about the ticked checkbox (Bike is a cousin of Taskpaper) explains where the mysterious data-done attribute comes from. In fact, my first head scratching moment at my desk @mwra came about because I knew, as you said earlier, that dashes are not allowed in Tinderbox attributes.
I’m learning things here and that’s a plus.
Bike also gives me the option of copying as Plain Text and that’s the way I’ll go in my workflow in the future.
Much as it is nice to go direct from app A to B (export from A, import to B), if the process has glitches but you’d like to do the process a lot don’t overlook a transform on the way.
This is more for later readers as it looks like @holland has a solution but a general approach might be:
look at direct app A to app B. What is ‘breaking’ when seen in app B? Are fields missing, garbled, etc.?
look at app A’s export, does it allow customisation?
If the export templates are built-in and if you’ve the experience to look inside an app package, see if the templates are visible†. If the export ‘template’ is accessible, try altering (a copy of!) the template to see if you can get a clean A to B transfer.
if A’s output is fixed, consider using a tool like BBEdit (the free version will suffice for this) and see if you can do a search/replace to fix the A output so it is compatible with B.
If/when you can figure the fix then tools like AppleScript‡, Automator, etc. can be used to automate the process and get a simpler A → [‘clean’] → B process.
†. Oft times, the app package’s content may reveal template files used for tasks like export—but go carefully and don’t move/change contents on a whim. If you find files of interested, e.g. export templates, you may well need to ask the app’s developer how data is added for export. I’ve found most developers responsive to a clearly-described and polite request for info—i.e. describing why you need to know. Even if the answer is essentially ‘No’, you still now know for sure you need to edit data post-export. Indeed, such an exchange might even lead to a feature change in A if the need is clear and not overly complex for the developer. A clearly worded question is enlightened self-interest all round.
‡. Tinderbox has AppleScript support. If app A does as well, then int might be a bridge. Applescript, despite it’s 'written in plain English" concept is arcane in use (‘plain’ English can be ambiguous to the computer!) so most of use using AppleScript may need some help. Ive found https://www.macscripter.net forums to be really helpful on general AppleScript—there is a wealth of expertise in that forum. Even if we don’t totally understand code we are givem if it works for our task, it works!
This is the OPML for exporting the standard built-in “Welcome to Bike”. (The file demonstrates to users the standard features of the app.)
<?xml version="1.0" encoding="UTF-8"?>
<opml>
<head>
<meta charset="utf-8"/>
</head>
<body id="hZpHpg6I">
<outline id="3C" type="heading" text="Welcome to Bike!"/>
<outline id="V7"/>
<outline id="cr" text="Use Bike to record and process your ideas. You'll need to spend a little time learning Bike to get the most out of it."/>
<outline id="Omp"/>
<outline id="95Q" type="task" text="Watch intro movie"/>
<outline id="-5Z" type="task" text="Browse the User's Guide"/>
<outline id="do-" type="task" text="Learn the keyboard shortcuts"/>
<outline id="Bp" type="task" text="Learn Bike's innovative rich text editing"/>
<outline id="b1D"/>
<outline id="um" text="Feel free to delete this text. Uncheck "Show Welcome in new documents" in Bike's preferences to stop including this text in new outlines."/>
<outline id="Sd"/>
<outline id="lg" text="Thanks,"/>
<outline id="Ca" text="Jesse"/>
</body>
</opml>
Perhaps the outline ID’s are not intelligent, but are generated by some randomizing logic.
Yes, @mwra I do have a solution—and a comment for general readers to followup on what you say.
Again, my mistake, which occurred in my first step and mis-assumption (is that even a word?) was the attempt to export from A, import to B. In doing so, I was trying to accomplish something with tools I didn’t fully understand. Backing up, my solution now is, as @eastgate said above, a simple cut and paste.
In fact, the easiest and simplest approach (since I am copying portions of outlines in Bike and not full files) is to copy from Bike into the text box of Tinderbox, then explode the note. Voilá, I’ve accomplished my goal without pain or undue stress.
I just summarize for future readers, knowing that I’ve learned a lot on this forum just from reading old threads while pursuing or looking for solutions.
Thanks again for the help from all, including @PaulWalters (whose posts I’ve come to appreciate throughout my journeys through the forum).
