dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/13/88)
: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. Just change the qualifier that goes with the RMB to bring the window to the back. example: -R1 sets it to left-shift (leftshift-RMB instead of LMB-RMB). NOTE TO ALL DMOUSE USERS: The -R option is not documented well. you give it a set of qualifiers in hex and if *any* one exists when you hit the RMB, it executes the window/screentoback function. That is: -R1 will give you leftshift-RMB, -R3 will give you anyshift-RMB, etc... value is in HEX. The misrepresentation in the documentation is that the docs say 'you should OR it with 8000'.... Right for -Q, wrong for -R. -Matt
langz@athena.mit.edu (Lang Zerner) (05/14/88)
I wrote: >>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. In article <8805130348.AA00528@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) replies: > Just change the qualifier that goes with the RMB to bring the window >to the back. example: -R1 sets it to left-shift (leftshift-RMB instead of >LMB-RMB). I'm not talking about using the qulifier-rightbutton combo method. I'm talking about the old fashioned, click-the-left-mouse-button-in-the-WindowToBack-gadget (you know, the second gadget from the upper right-hand corner of the window?) method. Try it! The window comes to the front and *then* goes to the back. As I mentioned this is to be expected givent the conflicting messages from dmouse (left button anywhere == WindowToFront) and WB (left button in Back gadget == WindowToBack). It's got nothing to do with qualifiers, coz we're talking about a plain ol' left button click. I still say allow double-click left = Front, double-click-right = Back. It's orthogonal, less kludgy, and it works. 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.19
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/14/88)
>gadget == WindowToBack). It's got nothing to do with qualifiers, coz we're >talking about a plain ol' left button click. I still say allow double-click >left = Front, double-click-right = Back. It's orthogonal, less kludgy, and it >works. And it takes two clicks to do it, and it means either delaying the first click until we know it isn't a double or not delaying it and seeing side effects (like the menu comes up). I'm going for convenience. At this point I use the window-to-front/back options so much with DMouse that a double click requirement would become infuriating! I carefully chose the sequences: * single click on LMB to bring the window forward because this operation is executed by the user most often * LMB-RMB (or whatever other qualifier-RMB). A somewhat more complication operation which nevertheless can be SOLELY accomplished with the Mouse. The default takes into account the fact that the user most likely has the window in the foreground already, (thus the LMB is the default qualifier for the RMB). But, hold a minute... there is no reason for you to hit the window-to-back gadget anyway! Just use (-Rqual)-RMB. It's called fixing the problem by taking an alternate course. There is still the 'problem' with the close gadget (same thing: window comes to front before closing), but hell, that isn't too much to ask is it? -Matt
langz@athena.mit.edu (Lang Zerner) (05/14/88)
In article <8805132256.AA26259@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > But, hold a minute... there is no reason for you to hit the >window-to-back gadget anyway! Just use (-Rqual)-RMB. It's >called fixing the problem by taking an alternate course. There is >still the 'problem' with the close gadget (same thing: window comes to >front before closing), but hell, that isn't too much to ask is it? Don't get me wrong, Matt. I think dmouse is the greeatest thing to happen to my Amiga since ConMan. The real problem I'm trying to work around is the dmouse conflict with wIconify; they both use the left-to-right double click. If the dmouse push-to-back maneuver requires using the keyboard I won't use it (push-to-back, that is, not dmouse), for exactly the convenience factor you mention. Ideally, I'd ask the author of wIconify to allow a qualifier-key system like you do, or perhaps to use right-button *drag* (hit the right button, then wiggle it around in the window you want to iconify). But he didn't ask for comments on what we'd like to see done to his piece, and you did. One more time, for the record: I LOVE DMOUSE! 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.19
joels@tekred.TEK.COM (Joel Swank) (05/17/88)
In article <5332@bloom-beacon.MIT.EDU>, langz@athena.mit.edu (Lang Zerner) writes: >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. This is related to another problem. Because Dmouse uses a single click to bring a window forward, a window that is active must be the forwardmost window. This is why I can't use Dmouse. I need to be able to look at one window while typing into a window behind it. Joel Swank Tektronix, Redmond, Oregon joels@tekred.TEK.COM
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/17/88)
:In article <5332@bloom-beacon.MIT.EDU>, langz@athena.mit.edu (Lang Zerner) writes:
:>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.
:
:This is related to another problem. Because Dmouse uses a single click to
:bring a window forward, a window that is active must be the forwardmost
:window. This is why I can't use Dmouse. I need to be able to look at one
:window while typing into a window behind it.
:
:Joel Swank
:Tektronix, Redmond, Oregon
:joels@tekred.TEK.COM
You are wrong (sorry!), but simply moving a pointer over another
window, whether it is in the foreground or not, activates it. You don't
have to click at all. I agree that DMouse isn't perfect... it isn't possible
to write any program of that type which satisfies everyone, but It's the
best solution I could come up with.
-Mattjoe@cbmvax.UUCP (Joe O'Hara) (05/17/88)
In article <2528@tekred.TEK.COM> joels@tekred.TEK.COM (Joel Swank) writes: >This is related to another problem. Because Dmouse uses a single click to >bring a window forward, a window that is active must be the forwardmost >window. This is why I can't use Dmouse. I need to be able to look at one >window while typing into a window behind it. Not so. Simply placing the pointer anywhere in a window will activate that window. Clicking is not required. -- ======================================================================== Joe O'Hara || Comments represent my own opinions, Commodore Electronics Ltd || not my employers. Any similarity to Software QA || to any other opinions, living or dead, || is purely coincidental. ========================================================================
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/18/88)
Joel Swank writes: > This is related to another problem. Because Dmouse uses a single click to > bring a window forward, a window that is active must be the forwardmost > window. This is why I can't use Dmouse. I need to be able to look at one > window while typing into a window behind it. No. Since Dmouse makes the window that the pointer is on top of the active window, you can type into a window behind the frontmost window merely by placin the pointer on the window and typing without ever clicking the mouse. Perhaps you've never actually tried Dmouse? --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"
u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) (05/18/88)
Michael Portuesi writes: >Joel Swank writes: >> ... active must be the forwardmost window. >> This is why I can't use Dmouse. I need to be able to look at one >> window while typing into a window behind it. > >No. Since Dmouse makes the window that the pointer is on top of the >active window, you can type into a window behind the frontmost window >merely by placin the pointer on the window and typing without ever >clicking the mouse. Perhaps you've never actually tried Dmouse? > >Michael Portuesi / Carnegie Mellon University >ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas One other point that may have been overlooked is that you can turn off the feature which activates the window the pointer is in. The -A0 flag turns it off, and -A1 turns it on. That should solve the whole problem of having one window current, even if not visible, while looking at another. Take a good look at all the neat parameters that the program can use. Dmouse is a really slick program. I have been waiting for something that can be tailored so nicely to fit my own personal needs. (I am too lazy/busy to do it myself) /| | /||| /\| | John M. Olsen \|()|\|\_ |||. \/|/)@|\_ | 1547 Jamestown Drive | | Salt Lake City, UT 84121-2051 u-jmolse@ug.utah.edu or ...!ihnp4!utah-cs!utah-ug!u-jmolse
chas@gtss.UUCP (Charles Cleveland) (05/18/88)
In article <sWY=v3y00VAAQ8S29A@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes:
)
)No. Since Dmouse makes the window that the pointer is on top of the
)active window, you can type into a window behind the frontmost window
)merely by placin the pointer on the window and typing without ever
)clicking the mouse.
So say half the people on the net. However, insane as it seems, some of us
actually turn off the Activate-the-Window-under-the-Mouse Mode. I do it
because I like to answer Requestors with Amiga-V or Amiga-B, and unless the
mouse is where the Requestor is going to pop up, I have to move it there to
answer the Requestor.
I'm not where I can try this but I have a suggestion for the person who
wanted to write in a window not the frontmost one (presuming that he has
his Activate-the-Window Mode set like mine). Try clicking in the
Window-to-Back gadget in the window you want to write in. I believe this
will 1) cause DMouse to pull the window to the front and then 2) cause
Intuition to activate the window and push it to the back. Of course if
you have more than two windows this may still not do what you want unless
you can move the irrelevant windows out of the way.
--
- It is better for civilization to be going down the drain than to be -
- coming up it. -- Henry Allen -
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332
UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edujoels@tekred.TEK.COM (Joel Swank) (05/18/88)
In article <8805170744.AA28410@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > : (I wrote) > :This is related to another problem. Because Dmouse uses a single click to > :bring a window forward, a window that is active must be the forwardmost > :window. This is why I can't use Dmouse. I need to be able to look at one > :window while typing into a window behind it. > > You are wrong (sorry!), but simply moving a pointer over another > window, whether it is in the foreground or not, activates it. You don't > have to click at all. True, I forgot to mention that I had sunmouse turned off. This results in the above mentioned problem. (I keep sunmouse turned off on my SUN too, because I like AmigaMouse better). > I agree that DMouse isn't perfect... it isn't possible > to write any program of that type which satisfies everyone, but It's the ^^^^^^^^^^^^^^^^^^^^^^^^ > best solution I could come up with. > > -Matt Yes, but by making all the features optional and providing source you come pretty close. Thanks. Joel Swank Tektronix, Redmond, Oregon joels@tekred.TEK.COM
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/19/88)
Well, what do people think of the following solution?:
add a switch to set the # of clicks required (1, 2, 3... 10) ... To
activate the window. I.E. -c#, where the default is 1?
-Mattejkst@cisunx.UUCP (Eric J. Kennedy) (05/19/88)
In article <251@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: >No. Since Dmouse makes the window that the pointer is on top of the >active window, you can type into a window behind the frontmost window >merely by placin the pointer on the window and typing without ever >clicking the mouse. I avoid these problems by disabling the click-to-front feature of dmouse and using wKeys to do most, if not all, of my window/screen rearranging. That way, I never have to click in the windows, because whenever I rearrange windows, the one under the pointer is automagically activated. Very handy. -- ------------ Eric Kennedy ejkst@cisunx.UUCP
chas@gtss.UUCP (Charles Cleveland) (05/20/88)
In article <9836@cisunx.UUCP> ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) writes: )In article <251@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: ) )>No. Since Dmouse makes the window that the pointer is on top of the )>active window, you can type into a window behind the frontmost window )>merely by placin the pointer on the window and typing without ever )>clicking the mouse. ) . . . )------------ )Eric Kennedy )ejkst@cisunx.UUCP I never the hell ever said any such thing. :-( -- - It is better for civilization to be going down the drain than to be - - coming up it. -- Henry Allen - Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332 UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edu