I didn’t make myself sufficiently clear when I talked about my use of the key attributes. The scenario I had in mind is the following. For my work, I need to be able to use a set of specific keywords to identify the different notes so that I am able to find the relevant information quickly and precisely. So having a quick way to introduce a new keyword while I’m working on a particular note would be helpful. With other apps I use Keyboard Maestro to do similar things. Keyboard Maestro allows you to call pretty complex macros with a simple keystroke combination but for the reasons I explained it was difficult to use it with TB.
What I wanted to do was to create a macro that automatically inserted a new keyword term as a key attribute in the note that I’m currently working on but because doing this involves having to click on various places with the mouse (on the ‘+’ sign and on the key attribute field), I wasn’t able to do it.
Sorry, I realize I must have confused a lot of you with my messages. I just realized that I have been talking about the keyword key attribute as if this is something everybody should be familiar with. It turns out that this is a key attribute that does not exist in TB but rather a user attribute that I had created myself a while back so that I could identify a note with a collection of labels or keywords.
This is very useful when you are looking for information and you don’t remember the name of the note where you stored it. Maybe now there is already a built in key attribute that does this but at the time there wasn’t any so I decided to create one myself.
A good tip is that when referring to an attribute name, a general tradition in this forum to write ‘$Keywords’ to indicate you are referring to a an attribute called Keywords. The two tees do indeed in mean different things as Tinderbox action code but as a textual reference it is very useful to indicate you are talking about an attribute name hat that might otherwise be confused with ordinary text. Thus, had you referred to ‘$Keywords’ , season users would realise you were explicitly talking about an attribute named ‘Keywords’ and which not being a built-in attribute must be a user attribute.
In my ‘moderator’ hat I will, at risk of sounding like a cracked record, point out that Tinderbox is a toolbox and not a one-task utility. Thus, it is a fallacy to assume that how i. use Tinderbox is how others, or more to the point a majority of other uses, work with the app. Once you accept this, some oddities in functionality seem less egregious.
As a long-term user (who doesn’t touch-type and probably never will) and beta-tester I happily test keyboard-only features I will never fully use. Optimising for a single sub-group of users generally disadvantages others.
I does seem that a number of your peeves are best addressed with making your own custom shortcuts (using the likes of Keyboard Maestro) rather than forcing engineering changes, e.g. menu alterations, that help you but perhaps not others. This is a big community with surprisingly diverse styles of use - I’ve long since given up the pretence of imagining ‘typical’ use.
In summary:
I appreciate cost may be an upgrade issue. But if just a case of if-it-works-don’t-update I strongly
suggest updating to v7 as there are many useful improvements that have nothing to do with the headline new features.
Don’t assume we all use the app the same way - be that in style of input (keyboard-only vs mixed keyboard/mouse), the attributes we use, the aspects of the app we use, or whether or not we use automation.
If you need a feature, suggest it. Ideally by direct direct to Eastgate rather than here to avoid opinion-shopping. If you look at the app’s genesis over some 17 years it will be apparent that the developer is very responsive to well-reasoned user suggestions.
Given some things you weren’t aware of, do take a wander through aTbRef. Disclaimer - I write it. That said it it’s heavily inter-linked hypertext. If it lacks an index it’s because there is no one way to structure the data. Just keep following links!
This a bit of a glass-half-empty take on things. There has been plenty of polish to other views. as I tend to work at scale, my use is generally outline based. However, I strongly support Map view being the default. I may working Outline view due to volume of notes but I still think in map view terms.
Tinderbox is a toolbox. Few other than beta-testers will try/use every function. it is totally possible to use just one view for your personal work. However, it also pays to understand there are others who use the app as hard but in different aspects. ‘Simple’ suggestions to 'just ’ fix one style of work can totally derail another. The best changes are those that are mindful of effects on other styles of use.
Please don’t read any of this as a negative response to your posts, that is far from my intent. I’m simply laying bare that in a toolbox app there is no one ‘right’ way or style that suits _all- users.
To add onto what @mwra says, so much has been added to the program in the past 2+ years, and so many of its features are customizable, that I think you’re [@jfontana] doing yourself a disservice by relying on an old version (and being concerned by things it appears not to do).
My experience is:
You can set up keyboard shortcuts for the vast majority of the routine functions you rely on, via either the MacOS System Preferences menu, or an app like Keyboard Maestro. I am very strongly anti-mouse, and I can do most of what I want by keyboard only.
The main functional improvements have been in areas other than mapping, in particular in the indispensable “Attribute Browser,” in which I do 3/4ths of all my work. (Eg How to use the Attribute Browser )
Since I use this program all day long, on my working days, the upgrade costs are completely worth it. FWIW.
OK, thanks to everybody who replied and thanks for your patience. Your comments convinced me I ought to have a serious look at the new version. I downloaded the trial version and I have been working with copies of my documents to check on some of the new features. You are totally right. There are quite a few pretty interesting and useful improvements that I had not been aware of. I have now placed my order and I’m waiting for the registration codes to start working with the new version.
One of the things that I also wanted to support was the friendly and helpful community around the TB project. Your tips on how to solve my problems have been very helpful and showed that I was misguided in some of what I considered to be problems in the interface.
I still think that Mark had not understood what I meant in some of my comments (or most likely, I did not express myself clearly). I was not really requesting the introduction of new features or to make major changes to satisfy my personal needs but rather to make the access to existing features easier to users like me without affecting the way other users do what they do now. I might be wrong but I think that being also able to create a new key attribute without necessarily having to click the ‘+’ button with the mouse would not make things worse for anybody while it might create new possibilities to do things with this amazing toolbox.
Anyway, my next posts will certainly be questions about things I would like to do with Tinderbox 7 :-).
I enjoy reading about everyone’s use of Tinderbox and there is never a reason to apologize for using the program the way you see fit or wanting betterment. I’d hazard on good evidence that every longer-term or frequent writer on this forum has requested features that at first blush might have seemed outré edge cases with little utility for the average user – and then Mark B. grabbed onto the idea and made it an interesting new feature.
The beauty of Tinderbox is that the owner is an artisanal hacker – in the best sense – and never satisfied with the status quo. Keep those ideas flowing – explanation is useful, but justification is never needed.
Re the ‘+’ button & visualisation and looking at the [existing map] of Tinderbox shortcuts(Reverse Look-up Map) (and I suspect even this is incomplete for some OS/system-wide shortcuts), what would you propose as a new shortcut?
Whilst it’s nice to have everything you want baked-in to an app, I think Keyboard Maestro+custom shortcuts might be an easier way to access, for instance, all the different highlight options.
This is my experience with what I view as the indispensable Tinderbox tool, the sainted Attribute Browser. Along with some other people, I had been agitating for some function of this sort, starting roughly a decade ago. (My argument was derived from some features of the old MS-DOS marvel Lotus Agenda, and then the Windows program Zoot.) Artisanal-style, the program kept evolving, and the AB came into being and has kept being refined.
Mark, the problem is that the fact that you need to click on a button with the mouse to access a function makes it hard to do this with Keyboard Maestro. The highlight options are actually easy to get to using Keyboard Maestro because they are part of a menu and Keyboard Maestro can record the steps you take going through a menu rather easily. Recording what you do with the mouse can get quite a bit more tricky and prone to errors, though.
Just for clarification, almost all the shortcuts that @mwra lists in the reverse-lookup table are bonafide keyboard-only shortcuts, with no need for the mouse (which I too avoid as much as possible). Which specific functions are you running into that are mouse-only? I know there are some, but I’ve worked my way around most of them that I run into. FWIW
OK, in the list of shortcuts that @mwra provided, as far as I can see, there is none for ‘Add key attributes’, which is what you do by clicking on the ‘+’ button. What I was aiming to get is a faster way to add specific key attributes for the particular note I’m working on at a given time.
I have various user attributes I have created that allow me to introduce metadata in my notes in a very similar way to what I see you do (Eg your link to ‘How to use the Attribute Browser’ ). So, I wanted to create macros that introduced the desired values for specific key attributes without having to use the mouse. Many times I really don’t know what particular key attributes I’m going to use in a note. The need for one or the other emerges as the note acquires its content and I analyze it.
As I’m writing or after I paste content from some source, I decide this note is related to a particular subject matter or it belongs to a particular class of notes in a classification that I have created, or whatever. My metadata for notes can be quite rich and so it is rather cumbersome to have to use the mouse, find the particular type of key attribute I need, introduce the value and then go back to writing on the note at the point where I left it.
The beauty of KM is that all this can be automatized and associated to a single keyboard shortcut. Alas, some things are a lot harder to record or program than others and clicking on this ‘+’ button is proving to be a bit of a challenge for KM.
As I said in the other message it works better with some things than with others. Basically KM has a harder time with anything that involves recording movements with the mouse and clicking on a small button because that requires encoding specific space coordinates relative to the measures of the app window. Since the window size and shape can change and the screens of different computers vary in different ways, this makes these kinds of macros a bit harder to develop and to get to work.
For me it was a pretty laborious process to get it to work in one of my computers but when I tried to adapt the macro for my laptop it fails.
Using UIBrowser v2.7.0, this AppleScript will click the KA ‘+’ button in the (front if several) window if Tinderbox - testing in AppleScript Debugger v.7.0.3 on Tinderbox v7.5.4:
activate application "Tinderbox 7"
tell application "System Events"
tell process "Tinderbox"
click button "+" of group 1 of splitter group 1 of front window
end tell
end tell
OK, I’m not very familiar with KM, but did manage to add the above to a KM action and get the same result. Perhaps someone better versed in KM use can add the most suitable KM macro configuration for using the above script via a custom shortcut.
Great! Thanks @mwra! I’m definitely getting there! I used KM to test whether it would work with the script you posted and it does. So, here is what I got:
If you notice, right after executing the script which clicks on the “+” button, KM inserts the name of the particular key attribute I’m interested in and that allows TB to select that particular attribute for which I want to introduce the value.
But here comes the next part of the problem for which now I see there can be a satisfactory solution (I still don’t know which one, though). The next screenshot shows the state of TB after executing the KM macro above. What needs to happen next is that the cursor has to be placed in the field where the specific value of the key attribute has to be written so that KM can introduce it there. The problem is that in order to do that, you need to use the mouse again. Unless, of course, that can be done using a similar script to the one you posted or via a keyboard shortcut.
Getting to this stage is already pretty helpful because it saves me quite a few steps. As I said, my goal is, however, to automatize the introduction of a selection of values for different key attributes that I use frequently by building different little macros that that will carry out the whole process automatically and quickly return me to the exact spot in the text of the note where I was working. This would be a huge improvement in productivity for me given my particular use of TB and it saves me from constant distractions. If I’m too busy and pressed for time, I usually tend not to introduce metadata (via key attributes) in my notes because in those particular times the process feels too cumbersome and distracting. Later I regret not having devoted enough time and effort to introduce the necessary tags because it becomes more difficult to locate the notes I’m looking for.
So, now, I would only need to find out how to do via script (or keyboard shortcut) the equivalent of introducing the cursor in the key attribute field and the equivalent of introducing the cursor in the main text field of the note. The rest (typing the specific values in the relevant fields and going back to the specific point in the text of the note where I was) can easily be done by KM.
This seems like an awful lot of work. I don’t understand why you need to manually add the same attribute ($KeyWords) over and over to your notes?
Isn’t it simpler to create a prototype whose sole key attribute is $KeyWords. Or to put $KeyWords at the top of the prototype’s KA list. Then create notes in a container whose OnAdd action is $Prototype='myPrototype'. Finally when you have created a note in that container then option tab (⌥⇥) to switch from the Outline to the Text pane. Option tab (⌥⇥) again to highlight the first attributed in the KA list (which will be $KeyWords because of the prototype that the OnAdd action assigned). Then press return and start typing the values of into $KeyWords.
No criticism intended here, but fiddling with scripts and KM etc., seems to be about creating mouse-avoidance automation to replace what Tinderbox already does.
(I’m using here Tinderbox 7.5.4 which is the most recent public release of the software.)
Good. The KA table is rendered from a Set-type attribute $KeyAttributes. Note: a Set not a List as Sets automatically de-dupe inputs. So we need to iterate the list of attribute names in column 1 of the KA table…
First, whilst the code below does work - sort of, at least for Boolean attributes, it is based on inspection of the Tinderbox UI with external rules. If, for whatever reason, ongoing changes to app mean the KA table is significantly re-coded then don’t be surprised if this approach
set myInput to "Opacity"
set myValue to "50"
set myInput2 to "NeverComposite"
set myValue2 to "0"
activate application "Tinderbox 7"
tell application "System Events"
tell process "Tinderbox"
tell table 1 of scroll area 1 of group 1 of splitter group 1 of front window
set elemList to every row
repeat with elem in elemList
--all attribute types except Boolean
if name of static text 1 of UI element 1 of elem is equal to myInput then
select static text 1 of UI element 1 of elem
set value of text field 1 of UI element 2 of elem to myValue
keystroke return
end if
-- Boolean data type
if name of static text 1 of UI element 1 of elem is equal to myInput2 then
if value of checkbox 1 of UI element 2 of elem is not equal to myValue2 then
click checkbox 1 of UI element 2 of elem
end if
end if
end repeat
end tell
end tell
end tell
What you’ll find it you run this (with the relevant attributes set as KAs) is the the Boolean setting does stick but the value for string/Number-based attributes resets to the pre-existing value. Go figure…
So a bit more to do. I do rather agree with @PaulWalters. In the time spent banging my head against the innards of AppleScript I found myself also thinking that prototypes would make most of this go away.
Before it’s asked, selecting a KA element so as to show and then access its pre-existing value list is likely an exercise in futility, but I’m happy to be proved wrong.
This is more or less my workflow, too. Especially when I’m creating notes on which I want to do a lot of “tagging”-type activity. (EG, when I’m categorizing research notes, and for an attribute like $Themes I want to add a number of values, like “China” or “Climate” or something.)
The crucial convenience factors, to re-emphasize, are: creating these notes in a container with the right on-add action to set the prototype ( eg $Prototype='myPrototype') and having the relevant Key Attribute up near the top of the list, so you can tab right over to it.
That is, a prototype can do a whole lot of the work of a script or macro, at least for me. (Meanwhile, admiring the scripts that have been offered here.)
