Rattling Scroll Bars

I’ve searched the forum for mention of scroll bar issues but could only find ones that give away Steve Revill’s involvement in the design of Mac OS ‘Lion’ in 2007. :-)

Am I the only one that has scroll bars that don’t always travel the length of their wells(?)? That is, the wells are too long/bars too short though you can scroll the document in its entirety. Must have been mentioned but I can’t find it. OS 5.17 BB xm revC.

[later] This seems to be an issue limited to Edit?

Eh? I don’t have a very good memory but I don’t remember having anything to do with Mac OS… :)

I was reading posts of yours from 2007 describing how you might like scroll bars to be. I was quick scanning but it read as a description of iPhone bars now adopted in Lion.

[later] This seems to be an issue limited to Edit?

Edit’s had dodgy scrollbars forever (or at least as far back as RISC OS 3, when I first used it). Maybe it’s about time we fixed it. Fixing the redraw bugs would be nice as well (unless those have all been fixed now – I generally avoid Edit like the plague)

Edit’s had dodgy scrollbars forever

Not just me then.

Fixing the redraw bugs would be nice as well

Unfortunately the version of Zap that runs on the BB (v1.48) seems to have really bad redraw problems, the reason why I didn’t update past 1.45 on my Risc PC.

I can’t remember Edit ever not suffering from this problem. Yeah, seriously, it’s about time it was fixed.

Unfortunately the version of Zap that runs on the BB (v1.48) seems to have really bad redraw problems

The version I’m using on my BB and BBxM doesn’t seem to have any redraw problems in text, BASIC or C modes. Do you have all the latest updates? (Sorry, I can’t remember where to find a link – but the information came from these fora.)

It’s version 1.48 (16 Sep 2011) tnk-7, I think from an announcement here. On scrolling or enlarging the window, there’s often a residual block of text which mismatches new text where the window boundaries were previously.

I noticed a few redraw problems too, probably with v. 1.48.

residual block of text which mismatches new text where the window boundaries were previously

Sounds like that!

OK, can I suggest that you guys invest a little effort to create a simple test case that Tank can use to see if he can locate and fix the problem(s).

!Edit does seem pretty useless; if I ever double-click on a file when no editor is loaded and Edit is the default editor, it simply crashes immediately. I have to admit that I haven’t updated the standard apps in a very long time. I should. (But, thanks to TalkTalk’s incompetence, I haven’t had Internet at home these last four days, and there is no sign that they are bothering to do anything about it; so I have no idea when I’ll be back on line from home.)

!Edit, just to be contrary, doesn’t give me problems with redrawing. I’ve made an image of the Zap problem, if that would help, but don’t have anywhere to post it.
All I’ve done is to load the GNU General Public Licence from the ROOL distro and scroll the content up and down, left and right. Simple as that.
Covering and removing with another window has the same effect.

Are you running in a 32K colour screen mode by any chance? There are definitely artifacts in such modes. Not present in 256 or 16M colour modes. I haven’t noticed any other redraw probs on my system.

With the BB xM I’m in 1024×768 16M, the Risc PC is at 1024×768 32K.

Do you get problems on both those setups? Also, are you sure the most recent ZapRedraw module is being used? What does *Modules give for ZapRedraw version?

I can’t remember Edit ever not suffering from this problem. Yeah, seriously, it’s about time it was fixed.

I think to fix something it needs to be broken, which is merely semantics. Edit’s scrollbars are totally logical when you know what the intent was: the vertical position of the bar bit within the well is how far you are through the file, and the size of the bar bit is (in some way) proportional to how much the stuff in the current view is of the total file.

This does mean the bar bit keeps changing size as you scroll through a file of course.

I think the rest of the world has gone in a different direction with proportional scroll bars and the Edit is now the odd one out, but it’s not broken – just different.

Do you get problems on both those setups? Also, are you sure the most recent ZapRedraw module is being used? What does *Modules give for ZapRedraw version?

I don’t get the problem with the Risc PC because I stopped upgrading to avoid the problem. On the BB xM the ZapRedraw module is 0.48 (07 Apr 2010).

Frederick, could you email me the screenshot of the problem? w dot blatchley AT yahoo dot com. If you don’t mind, I’ll upload it somewhere and link to it here so we can all see what we’re talking about.

The image I sent you shows the result of horizontal scroll. Vertical scrolling does the same on the other two boundaries and if I want really pretty patterns I can swipe another window over the Zap one.

I’ve posted Frederick’s screenshot in the “Rebuilding software for Beagleboard” thread here.

Now this thread can get back to rattling about scroll bars.

the size of the bar bit is (in some way) proportional to how much the stuff in the current view is of the total file.

This does mean the bar bit keeps changing size as you scroll through a file of course.

Does that mean it works on visible number of chars rather than number of lines?