SLMYQ@USU.BITNET (05/23/88)
Well, I wasn't going to post this idea because Matt said "this is the final
version" for 1.03 (?), but since 1.06 just got posted, I thought I might
as well. :)
Have a third format for DMouse. If you type DMOUSE BLANK, the screen
(and pointer) blanks IMMEDIATELY. That way you save 5 minutes worth of
phosphor every time you leave the computer. :)
Yes, I know lots of people don't think this is useful AT ALL, but I think
so, or else I wouldn't be posting this message!
Bryan Ford (SLMYQ@USU.BITNET)juan@gatech.edu (Juan M. Orlandini) (05/23/88)
In article <8805222242.AA03142@jade.berkeley.edu>, SLMYQ@USU.BITNET writes: > Have a third format for DMouse. If you type DMOUSE BLANK, the screen > (and pointer) blanks IMMEDIATELY. That way you save 5 minutes worth of or better yet, how about a hot key combination that does the same thing? better, nie? // _______ // "Honesty is the best policy // | __ // but, insanity is a better \\// | | | |__| |\ | \\// defense." \/ |__| |__| | | | \| \/ School of Information & Computer Science, Georgia Tech, Atlanta GA 30332 uucp: ...!{decvax,hplabs,ihnp4,linus,rutgers}!gatech!juan Internet: juan@gatech.edu BIX: juan
ejkst@cisunx.UUCP (Eric J. Kennedy) (05/25/88)
In article <8805222242.AA03142@jade.berkeley.edu> SLMYQ@USU.BITNET writes: >Have a third format for DMouse. If you type DMOUSE BLANK, the screen >(and pointer) blanks IMMEDIATELY. That way you save 5 minutes worth of >phosphor every time you leave the computer. :) You can fake this easily enough. Write an execute script or shell alias or something that calls "dmouse -s1" and one that calls "dmouse -s300" or whatever time you normally use. Dmouse lets you change parameters like that on the fly, so all you'd be doing is telling it to change the blanking time to 1 second, then changing it back. > Bryan Ford (SLMYQ@USU.BITNET) -- ------------ Eric Kennedy ejkst@cisunx.UUCP
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/20/88)
>>...not anywhere near as elegant as HeliosMouse or Dmouse. > > Yeah, well DMouse ain't perfect either - when a text requester comes up, >and the mouse doesn't happen to be over it, the cursor in the requester goes >away and I have to move the mouse up and click on it. Sometimes. (2/3 of the >time? I haven't kept track, just got pissed off.) Why does it do this? How >do I make it stop? AAARRRRGGGGHHHH!!! >-- >Dave Lewis Loral Instrumentation San Diego (619) 282-3341 If someone can suggest a clean way to do it (I don't have time to do everything). If not, there are two possibilities: (1) Disable auto-activate completely (-A0) (2) Disable keyboard-auto-activate but keep mouse-move-auto-activate one (-A2) Since any feature can be turned on/off at will, you still get the benefit of those other features which work for you. I have this requester problem too (everybody does). For now, I keep a-a on (-A3) and move the mouse onto the requester... inconvenient. -Matt
ecarroll@cs.tcd.ie (Eddy Carroll) (09/22/88)
In article <8809200700.AA27611@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>>...not anywhere near as elegant as HeliosMouse or Dmouse. >> >> Yeah, well DMouse ain't perfect either - when a text requester comes up, >>and the mouse doesn't happen to be over it, the cursor in the requester goes >>away and I have to move the mouse up and click on it. Sometimes. (2/3 of the >>time? I haven't kept track, just got pissed off.) Why does it do this? How >>do I make it stop? AAARRRRGGGGHHHH!!! >>-- >>Dave Lewis Loral Instrumentation San Diego (619) 282-3341 > > If someone can suggest a clean way to do it (I don't have time to > do everything). > How about SetFunctioning Intuition's Request() function and making it check to see if the requester being opened contains a string gadget which is initially selected; if it does, then position the mouse pointer over the cursor in the string gadget when it opens. Hey presto, no more problems with having to move the mouse pointer whenever one of those File requesters pops up. Of course, moving the mouse pointer behind the users back is not really very friendly, but the extra convenience gained would probably be worth it in this case (particularly if you arranged it so that the mouse pointer didn't re-appear if it was blanked - the user probably wouldn't even notice the mouse had moved). Another small change that would be nice: Left-Right clicking a window when it is the only window on a screen, or when it is a backdrop window, sends the screen to the back (this is great). However, doing this to a normal window which is on the same screen as a backdrop window (e.g. workbench) doesn't have any effect (unless there are other normal windows on the same screen). How about making this latter case also send the screen to the back? Oh well, just a few thoughts. I have DMOUSE1.09 on all my disks anyway, and I love it. -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived INTER: mcvax!ukc!cs.tcd.ie!csvax1!ecarroll@uunet.uu.net | until you've died UUCP: {...uunet}!mcvax!ukc!cs.tcd.ie!csvax1!ecarroll | in MUD!" - R.B.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/29/88)
Eddy Carroll writes: >check to see if the requester being opened contains a string gadget which is >initially selected; if it does, then position the mouse pointer over the >cursor in the string gadget when it opens. Hey presto, no more problems with >having to move the mouse pointer whenever one of those File requesters Ugg!! Never! I've used plenty of systems that 'move' the mouse for you and I would never subject that sort of torture to the Amiga community! The mouse should be moved by exactly one source ... the user. I agree that a fix needs to be made, but not that. >Another small change that would be nice: Left-Right clicking a window >when it is the only window on a screen, or when it is a backdrop window, >sends the screen to the back (this is great). However, doing this to >a normal window which is on the same screen as a backdrop window (e.g. >workbench) doesn't have any effect (unless there are other normal windows >on the same screen). How about making this latter case also send the screen >to the back? Ahhh... that's an idea.. Kind of a small special case that might not be worth the extra line or so of code. >Oh well, just a few thoughts. I have DMOUSE1.09 on all my disks anyway, and >I love it. Heh, so do I! -Matt
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/29/88)
In article <8809281725.AA21445@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >Eddy Carroll writes: >>check to see if the requester being opened contains a string gadget which is >>initially selected; if it does, then position the mouse pointer over the >>cursor in the string gadget when it opens. Hey presto, no more problems with >>having to move the mouse pointer whenever one of those File requesters > > Ugg!! Never! I've used plenty of systems that 'move' the mouse for >you and I would never subject that sort of torture to the Amiga community! >The mouse should be moved by exactly one source ... the user. I agree that >a fix needs to be made, but not that. > So, how about bringing the requester up under the mouse. This is much more presumptuous (DMouse overriding the oroginal programmer's intent), and may not work all the time (for example if the window that is opening the requester is not under the mouse pointer), but might work and you wouldn't have to change the mouse pointer position. > -Matt kevin -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
pds@quintus.uucp (Peter Schachte) (09/30/88)
The problem with DMouse people are trying to solve, if I understand correctly, is that with the 'sunmouse' mode on, the window under the mouse is ALWAYS the focus window (where keyboard input goes). And when a requester pops up, it's (by Murphy's law) never under the mouse. So if a program pops up a requester and programmatically gives it focus, DMouse sets focus back to the window the mouse is in. No good. Couldn't the problem be solved by making DMouse only set focus when the mouse moves into a window? So if a requester pops up not under the mouse, and is given focus, it'll keep focus until the requester goes away or the user moves the mouse INTO a window other than ther requester. Of course, the violates the principle that the focus is always in the window under the mouse. But maybe that isn't such a great principle anyway. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/30/88)
:Couldn't the problem be solved by making DMouse only set focus when the :mouse moves into a window? So if a requester pops up not under :the mouse, and is given focus, it'll keep focus until the requester :goes away or the user moves the mouse INTO a window other than ther :requester. Nope. The problem is that the window under the mouse can change without moving the mouse ... for example, a new window is openned, or the user selects the window-to-back icon. So, anybody got any elegant solutions? I was thinking of testing the very first window in the screen for an active requester... if that's possible. I think it is, but haven't looked at the structures yet. In anycase, if I can check this condition I can temporarily disable the focus-on-keyhit (using your terminology) and focus-on-mousemove features until the requester goes away or the mouse crosses a window boundry. -Matt
tegen@prefix.liu.se (Clas Tegenfeldt) (09/30/88)
[ Eat dirt...]
I love DMouse too, but...
DMouse makes a big no-no when trying to change the active window.
The offending sequence of commands is:
Forbid();
ActivateWindow();
Permit();
This results in a great lock-up if somebody else (read "me") has
performed LockLayers(). ActivateWindow is waiting for me to Unlock
the layers but since I am an input handler (actually, it's my program
that is an input handler) I won't get the proper input event since
DMouse is blocking the input. The conclusion is that ANY program that
locks the layers will cause DMouse to lock the input handling if
the mouse is moved to another window.
If I hold down a mouse button when moving the mouse everything works
fine, but then again, if I press a key DMouse tries to change the active
window and here we go again...
Solutions: (Matt!)
Change the input handler to Signal the main task so that the waiting
won't block the input stream.
Check to see if the layers are locked. Is this possible? If they are
locked, don't try to change the active window.
There is another solution: Intuition doesn't encounter this problem.
Why? Are all input handlers removed? Tell me, what is that other
solution?
Background:
I've written a set of programs. One of them implements pop-up menus
similar to those on Sun and Xerox, i.e. activated by the right mouse
button. If I move the mouse out of the menu and press a key... se above.
When the problem is solved the programs will replace the Workbench
with an environment similar to that on Sun & Xerox Workstations,
including:
Background menus with user definable menu items,
Prompt Window available to every task,
Pop-up menus available to every program,
File Browser (a la Peter "U-Wolf" Da Silva) with user definable pop-up menu
letting you add your own favourite "show", "type", "more", etc,
Snapping of characters and parts of the screen (for later character snapping),
Magnifier window,
and more things to come.
Note that these programs use Arp!
Disclaimer: Any opinions expressed are totally my own, but please
don't tell my mother that.
BTW, I'm not the one you think. This is a borrowed userid, but feel free
to answer to this address.
EMail: C86.M-KARLSSON@XNS.Liuida.Seismo
SMail: Mikael Karlsson, Lovsattersvagen 10, S585 98 LINKOPING, SWEDEN
Phone: +46 13 50479jimm@amiga.UUCP (Jim Mackraz) (10/01/88)
In article <8809300637.AA26420@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
)
) So, anybody got any elegant solutions?
) -Matt
I haven't really tracked the problem, but a technique in my sunmouse
emulator (autopoint2) is this: keep track of the last window my program
tried to activate. Don't try to activate it twice. This worked with
the only hard test case I tried: the workbench rename window/gadget.
Does DMouse handle that one?
jimm
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/02/88)
C86.M-KARLSSON@XNS.Liuida.Seismo (Mikael Karlsson) Writes:
:I love DMouse too, but...
:
:DMouse makes a big no-no when trying to change the active window.
:The offending sequence of commands is:
:Forbid();
:ActivateWindow();
:Permit();
:
:This results in a great lock-up if somebody else (read "me") has
:performed LockLayers(). ActivateWindow is waiting for me to Unlock
:the layers but since I am an input handler (actually, it's my program
:that is an input handler) I won't get the proper input event since
:DMouse is blocking the input. The conclusion is that ANY program that
:locks the layers will cause DMouse to lock the input handling if
:the mouse is moved to another window.
I'm sorry, you are wrong. The original DMouse *did* do that,
you obviously have a VERY OLD version. I moved all the intuition stuff to
a process. In the last couple of versions, the input handler has done
nothing more than call AllocMem() and send simple messages to the process
to do the more complex operations. Gee, that was easy!
-Matttegen%prefix.liu.se@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 3634; Sat, 01 Oct 88 22:58:19 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 22:58:15 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ab06459; 1 Oct 88 18:38 EDT Received: from USENET by Louie.UDEL.EDU id aa06429; 1 Oct 88 18:36 EDT From: Clas Tegenfeldt <tegen@prefix.liu.se> Subject: Re: DMouse Keywords: Forbid() Input-handler LockLayers() Dmouse Workstation Message-ID: <947@prefix.liu.se> Date: 30 Sep 88 13:13:06 GMT Organization: CIS Dept, Univ of Linkoping, Sweden To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU [ Eat dirt...] I love DMouse too, but... DMouse makes a big no-no when trying to change the active window. The offending sequence of commands is: Forbid(); ActivateWindow(); Permit(); This results in a great lock-up if somebody else (read "me") has performed LockLayers(). ActivateWindow is waiting for me to Unlock the layers but since I am an input handler (actually, it's my program that is an input handler) I won't get the proper input event since DMouse is blocking the input. The conclusion is that ANY program that locks the layers will cause DMouse to lock the input handling if the mouse is moved to another window. If I hold down a mouse button when moving the mouse everything works fine, but then again, if I press a key DMouse tries to change the active window and here we go again... Solutions: (Matt!) Change the input handler to Signal the main task so that the waiting won't block the input stream. Check to see if the layers are locked. Is this possible? If they are locked, don't try to change the active window. There is another solution: Intuition doesn't encounter this problem. Why? Are all input handlers removed? Tell me, what is that other solution? Background: I've written a set of programs. One of them implements pop-up menus similar to those on Sun and Xerox, i.e. activated by the right mouse button. If I move the mouse out of the menu and press a key... se above. When the problem is solved the programs will replace the Workbench with an environment similar to that on Sun & Xerox Workstations, including: Background menus with user definable menu items, Prompt Window available to every task, Pop-up menus available to every program, File Browser (a la Peter "U-Wolf" Da Silva) with user definable pop-up menu letting you add your own favourite "show", "type", "more", etc, Snapping of characters and parts of the screen (for later character snapping), Magnifier window, and more things to come.
jimm%amiga.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 8324; Sat, 01 Oct 88 02:58:33 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 02:58:30 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ab17123; 30 Sep 88 20:26 EDT Received: from USENET by Louie.UDEL.EDU id aa17110; 30 Sep 88 20:24 EDT From: Jim Mackraz <jimm@amiga.uucp> Subject: Re: DMouse Message-ID: <2980@amiga.UUCP> Date: 30 Sep 88 21:46:05 GMT Organization: Commodore-Amiga Inc, Los Gatos CA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <8809300637.AA26420@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: ) ) So, anybody got any elegant solutions? ) -Matt I haven't really tracked the problem, but a technique in my sunmouse emulator (autopoint2) is this: keep track of the last window my program tried to activate. Don't try to activate it twice. This worked with the only hard test case I tried: the workbench rename window/gadget. Does DMouse handle that one? jimm -- Jim Mackraz, I and I Computing amiga!jimm BIX:jmackraz Opinions are my own. Comments regarding the Amiga operating system, and all others, are not to be taken as Commodore official policy.
pds@quintus.uucp (Peter Schachte) (10/04/88)
In article <8809300637.AA26420@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:Couldn't the problem be solved by making DMouse only set focus when the >:mouse moves into a window? > Nope. The problem is that the window under the mouse can change >without moving the mouse ... for example, a new window is openned, or the >user selects the window-to-back icon. That's just the point. A window popping up under the mouse wouldn't necessarily get focus. A window would only get focus when the mouse moves INTO it. And conversely, a window would only loose focus when the mouse moves into another window, or the focus is changed under program control. As I see it, if a window that should be given focus pops up NOT under the mouse, you have two choices: a) move the window or mouse so that the window is under the mouse, or b) allow the window to have focus even though it isn't under the mouse. I'm suggesting b. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
nsw@cord.UUCP (Neil Weinstock) (10/05/88)
In article <501@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >That's just the point. A window popping up under the mouse wouldn't >necessarily get focus. A window would only get focus when the mouse >moves INTO it. And conversely, a window would only loose focus when >the mouse moves into another window, or the focus is changed under >program control. I could swear that this actually happened to me once with Dmouse, much to my surprise. However, I have not been able to reproduce the result. I had a window which was not active even though the mouse was in it. When I nudged the mouse, the window became active. No real reason for concern. >As I see it, if a window that should be given focus pops up NOT under >the mouse, you have two choices: > > a) move the window or mouse so that the window is under the > mouse, or > b) allow the window to have focus even though it isn't under > the mouse. > >I'm suggesting b. I agree. >-Peter Schachte .- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ... | Neil Weinstock | att!cord!nsw | "I think my cerebellum just | | AT&T Bell Labs | nsw@cord.att.com | fused." - Calvin | .- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...
ejkst@cisunx.UUCP (Eric J. Kennedy) (10/05/88)
In article <490@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >Couldn't the problem be solved by making DMouse only set focus when the >mouse moves into a window? So if a requester pops up not under >the mouse, and is given focus, it'll keep focus until the requester >goes away or the user moves the mouse INTO a window other than ther >requester. My personal objection to that is that I rearrange windows and screens from the keyboard, not the mouse. (Using wKeys, mainly) I _like_ the fact that any keyboard input automatically activates the window under the mouse. Given the choice between that feature and getting rid of the requester problem, I'll live with the requester problem. I've learned to leave the mouse sitting in strategic spots, anyway. That way, common requesters _do_ come up under the mouse. It seems to me that auto-activated string gadgets frequently stay activated, anyway, even with Dmouse active. -- ------------ Eric Kennedy ejkst@cisunx.UUCP
nsw@cord.UUCP (Neil Weinstock) (10/06/88)
In article <13005@cisunx.UUCP> ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) writes: <In article <490@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: <>Couldn't the problem be solved by making DMouse only set focus when the <>mouse moves into a window? So if a requester pops up not under <>the mouse, and is given focus, it'll keep focus until the requester <>goes away or the user moves the mouse INTO a window other than ther <>requester. < <My personal objection to that is that I rearrange windows and screens <from the keyboard, not the mouse. (Using wKeys, mainly) I _like_ the <fact that any keyboard input automatically activates the window under <the mouse. Given the choice between that feature and getting rid of the <requester problem, I'll live with the requester problem. I've learned <to leave the mouse sitting in strategic spots, anyway. That way, common <requesters _do_ come up under the mouse. < <It seems to me that auto-activated string gadgets frequently stay <activated, anyway, even with Dmouse active. Well, it only goes to prove that you can't please all of the people all of the time. How about making it a new command line option, which if specified would prevent windows from getting activated until the mouse moves? Frankly, I must confess that I'm not certain exactly how much I'd like it that way, but it sounds reasonable enough, and should solve the requester problem for people who find it annoying.... .- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ... | Neil Weinstock | att!cord!nsw | "I think my cerebellum just | | AT&T Bell Labs | nsw@cord.att.com | fused." - Calvin | .- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/07/88)
Neil Weinstock | att!cord!nsw Writes:
:How about making it a new command line option, which if specified would
:prevent windows from getting activated until the mouse moves? Frankly, I
:must confess that I'm not certain exactly how much I'd like it that way, but
:it sounds reasonable enough, and should solve the requester problem for people
:who find it annoying....
This already exists (V1.07 and beyond)
-A0 disable auto-activate
-A1 on mouse move only
-A2 on keyhit only (doesn't work right in 1.09, fixed next release)
-A3 on both
The requester problem has been 95% fixed anyway. V1.11 comming soon
to video screens near you!
-Matt840493n@aucs.UUCP (Bill Nickerson) (02/19/89)
Has anyone noticed this problem in DMouse? Maybe it has been fixed already.
(I'm using the first version of it.)
A few days ago, I booted up my Amiga 1000 and, after installing DMouse and
such, one of my friends sat down and started lazily messing around with the
mouse. He went to the drag bar at the top of the initial window, pressed
both mouse buttons, and moved the mouse down the screen quickly. *BANG*
GURU. "Waitaminute," I said, "that must have been a fluke." I booted
again and tried the exact same thing. *BANG* No GURU, but the screen was
f**ked and the machine was locked up. I tried a third time. Same thing.
Has this been eradicated? Is it unique to my machine?
..Bill
--
Bill Nickerson | UUCP : {uunet|watmath|utai|garfield}!dalcs!aucs!840493n
Acadia University | BITNet : 840493n@Acadia
Wolfville, NS |--------------------------------------------------------
B0P 1X0 | ...held prisoner here for 4 years - paroled this May...usenet@cps3xx.UUCP (Usenet file owner) (02/20/89)
In article <1583@aucs.UUCP> 840493n@aucs.UUCP (Bill Nickerson) writes: > >Has anyone noticed this problem in DMouse? Maybe it has been fixed already. >(I'm using the first version of it.) >mouse. He went to the drag bar at the top of the initial window, pressed >both mouse buttons, and moved the mouse down the screen quickly. *BANG* >GURU. "Waitaminute," I said, "that must have been a fluke." I booted >again and tried the exact same thing. *BANG* No GURU, but the screen was Yes, it works like this: Have only one window on the screen, and no workbench. Place mousecursor on the windowdrawbar, pressandhold RMB press and hold LMB, you can now drag the window *off* the screen. If you drop the window completely on screen you wont crash the machine, usually.
dkanthar@rodan.acs.syr.edu (Devaprasad Kantharaj) (10/22/89)
I am sorry if this is a silly question, but what is Dmouse? I have seen many references made it. What exactly does it do? Thanks in advance... Prasad