Version: 3.4.0 (using KDE 3.4.0, Mandrake Linux Cooker i586 - Cooker) Compiler: gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk) OS: Linux (i686) release 2.6.8.1-24mdk Folowing the steps, click in Kmenu -> Run Command, there if you click to show the list of runned apps and you select one, its executed imediatly, and shouldnt happen that, it should wait for the click to run the command. How can this be fixed?
yay, this bug is back =/
I don't think this behavior was ever different. IIRC Dawit made it that way from the start, arguing that it saved a click (or a keypress). However I agree that this is a bug: what if I select an item from the history in order to "fix" that command line? Then it shouldn't submit immediately.
On Thursday 03 March 2005 12:20, David Faure wrote: > ------- Additional Comments From faure kde org 2005-03-03 18:20 ------- > I don't think this behavior was ever different. IIRC Dawit made it that way > from the start, arguing that it saved a click (or a keypress). However I > agree that this is a bug: what if I select an item from the history in > order to "fix" that command line? Then it shouldn't submit immediately. Actually, the problem is not in minicli. It is in KCompletionBox. Yes, it can be easily fixed in minicli, but the last time we did that people on the other side of the fence complained to no end so it was reverted since it changed the original behavior. However, we can easily solve this problem the same way we solved the problem selecting and item using the keyboard and pressing the Enter key. If you press Shift+Enter, the item is only selected ; so following the same scheme (for consistency sake) the following patch to KCompletionBox allows you to simply select the item using Shift+Click (can be made LeftButton click only if that is what is desired).... Created an attachment (id=9963) kcompletionbox.diff
On Friday 04 March 2005 09:01, Dawit Alemayehu wrote: > Actually, the problem is not in minicli. It is in KCompletionBox. Yes, it can > be easily fixed in minicli, but the last time we did that people on the other > side of the fence complained to no end so it was reverted since it changed > the original behavior. Do you have a reference (bug number or mailing-list archive) to those "complaints"? Honestly I can't see how someone would defend this. I mean OK maybe for the keyboard case, but certainly not for the mouse case: clicking an item in a list never submitted the dialog, anywhere else, ever. Only the "pressing Return" case is sort of arguable. > However, we can easily solve this problem the same way > we solved the problem selecting and item using the keyboard and pressing the > Enter key. If you press Shift+Enter, the item is only selected ; so following > the same scheme (for consistency sake) the following patch to KCompletionBox > allows you to simply select the item using Shift+Click (can be made > LeftButton click only if that is what is desired).... Personally I disagree. This bug report would still be here even if Shift+Click did the job. Who would find this hidden secret?
i agree with David completely. make Shift+Click the "select + execute" command. but it really makes no sense whatsoever to have the default "select + execute" here's the use case that i run into: i select something to run from the completion list and then want to change the user to run it is ... but... it's already executed. bleh. this makes the run dialog's other features _useless_ in combination with the autocompletion list.
I personally have no preference about this issue as it pretains to Minicli ; so please feel free to remove/comment out the signal/slot that causes this in Minicli...
> I personally have no preference about this issue as it pretains to Minicli ; so please feel free to remove/comment out the signal/slot that causes this in Minicli... Thanks but which signal/slot? :) If I remove this connect then there's no way to submit with Return at all anymore (even when no completion is open). - connect( m_dlg->cbCommand, SIGNAL( activated( const QString& ) ), - m_dlg->pbRun, SLOT( animateClick() ) ); I guess it's something deeper in the completion popup that we need to deactivate... But I don't see how - I guess we need a new setTrapReturnKey or similar in KCompletionBox itself, since currently it only consumes Shift+Enter events?
Well i applyed the patch but didnt make any difference!
On Friday 04 March 2005 23:11, mmodem00@netvisao.pt wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=100733 > > > > > ------- Additional Comments From mmodem00 netvisao pt 2005-03-05 05:11 > ------- Well i applyed the patch but didnt make any difference! Did you make sure you make install in kdelibs/kdeui and restart KDE beforehand ? Otherwise the change will not take effect. Once you do that the Shift+Click should not execute the selection with that patch. However, it is a moot point now since I will post a new patch that changes the behavior as requested. Since previous discussions...
AH is needed to press in Shift with the click. Well but the correct behaviour wouldnt be with the need of pressing in the Shift key, should work onli with the mouse click, and with that, just after i click in a app from the drop down list, is executed without waiting for the click in the execute button.
Dave, Indeed KCompletionBox needed to be modified ; so here is a couple of patches for KCompletionBox and one for Minicli which should forever fix this problem... Created an attachment (id=9976) kcompletionbox.diff Created an attachment (id=9977) minicli.diff
On Saturday 05 March 2005 08:22, Dawit Alemayehu wrote: > Indeed KCompletionBox needed to be modified ; so here is a couple of patches > for KCompletionBox and one for Minicli which should forever fix this > problem... Dawit: Thanks for the patches. I can confirm that they don't work though :/ kdesktop: [void KCompletionBox::setActivateOnSelect(bool)] false That's called fine, but the rest of the new code isn't hit, when I click on an item in the popup.
On Saturday 05 March 2005 20:50, David Faure wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=100733 > > > > > ------- Additional Comments From faure kde org 2005-03-06 02:50 ------- > > On Saturday 05 March 2005 08:22, Dawit Alemayehu wrote: > > Indeed KCompletionBox needed to be modified ; so here is a couple of > > patches for KCompletionBox and one for Minicli which should forever fix > > this problem... > > Dawit: Thanks for the patches. > I can confirm that they don't work though :/ > > kdesktop: [void KCompletionBox::setActivateOnSelect(bool)] false > That's called fine, but the rest of the new code isn't hit, when I click on > an item in the popup. The obvious question: did you do make install in kdelibs/kdeui ? It works fine for me. I am trapping the mouse click events if the emitSelected flag is set to false in KCompletionBox...
i still didnt applyed the patches. Arent this going to be uploaded to cvs? If so theres no need to put the patches in spec file, just update the source code, now i would like to when uploaded in cvs?
On Sunday 06 March 2005 03:26, Dawit Alemayehu wrote: > The obvious question: did you do make install in kdelibs/kdeui ? How would I see the call to KCompletionBox::setActivateOnSelect(bool) if I hadn't? :) > It works fine for me. I am trapping the mouse click events if the emitSelected flag is set > to false in KCompletionBox... Ah, I see. There are two cases. 1) When I type something, completion box opens, I click an item -> indeed it works, minicli isn't closed. 2) But if I directly open the combo with the mouse, and then click on an item => minicli is closed. I believe this case should also let me edit the string I clicked on, no? I can confirm that your patch fixes 1) in any case - thanks for that.
CVS commit by adawit: - Do not execute when selecting an item from either the text completion box or the combobox's dropdown list box. Needs update of kdelibs/kdeui to work. BUG:100733 M +6 -2 minicli.cpp 1.191 --- kdebase/kdesktop/minicli.cpp #1.190:1.191 @@ -64,4 +64,5 @@ #include <kmimetype.h> #include <kurifilter.h> +#include <kcompletionbox.h> #include "minicli.moc" @@ -130,6 +131,4 @@ Minicli::Minicli( QWidget *parent, const connect( m_dlg->cbCommand, SIGNAL( textChanged( const QString& ) ), SLOT( slotCmdChanged(const QString&) ) ); - connect( m_dlg->cbCommand, SIGNAL( activated( const QString& ) ), - m_dlg->pbRun, SLOT( animateClick() ) ); // Advanced group box... @@ -213,4 +212,8 @@ void Minicli::loadConfig() m_dlg->cbCommand->setCompletionMode( (KGlobalSettings::Completion) mode ); + KCompletionBox* box = m_dlg->cbCommand->completionBox(); + if (box) + box->setActivateOnSelect( false ); + m_finalFilters = KURIFilter::self()->pluginNames(); m_finalFilters.remove("kuriikwsfilter");
with this change, when building kdebase i get this error: In file included from libkdeinit_kdesktop_la.all_cpp.cpp:2: minicli.cpp: In member function `void Minicli::loadConfig()': minicli.cpp:219: error: 'class KCompletionBox' has no member named 'setActivateOnSelect' make[3]: ** [libkdeinit_kdesktop_la.all_cpp.lo] Erro 1 make[3]: Leaving directory So its impossible to build kdebase. -- Zé Linux user #378762
On Wednesday 09 March 2005 08:24, mmodem00@netvisao.pt wrote: [bugs.kde.org quoted mail] Update kdelibs/kdeui....
eheehehhe, i compiled kdelibs, but i did forgot to install it, and i was already compiling new kdebase :)
Bug closed. Kdesktop is no more mantained.