#Subsystems
11 messages in this thread
Roy, I'm interested in what subsystems you have installed that seem to work
with each other. I've given up on Autopoint since the set (Autopoint, Conman,
FaccII) seems to be unstable. Could I get the same effect with QuickMouse and
Screenblanker?
Hi Tom,
QuickMouse does not activate windows it points at. It only accelerates
the mouse velocity in such a way to do both precision movements and to get the
mouse from one side of the screen to other side with minimal movement. It is
part of Gizmoz 2.0, but there is a PD version somewhere on CIS.
I never liked using Autopoint, finding it more a nuisance than a utility.
I even built a feature into RSLClock to disable my mouse when it hasn't been
used in a while, so that I can operate sans mouse if I wish to!
Have you tried other AutoPoint-like PD software (i.e. SunMouse,
HeliosMouse, AutoPoint2).
-RSL-
I haven't used any of the other 'make the window the mouse is over the topmost
active window' systems besides Autopoint. This genre is much improved when
used in conjunction with DropShadow.
Tom, Have you tried using "autopoint notofront"? I use autopoint and like it
very much. At first I found the "make active window the top one" feature very
anoying as well as inconvient and useless. But once I discovered the
"notofront" feature I like it very much.
Terry
I tried dropshadow once, but when more than three windows were opened I thought
the window redrawing took TOO MUCH time. I'm still concerned that too many
so-called "silent" background tasks take up too much CPU time and degrade the
whole system. I tend to use only those background programs that increase the
utility of the system, instead of the "cute" display programs (i.e.
DropShadow). As always, different strokes for different folks!
-RSL-
I worry more about having too many programs attached to input.device, which is
unstable enough as it is. When you get three or four programs using
input.device monitors written in an HLL, GURUS tend to be a lot more frequent.
I see what you mean. That was the whole point behind Jim McCraz's
Commodities.Exchange project. It's a shame that it seems to have been put on
hold (it seems). It would have made things MUCH more orderly and stronger
against GURUing! I am truly amazed that all the input.device intercepters work
all together without causing chaos!
-RSL-
Roy,
I like the mouse turn-off CONCEPT, but the implementation (all of them I've
seen, anyway) leaves a bit to be desired: when I move the mouse, there's quite
a time lag before the pointer pops back in. Can't say I care for having to
"wave" the mouse before I can use it.
I also vaguely remember something about RSLClock's implementation with an
earlier version of UEdit. I have 2.3 now; I'll have to enable the mouse
function again and see if I can generate a bug report for you. (Let's hope
not.)
Rick
Richard,
Try the MouseOff feature and tell me what you think. There is an
inevitable time lag (I hope it is not too long) from the fact that I don't want
RSLClock to degrade any other subtask! See if it works for you!
P.S. I haven't heard a single mention of version 1.4, either good or bad,
since its release (no news is good news?)!
-RSL-
Roy,
I'm running 1.4, no complaints.
Re MouseOffing, same problem: there is a slight lag. Maybe I'm being silly, I
dunno — it's perhaps a few hundred milliseconds — but it makes the response
feel really strange, and I can't say as I care for it. Not razzing YOUR code
in particular, every mouseoff I've tried does this.
Question: is it possible to let the mouseoff run as a seperate task/process in
a very low overhead, high priority setup? (I know naught about this stuff.)
I tried it again last night, and found the UE problem I mentioned. Every time
the mouse is turned off OR on, the entire UE screen/window goes away, returns,
and refreshes. Terribly annoying, and this was why I gave up with mouseoff on
1.3. NOT your fault, I bet… just an interaction between the programs.
Rick
Sorry about the problems with MouseOff, the coding uses RemakeDisplay() (at
least I think it does, its been a while since I reviewed the source), so
perhaps it causes UEdit's screen to go haywire. It does not seem to effect any
software that I run. Oh well… that's way I made it optional. As far as
coding it tighter, perhaps as a ML subtask, that would make it far faster, but
I am afraid that I have yet to find the time to figure out how to write in
Aztec's vversion of Amiga Assembler!
Perhaps someday….
-RSL-