Red Hat Bugzilla – Bug 435030
RHEL4U3 x86_64 openmotif-2.3 regression, keyboard selection breaks
Last modified: 2010-10-22 18:48:46 EDT
Description of problem:
- RHN login name LM-MSOC
- Company name LOCKHEED MARTIN SPACE OPS
- Platform x86_64
- OS RHEL4u3
RHEL4u3 x86_64 (and above) app compiled with openmotif.
Keyboard selection breaks when changing from XmMULTIPLE_SELECT mode to
This worked fine in Motif1.2. It does not work in any version beyond Motif1.2.
I've been conversing back and forth with this customer. The situation is that
they are porting an application that is actually quite complex, from Motif 1.2.6
to OpenMotif 2.3 as delivered on RHEL4. This application is used to communicate
with the space station. Apparently users select commands from the list widgets
and these get sent up and 'do stuff' on the space station. They apparently
spent some amount of time isolating the problem to the XmList widget, and
started to implement the workaround suggested by Yves Begrand of using
XmListSetAddMode(), but when they found it did not work in all cases they
started to balk at doing more. They have subsequently found that another,
somewhat better workaround of call XtVaSetValues() to set the XmNselectionMode
to XmADD_NORMAL seems to do the trick - however, they reluctant to try any
further workarounds because of the impact that some side-effect could have (like
crashing the space station). Despite that reluctance, they have pressed me for
a fix to the library for this issue.
I've attached a tar ball that has two versions of the program and a README:
The README goes into some detail on the steps to duplicate the problem.
My analysis shows that the SetValues() method for the XmList widget changes the
selectionMode *differently* than what XmListSetAddMode() does. It isn't clear
if this is *incorrect* or just *different*. What the customer needs is for
someone to make a call as to whether the behavior - of the XmList switching into
ADD_MODE when policy switches from MULTIPLE to EXTENDED is a bug or a defect.
It isn't clear to me whether this should be the case, but I worked on a case in
HPUX in 2003 where a similar report was made. The HP lab made a determination
that it was not a bug, and the customer modified their code to use
XmListSetAddMode(). Perhaps there is a bug on Linux in this area.
There are also quite a few behavioral changes from Motif 1.2 to OpenMotif 2.3
and this might be one of them. Unfortunately, while the api documentation on
Motif is extensive, there is little documentation about differences in internals
or behavior from Motif 1.2 to Motif 2.1.
I would suggest, if it has not already been done, that SEG contact the upstream
maintainers of OpenMotif (Motifzone? ICS? ). Someone is going to have to
determine if this is a bug or a feature that needs to be worked around
programatically - and write a definite reason for that. The end developer is
quite persistent and knowledgeable in some areas.
The closest I can find to a similar bug report is:
I don't see mention of this being fixed in RH's openmotif.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Unpack xbug2.tar.bz2
simple_xmlist and simple_xmlist_better_kludge (Instructions in the README)
The steps demonstrating the problem are as follows:
Bring up the application, it starts in Extended select.
Select some items.
Go to Single select.
Select an item, reselect it (it becomes unselected), and
use the down arrow key. (The hatch marks go down).
Press the "Set Extended" button.
No items are selected. (This is the key behavior)
The important behavior for our app is that the item under the hatch mark
is NOT highlighted (selected) going back into extended mode from single
select under the steps outlined above. That is, when going back to extended
from single, if no item is in reverse video (explicitly selected, as opposed
to just having the hatch marks showing around a list item), then no item
will be selected once Extended mode has been set.
Now, if you press "Turn SetMode On" toggle-button, and then push "Set Extended",
we get the arrow selection to work properly in extended mode, using the
workaround OS gave us. Next, select a few items. Use the arrow down key, the
selection is propagated correctly. Now, select "Set Single", select an item,
reselect it so that it becomes unselected, but still has the hatch marks
Now, push the "Set Extended" button, and you see that the item is automatically
highlighted, i.e., selected, which causes our application to fail.
Note that the highlighting problem seems to be fixed with the new code
in simple_xmlist_better_kludge.c, and the arrows still work like they
are supposed to. However, our delivery schedule precludes us from peforming
adquate testing to make sure there are no unexpected failures with this
fix for now.
Created attachment 295995 [details]
The MotifZone bug 1276 is not releted. I can reproduce it with the patched
version in el5.
I have verified your problem and have also contacted OpenMotif upstream (ICS)
about this. They have verified this with Motif 1.2.5, Motif 2.1.0 and OpenMotif
2.3; the behavior was consistent in all cases. The keyboard selection behavior
is different in your version 1.2.6, which is not an official OSF/Motif release.
It seems that the version 1.2.6 was built for CDE with additional patches to
1.2.5. Please have a look at http://www.opengroup.org/desktop/faq/#RTFToC34 for
I think the best for you would be to migrate to an official OpenMotif release
and to adapt your application accordingly. Changing the behavior in Motif will
break compatibility with other releases, therefore it is not possible to do
this. ICS has also declined to change the behavior for OpenMotif.
I am closing this as not a bug.