from preamble:
"Change Set: spsFocusPolicy Date: 30 August 2001 Author: Steven Swerling
This change set adds a preference called ""mouseClickFocusPolicy"" in the morphic tab of the preferences window. If unchecked, behavior is identical to the standard focus policy -- the pane that the mouse is over gets keyboard focus. If checked, the user must explicitly click in a pane to set the focus on that pane -- the location of the mouse does not effect where the keyboard focus goes.
I have been using this focus policy for awhile now, and it''s solid -- for me. There are bound to be little snags, which I will try to fix as they are reported. "!
sps2000@mail.com wrote:
from preamble:
"Change Set: spsFocusPolicy Date: 30 August 2001 Author: Steven Swerling
This change set adds a preference called ""mouseClickFocusPolicy"" in the morphic tab of the preferences window. If unchecked, behavior is identical to the standard focus policy -- the pane that the mouse is over gets keyboard focus. If checked, the user must explicitly click in a pane to set the focus on that pane -- the location of the mouse does not effect where the keyboard focus goes.
I have been using this focus policy for awhile now, and it''s solid -- for me. There are bound to be little snags, which I will try to fix as they are reported. "!
Wow! Great. This was one of the first things that got me when I started to use Squeak. I did a crude implementaiton of this same thing back then. This seems better and should be in the image!
Karl
On Thu, 30 Aug 2001 sps2000@mail.com wrote:
This change set adds a preference called ""mouseClickFocusPolicy"" in the morphic tab of the preferences window. If unchecked, behavior is identical to the standard focus policy -- the pane that the mouse is over gets keyboard focus. If checked, the user must explicitly click in a pane to set the focus on that pane -- the location of the mouse does not effect where the keyboard focus goes.
My preferred focus policy is that focus follows mouse. (No click-to-focus), except that if the mouse pointer enters the root window, the focus does not leave the previous window.
Thus, the focus only changes when the mouse enters some window. By focus, I mean that the focus is the window that recieves keyboard strokes.
One of my complaints about click-to-focus is that click-to-focus schemes almost always force click-to-raise schemes, IE, they always raise the clicked window to the top. I don't like this. Many times its nice to be able to type into a window thats slightly obscured. (Like a code-pane thats partly obscured by a selector-finder window.)
As I use linux, I can use the normally unused 'window' key (hereafter called Super. X has 5 modifiers: Control Shift Meta Super Hyper.) I have configured my window manager to:
1. Super-click to raise a window 2. Super-click-drag to move a window around. 3. Super-Up/Down/Left/Right (arrow keys) to switch between virtual screens in a virtual desktop.
A virtual desktop is a desktop thats more than one screen in size. What it means is that I can just type the two keys and switch to a different virtual screen to open windows onto. As I have 24 of these, I can always find an empty screen if I need it. In the squeak fashion, you can think of it as sorta like having a dozen 'temporary projects' arranged in a grid, and being able to switch between them instantly.
IMHO, iconization schemes like win95(with minimization to the task bar), or the classical mac (window-shade or [1]), or mac OS-X (with the dock) seem to not scale to serious computer use.
If you are doing a half-dozen tasks, like I usually do (web browsing, reading papers & doing research, one or two different coding projects, email&other communication software, games) It doesnt' scale. You have too many windows open to manage...
If you iconize, it can be hard to figure out exactly which windows are related to which task, and you end up with a million icons filling the screen (X/Classic Mac), or you have lots of tiny unreadible icons (OSX dock/win95 taskbar).
And, managing just two dozen overlapping windows is obviously hopeless.
So, I use my scheme. So far, it scales to me having 3-10 tasks open at once, and 30-100 open windows. I run the equivalent of a max of about 40 screens, and they're usually only a few keystrokes away with the Super-arrow keys. I never iconize a window, and I typically have very low overlap.
With my setup, any windows/icons may be marked 'sticky', so it is always displayed no matter which virtual desktop I'm on. (And, I have a keyboard shortcut to change the stickiness of any window.) There is also a 'pager' program that shows a minaturized view of all of the virtual desktops. Finally, I can drag windows between virtual screens or virtual desktops. [Screenshots available upon request]
I think that this might be an instance of a wonderful insight I heard, oh, about 3 years ago, a talk by someone from HP. (Put on the asbestos underwear)
User interfaces are being stuck in the red-balloon era.
Our civilization forces every member to learn a hard task, a difficult task, an unintiutive task. A task so hard that in most westen countries, it takes 4 years to learn the basics, another 8 years to master, and some people spend another 4 or 10 years becoming an expert. Despite the incredible difficulty of this task, we force our children to endure it, because it is a critical skill and tool if you wish to survive in modern civilization. The skill is literacy.
Why do we do this? Why do we not let children stick with the Red-balloon books into their adult life? Red-balloon books, used to help children who are just beginning to learn to read, with pictures of each word, next to each word, have got to be the most obvious and simple user interface.... Yet we force our kids away from such simple wonderful easy books, into pictureless Hardy Boys mysteries and Baby Sitters Club.
Why?
Because there are many sophisticated concepts which cannot be expressed in Red-Balloon books. How does one pictorally illustrate concepts like freedom, or mathematics, or philosophy, or algebra, this very email, or even our constitution in a Red-Balloon book? One can't. :)
Which is why we force our kids away from those books, why our civilization has relegated those books as learning tools, and unusable for serious work. Our civilization is all the better for it. Despite the complexities of literacy, almost every citizen has a high degree of proficiency. We have newspapers, textbooks, research journals, philosophy, and even freedom resulting from the answer to the question of ``What is the purpose of government.''
Now... My question?
Why do we treat computers in the exact opposite way? Computers will, within a generation or two, become as potent, or possibly more potent than literacy. Yet, our civilization seems to be working so hard to hobble our children. To invent and train them soley for the perfect Red-Balloon computer, thats as obvious as posssible to use, but utterly useless to do any sophisticated task?
Why?
If you say, ``Computers are too hard, most people are too idiotic to really be able to use them''. Well, I'd bet that if you asked literate monks from 1000 years ago, whether they thought that the masses were capable of literacy, they'd give the same answer.
If you say, ``Our civilization has many adults who need to learn these skills. Red-Balloon interfaces make excellent training wheels, but unlike our children, nobody is there who can force adults to give up those training wheels.'' I might agree with you, I have yet to find a better explanation.
The jobs one can do are controlled by the tools and the training that one has in using those tools.
Why aren't we working to design powerful and flexibible interfaces/tools and train our kids to use the computerized world with the maximum amount of power and flexibility available. Yes, its incredible hard, our kids may take 4 years to learn, and another 10 years to master such tools and training... But isn't it worth it to invent those tools and train our kids in their use? Let our kids gain the maximum utility from their computers.
We've invented the tool of literacy and we train our kids in it for a decade and our civilization is the stronger for it. Our computers are even more potent communication tools, yet it seems as if the goal is to create weak tools and to not train our kids in how to gain the maximum benefit.
I'm not saying that computers shouldn't be made easier to use, just that we seem to be heading toward the trap of the Red-Balloon. Squeak seems to be a bit of fresh air and a counterpoint to this. Both because of the beliefs of the people making it up; people who believe that children shouldn't be trapped in a useless Red-Balloon world. And that its an easy to use, yet incredibly powerful system. Nor are Red-Balloon books bad. They serve as training wheels before going out into the real world.
As for everyone else, they seem to think that Red-Balloon should be the ultimate goal of computer interfaces, that it is the best way. *This* is what I disagree with.
For example, what set me off to write this.
I am a computer user.. I tend to have many tasks ongoing on my computer at any one time, and dozens of windows. My computer and user interface should be helping me keep track of them. Yet win95/macclassic/osx, instead of being flexible and powerful and helping me manage the dozens of windows, they're hobbled with an iconization concept that cannot scale and makes it impossible for me to manage my tasks.
I'm sure any of us can find other examples where the ceaseless pursuit of the Red Balloon creates weak tools and powerless systems.
People master the sophisticated art of literacy, why are we presuming that they cannot master the art sophisticated computer use?
Scott
PS: Heh, after writing it, I wonder if I shouldn't contact some of the HCI (Human Computer Interaction, one of the forks of the school of computer science) people here and see what they think of my mini-rant.
--
[1] I do not count the classic-mac technique of hiding windows by other applications. Many tasks cross application boundries.)
-- No DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
Scott A Crosby wrote:
On Thu, 30 Aug 2001 sps2000@mail.com wrote:
My preferred focus policy is that focus follows mouse. (No click-to-focus), except that if the mouse pointer enters the root window, the focus does not leave the previous window.
Scott,
Here are some tips to get add the crosbyFocusPolicy option. First, you might want to take a quick glance at the spsFocusPolicy changeset (do a "browse code" on it from a file list), just to get a feel for the problem. I did a quick try at your policy, and got pretty close. So to get you started:
1. In PluggableListMorph>>mouseLeave: and PluggableTextMorph>>mouseLeave:, only allow the call to #releaseKeyboardFocus if Preferences>>crosbyFocusPolicy is not true.
2. In SystemWindow, add the following method:
mouseEnter: evt self activateRetainZOrder. ^super mouseEnter: evt.
3. Add another method to SystemWindow:
activateRetainZOrder "Bring me to the front and make me able to respond to mouse and keyboard"
| outerMorph | outerMorph _ self topRendererOrSelf. outerMorph owner ifNil: [^ self "avoid spurious activate when drop in trash"].
self submorphsDo: [:m | m unlock]. self isCollapsed ifFalse: [model modelWakeUpIn: self. self positionSubmorphs. labelArea ifNil: [self adjustBorderUponActivationWhenLabeless]].
That's enough to get pretty close to the focus style you're going for. I'm not posting it as a changeset -- it's only to get you started. For instance, the #activateRetainZOrder is just a stripped down version of #activate, and I may have stripped out too much (like the call to passivate to the previously active window).
With this kind of change to system, it's probably best to let it steap in your own environment for awhile to give it a chance to mature.
Good luck.
sps2000@mail.com writes:
I have been using this focus policy for awhile now, and it''s solid -- for me. There are bound to be little snags, which I will try to fix as they are reported. "!
I think this one prevents debug windows from highlighting the last execution point in the code window.
Thanks, -Simon
Simon Michael wrote:
sps2000@mail.com writes:
I have been using this focus policy for awhile now, and it''s solid -- for me. There are bound to be little snags, which I will try to fix as they are reported. "!
I think this one prevents debug windows from highlighting the last execution point in the code window.
You're right. I've got a fix for it. I'll wait a little to post it, I want to see if anymore bugs trickle in first. In the meantime just hit the "where" button (or menu selection) to highlight at the currently executing code
Thanks.
squeak-dev@lists.squeakfoundation.org