For various reasons – possibly not good reasons, but not absurd – the Attribute Browser action is only applied to new notes created in the attribute browser view.
How does one create a new note in the attribute browser view? In attribute browser view, all the relevant commands in the Note and File menus are greyed out; and the one that isn’t greyed out (Explode) doesn’t work.
Changing this would be huge improvement for my workflow (I would need agents way less often) and it seems that almost nobody else cares. 
???
There has always been significant appreciation of the attribute browser, for the reason you mention and others.
Sorry for the confusion. What I wanted to refer to was that apparently nobody took issue with the lack of functioning of action code in the AB in recent times. 
1 Like
Agree 100% with @PaulWalters .
Easy way to test the “no one cares about the attribute browser” hypothesis: read one of the many extensive threads on how to use it and why it matters. Eg the one starting here:
Also
And
I was only talking/thinking about this:
I know that many love the AB (your posts on the topic have been an inspiration for me). Again, sorry for not being clearer on this.
For what it is worth, when I first started using Tinderbox, I thought the Attribute Browser was pretty powerful. However, I had a guess that the Action should do something like an agent’s action, but it never worked as I expected. So I assumed I was misunderstanding something and that I might find out later when I needed to. In other words, you’ve asked the question I should have asked. And, like you, I’d find it helpful if it worked as you and I seem to have expected.
1 Like
Ah, understand, thanks.
In the sense of your original comment, it actually is true that I, personally, “don’t care” about having this kind of query/action functionality within the Attribute Browser.
I use the query part of the AB very intensively – working it almost to death! The AB is my go-to working palette when I’m organizing notes for an article or book, when I’m trying to sort out the status of various to-do’s or projects, when I’m categorizing financial data, etc.
But toward those ends I use the queries strictly to regulate and refine the display of what I’m seeing in the different sections of the AB view.
When I want to do something with them, 99% of the time I use the Column feature, and either (a) have a check-box, to switch something from “Undone” to “Done” etc, or (b) add a new string or set value to one of those attributes.
I very frequently want to change note values via checkbox or column-value. But I, personally, don’t ever want or need to make those changes on the basis of a query/action operations. (If and when I want to make changes via an agent or query, I go back to an outline view.)
I understand that other people’s work habits differ. This is why I didn’t register what you were asking about – it’s a use case that never comes up for me.
Off-topic: I do the same but struggle with one aspect of this. I use Scrivener to write and would like to retain a link to the note in the text so that I later can verify the quote. In the past I used “Tinderbox > Copy Note URL” and handmade UUIDs for this purpose, without being really happy with either solution. What do you use for linking a note in TBX to Scrivener/your word processor?
Maybe some more info on my use case is helpful. I’m looking at a policy called 乡村振兴 or Rural Rejuvenation, which is part of Xi’s Rejuvenation of the Chinese Nation. I noticed that in the key documents of this policy the term beautiful (美丽) is a new addition and now want to track all variants of its use in the variable $SloganName (of the type ‘set’).
The Attribute Browser is great to find all of these cases. I could then add terms like 美丽乡村 individually to all notes that carry it (or use an agent to do that for me) - but it would be great if I could automate it right in the Attribute Browser.
1 Like
Here’s another possible solution: via Stamp or QuickStamp, which (in my experience) work fine within the Attribute Browser, and give you the agent/action power you are looking for.
Main functional differences between them, to best of my knowledge: (a) Stamps can be saved, so if there is an action you’ll want to perform frequently, you can set up it as a go-to stored stamp. QuickStamps, by contrast, are ad hoc and not saved. (b) Stamps can have full action code, and can do pretty much anything an agent can do. (If they don’t, I haven’t myself encountered the limit yet.) QuickStamps, by contrast, change the value of an attribute, but don’t deploy the whole action-code vocabulary. More info here.
Both Stamps and Quickstamps can apply to a single item, or to a range of selected items. What I’d do, in your use case:
- Select the item(s) you care about, while you’re working in Attribute Browser
- Call up the Stamp/Quickstamp menu, and either do an ad hoc change via Quickstamp, or apply a saved Stamp.
- I think that the saved stamp could say something like
$Tags=$Tags+"美丽乡村"(or whatever attribute you’re wanting to change). Expects will correct me, but I believe a formulation of that sort would add an additional value to a set-type attribute.
好运 ! [For onlookers: Good luck]
Update Thanks for clarification by @mwra, below, that the AB does not allow multi-item selection. But it’s quick and easy to apply stamps to them one by one.
2 Likes
A further useful point about stamps. When applied, the stamp’s code once on the selected note(s) (AB view actually doesn’t allow multiple selections).
The point here is you have very tight control of what happens to which notes.
Bear in mind the AB view doesn’t always refresh as often as other views. Some changes update the view, e.g. changes to attribute values tested by a query. This might seem an annoyance but in big/mature document it is actually a boon as it’s not always helpful if the view is trying to re-draw just as you are trying to read it. That said you can force a manual refresh by clicking on the current view’s tab; in fact i believe this method works for most (all?) view types.
Are there any plans to allow multiple selections in AB? That limitation is a pain.
I’m not aware of plans. I’d assumed the status quo is in part dictated by the underlying design. Still, no harm in making a feature request with a use case.
What I had in mind for actions in Attribute Browser:
Let’s suppose that Attribute Browser let you create notes. Your view has a query — say $Prototype==“Dialect”. You select a note in some section of the attribute browser, and create a new note.
TROUBLE! As soon you the note is created, it fails to meet the query, and so it’s removed from the attribute browser view. That’s not good!
So, we need to adapt the note so that, at the very least, it satisfies the view’s query. In simple cases, be can do this automatically; here, we could probably figure out that, to satisfy the query, we need to set $Prototype. But what if the query were ($Price>100 & $Price < 200)? Should we set the price to 101? 199? All sorts of weird problems can crop up. Often, these involve esoteric queries that you might imagine would never crop up in real life. Alas, they do.
So, the action was invented to deal with this: you tell Tinderbox how to make new notes satisfy the query. The action exists, in this view, to prepare newly-created notes so they won’t vanish from the view.
But this was all in support of a trick that Profs. Marc and Jocelyn Nanard pulled off in their attribute browser-like system back in the 1990s. Suppose your attribute browser was exploring $Status, and you had bins for Critical, Important, Desirable and so forth. Select an Important note, and press return: Tinderbox would make a note right below the selected note, and then would set the $Status to match the status of that note’s attribute browser category. This is more feasible than doing the same thing for queries, because Attribute Browser categories are more limited. And it’s very clever.
Yet even here, I got tangled up in edge cases and complexity, and we needed Attribute Browser now, not next year. I turned off note creation to avoid both these headaches, and the only time the attribute browser action needed to be called in the original design was for new note creation.
So, that’s how we got where we are. It’s not malign, and not arbitrary — at least not from a design perspective. I’m happy to revisit.
Similarly, for multiple selections.
2 Likes
Thank you for that description of the challenges facing actions and creating notes in AB.
What is the challenge with multiple selections?
An additional problem with creating a note in Attribute Browser is “where does the note belong”? The AB is a flattened view across all containers. So does a note created in the AB belong to the root? A action could set $Container, but why?
AB is not broken, IMO. We have stamps, we can use them (better yet with multiple selection; workable with single). “Action” can be removed from AB and nothing would be lost.
1 Like
That is a very interesting thought process - and I agree, from this perspective it is much more feasible to just prevent the creation of a new note in the AB.
However, if we treat the AB as variant of an agent (with a slightly different design), having the ability to deploy action code in it seems to me like a great addition with little risks, or am I mistaken? Stamps are great if one is dealing with perhaps 20 notes in the AB. As soon as there are several hundred notes having some option to automatize the application of action code would speed up the process quite a bit. An example coming to mind is the addition of tags, codes etc. (I know, one could use a regular agent to do this. Yet, this would involve several more steps. Especially so, if one would like to repeat the process with another change.)
I agree. Obviously I don’t know the potential complexities involved in tuning AB to allow multiple selections. I assume that would be less complex that either (a) allowing new-note creation within AB, or (b) empowering full-scale Action code inside AB.
If that assumption is right, then I think there would be a lot of payoff, for a (comparatively?) smaller coding cost, in simply allowing multiple selections in the AB. In combination with (especially) Stamps, that would match much of the functionality of normal Action code in the AB.
(How? The Query part of a certain AB display could be as sophisticated and precise as a normal Agent – and then applying a Stamp to the results would have the same effect.)
FWIW.
1 Like
Did we ever get an answer to this? I’m working on something where AB’s action comes in super useful – I want to view my list of notes that match certain criteria, while creating new notes that will automatically join that list. So, AB and its action are perfect for this.
But I don’t see any way to actually create a note!