Mouse arrow flips, mouse and kbd locked out - Xwindows

This is a discussion on Mouse arrow flips, mouse and kbd locked out - Xwindows ; I am working on an enhancement to a corporate X/Motif 1.2 app that involved adding a popup menu for the first time. The enhancement is designed to pop up the menu upon META-right-click anywhere in the window. Because the existing ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Mouse arrow flips, mouse and kbd locked out

  1. Mouse arrow flips, mouse and kbd locked out

    I am working on an enhancement to a corporate X/Motif 1.2 app that
    involved adding a popup menu for the first time. The enhancement is
    designed to pop up the menu upon META-right-click anywhere in the
    window. Because the existing code already handles plain right-clicks
    to do processing, the code contains event handlers for both mouse-down
    (button press) and and mouse-up (button-release) events.

    The modified app works correctly and pops up the menu when META is down
    during the right clicks. Oddities happen when META is NOT down: the first
    plain right-click results in the mouse cursor changing from the standard
    arrow (which points north-northwest) to the cursor typically displayed
    by Motif for its menus (which points northeast). Once I get this
    "flipped" arrow, the app and the rest of my X display becomes totally
    unresponsive to human input. Both mouse and keyboard events are being
    ignored (and apparently being stored for later processing). I'm forced
    to kill the app from another machine on the network. Once I do this, as
    soon as the app's window disappears, I get the root menu, and the mouse
    and kbd are usable again.

    For some builds, the flipped arrow lasts for 3-4 seconds then clears up
    by itself. If I right-click several times during this time, I can get
    the full lockout, but this is intermittent and appears to be a race
    condition.

    Anyone know what's up with the event routing here? I've isolated the
    problem to be connected with the parent widget: when the parent is
    managed, the problems occur; when unmanaged, everything works fine
    as intended.

    The widget tree looks like:
    applicationShellWidgetClass
    |
    +-----------------------+
    | |
    | |
    | |
    xmRowColumnWidgetClass RowColumn
    | | |
    | | |
    | | |
    xmLabelWidgetClass RowColumn RowColumn
    | |
    | |
    | |
    Labels Labels


    I checked my .mwmrc, and I do not have button bindings for right-click
    or META right-click. The equipment here is Sun Ultra5's running Solaris
    2.6. We're in the process of updating these to Solaris 2.9, but that
    won't happen until July 2004.

    Jim Olson
    Software Engineer
    PHLX - The Philadelphia Stock Exchange
    www.phlx.com
    Email: e1-5r9m-mfpc-9017@emailias.com
    Temporary address - spam it and I'll expire it, rendering it obsolete!)

  2. Re: Mouse arrow flips, mouse and kbd locked out



    James Olson wrote:
    >
    > I am working on an enhancement to a corporate X/Motif 1.2 app that
    > involved adding a popup menu for the first time. The enhancement is
    > designed to pop up the menu upon META-right-click anywhere in the
    > window. Because the existing code already handles plain right-clicks
    > to do processing, the code contains event handlers for both mouse-down
    > (button press) and and mouse-up (button-release) events.
    >
    > The modified app works correctly and pops up the menu when META is down
    > during the right clicks. Oddities happen when META is NOT down: the first
    > plain right-click results in the mouse cursor changing from the standard
    > arrow (which points north-northwest) to the cursor typically displayed
    > by Motif for its menus (which points northeast). Once I get this
    > "flipped" arrow, the app and the rest of my X display becomes totally
    > unresponsive to human input. Both mouse and keyboard events are being
    > ignored (and apparently being stored for later processing). I'm forced
    > to kill the app from another machine on the network. Once I do this, as
    > soon as the app's window disappears, I get the root menu, and the mouse
    > and kbd are usable again.
    >
    > For some builds, the flipped arrow lasts for 3-4 seconds then clears up
    > by itself. If I right-click several times during this time, I can get
    > the full lockout, but this is intermittent and appears to be a race
    > condition.
    >
    > Anyone know what's up with the event routing here? I've isolated the
    > problem to be connected with the parent widget: when the parent is
    > managed, the problems occur; when unmanaged, everything works fine
    > as intended.
    >
    > The widget tree looks like:
    > applicationShellWidgetClass
    > |
    > +-----------------------+
    > | |
    > | |
    > | |
    > xmRowColumnWidgetClass RowColumn
    > | | |
    > | | |
    > | | |
    > xmLabelWidgetClass RowColumn RowColumn
    > | |
    > | |
    > | |
    > Labels Labels
    >
    > I checked my .mwmrc, and I do not have button bindings for right-click
    > or META right-click. The equipment here is Sun Ultra5's running Solaris
    > 2.6. We're in the process of updating these to Solaris 2.9, but that
    > won't happen until July 2004.
    >
    > Jim Olson
    > Software Engineer
    > PHLX - The Philadelphia Stock Exchange
    > www.phlx.com
    > Email: e1-5r9m-mfpc-9017@emailias.com
    > Temporary address - spam it and I'll expire it, rendering it obsolete!)


    First of all, you should not have multiple children of the
    applicationShell - shell widgets should have only a single child.

    Second, I see no purpose to have RowColumn widgets that have only a
    single child. Unless what you are showing is your menu tree (not your
    application structure), in which case the top level widget should be an
    OcerrideShell, not an ApplicationShell.

    The problem you are having with the cursor is likely due to the fact
    that you are using event handlers to determine what to do when the user
    presses/releases the mouse, and ignoring possible
    ButtonPress/ButtonRelease translations that still exist on the parent.

    You should seriously consider modifying the look-and-feel of your app -
    the "standard" way to interact with all Motif programs is for the right
    mouse button to control popup menus without any modifier keys; if you
    change that, your users will get confused when working with other
    programs.
    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Common User Interface Services
    M/S 2R-94 (206)544-5225

  3. Re: Mouse arrow flips, mouse and kbd locked out

    "Fred L. Kleinschmidt" wrote in message news:<40D98FE0.2257499E@nospam_boeing.com>...
    > James Olson wrote:
    > >
    > > I am working on an enhancement to a corporate X/Motif 1.2 app ...
    > >
    > >
    > >
    > > Jim Olson
    > > Software Engineer
    > > PHLX - The Philadelphia Stock Exchange
    > > www.phlx.com
    > > Email: e1-5r9m-mfpc-9017@emailias.com
    > > Temporary address - spam it and I'll expire it, rendering it obsolete!)

    >
    > First of all, you should not have multiple children of the
    > applicationShell - shell widgets should have only a single child.


    I re-checked the code, and sure enough it is creating two managed
    children of the shell widget. Thanks for reminding me of this
    requirement. I agree that this is not kosher in the least, and I'll
    look to get it changed.

    > Second, I see no purpose to have RowColumn widgets that have only a
    > single child. Unless what you are showing is your menu tree (not your
    > application structure), in which case the top level widget should be an
    > OcerrideShell, not an ApplicationShell.


    The tree I drew is the application widget tree. I didn't indicate
    which widget serves as the parent for the popup because I've had to
    move it around while making test builds. The above problems appear
    regardless of which RowColumn or Label widget is the parent as long as
    the parent is managed. For my most recent build, I created an
    unmanaged label widget to serve as parent, and the problems
    disappeared.

    > The problem you are having with the cursor is likely due to the fact
    > that you are using event handlers to determine what to do when the user
    > presses/releases the mouse, and ignoring possible
    > ButtonPress/ButtonRelease translations that still exist on the parent.


    Up to this point I haven't considered the translations in effect for
    our apps, so this will go onto my TO-DO list. Thanks.

    > You should seriously consider modifying the look-and-feel of your app -
    > the "standard" way to interact with all Motif programs is for the right
    > mouse button to control popup menus without any modifier keys; if you
    > change that, your users will get confused when working with other
    > programs.


    This is a good one. Just about all of us here at PHLX want to do this.
    The situation is that our apps are the only ones that run on the
    workstations used by the traders on the trading floor. We've got a
    custom trading environment here, and the traders have not seen the
    normal Motif GUI. Switching would create training issues, and some of
    hotheads on the floor will literally yell at you. Ideally training
    wouldn't be an issue since most traders have a MS-Windows PC next to
    their workstation, but to fall into compliance we would have to move a
    lot of features around and change the way they're invoked.

    My boss knows that our main app (with the above problem) is over 10
    years old, has many UI quirks and is deficient in many ways, and that
    a full rewrite will be necessary. He is not ready to bite that bullet
    now, but he knows he doesn't have much time. We're now installing
    Solaris 2.9, and Sun is dropping support for Motif and CDE in Solaris
    2.10.

  4. Re: Mouse arrow flips, mouse and kbd locked out

    e1-5r9m-mfpc-9017@emailias.com (James Olson) wrote in message news:<4c611a6f.0406221221.3f2b54e7@posting.google.com>...
    > I am working on an enhancement to a corporate X/Motif 1.2 app ...
    >
    >
    > The widget tree looks like:
    > applicationShellWidgetClass
    > |
    > +-----------------------+
    > | |
    > | |
    > | |
    > xmRowColumnWidgetClass RowColumn
    > | | |
    > | | |
    > | | |
    > xmLabelWidgetClass RowColumn RowColumn
    > | |
    > | |
    > | |
    > Labels Labels
    >
    >


    Clarification: in my earlier posting, I forgot to specify in the above
    chart that the lowest RowColumn widget on each branch is set up as the
    parent of 11 label widgets. In total, there are 33 such labels.

    > Jim Olson
    > Software Engineer
    > PHLX - The Philadelphia Stock Exchange
    > www.phlx.com
    > Email: e1-5r9m-mfpc-9017@emailias.com
    > Temporary address - spam it and I'll expire it, rendering it obsolete!)


+ Reply to Thread