yost@esquire.UUCP (David A. Yost) (10/16/89)
In answer to why you can't implement double-click in X: In article <1922@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes: >There really is a reason for it. X is network-based. There's no way for >an application to know, upon receiving one button click, whether there's >another one coming along. [and how long should it wait for one?] Thanks for explaining to us how the implementation stands in the way of a robust implementation of a desired policy. (Remember the X motto: implementation, no policy). Of course, users are best served when one starts from a specific user-centered design and then derives the appropriate implementation. Too bad UNIX and X are not from this culture. Isn't double-click commonly accepted enough that X servers should be able to reliably implement it? (i.e. after one click, if another click comes in before the timeout, send a double click event, else when the timeout expires, send a single click event.) What if one wanted to hack the drivers on a Mac so you could use it from an X terminal? "Sorry, no double click." Would someone from the NeWS camp care to add to this? Can you download code to the server to do this so you don't have to beg the protocol designers for the capability? What are some other examples of reasons why you need to be able to download input code? --dave yost
haffley@cs.purdue.EDU (P Michael &) (10/17/89)
If one wanted to use double clicks in X, then one could simply look at the
timestamp of the events. By flushing the event buffer after the
timeout and then by searching the event list of keypress events, one could
determine if a double click has occurred and then do the appropriate thing.
It is not restricting double clicks, it just takes some work (and
time) to use it.
_ __ _ _ _ _ _ , _
' ) ) ' ) ) ) / // ' ) / /) /) //
/--' / / / o _. /_ __. _ // /--/ __. // // // _ __ ,
/ o / ' (_<_(__/ /_(_/|_</_</_ / (_(_/|_//__//__</_</_/ (_/_
/> /> /
</ </ '
P. Michael Haffley
haffley@iuvax.cs.indiana.edu
(ames,rutgers,pur-ee,att)!haffleypeter@ficc.uu.net (Peter da Silva) (10/17/89)
In article <1490@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: > Isn't double-click commonly accepted enough > that X servers should be able to reliably > implement it? No. Double-click is a kludge foisted on the computing world by the decision to put only one button on the Macintosh mouse. Of course, the X people didn't help this situation any by their blind refusal to dictate policy. As a result the three mouse buttons don't mean anything, and you have people wanting to double-click. On the Amiga, the two buttons have a meaning: "select" and "menu". A third button, for "perform" would be nice, but the designers of the Amiga user interface fell in with the Mac fad and hid "perform" in "double- click-select". (that, and putting the ^&%^&%& menus at the top of the &^*&^* screen... another Macintosh kludge designed to avoid adding buttons) :-< -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
john@aardvark.ctt.bellcore.com (John Letourneau) (10/19/89)
In article <6564@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <1490@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >> Isn't double-click commonly accepted enough >> that X servers should be able to reliably >> implement it? > >No. Double-click is a kludge foisted on the computing world by the >decision to put only one button on the Macintosh mouse. > >Of course, the X people didn't help this situation any by their >blind refusal to dictate policy. As a result the three mouse buttons >don't mean anything, and you have people wanting to double-click. Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you have 3 choices of things->standard is i)selection ii)position iii)menu. Stan Switzer and I talked this one over and using the time element allowed us to include i-a)stretch! i-b)inverse! Basicly what Stan hacked up was to use the selection button to "canvas-to-top" on the border with a "quick-click", "canvas-to-bottom" on the border with a "double-quick-click" and "constrained/un-constrained-stretching" with "click-hold". The end result is we don't have to call up a menu or hit a function-key to do these things. Stan isn't ready to send this stuff out (if he ever will), but he and I are common friendly users of each others hacks, so don't bug him for the code! Sorry Stan, you were slightly out of touch when I responded to this! 8-) -_ .- _ * - ~ _______ "I feel the need... | John P. Letourneau . * = _ .~ _ / 9000 \___ the need for speed!!" | john@ctt.bellcore.com ~_ .~_ . = / Turbo \ | Bellcore ~. - _ = * - \-O------O----| | Piscataway, NJ.
peter@ficc.uu.net (Peter da Silva) (10/19/89)
In article <17943@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes: > Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you > have 3 choices of things->standard is i)selection ii)position iii)menu. What does "position" do? How do you select-multiple without a "perform" button? A (DO-IT) gadget? No default action? > Stan Switzer and I talked this one over and using the time element allowed us > to include i-a)stretch! i-b)inverse! Basicly what Stan hacked up was > to use the selection button to "canvas-to-top" on the border with a > "quick-click", "canvas-to-bottom" on the border with a "double-quick-click" > and "constrained/un-constrained-stretching" with "click-hold". Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise drop it to back. This will give you the same semantics for obscured canvasses, and save a click on unobscured ones. This is what the new Amiga windowing system is supposed to do (haven't seen it yet :-<). Click-hold is a different matter... you don't need to use the time domain: just see if the current position changes while the button is down. Doesn't everyone do it this way? What does 'selecting' a border usually do? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "You can tell when a USENET discussion is getting old when one of the 'U` participants drags out Hitler and the Nazis" -- Richard Sexton
robin@SUN.COM (Robin Schaufler) (10/20/89)
The difficulty with waiting for another event and then looking at the timestamp is knowing how long to wait. In NeWS, this problem is solved by sending oneself a shuttle event timestamped in the future; since distribution of events is ordered by timestamp, if the shuttle arrives before another down transition, then it is known to be a single click. If the down transition arrives before the shuttle, the client can dequeue the shuttle so it never gets distributed. X does not have this notion of timestamp ordering for all events. I don't see any way to implement this sort of shuttle interface. If anyone else does, please enlighten me. -- Robin
montnaro@sprite.crd.ge.com (Skip Montanaro) (10/20/89)
This note showed up in comp.windows.news. I thought it might be interesting for those people following the same thread in comp.windows.x. Can somebody speak to Robin's question about timestamp ordering of events in X? ---------- begin included message ---------- From: robin@SUN.COM (Robin Schaufler) Newsgroups: comp.windows.news Subject: Re: Help with double-click recognition. Message-ID: <8910192039.AA00634@borogove.sun.com> Date: 20 Oct 89 08:17:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 The difficulty with waiting for another event and then looking at the timestamp is knowing how long to wait. In NeWS, this problem is solved by sending oneself a shuttle event timestamped in the future; since distribution of events is ordered by timestamp, if the shuttle arrives before another down transition, then it is known to be a single click. If the down transition arrives before the shuttle, the client can dequeue the shuttle so it never gets distributed. X does not have this notion of timestamp ordering for all events. I don't see any way to implement this sort of shuttle interface. If anyone else does, please enlighten me. -- Robin ---------- end included message ---------- -- Skip Montanaro (montanaro@crdgw1.ge.com)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/20/89)
Followup to comp.windows.misc. please. In article <6594@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise >drop it to back. I HATE this in window systems that have this "feature". I set up the windows the way that I like, and some window system keeps moving my windows around when I don't want to. Example: I want to look at a large window 'cause it has a manual page, data or source, but do work in a smaller window on top of the first. Then I want to select something in the "back" window and move/copy/paste it in front. BANG! my small window goes away. Grr! This is a real pain when the small window is completely covered over by the large window, and both windows are on top of a dozen other windows. It might take me a dozen actions to undo the changes of this "helpfull feature". When I set up my windows, I don't want them changed! But, you ask, how do you change this? >What does 'selecting' a border usually do? Bingo! A lot of window systems use clicks on the border of a window to specify window-manager actions. These clicks can therefore be used to change window hierarchy, iconify state, move or resize windows, or pop up the menus that all window-based applications have. But inside the window, you can make that program use any sort of chord like Shift-Meta-Control-DoubleClick left, middle and right mouse buttons. I have that chord defined to update the database in my Watch! Well, not really. Maybe next week. :-) -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
john@aardvark.ctt.bellcore.com (John Letourneau) (10/20/89)
In article <6594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <17943@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes: >> Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you >> have 3 choices of things->standard is i)selection ii)position iii)menu. > >What does "position" do? How do you select-multiple without a "perform" >button? A (DO-IT) gadget? No default action? OK, OK, Sorry, Sorry...position should be DRAG! sheesh I don't understand the rest of the comment. You can define whatever you want on the mouse buttons. The above list is the standard actions for windows and panels. >Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise We've done this (for a loong time) and interresting things come of it. Since the actual display state is not always know (ie. a window can appear to be TOP to the observer but it's state does not say that) interesting things happen-> the toggle will seem to do nothing to the top screen the first time it is clicked; and on the second click it will go to the bottom as was probably intended with the first click. With an explicit TOP/BOTTOM type of action (double-click) this is avoided. >Click-hold is a different matter... you don't need to use the time domain: >just see if the current position changes while the button is down. Doesn't >everyone do it this way? Ah! You are in the world of implementations and not techonologies. Sure there are a plethora of ways of doing things. We wanted to see how the time element could be used. I'm sure when Stan returns (next week I think) he'll have a few things to add to this discussion. PS. The click and move can get trickey if framebuffer interrest are used for things...trust me on this I tried it. -_ .- _ * - ~ _______ "I feel the need... | John P. Letourneau . * = _ .~ _ / 9000 \___ the need for speed!!" | john@ctt.bellcore.com ~_ .~_ . = / Turbo \ | Bellcore ~. - _ = * - \-O------O----| | Piscataway, NJ.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/23/89)
X does not have this notion of timestamp ordering for all events.
I don't see any way to implement this sort of shuttle interface.
Robin is correct, the core X protocol does not have any support for this.sjs@spectral.ctt.bellcore.com (Stan Switzer) (10/23/89)
Well, frankly, it comes a quite a surprise to me that you can't do
double click detection in X, but is quite easy in NeWS.
Here's a routine to check if a click is, in fact, a double click.
After you have detected a single click, invoke this routine to see if
there is another click. Since it just checks to see if another click
follows the current one, it can be cascaded to detect triple,
quadruple, etc. clicks.
/DoubleClickDelay .3 60 div def
/DoubleClick? { % - -> another click(true) or not(false)
null blockinputqueue { % fork
ParentCanvas setcanvas
currentcursorlocation
createevent dup begin
/Name /MouseDragged def
end expressinterest
createevent dup begin
/Action /DownTransition def
/Exclusivity true def
end expressinterest
createevent dup begin
/Name /Timer def
end dup expressinterest createevent copy dup begin
/TimeStamp currenttime DoubleClickDelay add def
end sendevent
unblockinputqueue
WaitButIgnoreJiggle
/Action get /DownTransition eq % Have we a click?
} fork waitprocess
} def
/JiggleFudge 4 def
/WaitButIgnoreJiggle {
{
% get events until something more than a
% mouse jiggle happens
awaitevent
true % exit flag
1 index /Name get /MouseDragged eq {
1 index begin XLocation YLocation end
% stk: origX origY event exflag X Y
4 index sub abs JiggleFudge le exch
5 index sub abs JiggleFudge le and
{ pop false } if % continue (don't exit)
} if
{ exit } if
pop
} loop
} def
If you wanted to be more clever, you could download a global click
processor that converted all multiple clicks into distinct events for
distribution. It would probably be a bad idea, though, since it would
make all single clicks just a little bit sluggish.
Stan Switzer sjs@bellcore.comsjs@spectral.ctt.bellcore.com (Stan Switzer) (10/23/89)
In article <6594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > Click-hold is a different matter... you don't need to use the time domain: > just see if the current position changes while the button is down. Doesn't > everyone do it this way? Yes, we do. But what if the mousie doesn't move? No matter: In NeWS, it's easy to do this kind of event processing. Just wait for whichever happens first: timeout, click, or for the mouse movement more than a jiggle. AND, if you are careful about how you use blockinputqueue/unblockinputqueue, you'll never miss an event. (I guess that this is the problem with double-click in X, but as I said before, it strikes me as quite odd that you can't detect multi-clicks in X.) Stan sjs@bellcore.com
peter@ficc.uu.net (Peter da Silva) (10/24/89)
In article <18005@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes: > In article <6594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >In article <17943@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes: > >> Well, my $.02 as a NeWS user are like this...with a 3 button mouse, you > >> have 3 choices of things->standard is i)selection ii)position iii)menu. > >What does "position" do? How do you select-multiple without a "perform" > >button? A (DO-IT) gadget? No default action? > OK, OK, Sorry, Sorry...position should be DRAG! sheesh OK, I understand now. You have select/drag/menu. I don't know... I don't move windows around that much, so I can't see giving a mouse button up for that action. I'd rather use a poke point. > I don't understand the rest of the comment. You can define whatever you > want on the mouse buttons. The above list is the standard actions for > windows and panels. From a theoretical viewpoint, having a standard set of actions is desirable. What I mean to say is, suppose you want to "activate" a bunch of icons at once (where activate means start a program, send a signal, or whatever), what is your standard sequence of operations? I'd think you'd SELECT each one, then hit PERFORM. On the Mac, SELECT is a mouse click and PERFORM is a double click. I'd rather make PERFORM a seperate button. Then if you want more than the default action, you use the third button to call up a menu of actions. > >Try using 'click' as a toggle: if it's obscured, bring it to front. Otherwise > We've done this (for a loong time) and interresting things come of it. > Since the actual display state is not always know (ie. a window can appear > to be TOP to the observer but it's state does not say that) Implementation detail. I didn't say "top", I said "obscured". You can tell if a window is obscured either by looking at the clipping list for that window, or by looking at other windows. Whether it's the highest window or not is of little interest to the user. Was it just too much trouble to check for this, or was this information not available to the part of the program that decided on the action? > >Click-hold is a different matter... you don't need to use the time domain: > >just see if the current position changes while the button is down. Doesn't > >everyone do it this way? > Ah! You are in the world of implementations and not techonologies. Not really. If you *think* of the action as being in the time domain, it can be annoying to people whose perception of the time domain is different from yours. If everything depends only on a sequence of actions, instead of worrying about just when the actions occurred, it's a lot easier on the programmer and the user. > PS. The click and move can get trickey if framebuffer interrest are > used for things...trust me on this I tried it. Now it's my turn... what does this refer to? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "I feared that the committee would decide to go with their previous 'U` decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP
peter@ficc.uu.net (Peter da Silva) (10/24/89)
In article <18015@bellcore.bellcore.com> sjs@bellcore.com (Stan Switzer) writes: > In article <6594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > > Click-hold is a different matter... you don't need to use the time domain: > > just see if the current position changes while the button is down. Doesn't > > everyone do it this way? > Yes, we do. But what if the mousie doesn't move? Well, since we're using this to drag something, then if the mousie doesn't move you haven't dragged anything anywhere... so what's the problem? (Personally, I think click-hold is the *only* way to drag... this click here with this button move click there with that button stuff is strictly for the birds. Down with control-alt-meta-cokebottle-hold-your-face-right sequences). -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "I feared that the committee would decide to go with their previous 'U` decision unless I credibly pulled a full tantrum." -- dmr@alice.UUCP
john@aardvark.ctt.bellcore.com (John Letourneau) (10/24/89)
In article <6648@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <18005@bellcore.bellcore.com> john@aardvark.UUCP (John Letourneau) writes: >> OK, OK, Sorry, Sorry...position should be DRAG! sheesh > >OK, I understand now. You have select/drag/menu. I don't know... I don't >move windows around that much, so I can't see giving a mouse button up for >that action. I'd rather use a poke point. Weeeell we've got 100+ host on our network; Sun 3's, 4's, sparcstations, Pyramids, uVaxes, 3B2s, and on, and on. I typically have over 5 windows up at least, doing different things. FOR ME, moving windows or selecting them to be unobscured is how I choose to work as oppose to icons opening and closing. Besides I haven't had the time to hack up a "something has happened in the window represented by this icon" code...ie. missing some host event when the icon is up. > >hit PERFORM. On the Mac, SELECT is a mouse click and PERFORM is a double >click. I'd rather make PERFORM a seperate button. Well, YOU prefer the Mac look. Aren't user programmable interfaces neat?! > >Implementation detail. I didn't say "top", I said "obscured". You can tell if >a window is obscured either by looking at the clipping list for that window, Hmmmmmm > >Not really. If you *think* of the action as being in the time domain, it >can be annoying to people whose perception of the time domain is different >from yours. If everything depends only on a sequence of actions, instead >of worrying about just when the actions occurred, it's a lot easier on the >programmer and the user. Ah, I doubt if we'll agree completely (at all?) on some of these points. Maybe not even on the magnitude of their importance. End Of Comment (EOC) > >> PS. The click and move can get trickey if framebuffer interrest are >> used for things...trust me on this I tried it. > >Now it's my turn... what does this refer to? I was afraid you'd ask this...let's see...Ah, I have it set up so that a select click on the framebuffer will open another window on my Sun. When things are slow for whatever reason, I'll click on an existing window frame to unobscure it..I then move the mouse (just slightly) so that it is on the framebuffer..I get a new window instead. This is what I've observed, it doesn't make complete sense to me, I haven't had time to dig into it. It might vary well be a figment of my imagination, or a subtle difference between what event is actually used->down or up transition. Sorry I can't be any more specific than this. -_ .- _ * - ~ _______ "I feel the need... | John P. Letourneau . * = _ .~ _ / 9000 \___ the need for speed!!" | john@ctt.bellcore.com ~_ .~_ . = / Turbo \ | Bellcore ~. - _ = * - \-O------O----| | Piscataway, NJ.
john@aardvark.ctt.bellcore.com (John Letourneau) (10/24/89)
In article <6650@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >(Personally, I think click-hold is the *only* way to drag... this click > here with this button move click there with that button stuff is strictly > for the birds. Down with control-alt-meta-cokebottle-hold-your-face-right > sequences). AH!!! We agree! In fact this is part of my "anti-menu" feelings when it comes to "common" window activity. I know, what's common for you may not be for be for me (iff 8^)). Even though calling up a menu and doing a selection is just a matter of clicking (single and/or multi) there is still an element of mouse movement. MY feelings are that this counts as a "key-stroke". Your "choose these windows" now "do this" paradigm is OK...actually something I may concider for some applications I've been concidering. Well, I'm tired of talking about this for today. Later......... -_ .- _ * - ~ _______ "I feel the need... | John P. Letourneau . * = _ .~ _ / 9000 \___ the need for speed!!" | john@ctt.bellcore.com ~_ .~_ . = / Turbo \ | Bellcore ~. - _ = * - \-O------O----| | Piscataway, NJ.
peter@ficc.uu.net (Peter da Silva) (10/25/89)
I'd agree with this business of "well, it's programmable so you set things up the way you want" but for one thing: I don't have the source code to all the programs so I *can* set them up. Playing games with the system definitions only goes so far: I can't convince Xpic to use hold-and-drag instead of click-move-click, for example, by redefining buttons. I know NeWS is more configurable than X, but I don't get the feeling it's practical to do it en mass: otherwise why would anyone need a mouse help menu? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)