Selecting Map- or Outline view. Cannot change the size of Map or Text pane. Moving the size bar works but as soon as I let go it jumps back to its first position.
Using Tinderbox version 11.0.0 (b733) on macOS 26.0
Selecting Map- or Outline view. Cannot change the size of Map or Text pane. Moving the size bar works but as soon as I let go it jumps back to its first position.
Using Tinderbox version 11.0.0 (b733) on macOS 26.0
I have encountered the same issue. Canāt reliably reproduce it. A restart of the app helps.
Seems to be an initialization issue. After some fiddling with sizing window and changing the pane-size selector it started to work. Further it works so well that I“m unable to get back to failing mode, even after a computer reboot.
If convenient, please email a document which has this odd behavior to bernstein@eastgate.com, or upload it here.
Cannot do that, problem vanished once I got it to work for one file. I have tried to get back to a situation I originally reported, but Iām unable to do it. I have tried Tinderbox 10 (working), Tinderbox 11 (now working), rebooting, but I cannot get the behavior back.
I also experience this periodically. The text pane is suddenly at the halfway point in the document window. When selecting the left hand side, Iāll see a blue outline of what the left side should be thatās visible for a moment, and then it goes away. Moving the slider bar to change the size of the right hand text pane results in it snapping back to the halfway mark as soon as itās released. Closing and reopening the document āfixesā it, and it seems completely random as to when it happens. Iām currently on Tinderbox 11.
I had also seen this a few times but it was not reproducible. But I had a new situation with MacOS Tahoe and Tinderbox 11. In addition, a few crashes of Tinderbox, which were probably caused by MacOS Tahoe (Support Eastgate)
I saw one instance of this is a new, unsaved, TBX. It appeared the Text pane refused to go smaller, rather than the view pane. Showing the rules in the text area, it was apparent that the Text pane refused to go less wide that the width of the ruler, i.e. to the right margin (wrap point?) marker, a down pointing triangle like that shown below (N.B. this is not from the problem file):
Normally, if the text pane width decreases, the above-shown right marker moves to reflect the new width. In the misbehaving TBX, this didnāt happen and the āstuckā tight marker āpushedā the text pane width back out so the whole ruler width showed.
After something (tab swap?) the stuck effect disappeared and Iāve not see the issue since nor can i trigger it on demand. As the fault self-cleared, I wonder if it is possibly related to initialisation of the ruler (does it need to be showing?) in the text space.
HTH.
Just installed 11.0.1 and I got the jumping back.
Procedure:
I include a file that has this issue, but I have no idea what will happen when used on another macOS system.
Jump-back.tbx (121.1 KB)
Here is a way to get the jumping separator.
Install Tinderbox from a .dmg. Start the fresh installation. Move the separator. Note that it behaves correctly. Grab a window-corner and enlarge window. Grab separator and move it, let go and it jumps back.
The above is repeatable and I have it happen on both my iMac(26.0.1) and Macbook(26.1 Pub beta).
As soon as Tinderbox jumps back to expected functionality regarding the separator (I have not found a repeatable pattern for what causes this) I have not been able to get it to fail again.
Doing the above with a new TBX, and with no notes added, I cannot reproduce this.
Note that I am using Tinderbox v11.0.1b737 (current release) on macOS 15.7.1 (updated last night). One possible difference, is that Iām still using macOS Sequoia (15)ā and not the latest macOS Tahoe (26) so that could be a factor.
ā . I normally wait for the first round of OS bugfixed before changing major OS version.
Yes, I also believe its a Tahoe thing.
Tried Tinderbox on macOS 12.7.6, works OK.
Not a Tahoe thing. Same behaviour with Sequoia.
Please send an example to bernstein@eastgate.com; despite many, many hours of effort, we have not been able to reproduce.
I outlined a method above using a new Tinderbox installation (starting from the .dmg file). This is fully repeatable on my two systems. Are you saying that you cannot repeat the behavior on your side.
Noted that it appears at present) to be a Tahoe (macOS 26.x) issue, and an initialisation issue. Unless I hit a separate issue in Sequoia (macOS 15.x)āsee here upthread, the reproduction steps (here) have some ambiguity.
I donāt have access to a Tahoe Mac ATM but it is not clear whether the effect requires that no notehas yet been created or whether it occurs with/without at note(s) present. It is possible the note(s) are immaterial, but the issue I encountered (linked above) pointed to the text window ruler (whether visible or hidden) acquiring a fixed width and until other activity like a doc re-open cleared it, the āstuckā text pane width seemed to be what was causing the observed effect. IOW, the text pane (at the time of the issue) desired to be a fixed width: any splitter drag re-set the tab so that the text pane width remained unchanged. Iāve no idea if a new TBX with no notes haveāor should haveāa prededined ruler width.
Not just Tahoe. I definitely have the very same issue at completely random seeming points on Sequoia. Closing the document and the application and then restarting the app and reopening the document eliminates the issue, until it recurs. I have absolutely no idea how to make it happen predictably.
FWIW, Iāve had this issue, too, on Sequoia intermittently. Unfortunately, I cannot consistently reproduce it.
@fintelkai, @JacobIO . To help pin this down for the developer, is your cases does this issue happen in existing documents with content, or only with new documents? Also does it occur at the start of using a document or in a session?
I ask only as currently, the issue seems to relate to use of a new document and/or at the start of a session, i.e. when a document is opened. If you are seeing in it other contexts that widens the search a bit. Hopefully by comparing users reports we can get to the point where it can be repeatably triggered and on more than one Mac, to help focus on a possible cause.
For anyone else reporting this, please report if you can on the following facts:
⢠(Added: MB) what rulers, filter bars, find bars, etc. were currently in use, or had been used earlier in the session