I’m spending too much time in outline view. Not a problem, glad it’s there, I’m finding it a great aid to writing.
A request, however, which may have impact elsewhere. I’d like to be able to reduce the width of the ‘View’ pane while I’m writing in the ‘Text’ pane. Sometimes I’m looking at a huge amount of dead space in ‘View’ that I’d much rather allocate to ‘Text’, but when I grab and slide the separator to the left, it snaps back to a minimum ratio.
Some of this may be due to being on a decrepit old mac with what was once an amazingly high-resolution screen, and some may be to do with views (such as ‘Map’) where small viewports induce some other form of visual delerium, but if it would be at all possible to loosen this up, I’d be hugely grateful. I can see the layout engine handles it as I drag the separator horizontally, and reflows the layout without an issue, only to decide it knows better when I let go!
Well, squeezing it to invisiblity reduces its utility somewhat. Resizing the window doesn’t seem to have any effect on its minimum size, so it’s not a proportional limitation, it seems to be a fixed limit of some other measure. I wondered if having columns made any difference - it did not, whether I toggled them on or off or deleted all the columns individually. Though I did not reboot, I have seen the same behaviour on previous reboots.
I notice separators in the ‘view’ pane remain at the width set manually, and don’t snap back to full size when the UI seperator between panes is released - they do so when the window is resized, though. I don’t think this is part of the issue.
I’m stuck on 11.7.10 for macOS and 9.7.2 Tinderbox. I think this is something baked into Tinderbox itself, unless it’s symptomatic of a weird combination of ancient OS and latest TB.
Checking Using the pane splitter, I’d expect dragging the window to move the splitter bar to maintain the ratio, but clearly at some point that behaviour changed. I can’t find a release note stating that as deliberate change so I guess it might be an intention effect. So currently, when resizing a document window, the extra/lessened pace is all added to the text pane (tight of the splitter bar).
Using v9.7.2 on macOS 13.6.6, I have no limitation on the narrowness of the view pane. For instance,
I’ve also checked that using Outline+column view isn’t an issue.
When I drag the splitter bar, any separators re-size, wrapping their titles (if any) when necessary.
Can you upload test TBX that shows the problem consistently in your Tinderbox?
Whilst 9.7.x supports macOS 11.x+, I do note your are using on macOS 11.7.0 and it might be that changes to underlying Apple frameworks might be a factor. A first step is trying to replicate the problem on a Mac other than yours (thus the suggestion above of a test doc created on your Mac).
There were legacy v60-only attribute relating to the splitter: TextPaneRatio and TextPaneWidth. It might be worth checking your document for local values of that. My rationale, although my understanding is these attributes aren’t in v7+, i’m wondering if an old TBX with any local (note rather than doc) value for those attribute might cause some confusion, but this is clutching at straws.
I didn’t suggest that for your issue. I described the range of options. “to entirely cover the left-side view of the outline, or drag it to a very narrow width”.
Great to hear, thanks @eastgate for confirming I will get some more life out of this old dog machine yet!
@PaulWalters Apologies if I came over snarky, that wasn’t my intention. I realise you put a great deal of work in here heading off future enquiries as much as responding to current ones!
And thanks @mwra for your test document. It all seems to be a mix of legacy issues that are otherwise resolved, but for sake of follow-up, I recreated your example but still got the anomolous behaviour I described earlier. Screenshot attached, you can see the rendering of ‘ddd’ clips to where the divider would go to, before it sprung back.
For anyone reading now who’s in the Backstage program, this view splitter issue is already fixed in the latest beta (actually fixed in build b666 just after v9.7.2b665!).
For everyone else, it will be fixed in the next public release (v9.7.3?).
