Community
Participate
Working Groups
It works in windows environment, but not in Linux-GTK. Eclipse build id:Build id: I20080207-1530. First, I describe the problem, and I'll attach the code later. Step to reproduce: 1.Create a combo, and set several items for it. 2.Add a selection listener to this combo, implement related functions, and set a break point in the function widgetSelected(). 3.Click the triangle at the right of combo, and select the first item, you'll find that it suspends in the function widgetSelected(). It's to say that widgetSelected() is invoked. 4.Click the triangle at the right of combo, and select the first item again. And note: widgetSelected() is not invoked any more. And I also find that if and only if the text in combo is not equal the selected one, then widgetSelected() invokes. But it works in windows environment, could you please fix it in Linux-GTK ?
Created attachment 94172 [details] Snippet to reproduce this bug. Please reference to attachment, it's the snippet to reproduce this bug.
Praveen to investigate.
GTK behaves similar to Mac and they doesn't trigger any event when the same element is (re)slected. I feel this could be the right behavior and Windows has to be worked to get the similar behavior as GTK/Mac. This can be closed and Windows behavior can be worked through bug 242585
When an element is reselected, an event is supposed to be issued. Windows is correct. This allows people to refresh views that are depended on the selection.
Created attachment 130230 [details] Proposed patch While I was working on the patch, I noticed few observations I want to mention it here. Though GTK does not support sending Selection/Change event on re-selection of same element, the steps I took to simulate the behaviour similar to Windows is - 1) Preserve the previously selected element when the drop down list is mapped/displayed. Also, at the places where an element is selected programmatically. An element can be selected either through mouse or keyboard. So, a Selection event has to be send when a element is reselected through either of these methods. 2) I tried to capture button-press-event on listHandle(popup-list of combo box, which is implemented as GtkMenu since Gtk2.4) after the list is displayed. However when the popup is displayed, button-press-event is generated irrespective of the position where the mouse is clicked. Thus, button-press-event occurs on listHandle (after popup list is displayed) though mouse is clicked on completely different application. In order to capture the specific button-press-event, I made use of the actual widget on which the event is generated(which is menuItem, child of listHandle). 3) A element can be selected from keyboard through Enter/Return/Space keys. However, key-press-event for Enter/space keys never occurs on listHandle though the listeners are hooked on it. Further, I realized that I can capture key-press-event for listHandle (for Enter/space keys) only through event_after signal. NOTE: The code changes contained in the patch will also address the problem reported in the bug 113300 together.
I've used snippets available in this bug (various ways of selecting an element - through keyboard/mouse; initially element is selected through select() call) and at bug 113300 (when verifyListener is hooked and the text of the active item is changed) for testing the code changes.
Created attachment 135356 [details] Patch Fixed a bug in the previous patch and this is the cumulative patch for 273850, 113300 and 224837 (for GTK >=2.8)
Fixed in HEAD > 20090722
I noticed the following behavior while testing the integration build I20090806-0100. Selection event is fired even when no item is selected in the Combo's dropdown. It can be reproduced using the ControlExample.
Praveen, see if you can reproduce what Lakshmi is seeing. If so, please fix.
Created attachment 150970 [details] Patch v01 The existing code changes does not handle the below scenarios - 1) When the drop-down menu is cancelled, then it doesn't recognise that - so, selection events are sent though it shouldn't. 2) If the items are changed through keyboard (up/down arrow), then re-selecting the same item through popup-menu doesn't send selection item. In order to fix these issues, the new patch preserves the indexSelected when the popup menu is 'mapped' (through the map event of menuHandle). Whenever the menu is cancelled (either through Esc, or mouse click out of popup-menu), it is recognized. After the selection of menu is done, selection event is posted only if the menu is not cancelled and currently selected item is same as the saved indexSelected. Bogdan, please review the patch. Thanks.
