Xref: utzoo comp.windows.x:14522 comp.windows.news:1595
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ginosko!brutus.cs.uiuc.edu!apple!sun-barr!newstop!texsun!texbell!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.windows.x,comp.windows.news
Subject: Re: Help with double-click recognition.
Message-ID: <6648@ficc.uu.net>
Date: 23 Oct 89 18:43:17 GMT
References: <603@granite.dec.com> <1922@bacchus.dec.com> <1490@esquire.UUCP> <6564@ficc.uu.net> <17943@bellcore.bellcore.com> <6594@ficc.uu.net> <18005@bellcore.bellcore.com>
Reply-To: peter@ficc.uu.net (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 65

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