Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!rsiatl!meo
From: meo@Dixie.Com (Miles ONeal)
Newsgroups: comp.windows.x
Subject: Re: running while iconized
Message-ID: <8309@rsiatl.Dixie.Com>
Date: 18 Mar 91 03:38:25 GMT
Organization: Systems & Software Solutions, Inc.
Lines: 33

David Rosenthal writes (and we all litsen 8^):


(quoting the IC3M)
|	Window managers will differ as to whether they support input events
|	to client's icon windows; most will allow the client to receive some
|	subset of the keys and buttons.

|What this means is that it is OK to have your client do the appropriate
|this *if* it receives a keystoke or button press via its icon window,
|and thus that it is perfectly OK to select for these events on the icon
|window, but it must not be essential to the operation of the client that
|it receive such an event.

Of course, there is the additional problem of conflict between menu
manager mapping vs client mapping. You want to make the client useful
without aggravating the user. It is therefore not a good idea to
have anything important expect a button1 event on an icon, for
instance, or even a button2 or button3 event, as these, in various
guises, are all used by various window managers for opening, moving,
etc. Of course, the user can remap the icon events (you DID use the
TM, eh?).

BUT, if the normal, desired behavior in the uniconified client involves
these buttons, the user will expect do the same thing in the same way
in the iconified client.

So you should have not only an excellent reason to do this, but you
have to convey to the user why this is worth their while in extra
setup time, retraining, or whatever.

-Miles
meo@dixie.com