Hi all,
One of Tinderbox’s behaviors that drives me up the wall is its automatic deletion of notes in outline view that have a $Name of “untitled”. Is there a way to disable this?
Thanks!
1 Like
FWIW, this has been the designed behaviour since v6.0.0b23 though I’m unclear as to the underlying assumptions and why Outline is special in this regard. As this is designed behaviour (writing as at v7.1.0) I don’t think the user can alter this behaviour.
IIRC, the behavior was added because of complaints that outlines were being cluttered by “untitled” notes.
That’s my recollection too. It was an auto-cleanup measure.
After you create a note in outline view, the name of the note is automatically opened for editing. Simply type something for the name to replace “untitled”.
Other Tinderbox users found that, notes being so easy to create, they sometimes created notes accidentally. This behavior, which has a number of tricky edge cases that were quite difficult to make correct, makes it very easy to discard such accidents.
1 Like
Hmm, it looks like I was running into a bug in which a newly created note in outline mode would be deleted when I hit tab or ⌘] to indent it. This was the most frustrating instance of this behavior. I see this doesn’t happen on newly created documents, so I’ll try to figure out when it does happen and submit a report to Eastgate.
As a side note, this seems like the kind of thing it would be easy to provide an option for in Tinderbox’s preferences. But the Tinderbox design ethic seems to generally avoid such preferences. Is this true, and does anyone know why?
Thanks!
Modern software strives to limit the proliferation of “preferences” for different user interface choices. Preferences, most designers now believe, should be reserved for those situations where distinct audiences are in fact best served by distinct settings.
For example, making font sizes reconfigurable can facilitate the use of a program by visually-impaired people. You will have noticed that many contemporary programs have a very modest array of preferences; Pages has three panes, Numbers has the same three, Transmit 5 has a bunch of very small panes, few of which pertain to the user interface. Acorn 6 has 5 preference panes, but these include “advanced”, “fussy stuff”, and “registration”.
In addition to the cost of maintaining Preferences (and their panes) and the cost of documenting them, Preferences increase the complexity of the underlying code. That complexity, in turn, makes future improvements more difficult, and tends to impede refactoring.
The counter-argument here is, in my view, Richard Stallman’s landmark work on EMACS as a reconstructible user interface. Here, however, we again see the pattern of distinct audiences best served by distinct settings – in this case, people who were trained in vi commands vs. those who were migrants from TECO.
The behavior you report is not a bug. You can achieve the effect you want in two ways:
- Create the note. Name it. Press [tab] to indent it.
- Create a child note (press ⇧-Return). Name the note.
Method #1 uses the same number of keystrokes as your method, in a different sequence. Method #2 uses one fewer keystroke, but might be a bit harder to remember.
2 Likes
Very interesting — thank you, Mark!
Yes it is.
The bug is not the design choice you have made. The bug is the inconsistency of behavior that I’m seeing between documents.
When you create a new note in outline mode, focus is on the note’s name. If focus leaves while the note’s name is “untitled” the note is removed. Fine. However, sometimes indenting with tab removes focus from the note’s name and the note is deleted. Sometimes indenting with tab keeps focus on the note’s name and the user still has the chance to rename the note. (And sometimes hitting tab has no effect, and you must use ⌘] for some reason — I have sent you a bug report about this.)
I will try to hunt down these inconsistencies and send in some further reports.
I’ve never seen Tab not work to indent a note in Outline view. I wonder if some other app or process is grabbing the input? I can’t replicate Tab causing focus loss but I’m a slow [sic] typist. I wonder if this is a speed-of-input issue that’s causing the issue.
Hi Mark,
In the attached file, there are two notes in outline mode. If you double click on the lower note so that you are actually editing its name, and then hit tab, the lower note will not indent. Hitting ⌘] will indent the note when you are editing its name, however.
I don’t see this behavior with newly created documents, so there is some funny state in this document that is causing this issue.
As I said, I’ve reported this to Eastgate.
Best,
Galen
test.tbx (58.9 KB)
Well that’s weird. I can confirm the behaviour in the file you posted. I can’t replicate the same on files on my system (MBAir 2013, macOS 10.12.6, v7.1.0). I’ve tried both new (unsaved) and existing files here and they don’t behave like your test file. Most odd. I can’t see any obvious differences in the prefs in XML either.
Yes, I’m not able to recreate it in a new document. I noticed the behavior in a document I was working with, and found that it persisted even after I had deleted all notes in the document. And the behavior doesn’t occur in the template document that I use as the basis of all my TBX docs. So I don’t know what’s going on…
1 Like
This particular outline view is set up to use columns, but has only one column.
In outline view when using columns, pressing tab while editing a value tabs to the next column. In this case, there is no next column.
1 Like
Ah, that makes sense. Thanks for the quick diagnosis!
Just a quick update to this topic: This behavior usually bites me when I am in outline view adding many notes to the same parent container. In that case, it’s easily remedied by adding this to the parent container’s $OnAdd action (settable via the “Action” tab of the Action Inspector):
if ($Name == "untitled") { $Name = "temp name" }
2 Likes
Very useful! Thanks.
I used this and followed your video (I used Shift+Return for the new child) and the action works fine - the note is called temp name.
But, if I add the container action and don’t press Return to explicitly save the action but then do the test, I can re-create the conditions in the video above. It fails a despite the code seen in Inspector it isn’t (yet) the actual saved $OnAdd code. Not saying that has to be the only cause of this but HTH.
If I had watched my own video and saw I had put the code in Rule and not Action I would have succeeded. The code is working over here 
2 Likes