From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Ralph Corderoy Message-ID: <2a6c.3f2baa23.261b2@blake.inputplus.co.uk> References: , Subject: Re: [9fans] horizontal scroll for acme? Date: Mon, 4 Aug 2003 08:59:24 +0000 Topicbox-Message-UUID: 100c5168-eacc-11e9-9e20-41e7f4b1d025 Hi Charles, > i'd try to find another scheme. in my experience, and i'm fairly sure > i'm not the only one, having two scrollbars hardly ever works sensibly > in practice: you rarely want to move in just one dimension at once, so > you end up having to flit between them, typically losing context > whilst doing so. it's particularly bad for program text and web > pages. indeed, i'd say it's a good example of an attempt to appear to > solve a problem without actually doing so. `RISC OS' developed by defunct UK company Acorn for their ARM computer, they developed the ARM too, used the 3-button mouse thus Button 1 on scrollbar arrow scrolled in indicated direction, button 3 scrolled in the opposite. This saved having to move the mouse pointer from one end of the scroll bar to the other. This has been avoided in the past by having both arrows at the one end of the scrollbar but that just looks wrong. Clicking button 1 above the scrollbar `thumb' paged in the direction of the pointer. Holding the button down made the paging repeat. Using button 3 instead again went in the opposite direction. Dragging the scrollbar thumb with button 1 scrolled the window with continuous update, i.e. the window didn't scroll only on button release. The mouse pointer's movement was locked to the bounds of the scrollbar, e.g. the pointer couldn't move sideways out of the scrollbar. Dragging with button 3, when there was a horizontal and vertical scrollbar, dragged *both* scrollbars, i.e. a `panner' widget for free. The use of button 3 to do a similiar but different thing to button 1 was used throughout the GUI and was very useful. Another example, pop-up menus appeared on button 2 click. Selecting an item with button 1 made the menu disappear. Using button 3 made the menu stay open, although it may update to reflect the new state. That these type of experiments were around over a decade ago, and have disappeared thanks to everyone copying Microsoft is a real shame. Having to have the confusing OK, Cancel, and Apply buttons on a dialogue so changes can be applied without the dialogue disappearing is poor. Using button 3 to `OK' the dialogue but have it remain on the screen is much better in use. Cheers, -- Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/