dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/09/88)
After looking at and rejecting several mouse-intuition input handler enhancers (you know, accelerate the mouse, click-to-front, etc...) and finding them ALL useless, I have written my own. Before I release it, though, I need information on how to clear the intuition pointer sprite... as in turn it off after some timeout, then restore it when the mouse is moved. * I have tried GetPrefs()/SetPrefs(). This works, but has some nasty side effects, like propogating keyboard input to ALL console devices for a short period after you SetPrefs(). * No, SetWindowPointer() does NOT work.. this has got to be global. Assuming somebody can tell me how to do that one little item, I'll post it to comp.sys.amiga (it's small). What does it do? Oh yah: - Any option can be turned off. - Screen blanker after N1 seconds inactivity (def. 300 secs) - Mouse blanker after N2 seconds inactivity (def. 5 secs) (this is what I need info on how to do) - Auto Activate window when mouse moved over it - Mouse Accelerator. Back feeds power into the mouse unit, give it a nudge and it is guarenteed to penetrate up to an inch and a half of wall plaster. - Programmable command-key and command string ala PopCli, default left-Amiga ESC. - Left Mouse Button click in window brings it to the front DOES NOT BRING THE WINDOW TO THE FRONT IF IT IS ALREADY IN FRONT. Other programs would call WindowToFront() on every click, which is horrible if you have a simple-refresh window. - Hold LMB, click Right Mouse Button .. Window to Back! Great for cycling windows. - NO DAMN CLOCK. Use another utility to get a clock. - Uses a CLI (sorry), but is *small*... RUN able, of course, BREAK it to exit. -Matt
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/09/88)
> *Excerpts from ext.nn.comp.sys.amiga: 9-May-88 Finishing up YAIP (Yet Anot..* > *Matt Dillon@CORY.BERKELE (1740)* > After looking at and rejecting several mouse-intuition input > handler enhancers (you know, accelerate the mouse, click-to-front, etc...) > and finding them ALL useless, I have written my own. Good. Now we'll finally have one that works properly. > - Hold LMB, click Right Mouse Button .. Window to Back! Great > for cycling windows. Not so great if you are running WIconify (which uses this button combination to iconify windows). Is this feature switchable as well? I think the Amiga needs a three-button mouse. Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/10/88)
>> - Hold LMB, click Right Mouse Button .. Window to Back! Great >> for cycling windows. > >Not so great if you are running WIconify (which uses this button combination to >iconify windows). Is this feature switchable as well? > >I think the Amiga needs a three-button mouse. I agree. I didn't think of WIconify. I suppose I can have an option setting the qualifier required + RMB to get window to back. The default will be the left mouse button. -Matt
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/10/88)
In article <8805090351.AA04051@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > After looking at and rejecting several mouse-intuition input >handler enhancers (you know, accelerate the mouse, click-to-front, etc...) >and finding them ALL useless, I have written my own. Before I release it, >though, I need information on how to clear the intuition pointer sprite... >as in turn it off after some timeout, then restore it when the mouse is >moved. > > * I have tried GetPrefs()/SetPrefs(). This works, but has some > nasty side effects, like propogating keyboard input to ALL > console devices for a short period after you SetPrefs(). > Sounds like a bug to me, and should be reported if it hasn't already. > * No, SetWindowPointer() does NOT work.. this has got to be global. > At the risk of incurring the most Powerful and Awful Wrath of Jim Mackraz, I would suggest fiddling around with IntuitionBase. I picked through there once, and found a SimpleSprite structure which I presumed to be the structure that managed the default Intuition pointer. "Logic would suggest" that all you need to do is fiddle with it, pointing it to a blank sprite. The other thing you could do is to create a user copper list whose sole purpose in life is to turn off sprite DMA for sprite channel 0. This has a much lower probability of pissing off Jimm, but a higher probability of breaking on the Hedley hi-res monitor. An interesting puzzle, no? Jimm, help this guy so he can get to work on "resources". _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jimm@amiga.UUCP (Jim Mackraz) (05/11/88)
In article <5918@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: )In article <8805090351.AA04051@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: )> After looking at and rejecting several mouse-intuition input )>handler enhancers (you know, accelerate the mouse, click-to-front, etc...) )>and finding them ALL useless, I have written my own. As an input handler writer, I'd be interested in hearing what you think the problems are, or is it that they don't support your long list of features? )>Before I release it, )>though, I need information on how to clear the intuition pointer sprite... )>as in turn it off after some timeout, then restore it when the mouse is )>moved. )> )> * I have tried GetPrefs()/SetPrefs(). This works, but has some )> nasty side effects, like propogating keyboard input to ALL )> console devices for a short period after you SetPrefs(). )> ) Sounds like a bug to me, and should be reported if it hasn't )already. I've mailed it in. Please mail bugs to cbmvax!bugs, Matt. Now is the time, and your contributions are important. thnx. ) At the risk of incurring the most Powerful and Awful Wrath of Jim )Mackraz, I would suggest fiddling around with IntuitionBase. Wrath? No wrath here, but my little joke about your system-programming sensibilities is getting a little less funny ;^) ) I picked through there once, and found a SimpleSprite structure )which I presumed to be the structure that managed the default Intuition )pointer. "Logic would suggest" that all you need to do is fiddle with it, )pointing it to a blank sprite. Will not work in future releases of the OS, and maybe not the current one. ) The other thing you could do is to create a user copper list whose )sole purpose in life is to turn off sprite DMA for sprite channel 0. Sounds interesting. I put an example on the DevCon disks of an input stealer that uses sprite 0 and gives it back. It grabs it by saying ChangeSprite() or MoveSprite() and by being careful to deny Intuition() of all input, so (in most cases) Intuition will not ChangeSprite() or MoveSprite() which grabs it back. In my example, saying SetPointer() or ClearPointer() immediately causes Intuition to call ChangeSprite(), which reappears the normal mouse pointer, because my window is active at the time of the call. In your case, half of this might work: you can ChangeSprite() to whatever (something invisible?) and deny Intuition input. Sprite gone. To reappear, if you have a window, call ClearPointer(). Else, when the mouse is moved (which you can force from an input handler, by the way) the Intuition call to MoveSprite() will do the trick. Send mail if you need details, and let me know more about this propogation of keystrokes business. First glances at our end (no attempt at reproducing yet) make it hard to imagine how it happens. By the way, it is probably not a good idea for programs to call Intuition functions (such as SetPrefs) from an input handler. I can identify problems that might occur with locking, and there are probably others. My intuition helper (IHelp) has input device signal or message a normal application task which calls Intuition for move windows and so on. I bet yours does the same. 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) (05/11/88)
:By the way, it is probably not a good idea for programs to call Intuition :functions (such as SetPrefs) from an input handler. I can identify problems :that might occur with locking, and there are probably others. My :intuition helper (IHelp) has input device signal or message a normal :application task which calls Intuition for move windows and so on. I bet :yours does the same. : : jimm Right. I was calling SetPrefs() from a slave task ... the input handler simply Signal()d it. However, I *am* calling WindowToFront(), WindowToBack(), WindowToBack(), and WhichLayer() from my handler. Is that OK? I was under the impression that intuition doesn't depend on input device timer ticks to be able to execute such operations. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/11/88)
>As an input handler writer, I'd be interested in hearing what you think >the problems are, or is it that they don't support your long list of >features? Blatent bugs, like in MachII it always turns on the clock on startup no matter what I set the clock option to. MachII also called WindowToFront() everytime you clicked in the window, causing havoc with simple_refresh windows. I wonder how many of these accelerators don't work with the workbench because they call WindowToFront or ActivateWindow before the user lets go the button when moving an icon from one window to another? Sunmouse didn't even work on my system! PopCli is getting closer, but for some reason has a tendancy to crash my machine. Various derivatives appear to work, but don't have the features I want. But the very worst thing these programs do is not provide the source! And then some people have the gaul to call their creations shareware. Give me a break! Of course, all in all, your second comment is the correct answer... the other programs just don't do what I want. I got fed up not being able to customize the program (not having source) so I wrote my own. Next installment (fixing the interlace bug) comming soon. Oh what the hell, I'll spend some time and make it a handler so you can endcli (for you workbench users). Comming soon... -Matt
peter@sugar.UUCP (Peter da Silva) (05/11/88)
In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > - Screen blanker after N1 seconds inactivity (def. 300 secs) How about a screen dimmer? To do this generally would be pretty hard (how do you dim a HAM image), but it'd be easy to instead of putting up a blank screen, put up a dimmed out copy of the workbench screen. That's what the Lisa screen saver does (well, it dims the CRT, but it's the same visual effect). Perhaps a progressive dim-out? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
page@swan.ulowell.edu (Bob Page) (05/11/88)
Since nobody's mentioned it yet, I'll put in a plug for Commodities
Exchange. The version I have (v0.3) sits in front of Intuition in the
input food chain and allows Message Brokers to pass input events to
applications that have requested them. On the distribution disk are
such gems as a program to strip the CAPSLOCK bit from all input, and
a DMouse-like application. Future (current?) versions can also sit
behind Intuition.
I mention it because at this point we have 107 different applications
vying for input events, and nobody to manage it. I know of at least
three 'hotkey' programs that have L.ALT-ESC hardwired in, for example.
I type the 'F10' key in ConMan to throw window-to-back ... oops, I'm
in WACK, so I get a 'symbols' listing.
Commodities Exchange is the AREXX of input events. I wish everybody
had it, or that it would be in WB1.3. Rumors are that it will be
in WB1.4 ... maybe too late.
It was written by Mr. Event Handler himself, Jim Mackraz.
I don't know the redistribution deal with Commodities Exchange.
As an aside, many of these input event enhancers could possibly be
made part of Intuition in "a future release."
jimm@cloyd.UUCP (Jim Mackraz) wrote:
>I put an example on the DevCon disks of an input stealer that uses sprite 0
Although I announced availability of this via FTP, there were some
concerns about its redistribution, and after talking to Carolyn and
JimM, I decided to remove it. (if you went looking for the CLIP:
handler -- it had some problems, so I pulled it as well).
..Bob
--
Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!pagepage@swan.ulowell.edu (Bob Page) (05/11/88)
dillon@CORY.BERKELEY.EDU (Matt Dillon) wrote: >MachII ... Sunmouse ... PopCli ... Various derivatives >But the very worst thing these programs do is not provide the source! I have source to all of these. Well, I don't know about SunMouse; but Click#?Front, Mackie, various snip programs, etc as well. All were part of the archive I downloaded from wherever (usenet, peoplelink, etc). >I got fed up not being able to customize the program (not having source) >so I wrote my own. It's often easier to do that anyway, since you (generic you) don't have to learn somebody else's code (and mindset) first. But the sources are available. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
jimm@amiga.UUCP (Jim Mackraz) (05/12/88)
In article <8805110206.AA19547@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
):By the way, it is probably not a good idea for programs to call Intuition
):functions (such as SetPrefs) from an input handler. I can identify problems
):that might occur with locking, and there are probably others. My
):intuition helper (IHelp) has input device signal or message a normal
):application task which calls Intuition for move windows and so on. I bet
):yours does the same.
):
): jimm
)
) Right. I was calling SetPrefs() from a slave task ... the input
)handler simply Signal()d it. However, I *am* calling WindowToFront(),
)WindowToBack(), WindowToBack(), and WhichLayer() from my handler. Is
)that OK? I was under the impression that intuition doesn't depend on
)input device timer ticks to be able to execute such operations.
)
) -Matt
WhichLayer() is probably OK, but WindowTo*() isn't safe. WhichLayer() is not
an Intuition call, but may (or may not) lock layers, in which case
it is dangerous.
You may be lucking out,
in that you don't call these functions when Intuition is in the middle of
a prop gadget or something, but it MAY be that calling these functions
from the input handler violate the locking order protocol that Intuition
observes itself. For example: we all know that when dragging an Icon,
WindowToFront() will hang the system. This is because workbench has
the layers locked, and Intuition needs the layer locks to do
WindowToFront(), so the input stops while Intuition waits for the locks,
which WB won't free until it hears a mouse up. Deadlock.
The fix for this will be in the Intuition() input handler. Now, if this
and similar situations don't happen to arise because of the specifics
of your user interface, you're off the hook, for now. I think you
can appreciate that the general advice must stand, though. "Don't
call Intuition from the input.device task." If it works for you, and you
would'nt mind updating your software if it stops working in a future
release, feel free to use whatever works. No police action here, just
no guarantees.
Anyway, I'm still interested in hearing (maybe email) you general comments
on input handlers. Have you looked at Commodities? My claim is that
it should make your application trivial to write, and further that the
examples using it (in this case autopoint2) have something to offer.
Current version was written with a future performance tune in mind (which
I am about to start on), but apart from performance, I'm wondering what
it might lack.
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.juan@gatech.edu (Juan M. Orlandini) (05/12/88)
In article <1963@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > - Screen blanker after N1 seconds inactivity (def. 300 secs) > > How about a screen dimmer? To do this generally would be pretty I LIKE IT!! I WANT IT!!! PLEASE MATT ADD THIS TO DMOUSE. PLEASE. // _______ // "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
Chad_The-Walrus_Netzer@cup.portal.com (05/12/88)
In article <8805110247.AA21015@cory.Berkeley.EDU> (Matt Dillon) writes: > But the very worst thing these programs do is not provide the >source! And then some people have the gaul to call their creations >shareware. Give me a break! Hmmmm. Brian Moats has been distributing the source for Mach since release 1.6 (I have the source for 1.6(which is what I prefer to use) and Mach II)... In reference to this, I need to answer a couple more of your statements. > Blatent bugs, like in MachII it always turns on the clock on startup >no matter what I set the clock option to. MachII also called WindowToFront() >everytime you clicked in the window, causing havoc with simple_refresh >windows. I wonder how many of these accelerators don't work with the >workbench because they call WindowToFront or ActivateWindow before the user >lets go the button when moving an icon from one window to another? All of these problems have been addressed in Mach. The Mach source code lets you compile in the Clock option (Making it MachClk, rather than Mach) by changing a single #define (really nice). Usually the program is distributed in both the regular and clock form (as well as the source), so It seems strange you didn't get either. The programmer has also addressed the bug of WindowToFront() while holding an Icon (I forget his specific solution, but it was along the lines of doing a case check to make sure this doesn't happen). > Of course, all in all, your second comment is the correct answer... >the other programs just don't do what I want. I got fed up not being able >to customize the program (not having source) so I wrote my own. YES, having the source code IS very important. In fact, I customized my version of Mach so that upon a screen blank, It calls a function I created which does all kinds of bizzare screen things ALA Mackie). Stuff without source is a sin. (Generally speaking) So anyway, I'll mail you both (shar'ed) sources tonight... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chad 'The_Walrus' Netzer -> AmigaManiac++ "8 Data Bits, 2 Stop Bits???? That's a bit too much."
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/12/88)
>WhichLayer() is probably OK, but WindowTo*() isn't safe. WhichLayer() is not >an Intuition call, but may (or may not) lock layers, in which case >it is dangerous. The main problem I face moving WindowTo*() to another task is that there isn't much assurance the layer will stick around between determining the window ptr and the other task actually doing the WindowTo*(). Right now, I Forbid() BEFORE WhichLayer() and Permit() AFTER WindowTo*(). Now I realize that the two calls can block and temporarily undo the Forbid(), but WhichLayer() would only block getting its locks, and WindowTo*() is hopefully sequenced inside Intuition (I don't know) so if intuition blocks, somebody else doing a CloseWindow() won't get his call done before mine. I can't move WhichLayer() to the other task because that will involve two task switches for every mouse event! Am I making sense? >You may be lucking out, >in that you don't call these functions when Intuition is in the middle of >a prop gadget or something, but it MAY be that calling these functions >from the input handler violate the locking order protocol that Intuition >observes itself. For example: we all know that when dragging an Icon, >WindowToFront() will hang the system. This is because workbench has >the layers locked, and Intuition needs the layer locks to do >WindowToFront(), so the input stops while Intuition waits for the locks, >which WB won't free until it hears a mouse up. Deadlock. Actually, that came up early testing. I was calling WindowToFront() *while* moving a workbench icon from a WB window to the backdrop. The icon-move simply aborted... which is incorrect operation of course so the release version of DMouse does not ever call WindowTo*() while the LMB is being held down. This probably saves my ass in a couple of cases. >Anyway, I'm still interested in hearing (maybe email) you general comments >on input handlers. Have you looked at Commodities? Haven't looked at Commodities yet. When I find the time... If I find the time... Sigh. Actually, if you think about it, the all-in-one utilities probably load the input handler less than a whole bunch of one-in-one utilities, commodities or not. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/12/88)
> How about a screen dimmer? To do this generally would be pretty > hard (how do you dim a HAM image), but it'd be easy to instead of I thought of that, but after seeing burn-in on many an office CRT, I decided that if the guy leaves his computer for that long a period of time, it would be better to blank the screen. My best solution is actually on an IBM-PC (don't laugh!) This PC is used as a database storage and retrieval system for a telemetry system and thus is left on 24 hours a day, 7 days a week, 365 days a year. To prevent employees from thinking the machine is off, I wrote a screen saver which 'pong'd the date and time around the (blank) screen. P.S. You might wonder about the harddrive. We've got a Bernoulli (sp) Box connected to it ... 80 Meg Winchester + two 20 Meg cartridges. The Winchester has been ON 24 hours a day for the last two years! ok .. subtract maybe a week total for maintenance. No power failures though, the whole system is running under a UPS. -Matt
jimm@amiga.UUCP (05/12/88)
In article <8805120833.AA03541@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
) The main problem I face moving WindowTo*() to another task is that
)there isn't much assurance the layer will stick around between determining
)the window ptr and the other task actually doing the WindowTo*().
WindowToFront() does a sanity check on the existence of the window
(amazingly enough).
) I can't move WhichLayer() to the other task because that will
)involve two task switches for every mouse event!
I also use a signal instead of a message so that I might not call
WhichLayer() for every mouse movement.
Well, if you start getting deadlocks, you might throw in an
AttemptSemaphore() on the SignalSemaphore inside the LayerInfo before
calling WhichLayer(). (Simulating a call "AttemptLockLayerInfo()".)
Note, by the way, that one good test for Sun-style window activation is
the Workbench rename window/gadget. AutoPoint2 (commodities example)
passes this one, but I don't use it, so I might have missed other
pathologies.
) Am I making sense?
More or less, eh?
) Haven't looked at Commodities yet. When I find the time...
)If I find the time... Sigh. Actually, if you think about it, the all-in-one
)utilities probably load the input handler less than a whole bunch of one-in-one
)utilities, commodities or not.
) -Matt
Well, if it really is All-in-one, and until Commodities is a little
lighter on its feet, you might be right. It's point is to have only
one Input Handler around for multiple applications, with user-interface
standardization and ease of application development right up there with
"load."
I don't think All-in-one is going to be true for other people. I already
have plans for input thieves that aren't appropriate for being
always loaded (like my hostile picture snipper). Priority between
key translators and hotkey programs is also a thorny problem.
Anyway, I never fault anyone for carving their own development environment.
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 (05/13/88)
In article <1963@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > - Screen blanker after N1 seconds inactivity (def. 300 secs) > > How about a screen dimmer? Better yet, how about executing a program after timeout? When the program exits, assume something happened to signal that the screen shouldn't be blanked anymore, and that the screen is the way it was when the blanking prog was executed. This would let anyone write their own blank-screen routine to do whatever they like. Someone could even write a screen blanker that required a password to leave blank-screen mode. Doesn't seem like it would be any harder to execute a program than to call a subroutine, the commandline parser would just have to be fixed up. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
scott@applix.UUCP (Scott Evernden) (05/13/88)
In article <8805110247.AA21015@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >... I wonder how many of these accelerators don't work with the >workbench because they call WindowToFront or ActivateWindow before the user >lets go the button when moving an icon from one window to another? Sunmouse >didn't even work on my system! Sunmouse doesn't call WindowToFront() or ActivateWindow(); it merely injects a mouse click into the input stream before the 1st keystroke after any mouse motion. I think HeliosMouse does the same, but I might be wrong. -scott
schein@cbmvax.UUCP (Dan Schein CATS) (05/13/88)
In article <1963@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > > That's what the Lisa screen saver does (well, it dims the CRT, but > it's the same visual effect). Perhaps a progressive dim-out? I had fooled around with progressive dim-out a few weeks ago... For the quick approach (IE: Easy access) Try using Blanker (should have been called Dimmer) for 300 seconds and PopCLI for 600 seconds. After 5 minutes of inactivity your screen dims and after 10 minutes it goes black. >-- >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Dan "Sneakers" Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ Call BERKS AMIGA BBS - 24 Hrs - 3/12/2400 Baud - 40Meg - 215/678-7691 +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/13/88)
> Hmmmm. Brian Moats has been distributing the source for Mach > since release 1.6 (I have the source for 1.6(which is what I prefer to > use) and Mach II)... In reference to this, I need to answer a couple > more of your statements. Why do you prefer to use it? I installed Mach 1.6 on my Amiga for two days. The frequent gurus stopped when I removed it. After having too many gurus lately for no apparent reason, I've dropped the cavalcade of "background" software to FaccII, ConMan and Dmouse. Hopefully things will return to normal... --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/13/88)
> Hmmmm. Brian Moats has been distributing the source for Mach > since release 1.6 (I have the source for 1.6(which is what I prefer to > use) and Mach II)... In reference to this, I need to answer a couple > more of your statements. Why do you prefer to use it? I installed Mach 1.6 on my Amiga for two days. The frequent gurus stopped when I removed it. dropped the cavalcade of "background" software to FaccII, ConMan and Dmouse. Hopefully things will return to normal... --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/13/88)
> Hmmmm. Brian Moats has been distributing the source for Mach > since release 1.6 (I have the source for 1.6(which is what I prefer to > use) and Mach II)... In reference to this, I need to answer a couple > more of your statements. Why do you prefer to use it? I installed Mach 1.6 on my Amiga for two days. The frequent gurus stopped when I removed it. dropped the cavalcade of "background" software to FaccII, ConMan and Dmouse. Hopefully things will return to normal... --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas
langz@athena.mit.edu (Lang Zerner) (05/13/88)
I've been using dmouse 1.03 for a bit now and I have a little aesthetic
objection. However, it is a picky thing that is probably more of a pain in the
but to handle than it's worth.
I almost always have a nearly full screen CLI window on my WB screen.
I had the following situation:
WINDOW1 is in front of the CLI window.
The CLI window is in front of WINDOW2.
I want to do some stuff in WINDOW2.
When I click in the Window-to-Back gadget in the CLI window, instead of the
window just going to the back, it goes to the front *then* goes to the back.
Furthermore, if there isn't anything behind the window but I don't know that
and try to check: (1) I click the Window-to-Back gadget, (2) the whole screen
is filled with the full-screen CLI window for the time it takes to click the
button, (3) the CLI window stays at the back (since I just clicked the button.
This looks and feels really ugly, but it makes sense under dmouse.
A way I've seen this fixed is in ClickToFront (or was it ClickUpFront?), which
requires a double-click to bring the window up. When I thought about that some
more, I realized that it isn't such a bad idea, since then dmouse could have an
*orthogonal* system which would not require keyboard modifiers or the kludgy
and already overused left-right click:
Double click left: bring window to front.
Double click right: push window to back.
(And the same for screens if you double click without a window under the
pointer.)
Possible problems:
(1) You have to be careful not to be over an icon when you are bringing
a window or screen to the front, unless you want to open the icon
while you are at it.
(2) There is some contention if you use an application that uses
a DoubleMenuRequest. But then again I have only ever seen one
of these, and I can't even remember what it's called. Hmmm...
Well, there you have it. That's how I'd like dmouse to be changed, before
`backward-compatibility' becomes a real major issue :-)
Be seeing you...
Lang Zerner langz@athena.mit.edu ihnp4!mit-eddie!athena.mit.edu!langz
"Many a good hanging prevents a bad marriage..."
-- Bill Shakespeare, Twelfth Night, I.v.19peter@sugar.UUCP (Peter da Silva) (05/13/88)
In article <7002@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > Commodities Exchange is the AREXX of input events. I wish everybody > had it, or that it would be in WB1.3. Rumors are that it will be > in WB1.4 ... maybe too late. No, it's better than AREXX because it doesn't force a bogus PL/I lookalike language on you. It's more like a super-streams. I do hope that, since AREXX seems to becoming the standard, Comm-Ex will get an AREXX interface before too long. I still don't see that AREXX is *the answer* to IPC, but it's useful enough as a control language. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
doug-merritt@cup.portal.com (05/13/88)
Scott Everndon says: >Sunmouse doesn't call WindowToFront() or ActivateWindow(); it merely injects >a mouse click into the input stream before the 1st keystroke after any >mouse motion. I think HeliosMouse does the same, but I might be wrong. Someone was asking previously, "what's wrong with existing handlers like Sunmouse etc?" This is the answer...they do a mouse click. I stopped using the other ones because of this behavior; it doesn't always work right. Consider Dpaint, for instance. A mouse click on the screen causes a mark to be made on your painting! Bleah. That's why I like the idea of dmouse; I'd been looking for one that did it "right". --- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug