dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/24/87)
I happen to *like* the way the Amiga handles window activation... I don't want a window to activate whenever I move my mouse into it. How about this for 1.3: If a window gets closed and it is the active window, then the new active window must be picked from the remaining windows on the screen. Why don't you pick the one under the mouse?? It would be utterly trivial to write a program to handle this... simply catch CloseWindow(), do the CloseWindow(), then push a mouse click into the input event stream. -Matt
gary@eddie.MIT.EDU (Gary Samad) (06/26/87)
In article <8706241834.AA13064@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: } }How about this for 1.3: } } If a window gets closed and it is the active window, then the new }active window must be picked from the remaining windows on the screen. Why }don't you pick the one under the mouse?? } } It would be utterly trivial to write a program to handle this... }simply catch CloseWindow(), do the CloseWindow(), then push a mouse click }into the input event stream. Not intending to specifically pick on you Matt, but puhleeze don't add anything to the OS that starts sending false mouse clicks down the input streams!! It's one thing if people want to torture themselves by running daemons that send these clicks and double clicks around but don't force me to deal with unwanted gadget activations, etc. that are caused by unintentional mouse clicks. For you guys simply running CLIs, these click daemons are fine but, watch out! Don't leave your mouse sitting in a window pointing at a gadget or scrollbar when you activate one of these things! And, by the way, to some programs (such as The Microfiche Filer) double-clicks are meaningful and if you run one of these double-click-eaters you cannot effectively use the program! This is not to say that these programs are not useful to some people, but it would be a grave mistake to add something like this to the OS. Thank you. Gary
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/26/87)
In article <6192@eddie.MIT.EDU> Gary Samad typed: }In article <cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: }} }} How about this for V1.3: [...] }} [It] would be utterly trivial to write a program to handle this... }} simply catch CloseWindow(), do the CloseWindow(), then push a mouse click }} into the input event stream. }} } [puhleeze] don't add anything to the OS that starts sending false mouse } clicks down the input streams!! It's one thing if people want to torture } themselves by running daemons that send these clicks and double clicks } around but don't force me to deal with unwanted gadget activations, etc. } that are caused by unintentional mouse clicks. You are correct, dumping click events into the input stream is a nasty thing to do. What is needed is a way to say to Intuition, ActiveateWindowUnderPointer() or, better, WhichWindowIsUnderThePointer() I tried to ask JimM this question at a recent BADGE meeting, but did not quite get to it. SunMouse would then become a respected member of society, as would the idea you complained about. AutoFacc is just plain dirty, and will soon be obsoleted by Facc II, anyway. Have any more click-ish programs to complain about? While on the subject of needed Intuition tricks, how about RethinkWindow(). It would rethink a window, primarily the size and position, in one atomic step. This would eliminate the need for a TWO step move THEN size operation. > And, by the way, to some programs (such as The Microfiche Filer) double-clicks > are meaningful and if you run one of these double-click-eaters you cannot > effectively use the program! [ That's my goldfish you just stepped on! :-] If you are referring to the only double-click program I know of, ClickToFront, you're wrong. ClickToForont does not eat anything but ~50 bytes of RAM. The thing that can trip ClickToFront up is if something like SunMouse or Matt's idea dumps a fake click event into the stream. Try ClickToFront with Microfiche, or just with the Workbench tool. Both use double-clicks, and both integrate smoothly. >-------- > This is not to say that these programs are not useful to some people, but > it would be a grave mistake to add something like this to the OS. Not to rule on the merit of these ideas in particular, but I'm convinced that they could be added to the OS with no problems. Also remember that when something becomes part of the OS everyone will get a chance to test their stuff out with it, and problems can be compensated for. The Amiga is amazingly tollerant and forgiving as to the amount of stuff you may muck with externally before something breaks. The only grave is the lack of innovation, enhancemnt and change. } Thank you. } Gary |\ /| . Ack! (NAK, EOT, SOH) {o o} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U Single tasking? Just stare at them for a moment, then start to laugh.
tadguy@xanth.UUCP (Tad Guy) (06/26/87)
In article <8706241834.AA13064@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I happen to *like* the way the Amiga handles window activation... >I don't want a window to activate whenever I move my mouse into it. How >about this for 1.3: [Description of Yet Another Window Activation Procedure deleted]. > -Matt No. What *really* should happen is we should get another screen in Preferences with your suggestion, point-to-type, click-to-type and any other window selection method to choose from. I don't want to be locked into one particular window selection scheme; I want the one I prefer. Maybe handing it like printer selection is handled now, with loadable drivers? ...tad -- Tad Guy (804)-440-4529 UUCP: tadguy@xanth.UUCP Old Dominion University or: ...!seismo!xanth!tadguy Department of Computer Science CSNET: tadguy@odu.CSNET Norfolk, Virginia 23508 old ARPA: tadguy%xanth.cs.odu.edu@RELAY.CS.NET
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (06/27/87)
In article <8706260624.AA20450@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >In article <6192@eddie.MIT.EDU> Gary Samad typed: >}In article <cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >}} How about this for V1.3: [...] >}} [It] would be utterly trivial to write a program to handle this... >}} simply catch CloseWindow(), do the CloseWindow(), then push a mouse click >}} into the input event stream. >}} >} [puhleeze] don't add anything to the OS that starts sending false mouse >} clicks down the input streams!! > >You are correct, dumping click events into the input stream is a nasty thing >to do. What is needed is a way to say to Intuition, >ActiveateWindowUnderPointer() or, better, WhichWindowIsUnderThePointer() It's easy. First, find out the screen coordinates of the mouse pointer (trivial). Then, call the layers.library function WhichLayer(). This will return a pointer to the layer that the specified X,Y coordinates are inside. Then, search through the linked list of windows and find the one with the same layer address. >While on the subject of needed Intuition tricks, how about RethinkWindow(). >It would rethink a window, primarily the size and position, in one atomic >step. > Yes, please. Another vote for this one, too. Note that it is an addition to the layers.library, not Intuition. >The Amiga is amazingly tollerant and forgiving as to the amount of stuff >you may muck with externally before something breaks. > Hmmm. I don't know. I think the system would get *terribly* annoyed if you had Robotroff, Ping, AutoPoint, and Facc I all running at the same time. :-) :-) :-) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
lachac@topaz.rutgers.edu (Gerard Lachac) (06/27/87)
In article <1418@xanth.UUCP> tadguy@xanth.UUCP (Tad Guy) writes: > >No. What *really* should happen is we should get another screen in >Preferences with your suggestion, point-to-type, click-to-type and any >other window selection method to choose from. I don't want to be locked >into one particular window selection scheme; I want the one I prefer. > >Maybe handing it like printer selection is handled now, with loadable drivers? Hey, and while we're fantasizing how about including a font selection menu in preferences. I know this has been suggested before (but in case everyone forgot :-) but it would be nice to see a requestor for default system font built into the system-configuration scheme. Sort of like incorporating SETFONT into preferences... -- "Truth is false and logic lost..." - Neil Peart (who at the time didn't realize he was talking about RU) lachac@topaz.rutgers.edu <--------OR--------> {seismo|ames}!rutgers!topaz!lachac
gary@eddie.MIT.EDU (Gary Samad) (07/07/87)
In article <8706260624.AA20450@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: }In article <6192@eddie.MIT.EDU> I typed: }> And to some programs (such as The Microfiche Filer) double-clicks }> are meaningful and if you run one of these double-click-eaters you cannot }> effectively use the program! } }[ That's my goldfish you just stepped on! :-] } }If you are referring to the only double-click program I know of, ClickToFront, }you're wrong. ClickToForont does not eat anything but ~50 bytes of RAM. } }Try ClickToFront with Microfiche, or just with the Workbench tool. Both }use double-clicks, and both integrate smoothly. Sorry, Bryce, I didn't mean to step on your toes but someone (and someone doing a review!) thought that the MFF was buggy because double-click didn't work! Good thing he sent some mail and asked about it before publishing that in his review! He did say he was running ClickToFront. Was it just version 1.0 that ate double-clicks or something? Gary