Drag-scrolling

[PeterHolbrook]

Much to my surprise, I read that it is possible to "drag-scroll" the contents of a Finder window on OS 9 by pressing Command and, at the same time, "dragging" on an empty portion of the window contents. Unfortunately, I've been unable to do it.
Is this a known feature of OS 9? Does this feature need to be "enabled" somehow? Is there a reason why this feature won't work on SheepShaver? If it works for some of you, can you please give me a hint as to what I might be doing wrong?
Thanks!

[Ronald P. Regensburg]

This is new to me (Mac user since System 7), where did you read that? Sure it is not about a feature in a different (graphics) application or possibly about a utility that adds the feature to the Finder?

[PeterHolbrook]

This is new to me (Mac user since System 7), where did you read that? Sure it is not about a feature in a different (graphics) application or possibly about a utility that adds the feature to the Finder?

Open SheepShaver (OS 9.0.4). Press Command + ?. Mac Help will open. Enter drag-scrolling in the text box. Select the first choice presented. Read the information presented. It says: "You can scroll the contents of a window in the Finder without using the scroll bars.
"To scroll a window:
"Hold down the Command key and drag an empty area of the window."
That's all there is. I've read a discussion among several users, some of whom said it didn't work, whereas others said it did, but none of them were using SheepShaver. I wonder if it has ever worked, or, if it did, in which machines it worked. Maybe it's a Mac OS ROM thing?

[Ronald P. Regensburg]

Well, never too old to learn something new.

It does indeed work. First click and hold the mouse button, then push and hold the command-key and finally move the cursor to the edge of the window. It does not work if the command-key is held down before clicking and holding the mouse button.

[kelvin31415]

The SDL library used by SheepShaver eats command-clicks and option-clicks, turning them into right-clicks and middle-clicks of the emulated 3-button mouse.

I don't yet know why real right-clicks, or command-click-emulated right-clicks, don't actually seem to work in the hosted Mac OS. Of course, I only have Mac OS 8.6 to play with, and I don't remember whether it did anything with right-clicks.

You can disable this "feature" of the SDL library by setting the environment variable SDL_HAS3BUTTONMOUSE to any value. This tells it "hey, I have a real 3-button mouse, so leave my command and option-clicks alone".

This tidbit came in handy for me in the application MacMoney, where I had to do a command-click and found that the trick of clicking first, then holding down command, didn't work.

[PeterHolbrook]

Well, never too old to learn something new.

It does indeed work. First click and hold the mouse button, then push and hold the command-key and finally move the cursor to the edge of the window. It does not work if the command-key is held down before clicking and holding the mouse button.

OK, I can see now that it sort of works. In the couple of minutes that I've been trying your method (on 9.0.4 under SS), though, I've found this:
1. The place where you click and hold the left mouse button may be critical. In my experience, it is best if the click occurs away from an icon (in the icon view).
2. I don't see any sense in clicking and holding Command. The window will scroll without it.

Kelvin, thanks to the indications of rleatherwood on this forum, I've been able to successfully emulate a right-click (= ctrl+click) on 9.0.4 (under SS) using ControllerMate for OS X. Are you saying that setting SDL_HAS3BUTTONMOUSE, let's say, to 1, will restore normal behaviour to the Command button in 9.0.4?

Thanks to both of you.

[Ronald P. Regensburg]

1. The place where you click and hold the left mouse button may be critical. In my experience, it is best if the click occurs away from an icon (in the icon view).
2. I don't see any sense in clicking and holding Command. The window will scroll without it.

Hm, yes, you are right. It is in fact just selecting by drawing a marquee without including icons. So the command-drag scroll feature probably does not work in SheepShaver after all. Using the command-key with other keys works though, and the control-key works with a mouse-click to open contextual menus.

[Ronald P. Regensburg]

The SDL library used by SheepShaver eats command-clicks and option-clicks, turning them into right-clicks and middle-clicks of the emulated 3-button mouse.

Hm, why would SheepShaver emulate a 3-button mouse for a emulated machine that does not by itself use a 3-button mouse as such? Or does it? It never occurred to me that it does.

[kelvin31415]

Hm, why would SheepShaver emulate a 3-button mouse for a emulated machine that does not by itself use a 3-button mouse as such? Or does it?

The multi-button mouse is inherited from SDL and Basilisk II.

The emulated mouse is a 3-button ADB mouse, and I've traced the code all the way down to the level where clicking the right button on my mouse generates an ADB transaction that should tell the emulated Mac OS "button 2 was clicked". Mac OS seems to ignore it, but I don't have the tools at hand to delve into the Mac OS code itself, so I don't know why.

Perhaps the ROM or Mac OS that I'm using does not support multi-button mice, or perhaps I'd need to install a mouse driver.

I do know that ADB supports multi-button mice, however, so some ROM/OS/driver combination must permit use of them.

[kelvin31415]

Kelvin, thanks to the indications of rleatherwood on this forum, I've been able to successfully emulate a right-click (= ctrl+click) on 9.0.4 (under SS) using ControllerMate for OS X.

Thanks for that tip. As it happens, so far I haven't regretted not being able to right-click; my interest is in knowing, as a developer, why it doesn't work -- to see if I can fix it.

Are you saying that setting SDL_HAS3BUTTONMOUSE, let's say, to 1, will restore normal behaviour to the Command button in 9.0.4?

Yes, if that environment variable is present, command-clicks will be seen by the emulated Mac OS as command-clicks.

[PeterHolbrook]

if that environment variable is present, command-clicks will be seen by the emulated Mac OS as command-clicks.

