Version: (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages the "OK" button has a very wrong behavior, ie : - fire kpackagekit, search for any software - click on it - click "ok" (like you could expect to install it) => Kpackagekit close. Please give us a "OK" button that is not a hidden close button.
Yes, that's something I wondered about several times. What I expected: - OK in Software Management: Apply changes and exit - OK in Softwatware Updates: Apply all available updates (without having to press that button before) and exit - Cancel: Exit directly
Besides: The "Default" button is really useless, at least in 0.4. It could be removed. Also it's the question if we really need a Apply *and* an OK button: In most cases you know what you want to install/remove and mark all packages accordingly. After that you expect to press OK and after all the work is done the window is closed unless there are no errors => Apply isn't really needed. Maybe it's compromise to remove the Apply button and let the user choose (by a checkbox in Settings) of he wants to leave the window open or not after pressing OK.
You are probably right, although i cannot test it now, you are probably using kpackagekit executable,, does this happen in system settings too? Thanks.
No, in System Settings there is no OK or Cancel button, only Apply (and the useless Reset and Default buttons).
it's similiar to the bug I found:when I check "all possible updates", press OK, program crashes with this backtrace: Application: KPackageKit (kpackagekit), signal: Segmentation fault [KCrash Handler] #6 QWidget::window (this=0x92669e0) at kernel/qwidget.cpp:3883 #7 0xb67f4d2e in QApplicationPrivate::dispatchEnterLeave (enter=0x911e560, leave=0x92669e0) at kernel/qapplication.cpp:2527 #8 0xb67f517a in QApplicationPrivate::sendMouseEvent (receiver=0x911e560, event=0xbfa006c0, alienWidget=0x911e560, nativeWidget=0x90b76f8, buttonDown=0xb7068aa0, lastMouseReceiver=...) at kernel/qapplication.cpp:2908 #9 0xb68637c0 in QETWidget::translateMouseEvent (this=0x90b76f8, event=0xbfa01d0c) at kernel/qapplication_x11.cpp:4409 #10 0xb6862c4b in QApplication::x11ProcessEvent (this=0xbfa020a0, event=0xbfa01d0c) at kernel/qapplication_x11.cpp:3428 #11 0xb688f502 in x11EventSourceDispatch (s=0x9028368, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #12 0xb5a10e78 in g_main_dispatch (context=0x9027690) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:1960 #13 IA__g_main_context_dispatch (context=0x9027690) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2513 #14 0xb5a14720 in g_main_context_iterate (context=0x9027690, block=<value optimized out>, dispatch=1, self=0x902a980) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2591 #15 0xb5a14853 in IA__g_main_context_iteration (context=0x9027690, may_block=1) at /build/buildd/glib2.0-2.22.2/glib/gmain.c:2654 #16 0xb658302c in QEventDispatcherGlib::processEvents (this=0x9007f08, flags=...) at kernel/qeventdispatcher_glib.cpp:327 #17 0xb688ebe5 in QGuiEventDispatcherGlib::processEvents (this=0x9007f08, flags=...) at kernel/qguieventdispatcher_glib.cpp:202 #18 0xb6556c79 in QEventLoop::processEvents (this=0xbfa02004, flags=) at kernel/qeventloop.cpp:149 #19 0xb65570ca in QEventLoop::exec (this=0xbfa02004, flags=...) at kernel/qeventloop.cpp:201 #20 0xb655953f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #21 0xb67eddd7 in QApplication::exec () at kernel/qapplication.cpp:3525 #22 0x0804e47b in _start () My kpackagekit -v output: Qt: 4.5.2 KDE: 4.3.2 (KDE 4.3.2) KPackageKit: 0.4.2
*** Bug 214377 has been marked as a duplicate of this bug. ***
Yes, now that I have a bit more time I'll fix this, I'll post here when it's done. Thanks.
Fixed in 1050041 which will be fixed in 0.5.1 some time soon. Thanks.