[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1505.0. "Popping windows to front" by HPSCAD::SMORRISON (Sue Morrison) Thu Sep 28 1989 17:28

In our application we bind an action to MB1 so that you can repeatedly
execute a command until you select another.  For example, if you select
CENTER AT POINTER then whenever you click in the window, the object at the
pointer is moved to the center of the window.

This MB1 binding causes a problem when you click in the window in
order to bring it to the top of a stack of windows.  We interpret this to
mean "execute the last command", ie, CENTER AT POINTER, and the drawing is
updated before you realize what happened.

I have found that a way around this is to ignore the ButtonPress event if
it is followed by an Expose which comes before the ButtonRelease.  If the
Expose does not arrive before the ButtonRelease, however, we will have
already processed the MB1 action.

Is it safe to assume the Expose will always come after the ButtonPress but
before the ButtonRelease if you are really only bringing the window to the
top of the stack?

Does anyone know of an easier way to detect this?


					Sue
T.RTitleUserPersonal
Name		DateLines
1505.1Probably not an RGI (real good idea)DECWIN::KLEINThu Sep 28 1989 18:3431
>>>Is it safe to assume the Expose will always come after the ButtonPress but
>>>before the ButtonRelease if you are really only bringing the window to the
>>>top of the stack?

This is probably NOT a safe (reliable) assumption.

I see two problems with this.  First off, "occlusion" is a relative thing.
Suppose the window is only slightly occluded by a sibling.  The user may
really mean MB1 (the command), not MB1 (pop to top).  The boundary
condition bothers me.  Although the behavior is predictable, it depends
too much on what might be a one-pixel change in window position.  I
don't think that a window's behavior should depend on where it is
(on the screen, or in the stacking order either).

Second, because of the asynchronous window manager interaction of
bringing the window to the front, I believe that a slow-running window
manager could cause the ButtonPress/ButtonRelease to be send to the
client before the (restack) Expose event is triggered.  So, the
timing is not always reliable.  (I might be wrong about this, but
there are an awful lot of window managers out there for you to be
able to depend on this working for all of them.)

I'm not sure what to suggest, but I think that you need to think about
your MB1 UI a little more.  Suppose, for example, that you made
MB1 double-click mean "do it again" (instead of MB1 single-click).
This would avoid the pop-to-top ambiguity and might be acceptable to the user.

Any other ideas out there?

-steve-
1505.2LEOVAX::TREGGIARIThu Sep 28 1989 20:308
    I agree that it is not a good idea.  I don't know if the style guide
    talks about this case explicitly, but I do remember discussing this
    issue during the development of the style guide.  The answer was that
    the MB1 should both pop the window and do the normal action in the
    application.
    
    Leo
1505.3Doing the action may be undesirable...HAYAMA::FENNELLTim Fennell - HPS CADMon Oct 02 1989 10:2522
We have been developing CAD tools that use DECwindows for the front end.
Many have "sticky" operations which continue until you select another
function.  Popping the window to the front and doing the operation might
not be what the user wanted to do.  Consider a window for an application
which has the function "delete" enabled.  Clicking in the window could
delete a component in the window.

VWS had the "cycle" button that pushed a different window to the top.  That
was one way to solve the problem.  It meant you had to look at potentially
n-1 windows to get to the one you wanted.

I belive that .0 was concerned about getting the window you wanted to the
top without having to worry about operations that were enabled in that
window.  If only part of the window is visible, (like the lower half), then
it would be nice to figure out an easy way to get that window to the top.
1505.4DECWIN::FISHERBurns Fisher 381-1466, ZKO3-4/W23Mon Oct 02 1989 17:529
Well, you can click on the border, or you can double-click on its icon in the
icon box (for either DWM or MWM, it turns out [if you have mwm customized to have
an icon box that is]).

I, too, think you should think about a different user interface.  Single click
means select something.  Double click means do something.

Burns