[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:	AMIGA NOTES
Notice:	Join us in the NEW conference - HYDRA::AMIGA_V2
Moderator:	HYDRA::MOORE

Created:	Sat Apr 26 1986
Last Modified:	Wed Feb 05 1992
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5378
Total number of notes:	38326

3319.0. "Qmouse and VLT battle it out" by WJG::GUINEAU (Quantum Reality) Wed Jan 10 1990 22:37

I couldn't find the other note on this, so here a new one!

I downloaded QMOUSE 1.6 and believe I've found a bug or two.

First, if you specify both the -Z option (set priority) and the -R option
(SUN mouse) then as soon as you move the mouse out of that window (the active
one) and back into it again, QMOUSE (or *someone*) set the priority of
input.device to whatever priority you specified with -Z. Since input.device
normally runs at pri 20 (highest of all normal tasks), this causes real
trouble.

So fine, toss the -R option (I can deal with a mouse click to activate a 
window :-). So now QMOUSE is happy at whatever pri you set (I used 7) UNTIL
you run VLT. Once you select VLT and then back to a shell, QMOUSE has
dropped back to pri 0 and I'm back where I started with no qmouse features
while VLT is running (and then a flood of queued events when VLT exits).

I found that if I start qmouse AFTER VLT is running everything seems to work
fine (input.device stays at 20, qmouse stays at whatever I set and I can
use qmouse features, for example hot keys).

I also run SNAP in the background... I wonder?

Anyone get these results?

John

T.R	Title	User	Personal Name	Date	Lines
3319.1	works for me	CGOFS::DREW	Steve Drew	`Thu Jan 11 1990 22:51`	10
	With the -R option, I did notice that qmouse changed the priority of the input.device to 5. I did'nt investigate the consequence of this since I did'nt like the sun mouse mode to being with. But without the -R option, (even with the -Z7) it works fine with vlt. .Steve.
3319.2	SNAP Does break Qmouse	CGOFS::DREW	Steve Drew	`Thu Jan 11 1990 23:00`	16
	I just tried running SNAP as you mentioned, and this does seem to interfere with Qmouse. When using the Amiga 'M' key to flip screens it no longer makes the window within the screen active. For example if you 2 shell windows open, then Amiga 'M'd to a VLT screen, Qmouse makes the VLT screen active. Then when Amiga 'M'd back to the workbench screen the shell window you were last using becomes the current selected window. This is not just with the -R (sunmouse) option qmouse does this all the time, however, it does'nt work while running SNAP. And this maybe the cause of your other problems too... hope this helps... /Steve.
3319.3	Toggle VLT mouse support when tracking down conflicts.	STAR::ROBINSON		`Fri Jan 12 1990 12:02`	9
	No answers here but some more speculation. I am always amazed when I can use SNIPIT running in the background and the VLT Mouse support to get mouse based cut and paste in EVE etc. There is sometimes craziness with the mouse support though, so turning it on and off may help analyze problems with QMOUSE, SNAP and VLT. BTW,the beginning of this stream was in the BLOCKOUT note, but it belongs here. Dave
3319.4	SNAPped	WJG::GUINEAU	Quantum Reality	`Sat Jan 13 1990 13:51`	9
	I think I'll toss SNAP and go back to snipit. I used SNAP cause it used to copy from VLT windows. But I've since gone to a custom screen for VLT to save my eyesight and SNAP no longer works. Oh Well John
3319.5		WJG::GUINEAU	Quantum Reality	`Sat Jan 13 1990 13:53`	4
	Oh, the reason -R sets input.device to 5 is that's the default priority for -Z. It actually set's it to whatever you give -Z (like -Z7) John
3319.6	QMouse + DVIII = Guru	BELFST::MCCLINTOCK	Peter	`Mon Jan 15 1990 17:34`	3
	Running QMouse V1.6 and Deluxe Video III = Instant Guru. Peter