home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.atari.st.tech
- Path: sparky!uunet!mcsun!sun4nl!alchemy!avgroeni
- From: avgroeni@cs.ruu.nl (Annius Groenink)
- Subject: The gawdawful menu bar and a moving mouse
- Message-ID: <1992Aug27.132937.17637@cs.ruu.nl>
- Date: Thu, 27 Aug 1992 13:29:37 GMT
- Organization: Utrecht University, Dept. of Computer Science
- Keywords: Mouse Movement Question
- Lines: 31
-
-
- First, a reaction on the ACCs Die! Die! article. Yes, and because
- of the fact that only accessories will not have that awful menu bar,
- people should stop writing applications. I hate to look forward to
- a system that works like Mac 7.0: if you top a window of a new application,
- the whole desktop and menubar are redrawn. This is ridiculous, but for
- compatibility with programs that use a WF_NEWDESK or menu bar,
- necessary.
- A friend of mine (Wilko Quak) wisely remarked that it would have been
- MUCH better if GEM worked with a co-ordinate system relative to the
- work.g_x and work.g_y of the window one is redrawing. Then, the conventional
- desktop could have easily been replaced by a desktop in a window.
-
-
- And now for something completely different:
-
- How do manually (that is, without using your hands) position the mouse?
- Example: Turbo ST automatically puts the mouse arrow on the OK button
- of its alert box! Can this be done, how, and does it confuse the AES?
- What I'm thinking of is, when you touch a direct-reaction scroll bar
- such as used for example in the Gemini Dialog boxes, can you make the
- mouse go up slower, thus increasing the number of mouse 'dots' needed
- to scroll through the whole text and hence increasing the resolution of
- the scroll bar.
-
-
- --
- ________________________________________________________
- Annius Groenink|undergraduate student
- Laan van Borgele 24|maths/computer science at the
- 7415 DJ Deventer|University of Utrecht, Holland.
-