lloyd@comp.vuw.ac.nz (lloyd Parkes) (11/16/89)
I have got most of a mouse driver going under real mode minix. There are just a few things that need to be done. Things it does do ~~~~~~~~~~~~~~~~~ Places a (text) cursor on the screen. Knows about hardware and software scrolling. Keeps track of what is under the cusor. Works with two or three buttons. Looks very nice. Things it doesn't do ~~~~~~~~~~~~~~~~~~~~ 1) Run in protected mode. :-( 2) Work with serial or 'new bus' mouse. 3) I only have a two button mouse, so I can't verify the three button code. 4) The IRQ setting should be determined at run(boot)time, this seems to be very hard in protected mode. 5) There aren't enough IRQ lines to go around. 6) Send messages anywhere. Fixs ~~~~ 1) I will fix up some of the segment stuff, and hope it goes. (I don't know much about protected mode). 2) I have access to a serial mouse. I hope someone will offer to test my 'new bus' mouse code. 3) The serial mouse has three buttons. 4) Bruce?? are you out there??? 5) Tough, you must drop something, although this will only be a problem if you have lots of hardware e.g. AT with two terminals and a hard drive. Ethernet counts as a second terminal. 6) I don't know what people want, so a few points a then some suggestions. You can guarantee (sp?) three buttons, if the mouse only has two buttons, the third will be simulated by both at once. It is assumed that the messages will be sent to the tty task, probably pretending to be keyboard messages. It is also assumed that because there is no fancy windows (yet) that the mouse will be used most often in elle. I don't want any double click hacks, (the third button one is bad enough), those are for people who can't even get to grips with two buttons :-) There can be no clicking and dragging or menus, because the mouse driver has no task of its own. Suggestion 1: left button sends enough ^B, ^F, ^P and ^N to move the elle cursor to the mouse cursor. Right button does same, but sends ^@ first and ^W afterwards to kill the region. Middle button same as right, but a copy region instead of kill. Suggestion 2: left button moves, as for one. Right button grabs word (whitespace delimited) at mouse cursor and sends that to tty. This creates problems, because the tty driver expects to recieve scan code, not ASCII codes. This is horrid, and is on my 'to fix' list. :-) Middle button, kill or copy region?? Suggestion 3: up to you. Please mail any offers to test 'new bus' driver and your suggestions. How many people out there actually have mice? and what type do you have two/three buttons new/old/serial ? Lloyd ------------------------------------------------------------------------ Lloyd | lloyd@comp.vuw.ac.nz | I just hope these addresses Parkes | ...!uunet!vuwcomp!lloyd | are right. :-) ------------------------------------------------------------------------
peter@ficc.uu.net (Peter da Silva) (11/18/89)
For a three-button mouse: Hold down the left button, it will highlight the character under the mouse. Move the mouse... the selected region extends Release the left button... the highlight disappears. Click the right button and the copied text is sent to stdin. Click the middle button and it sends an escape sequence containing the mouse position (raw mode only!). You would have to modify the editor to handle this. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "vi is bad because it didn't work after I put jelly in my keyboard." -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)
tkb1@ukc.ac.uk (T.K.Berge) (11/20/89)
In article <1989Nov16.003710.19533@comp.vuw.ac.nz>, lloyd@comp.vuw.ac.nz (lloyd Parkes) writes: > > > Things it doesn't do > ~~~~~~~~~~~~~~~~~~~~ > 6) Send messages anywhere. > If you want to port a MSDOS program that uses the microsoft mouse library, the mousedriver has to be read by the application program, and the application program moves the cursor on the screen. The application program needs to know when the the mouse has been moved, or when a button is pressed. There is 2 solutions to this problem: 1) Create a subprocess that is constantly reading the mousedriver 2) The mousedriver sends a signal to the application program every time the mouse has moved or a button is pressed. For several reasons, I think the latter solution is the more elegant the the former. Anyway, I think a mousedriver is needed for the MINIX operating system. Since I am currently working on mousedriver implemtation on MINIX, I am quite happy to post the specification of my own mousedriver as soon as I have time to do so. Yours sincerely Tor Kristjan Berge Electronic Engineering Laboratory, University of Kent at Canterbury, ENGLAND ps. I am looking forward to see a more detailed specification of your mouse- driver mr. Parkes. ds.
lloyd@comp.vuw.ac.nz (Lloyd Parkes) (11/24/89)
In article <7040@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > Hold down the left button, it will highlight the character > under the mouse. > Move the mouse... the selected region extends > Release the left button... the highlight disappears. No, non, nyet, nien, (feel free to add more negatives in the language of your choice). Not under any circumstances (well almost). This gets to be quite hairy, especially if the screen is scrolled etc. Also, there isn't much need for it, it is just the same as click left: move (& mark) click right: (mark &) move & kill (or copy) region click middle: yank only in elle (I don't use mined) of course. Since the only other use I can see for the mouse is selecting previous commands, while in the shell, and I use clam, so ^F will go back up the history buffer, I can get almost the same usefullness, whith a damn sight less work. Clicking and dragging is at the bottom of my to do list along with windows :-) Lloyd -- ------------------------------------------------------------------------ Lloyd | lloyd@comp.vuw.ac.nz | Now all I have to do is write X Parkes | ...!uunet!vuwcomp!lloyd | window & segment swapping ------------------------------------------------------------------------
pcm@iwarpr0.intel.com (Phil Miller) (11/27/89)
In article <7040@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >For a three-button mouse: > Hold down the left button, it will highlight the character > under the mouse. > Move the mouse... the selected region extends > Release the left button... the highlight disappears. > Click the right button and the copied text is sent > to stdin. > Click the middle button and it sends an escape sequence containing > the mouse position (raw mode only!). You would have to modify > the editor to handle this. An existing mechanism which is useful to consider is the Sun mouse's mode of operation, with a couple of enhancements. Click the left button for defining the beginning of text. Click the right button to define the end of text. Middle button [or left and right button together] brings up a menu which includes the option "paste" which submits the text to standard input. It would also be nice to make the `middle button menu' user-definable, say with a file `.mouserc' in the home directory of the user. This would provide some fairly simple mechanism for extending the functionality of the mouse, like for example, walking menus. It would be nice to incorporate a similar mechanism into `elle' and other interactive programs. Comments? Phil Miller iwarp.intel.com
peter@ficc.uu.net (Peter da Silva) (11/27/89)
In article <LLOYD.89Nov24094436@breaker.comp.vuw.ac.nz> lloyd@comp.vuw.ac.nz (Lloyd Parkes) writes: > Clicking and dragging is at the bottom of my to do list along with > windows :-) A pity. I've used click-click systems and click-drag systems, and my vote goes for click-drag any day. It's so much more intuitive. And locking the thing into 'elle' is pretty daft. You haven't lived until you've done cut-and-paste on your shell session. Hey, how about this, for multiple consoles. Clicking in the bottom row and pulling down drags the current 'screen' down, displaying part of the next screen. Clicking the top and dragging up drags the screen up. (raves off into the distance) -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
lloyd@comp.vuw.ac.nz (Lloyd Parkes) (11/28/89)
> It would also be nice to make the `middle button menu' user-definable, say > with a file `.mouserc' in the home directory of the user. This would > provide some fairly simple mechanism for extending the functionality of the > mouse, like for example, walking menus. It would be nice to incorporate > a similar mechanism into `elle' and other interactive programs. Groan, someone has to write this you know (me) and I don't even have all three types of mouse, to test it on. Not only that I am supposed to be writing an interpreter tool kit for the University (instead of reading the news :-) and I did want to build a home brew system over the summer (southern hemisphere) break. Not a chance of me getting half that lot done, let alone writing windowing stuff as well. Lloyd -- ------------------------------------------------------------------------ Lloyd | lloyd@comp.vuw.ac.nz | Now all I have to do is write X Parkes | ...!uunet!vuwcomp!lloyd | window & segment swapping ------------------------------------------------------------------------
ghelmer@DSUVAX.uucp (Guy Helmer) (11/28/89)
In article <7109@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <LLOYD.89Nov24094436@breaker.comp.vuw.ac.nz> lloyd@comp.vuw.ac.nz (Lloyd Parkes) writes: > > Clicking and dragging is at the bottom of my to do list along with > > windows :-) > > A pity. I've used click-click systems and click-drag systems, and my vote > goes for click-drag any day. It's so much more intuitive. I second that. Click and drag is nice. However, why not make the mouse driver configurable? The Apollo's Aegis O/S allows one to make the mouse buttons do lots of neat things by just customizing a script. > And locking the thing into 'elle' is pretty daft. You haven't lived until > you've done cut-and-paste on your shell session. Definitely! I had my Apollo's mouse buttons set up to quickly grab old commands and paste them into the command line. It was almost a necessary tool some days. > Hey, how about this, for multiple consoles. Clicking in the bottom row and > pulling down drags the current 'screen' down, displaying part of the next > screen. Clicking the top and dragging up drags the screen up. Like an Amiga? Yes, that would be nice. > `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. > 'U` -------------- +1 713 274 5180. -- Guy Helmer ghelmer@dsuvax.uucp Dakota State University Computing Services helmer@sdnet.bitnet
peter@ficc.uu.net (Peter da Silva) (12/01/89)
In article <1989Nov28.142537.1750@DSUVAX.uucp> ghelmer@DSUVAX.uucp (Guy Helmer) writes: > In article <7109@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > Hey, how about this, for multiple consoles. Clicking in the bottom row and > > pulling down drags the current 'screen' down, displaying part of the next > > screen. Clicking the top and dragging up drags the screen up. > Like an Amiga? Yes, that would be nice. Not quite, but similar. More like a terminal program I wrote for the IBM-PC about 4 years ago, so I could watch commands on the VAX and the PDP-11 at the same time. It was more useful for a text display to make the screens slide up from the bottom, displaying the last few lines of the next screen. The reason was that for text screens it's usually the stuff at the bottom that's most important. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
pcm@iwarpr0.intel.com (Phil Miller) (12/04/89)
In article <LLOYD.89Nov28133415@makara.comp.vuw.ac.nz> lloyd@comp.vuw.ac.nz (Lloyd Parkes) writes: >> It would also be nice to make the `middle button menu' user-definable, say >> with a file `.mouserc' in the home directory of the user. This would >> provide some fairly simple mechanism for extending the functionality of the >> mouse, like for example, walking menus. It would be nice to incorporate >> a similar mechanism into `elle' and other interactive programs. >Groan, someone has to write this you know (me) and I don't even have >all three types of mouse, to test it on. Not only that I am supposed >to be writing an interpreter tool kit for the University (instead of >reading the news :-) and I did want to build a home brew system over >the summer (southern hemisphere) break. Not a chance of me getting >half that lot done, let alone writing windowing stuff as well. > Lloyd >Lloyd | lloyd@comp.vuw.ac.nz | Now all I have to do is write X >Parkes | ...!uunet!vuwcomp!lloyd | window & segment swapping The point is that *it would be nice* to have these features. You should in ANY event keep your design open ended. Why? MINIX will eventually support more sophisticated user interfaces which we cannot presently envision; mouse support is a part of most contemporary user interface packages. Perhaps if your mouse software is designed to be open-ended, it will EVOLVE into what I was talking about above. If the design is NOT open-ended, someone will have to start from scratch later, and your design will have a short life. WRT the problem of not having all three (?) types of mouse, I can't really see this as a major obstacle. There are a number of books on the market which describe the behavior of mice; use them. If you don't know the books, e-mail me and I'll send you a list. I would think it a terrible waste of your time to develop a mouse driver which only supported ONE type of mouse. BTW, it is nice of you to volunteer to contribute a mouse driver. I think probably other people will be happy to X and segment swapping. Sounds like your summer is spoken for ;-) ;-) ;-). Phil Miller pcm@iwarp.intel.com