I take it that environment variable doesn't go in the .sheepshaver_prefs file, but somewhere else. Is this a compile-time variable, or a run-time one? How do you set this variable?

[kelvin31415]

I take it that environment variable doesn't go in the .sheepshaver_prefs file, but somewhere else. Is this a compile-time variable, or a run-time one? How do you set this variable?

It is a run-time variable. Typically, environment variables are set in your command-line shell's startup file (.profile or equivalent). However, I assume that you're running SheepShaver in Mac OS X; in this case, setting environment variables for apps launched from the Finder requires a different technique. See http://developer.apple.com/qa/qa2001/qa1067.html for an explanation. The preference pane RCEnvironment provides an easy way to create and maintain the necessary file; you can get it at http://www.versiontracker.com/dyn/moreinfo/macosx/15073.

I might change my SheepShaver builds to always turn this environment variable on, since as far as I can tell, the behavior without it benefits nobody.

[PeterHolbrook]

It is a run-time variable.
...
I might change my SheepShaver builds to always turn this environment variable on, since as far as I can tell, the behavior without it benefits nobody.

Thank you for the tip. All the changes you've brought to SS go beyond the purely cosmetic and are causing this piece of abandonware to near perfection. It would be great if you somehow managed to achieve normal behaviour for the Command key (isn't Command supposed to work for multiple selections and for moving files or folders from one volume to another?) and for mice with three buttons.
A future project might involve fixing the jerky sound of some games and/or MIDI files. I guess that would involve finding out what on earth is wrong with QuickTime and why QuickTime 6.0.3 won't work decently on SS systems.
Giving up hope that an MMU can't be emulated, here's one more programmatic challenge for your abilities: Would it be possible to disable extended memory on 9.2.2 so that it can run on SheepShaver?

[yksoft1]

It is a run-time variable.
...
I might change my SheepShaver builds to always turn this environment variable on, since as far as I can tell, the behavior without it benefits nobody.

Thank you for the tip. All the changes you've brought to SS go beyond the purely cosmetic and are causing this piece of abandonware to near perfection. It would be great if you somehow managed to achieve normal behaviour for the Command key (isn't Command supposed to work for multiple selections and for moving files or folders from one volume to another?) and for mice with three buttons.
A future project might involve fixing the jerky sound of some games and/or MIDI files. I guess that would involve finding out what on earth is wrong with QuickTime and why QuickTime 6.0.3 won't work decently on SS systems.
Giving up hope that an MMU can't be emulated, here's one more programmatic challenge for your abilities: Would it be possible to disable extended memory on 9.2.2 so that it can run on SheepShaver?

The developers obviously did not find a way to override some keyboard-combinations of Mac OS X and Windows. so you cannot do cmd+shift+3 in Sheepshaver Mac or use the Option key (mapped to Windows key) in Windows without invoking the Start Menu.
QT's problem is probably in the QuickDraw and Sound Manager level and may need a complete rewrite to be solved.

[kelvin31415]

I take it that environment variable doesn't go in the .sheepshaver_prefs file, but somewhere else. Is this a compile-time variable, or a run-time one? How do you set this variable?

I might change my SheepShaver builds to always turn this environment variable on, since as far as I can tell, the behavior without it benefits nobody.

I have now done so, and my latest build incorporating this change has been announced here: http://www.emaculation.com/forum/viewto ... 7021#27021

If you have any feedback about this change or any other aspect of this SheepShaver build, please respond on that thread.

[kelvin31415]

It would be great if you somehow managed to achieve normal behaviour for the Command key (isn't Command supposed to work for multiple selections and for moving files or folders from one volume to another?) and for mice with three buttons.

While command/option-clicks should work normally with my just-announced builds, multi-button mice are not supported by the emulated Mac OS (as far as I've been able to determine) without a third-party mouse driver or enabler. Though I'm fairly certain that's true for Mac OS 8.6, which is what I'm using, I thought that native support for multi-button ADB mice was incorporated into some later version of Mac OS. I don't know what version, and I couldn't find any definitive statements.

A future project might involve fixing the jerky sound of some games and/or MIDI files. I guess that would involve finding out what on earth is wrong with QuickTime and why QuickTime 6.0.3 won't work decently on SS systems.
Giving up hope that an MMU can't be emulated, here's one more programmatic challenge for your abilities: Would it be possible to disable extended memory on 9.2.2 so that it can run on SheepShaver?

These are interesting and worthy projects, but ones that I'm not currently equipped to delve into.

[Ronald P. Regensburg]

In this latest version, the command-drag scroll feature in Finder windows now works. With command-click-and-hold, a 'hand' icon appears (in the "S" version, not in the "H" version) that can scroll the window in all directions.

I do not remember native support for multi-button ADB mice. Hasn't it only been available for USB mice?

[kelvin31415]

In this latest version, the command-drag scroll feature in Finder windows now works. With command-click-and-hold, a 'hand' icon appears (in the "S" version, not in the "H" version) that can scroll the window in all directions.

That difference in behavior between S and H versions is very interesting, and I suspect it might have something to do with color cursor support. When I try this with the "H" version on Mac OS 8.6, I see a garbled cursor.

I do not remember native support for multi-button ADB mice. Hasn't it only been available for USB mice?

That makes sense. I have no personal knowledge because I never used a multi-button mouse on a mac until this year!

[DrLex]

I should have thought about this earlier, but I have actually been able to command-click (and -drag) since the first version of SS I've been using. The trick is that I have a 3-button mouse and command-clicking only works with the middle mouse button (i.e. pressing the scrollwheel). I have no idea why it only works with the middle button. Of course, with the latest SS build this hint becomes obsolete