Starting point of what I have in my Tinderbox file:
I have a container Seedlings with notes, that I think are worth being worked on and visible. These outline order represents a ranking of how important the notes are to me.
I have a container Speculative Outline, where I want to sort notes from Seedlings, so that notes on related topics are grouped together, like one would using chapters, sections, subsections etc. in a non-fiction book.
What I wanted to do just now:
Move one of the notes from Seedlings to Speculative Outline.
What I did not like about what I could have done:
If I simply move it, I loose the information of where among the other Seedlings it ranked.
If I instead create an alias, I feel that when later visiting the Outline, I may miss out on descendant notes nested under the original note, as the alias will not carry these.
What I wondered about/wanted:
Is there a visual indication on aliases (in outline view especially), that tells me, it has child notes? If not, what would be a good way create one?
Why do I want this?
Ordering note-for-note gives me a better representation of what I want to work on.
Sure, I could say „sort all of them into categories, and then sort the categories“, but something is lost if I do that:
A small note, that I consider „lot’s of benefit for few work“ may rank high in terms of what I want to work on – even though the overall topic is not the most important one. If I have the ordered list of notes, it will be at the top – if I only have the sorted chapters & categories it may be overlooked.
PS:
This shares the same core as what I asked for in this thread here: Multiple map arrangements of the same set of notes , creating multiple arrangements from the same set of notes. In the end it comes down to me bumping into Tinderbox being designed with an architectural approach i.e. “a thing can only be in one place” (correct me if I recalled this incorrectly). Keeping the “original” notes in a large container without any structure as soon, as I want to use it in 2 places also seems appealing to me. Then I’d just have two aliases and the original in the “unsorted pile where all the things live”. Always seemed to cumbersome though – but may be possible to get working with action code etc. …?
My first attempt at a solution would be to display the number of child notes as a column in the outline view – but I don’t really like how it clutters the view with a lot of irrelevant information (for non-alias notes I would not need it as they have their children nested and I can always see the triangle indicating they are there).
One approach would be to have each of your seedling notes adopt a common prototype, perhaps A Seedling. Then, add a Badge to the seedlings that have child notes. You could automate this with a rule:
If you’re already using $Badge a couple of other, less optimal alternatives—which I’d still suggest applying via a prototype…
#1. Flags. An outline item can show the notes’s (first) flag (from $Flags) as described here: Flags in outlines. The downside is, that the selected item - the one you’re likely looking at uses the same space for the link widget thus:
Tip: As $ChildCount is a Number-type attribute, by default it displays 2 decimal places, i.e. ‘4.00’ not ‘4’ as makes more sense. tho get zero decimal places dipslayed in the pop-up where you select the attribute to display, change the value of the Decimals box from 2 to 0.
Why would you prefer the Badge over the flag with number? I think directly seeing the value of $ChildCount is very nice, so I assume there must be some downside you have in mind, that I am overlooking? Or is it just the fact, that it takes the spot of the Link arrow?
Yes. As stated/illustrated: when a note with a flag is selected the (outline view) space used to show the flag is replaced, for good reason by the link widget. But, if that doesn’t bother you, the flag is a nice alternative.
Note in the article on flag syntax that a flag can hold 1–3 characters. In fact the limit is not the count of characters in the number but horizontal space. But hopefully you’ve <1k child notes in your scenario.!
One could have guessed it: next issue I am facing is identifying all seedling notes that have no alias in the container speculative outline.
As I’ve read elsewhere on the forum, notes do not have a record of all their aliases. So there is no $AliasCount, and no easy way of querying for all aliases. Is this still true (thread I read this in is 5 years old)?
Ok – so $Aliases was added at some point after this thread.
My quick and humble fix will be to indicate with a badge those seedlings that have no alias at all, and additionally show $Aliases via $DisplayedAttributes – so I can see if those with aliases may still not have one in the speculative outline.
If I can carve out time, I’ll also try to get the actual logic I want, which would be a flag being set if
there is at least one alias of this note, in a specific container.
A thread from 2018. There is no resource mechanism for going back and annotating more recent app changes. Too big and unbounded a task.
Pertinent though is to ask where you looked in the app/help/documentation and didn’t find your problem answered. Indeed, what were your search terms? i’m not asking by way of judgement but instead to see if there’s a gap in the docs. The apps open-ended, so there can’t be a canned answer for every processes, but the building blocks for those a (mostly) described. Yet, we’re always looking for oversights.
[quote=“rald, post:10, topic:7119”]
If I can carve out time, I’ll also try to get the actual logic I want, which would be a flag being set if
there is at least one alias of this note, in a specific container.
[/quot]
Definitely do-able.
The joy of Tinderbox is you can do this. Sure, you set the logic (action code) but at least there is the choice.
The fact this count/logic isn’t baked in serves to remind us how personal are workflows are. The choice is to work in the walled garden of fixed system where you do what the am allows/demands in terms of process, or you trade that for rolling your own albeit at the effort of coding the necessary automation.
And the forums here for any questions if/when you get stuck.
Google query for “alias count OR many tinderbox” iirc. That brought up Aliases in aTbRef and 2 posts here on the forum. Forum posts indicated what I was looking for was not easily achievable 5 years ago. On aTbRef I did not see anything contradicting “there is no attribute in which a note keeps track of it’s aliases” on the aTbRef page (there may be – the page is quite long, so I quickly skimmed over).
In general I’d say I tend to look at the forum first, because I often find what I need easier (search engines work well on threads, where many different words are used for the same things – if I miss the terms used in a concise reference doc, I’ll not find anything). Once I know more precisely what I need & what it’s name is/may be, I’ll turn to aTbRef.
Well, now I tried. My idea was to use $Edict, which I’d set via a Seedling prototype.
First step was to just test my edict, so I just manually changed $Edict for one of my seedling notes, without using any prototypes:
if (find($Name==$Name(this) & $IsAlias==true & $Container=="/Speculative Outlines/tobenamed/").count>0)
{$Color="green"}
else
{$Color=;}
This worked as expected.
So now I tried to use this as for $Edict of my Seedling prototype.
But that leads to the prototype itself getting $Color=“green” (and inheriting this to any seedling, regardless of it’s aliases and thus breaking what I wanted to accomplish) – even though there is no alias of it in the container “/Speculative Outlines/tobenamed/”.
Could you explain why this happens?
Prototypes are notes like other notes, and may have rules and edicts that affect them.
Often, as here, you want a rule or edict on a prototype so instances will inherit, but do not want that rule or edict to apply to the prototype. The boolean attributes $RuleDisabled and $EdictDisabled do this. These are intrinsic attributes, so their values are not inherited.
You can set these attributes in the inspector (lower-left corner):
Thanks. This is helpful. as (disclaimer!0 I write aTbRef, I think I might be able to make things more findable. Some tips arising:
use Cmd+F (in-page find) in your browser on the aTbRef site map page (linked in the head/foot of every site page). Though it wouldn’t have helped in this case an in-page search might have found you the page for the $AliasCount and that page might have got you some way to your goal.
an oddity that is—depending on your task—a blessing of impediment is the fact that whilst an agent query automatically de-dupes an favours an original a match, find(), operates differently. find() on a note $Name returns a list of all matches, i.e. original and all aliases. Filter that list for an ancestor note all matches need and it might help your general plan.
Anyway, thanks for that feedback, I’ve got some useful pointers from it.
I was not aware of the aTbRef Site Map page. I definitely have used other links from the Quicklinks section on top of each of each page. But never that one – I did not get what was hiding behind the name. I would for sure have clicked on something like Searchable outline of all pages. If you want to improve discoverability of that page, maybe a rename or adding a hint in parentheses would be an idea.
Definitely my new go-to resource now, instead of Google.
Given the size of aTbRef, the sitemap isn’t particularly easy to read due to length. But, it does—allied with in-page search—offer a quasi-index. An automated index for the site would be bigger (good indexing is still really a human skill—what to omit or elide). The sitemap at least gives something searchable.
The site map was also part experiment in using the envelope/letter (re-cursing) template technique. A challenge (unseen in the final output) is whether to list all agent contents (as the contents are all aliases)—there is not ‘right’ answer.
An as yet unrealised experiment was to label some (all?) notes with extra metadata (essentially search-related keywords) to address the issue where a note’s title ($Name) omits words relating to its content. Bear in mind:
Tinderbox omits static sites. For a long-lived resource (aTbRef is 19 years old) moving/renaming notes has non-trivial effects. I flirted with fixed HTML names and letting titles change but it just made for an admin headache. As aTbRef is only me, in my spare (!) time, tit wasn’t a sustainable approach—though it might be for other people’s projects.
I try to name notes either for the feature they describe, e.g. ‘Document Inspector’, or the nature of the task, e.g. ‘Stream Processing and parsing’. This often does not mesh well with the terms a questioner might use to search for the article.
In the early days, I flirted with a wiki-style approach but you end up with both weirdly named articles and in in-text anchors that jar.
I’d like to recognise a member of our community, the late Rosemary Simpson, who had expertise as an indexer. Over aTbRef’s life she gave me useful advice as to how I might make things more findable within such an expansive work. In part it made me realise that a human-compiled index simply isn’t possible in a one-person work like this which is under constant expansion/re-factoring (i.e. possible—but not with available resource).
So, the sitemap is the best of the less-good options! I hope this digression also explains why there isn’t a better index!
Prompted by @rald, I’ve added a section to the main page on Aliases— see heading ‘Finding and counting aliases’—and cross-referenced is to the article on the system attribute $Aliases.
Making that content more findable remains as a challenge, but at least the topic is now mentioned somewhere. The change to the ‘Aliases’ page shows another challenge: Tinderbox lacks any automated way to insert anchors to headings in a page. It os part of the reason aTbRef has so many small pages—addressability.
Anyway, I hope that helps, even if after the fact.
One final remark, for possible future readers:
I initially wanted the aliases to form the speculative outline and the originals to remain in the seedlings container.
Quickly I realized, that putting together an outline using aliases is not a good idea: Aliases can not have children. So if one seedling would naturally be a child of another, I can not represent that in my outline.
Resolution:
Create an Alias for a seedling when you want to place it in the topic-based outline – this alias can stay in the original location and the original note will live in the outline.
I explicitly want all the seedlings in a plain list without nesting in the Seedlings container. So it does not hurt that aliases don’t allow children for this list.
