Description of problem: - RHN login name LM-MSOC - Company name LOCKHEED MARTIN SPACE OPS - Platform x86_64 - OS RHEL4u3 [Environment] RHEL4u3 x86_64 (and above) app compiled with openmotif. [Problem Description] Keyboard selection breaks when changing from XmMULTIPLE_SELECT mode to XmEXTENDED_SELECT mode. This worked fine in Motif1.2. It does not work in any version beyond Motif1.2. Hello David... 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: ./README ./simple_xmlist_better_kludge.c ./simple_xmlist.c 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: http://bugs.motifzone.net/long_list.cgi?buglist=1276 I don't see mention of this being fixed in RH's openmotif. Rick Version-Release number of selected component (if applicable): openmotif-2.2.3-10.1.el4 How reproducible: always Steps to Reproduce: 1. Unpack xbug2.tar.bz2 2. build simple_xmlist and simple_xmlist_better_kludge (Instructions in the README) 3. 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 around it. 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. Actual results: Expected results: Additional info:
Created attachment 295995 [details] reproducer
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 more information. 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.