A Few Reasons to Add Trash Cans, Precautionary Capabilities

  1. The notes in the Chinese input state are lost
    Recently, I was writing on a map. I wrote about 1000 words in the text window of a note. I used the Chinese input method. When I was resting, I left the macbook and the macbook went into sleep mode.
    I use Baidu Wubi input method to input Chinese.
    Afterwards, I go back to my macbook and wake up the screen. I saw that the input method has some Chinese content, which is roughly similar to the picture below. However, I pressed the Esc key to try to cancel the input or click the mouse elsewhere. At the same time, this note disappeared and disappeared.
    I press command+z to undo, but I can’t undo it.

  2. Cannot undo, retrieve lost notes
    After the accident of the previous Chinese input method caused the note to be lost or accidentally deleted (it needs to be specially explained, I did not press the delete button), anyway, this note was lost due to an unexpected bug.
    I pressed command+z repeatedly and couldn’t get back what I lost.
    It is worth mentioning that the undo of command+z is very stable in ithoughts, and in most cases, it can restore accidentally deleted notes infinitely.

  3. The unexpected crash of the new version
    Tinderbox 9.5.1, more frequently than earlier versions, unexpectedly crashes, the program will exit, and notes will be lost accordingly.

  4. The crash of importing too large opml
    When I try to import a large opml file, tinderbox will fall into a state of suspended animation, which will last for a long time, and even cause the program to exit in severe cases.

Among the above four reasons, the instability of tinderbox itself and possible conflicts with other programs will lead to the loss of notes.

I think tinderbox should add a preventive design, that is, a trash can, or version control, so that users can easily retrieve lost content.

I also mentioned the design of the trash can in an earlier post. Other users suggested regular backups. This kind of regular backup is preventive, but this preventive work must be done manually by the user.

Scrivener also has preventive design, trash can and backup options, and a copy will be automatically backed up when exiting scrivener. With this preventive design, my sense of security is guaranteed when I use scrivener.

But in tinderbox, I often feel uneasy about losing notes. This happened not once or twice, but many times.

I think tinderbox should add a precautionary design:

  1. Enhance the ability of unlimited undo. Unexpectedly lost data should be able to roll back infinitely through command+z, but this ability is weak and insufficient.
  2. Increase the trash can. Accidentally lost, accidentally deleted data can be found in trash.
  3. Regular backup function. Automatically back up a tbx file by date when quitting tinderbox.

Respectfully, this should go to tech support tinderbox@eastgate.com. This is a user-to-user forum so we can’t do anything about this. Though @eastgate may post here, the convention of u-to-u forums is that doesn’t mean posting here is contacting support.

Note too, if you need support, contact support, you’ll get an answer quicker, especially for things like above that other users can’t do anything about.

1 Like

Tinderbox does this, both on quit and periodically through your work session.

I have not received a report of a lost note in seven or eight years. I certainly haven’t seen such a thing, and I’ve made quite a few notes!

By scrivener backup, I mean a copy produced at a specified time, such as the screenshot below, where Scrivener makes a copy based on the date

@mwra mentioned several times that I should contact tech support, email tinderbox@eastgate.com.

In the process of using tinderbox, I have various problems, such as learning, system customization, user experience, bug defects, and function improvement. There are many such problems, about 20 or so.

If the forum is a user-to-user communication, it is obvious that for bug defects and function improvement issues, technical support should be contacted by email.

For a long time, I have posted various questions directly on the community forums. I didn’t know that the tinderbox forum has this rule. Bug defects and function improvements should not be posted on the forum, but contact technical support.

However, I think this provision is very difficult. Because sometimes bugs and feature requests, other users have different solutions, I can still get advice and help from other users.

For example, the issue of data loss and security. A user on the forum suggested that I back up in time. I listened to this user and backed up manually every day. Now I am learning rsync and kopia cloud backup.

Although users can’t do anything about bug defects, feature requests, other users will encounter such problems, and they will provide a compromise solution that meets my needs.

Therefore, I think that mutual cooperation between users can still solve problems in a compromised way.

Users are not powerless when it comes to feature requests. When more users report a strong need for data security (feature request voting), this will affect the development priorities of product managers, or the necessity of incorporating them into development requirements.

Perfect, absolutely safe and reliable products do not exist, but the voices of criticism and praise can promote the evolution of tinderbox.

Today I lost another note in the map view, I think it should be my own problem, it may be a misoperation, accidental deletion, no matter what, I lost a note. In addition, I found that the undo function is more stable and reliable in the outliner view, but it is insufficient in the map view.

Loyal tinderbox user.

Submitting a Bug

I think the issue is not as much about reporting a “bug” in the forum but ensuring we’re all clear on the expectation as to who can fix it. Also, as you point out, sometimes a bug is not a bug but a feature. Other times a bug is a bug, but it takes a tremendous amount of context to reproduce. Tor example, I’ve reported several “bugs” in the past that turned out to be not bugs directly in TBX but were caused by my use of Pandoc and missteps I was making in my use between the two applications, pandoc and Tinderbox. Or, in your case here using working with unicode Chinese chartercets. In these contextual situations, it can be VERY difficult for the community to track it down.

More on the Trash Can

As for your “Trash Can” question, you can actually build your own trash can with Tinderbox. Rather than deleting a note, you can use action code to move a note to a $Container called “Trash Can.” Now, there are many things that you’ll want to think about before doing this, e.g., would you ever want to recover the note and put it back in place, for instance? Do you want the note to change color when it is moved to the trash can? How do you want to trigger this move, with a stamp or a boolean attribute? Do you want the name to be struck through our not? Do you want the note to remain searchable?

On the surface, the idea of a “trash can” sounds very simple, but as discussed above, there are so many considerations to keep in mind. So, exactly how would you like your trash can to work and when? Perhaps we can go back to a summarized review of all your requirements and then address them with an action code.

1 Like