It's defined like that, and it's always been like that. Try the Events.ycp UI example.

If you need fine-grained event control like that, you need to check more fields of the event map, not just the "widget" field.

No, it has been changed, single click emitted only "SelectionChanged" event in 11.0. The current version emits "SelectionChanged" and "Activated" events.

I just have checked that in 11.0 - start the Events.ycp example and do a single click in the table widget, you'll see only "SelectionChanged" events.

In the current yast from SVN you'll see "Activated" events.

Not true. I just double-checked, and I have an eyewittnes (tgoettlicher) who watched it:

On 11.0 (mandelbrot.suse.de) just like in the latest 11.1 SVN (snells.suse.de) you get a SelectionChanged event and then an Activated event if you double-click on a list item that was not selected before.

If you double-click on the same item again, you only get an Activated event - on 11.0 like in 11.1 SVN trunk.

The behaviour makes sense, if you think about it: The first thing the first of the double-clicks does is to select that item - if it wasn't selected before anyway. This is a chance for the application to update any other widget that might contain additional information about that item.

The second click of the double-click is what should be sent to the application to perform any special action - like edit that item or whatever.

Try for yourself with the Events.ycp example on a plain 11.0 machine and on a machine with 11.1 SVN trunk.

Bottom line: Behaviour as desired, and unchanged since the last release (or older releases, don't have one available to check).

Sorry, I'm talking about SINGLE click!

Try as I might, I only get ONE event per single click - like it should be.

Are you sure you have the latest version of all the libs? Did you compile everything from source, or is it really some FACTORY snapshot on that machine?

It's Beta3 + factory (because of missing some -devel packages) + yast from SVN.

I'll try to reproduce it in Beta4 when it's out.

Please also check if your mouse doesn't send multiple click events when it should send only one. "xev" is a good tool to test that.

The mouse is definitely OK (xev confirms that), I did the 11.0 test over ssh using the same mouse.

I just have completely removed Yast from the machine and reinstalled from SVN - with the same result :-(

Let's wait for Beta4...

We just tried on tgoettlicher's VMWare Beta3 installation, and I can reproduce the problem there (only with the mouse, not when using the keyboard). But on Adrian's FACTORY, it's gone again.

Without any change in yast2-qt anywhere near that code (and no problem with the Qt4-lib from Beta2 + latest SVN trunk), I can only conclude that the Qt4 lib on Beta3 had a problem with that event delivery.

For the time being, this problem seems to have been fixed somewhere else. But let's be watchful for it; it might reappear just as suddenly as it came and then disappeared.

Tested on garbarek.suse.de with current FACTORY - works as expected.

Reopening - it's back

Looks like this is an issue of the "Oxygen" widget theme - see bug #456925.

*** Bug 456925 has been marked as a duplicate of this bug. ***

Test case: 

/usr/lib/YaST2/bin/y2base ./Events.ycp qt

with http://svn.opensuse.org/svn/yast/trunk/ycp-ui-bindings/examples/Events.ycp

A single click into the "Drink" table should result in a "SelectionChanged" event in the "Event" subwindow. A double click should send an "Activated" event (it will send a "SelectionChanged" event upon the first click, immediately followed by the "Activated" event).

With the "Oxygen" theme, it sends an "Activated" event already upon the first click.

I just found a pure Qt4 example that shows the exact same problem:

/usr/lib/qt4/examples/assistant/simpletextviewer/simpletextviewer

from the libqt4-devel-doc package:

- Start the program
- From the "File" menu, pick "Open"
- In the file selection box that opens (a QTreeWidget), a single click should select an item, and a double click should open the corresponding file.

With the "Oxygen" widget theme, the first click already opens the file. With the standard Qt4 widget themes, it simply selects the item.

Applications need to check the QStyle::SH_ItemView_ActivateItemOnSingleClick property using QStyle::styleHint() if they use the activated() signal. Depending on the style, that may be a single click, or a double click.

(In reply to comment #18 from Christoph Feck)
> Applications need to check the QStyle::SH_ItemView_ActivateItemOnSingleClick
> property using QStyle::styleHint() if they use the activated() signal.
> Depending on the style, that may be a single click, or a double click.

Ugh? You can't be serious. This is broken by design. This invalidates the whole idea of widget styles.

If applications have to do arcane things like that, we'd better drop that widget style immediately. There is no reasonable way for this to be handled in all the Qt applications that are out there.

You should really read Qt docs before you are going to state this.

The style hint is required because on many platforms it is a _users_ choice wether items should be activated using single or double click. Applications should respect that choice. And they do automatically, i.e. without any additional code, if they use the activated() signal.

However, if there is a difference between selecting an item, and activating it, you should be aware of the platform differences.

Solution: Simply use the doubleClicked() signal instead of the activated() signal, if your item view needs to distinguish between selection and activation.

Please see the documentation about QAbstractItemView::activated(), ::clicked() and ::doubleClicked() signals.

*** Bug 462973 has been marked as a duplicate of this bug. ***

As broken as that concept of activated vs. double click is, I simply threw out all the itemActivated signals of the YaST2 Qt UI, relying only on itemDoubleClicked instead. It's a workaround, not a solution, of course.

From my side this is issue is done with that workaround. Fixed in SVN trunk.

Created attachment 265357 [details]
Workaround for yast2-qt

> The bug may also cause problems in other Yast modules => Critical

That's no criteria for "Critical" severity.

*** Bug 465106 has been marked as a duplicate of this bug. ***

Should this bug not be assigned to YaST?

(In reply to comment #26)
> Should this bug not be assigned to YaST?
In yast it's fixed with a workaround (see comment #22). 

As the use of the various signals (activated, clicked, doubleClicked) might cause confusions in all qt application with certain widget styles this bug isn't yast specific.

what should we do with this bug?

The style of single/double click is a *user's choice*. by default the KDE4 style is single click. you can *configure it*. The whole thing is a *feature*. 

if you want to disrespect the user, then do your own sh*t. otherwise, adapt to the feature and make sure that your UI works with single-click behavior (macosx like) and with double-click behavior (windows-like)

resolving as invalid because the whole discussion is just pointless.

Uh, just as a heads up VirtualBox is also affected, so looks like it is not that obvious to a lot of people.
(this is no bugreport, just an info)

Hey, using KDE 4.2.1 (not sure if this is important or not) I still have the problem with yast2 repository editor.

I don't understand why this is marked as invalid.
It's a problem.
Other users are encountering the problem.
Since all apps appear to use the same theme and only yast2 is effected (affected?), it would appear to be a yast QT issue.

Since the behavior is still present I'm reopening.

yast2-qt package has been fixed since version 2.18.5 (not in 11.1, you have to install it from FACTORY).

Which version do you have installed? Could you try the latest version from factory?

After installing from factory:

rpm -Uvh libzypp-6.2.2-1.1.x86_64.rpm yast2-qt-pkg-2.18.4-1.7.x86_64.rpm satsolver-tools-0.14.0-1.1.x86_64.rpm yast2-pkg-bindings-2.18.2-1.11.x86_64.rpm libqdialogsolver1-1.2.6-1.38.x86_64.rpm zypper-1.1.0-2.1.x86_64.rpm yast2-ncurses-pkg-2.18.1-1.4.x86_64.rpm zypper-1.1.0-2.1.x86_64.rpm aria2-1.2.0-2.1.x86_64.rpm yast2-ncurses-2.18.5-1.1.x86_64.rpm aria2-1.2.0-2.1.x86_64.rpm yast2-libyui-2.18.6-2.1.x86_64.rpm libboost_signals1_38_0-1.38.0-4.1.x86_64.rpm libreadline6-6.0-4.1.x86_64.rpm boost-license1_38_0-1.38.0-4.1.x86_64.rpm


and running yast2 sw_single

and then switching to repositories:

YaST got signal 11 at YCP file /usr/share/YaST2/clients/repositories.ycp:245
/sbin/yast2: line 437:  7636 Segmentation fault      $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS

(gdb) run repositories -S qt                                                 
Starting program: /usr/lib/YaST2/bin/y2base repositories -S qt               
[Thread debugging using libthread_db enabled]                                
[New Thread 0x7fffeafdf950 (LWP 8585)]                                       
terminate called after throwing an instance of 'std::bad_alloc'              
  what():  std::bad_alloc                                                    

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffeafdf950 (LWP 8585)]
0x00007ffff4ce2645 in raise () from /lib64/libc.so.6
(gdb) bt                                            
#0  0x00007ffff4ce2645 in raise () from /lib64/libc.so.6
#1  0x00007ffff4ce3c33 in abort () from /lib64/libc.so.6
#2  0x00007ffff553f644 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#3  0x00007ffff553da46 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x00007ffff553da73 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5  0x00007ffff553db5a in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6  0x00007ffff553dfb1 in operator new(unsigned long) () from /usr/lib64/libstdc++.so.6
#7  0x00007ffff551b7d1 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) ()
   from /usr/lib64/libstdc++.so.6
#8  0x00007ffff551c07b in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) ()
   from /usr/lib64/libstdc++.so.6
#9  0x00007ffff551caac in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib64/libstdc++.so.6
#10 0x00007fffee4114f4 in YQTableListViewItem::updateCell(YTableCell const*) () from /usr/lib64/YaST2/plugin/libpy2qt.so.2
#11 0x00007fffee411aab in YQTableListViewItem::YQTableListViewItem(YQTable*, QY2ListView*, YTableItem*) ()
   from /usr/lib64/YaST2/plugin/libpy2qt.so.2
#12 0x00007fffee413434 in YQTable::addItem(YItem*, bool) () from /usr/lib64/YaST2/plugin/libpy2qt.so.2
#13 0x00007fffee413a20 in YQTable::addItems(std::vector<YItem*, std::allocator<YItem*> > const&) ()
   from /usr/lib64/YaST2/plugin/libpy2qt.so.2
#14 0x00007ffff2e227a2 in YCPPropertyHandler::trySetTableItems(YWidget*, YCPValue const&) ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
---Type <return> to continue, or q <return> to quit---

#15 0x00007ffff2e25608 in YCPPropertyHandler::setComplexProperty(YWidget*, std::string const&, YCPValue const&) ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#16 0x00007ffff2ddc3d1 in YCP_UI::ChangeWidget(YCPValue const&, YCPValue const&, YCPValue const&) ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#17 0x00007ffff2dbed1c in YUINamespace::ChangeWidget(YCPTerm const&, YCPSymbol const&, YCPValue const&) ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#18 0x00007ffff2dc4538 in YUIFunction::evaluateCall_int() () from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#19 0x00007ffff2de00d2 in YCPBuiltinCaller::call() () from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#20 0x00007ffff2b2f4d3 in YUI::uiThreadMainLoop() () from /usr/lib64/libyui.so.3
#21 0x00007ffff2b2f6fe in start_ui_thread(void*) () from /usr/lib64/libyui.so.3
#22 0x00007ffff6759070 in start_thread () from /lib64/libpthread.so.0
#23 0x00007ffff4d8310d in clone () from /lib64/libc.so.6
#24 0x0000000000000000 in ?? ()

Did you also update yast2-qt package? It looks like a version mismatch...

*** Bug 494399 has been marked as a duplicate of this bug. ***

*** Bug 507115 has been marked as a duplicate of this bug. ***

I'd like to add to this issue from a *user's* point of view (I'm a developer myself, but YAST2 is a tool for me, not a project ;-)):

First of all there are amongst others two possibilities I want to have when working with the repositories module:
1) I want to have an obvious way to *select* a repository to view additional information *without* changing any state of it
2) Maybe I want to have a fast possibility for activating and deactivating a repository, but it's "only" albeit important convenience, if I need not to move my mouse down to the "Enable" check box to change the activation state.

Possibility (1) is a *must* regardless of the chosen interaction style. I myself am used to double clicks for "activating" items as e.g. icons in dolphin or nautilus to run an application or open a file, but e.g. in the case of file browsers (within an according interaction style) also using a single click for that purpose is clear to me. It is not though in the case at hand: in my opinion "enabling" a repository in YAST repository management has a fundamentally different meaning than "activating" a file in the case of file browsers. This becomes clear if you search the Qt signals of QTreeView for a signal called "deactivated" - there is none! You cannot "deactivate" a file in a file browser. The Qt signal "activated" has nothing to do with switching on/off an "enabled" state (btw, it is not comprehensible to me as an user why the "Enabled" state should be switched with principally different methods than the "Automatically refresh" state). Thus regarding comments #22,#26 and #27: yes, it's a YAST bug! The "activated" signal was abused, using the "doubleClicked" signal is not only a workaround but a consistent solution (a context menu would be even better though. Finanly a clear GUI solution also would be if the "Activated" and "Autorefresh" check boxes simply were in separate columns of the view. Then a single click on them had the obvious meaning of changing the respective state and you could select a repository by clicking on the text item of the row).

So, the reason why people (in the openSUSE 11.1 version) see YAST behave strange may be the following: usually you configure your desktop experience as a normal user, not as root. Thus maybe you (as I did) configure KDE to use double click for activating icons. Then you run yast via the start menu, the kdesu module comes in and makes YAST run as root - but you may not have configured your root account to use double click for activation and thus only in the YAST window you get KDE default behavior: single click = activated. Voila...

Sorry, regarding my comment: Enabled and Autorefresh state already have their own columns. Thus clicking in the respective column of a repositorie's row easily could be interpreted accordingly.

I think so but I prefer double click ;?)

Thomas, please check whether the Qt UI contains the patch by Steffan (as written in comment #22) and whether it works correctly in 11.2 (or Factory). Thanks.

Ladislav, yes, the patch is checked in and it works with Oxygen on my machine. I think there isn't anything else that can be done from the yast2-qt side.

OK, closing as FIXED.

*** Bug 527365 has been marked as a duplicate of this bug. ***