Bug 175176

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

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

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

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

As stated in bug 179372 comment 5 I can reproduce this in current trunk. Now in this bug I see a proper way to reproduce it :)

May be bug 180241 related to this?

Would be a great thing to fix before kde 4.2 release. To me it feels like it doesn't run the command I type exactly 50% of the times.

After deleting my .kde4/share/config/krunnerrc, I'm not able to reproduce this any more. Unfortunately I forgot to back up the old config.

Ok, after typing some other commands, it actually did happen again, so it probably isn't related to krunnerrc.

Same problem here. Another workaround is to delete the last letter and retype it. Should be great to be fixed before 4.2.

Same problem here and all 3 workarounds working.
When I run krunner in konsole and type in for example kwrite, I have:
"QObject: Do not delete object, 'unnamed', during its event handler!" for every letter.

I must say I encounter the bug on daily basis now, so if you wanna have debugging requests for me, feel free.

Today I even encountered even worse behavior, that is, none of the workarounds worked. It simply did not run anything on ENTER no matter what I tried. Closing the window and opening it again got me back to the old buggy behavior, with the workarounds working.

This all suggests it really is some silly oversight with handling objects and/or memory.

Thanks to a long flight, I managed to come up with something.

The bug is originated in the following function:

workspace/krunner/interfaces/default/interface.cpp:432

void Interface::queryTextEdited(const QString &query)
{
[...]
        m_resultsScene->launchQuery(query);
        m_queryRunning = true;
[...]    
}

the variable m_queryRunning is always set to true after launching a query.
*BUT* in the case described in the bug report we have that the function launchQuery actually does not launch any queries since we have just queried the exact same term last time (the autocompleted string), therefore:

kdelibs/plasma/runnermanager.cpp:407

void RunnerManager::launchQuery(const QString &term, const QString &runnerName)
{
[...]
    if (d->context.query() == term) { //-----------RETURNS TRUE---------
        // we already are searching for this!
        return;
    }

Since it returns without launching a query, the following function will never be invoked:

workspace/krunner/interfaces/default/interface.cpp:460
void Interface::matchCountChanged(int count)
{
    m_queryRunning = false;
    [...]
 
therefore m_queryRunning is never reset to false and so:

workspace/krunner/interfaces/default/interface.cpp:423
void Interface::runDefaultResultItem()
{
    if (m_queryRunning) { //------- RETURNS TRUE!
        m_delayedRun = true;
    } else {
        run(m_resultsScene->defaultResultItem());
    }
}

and the command is not executed.

I came out with a patch which lets launchQuery return true or false depending on the fact that a query is launched or not. I attach the patch in two pieces: one for krunner, the other one for kdelibs, I didn't really know the best way to put them togheter. 
It shouldn't break anything but PLEASE CHECK, I really would like to see this bug fixed before 4.2.

(Also, this might well be unrelated but the patch seems to resolve an occasional crash that I noticed when typing an exact match (e.g. systemsettings), then hitting backspace to delete the last letter (and all matches disappear) and hitting return to run the command. This usually lead to a crash)

Created attachment 30614 [details]
patch for workspace/krunner

Created attachment 30615 [details]
patch for kdelibs/plasma

Has anybody checked out the patches I attached? Do they solve the problem for you as well?

@Jacopo: I just applied it and it seems to work OK, I will try it a little more. But I suppose we need aprooval from someone related to KRunner/Plasma
Good job :)

Come on plasma devs, there is even a patch, what's going on with this?

This bug renders krunner one of the most frustrating app I've used for a long time(It's totally useless if it doesn't run the app).

SVN commit 919611 by beatwolf:

allow krunner to launch applications that have been launched before.
BUG:175176


 M  +6 -5      runnermanager.cpp  
 M  +2 -2      runnermanager.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=919611

SVN commit 919616 by beatwolf:

Allow krunner to run application that have already been launched from krunner
BUG:175176


 M  +1 -2      interface.cpp  
 M  +4 -4      resultscene.cpp  
 M  +2 -2      resultscene.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=919616

Actually i'm sorry, had to revert the patch.
The patch is binary incompatible (for kdelibs). I try to come up with another solution of the problem, if there is one.

SVN commit 919662 by beatwolf:

found a binary compatible way to do exactly the same as the previous patch.
BUG:175176



 M  +3 -2      interface.cpp  
 M  +6 -2      resultscene.cpp  
 M  +2 -2      resultscene.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=919662

(In reply to comment #22)
> SVN commit 919662 by beatwolf:
> 
> found a binary compatible way to do exactly the same as the previous patch.
> BUG:175176
> 
> 
> 
>  M  +3 -2      interface.cpp  
>  M  +6 -2      resultscene.cpp  
>  M  +2 -2      resultscene.h  
> 
> 
> WebSVN link: http://websvn.kde.org/?view=rev&revision=919662
> 

Much better, thanks!!
Btw,

bool temp = !(term.isEmpty() || m_runnerManager->query() == term);
  m_runnerManager->launchQuery(term, runner); 	    

why do you still call launchQuery if we already know it is not going to do anything?

 J

good question.

From what i can see,it actually does stuff:

    if (d->runners.isEmpty()) {
        d->loadRunners();
    }

    if (term.isEmpty()) {
        reset();
        return;
    }

Since i did not write that code, and i'm not totaly sure about the implications of not calling the code, and it is not a performance critical code, i decided to call it anyway. good or bad?
    if (d->context.query() == term) {
        // we already are searching for this!
        return;
    }

that was actually one code segment. I must have missclicked to write my text in the middle of it. Here the same code segment:

    if (d->runners.isEmpty()) {
        d->loadRunners();
    }

    if (term.isEmpty()) {
        reset();
        return;
    }

    if (d->context.query() == term) {
        // we already are searching for this!
        return;
    }

good point indeed.
do you mind backporting it to 4.2?

Thanks 

 -- J

backported it

Great, thanks. Seems to work very good.

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

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

Sorry I have to tell this, but in KDE 4.2 with recent opensuse development packages, I still experience the problem. Not as often as when I wrote last time into this bug, but still about 1/4 of the times.

So I guess there is still a problem that's not fixed?

does it have anything to do with the history this time? 
Could it be just the same as #181453 (which appears unrelated)?

Ah yes that's exactly what I'm talking about, thanks.

I'm afraid this really isn't fixed yet. With 4.2.2, I am seeing this behaviour a lot (as well as seeing no hit icons when entering an url I had previously entered until I've typed all of it).

(In reply to comment #34)
> I'm afraid this really isn't fixed yet. With 4.2.2, I am seeing this behaviour
> a lot 

Are you sure you're not hitting bug #181453 (fixed now, but not in time for 4.2.2)

> (as well as seeing no hit icons when entering an url I had previously
> entered until I've typed all of it).

What do you mean exactly by that? 
- If the url is in the browser history and you have the webrowser history runner enabled you should be able to see items (icons with an hourglass) also if you don't type the whole url
- If you see the url completed in gray, you can hit the right arrow key, or the end key (the TAB key also works, sometimes) to complete it without having to type it all over again. 

There used to be a bug which would automatically look for items matching the autocompleted (grey) string, and this has been fixed. If you are expecting this behaviour, I am afraid it's not there anymore.

It's quite possible that it's the same thing as 181453 -- although it often happens that opening krunner for the second time and choosing the command again still doesn't do anything.

About the other behaviour: if this means that I have to press an extra key just to open an autocompleted url (like in KDE 3.5) then that is quite disappointing. 

In KDE 4.2.2, the behaviour of krunner is, I'm afraid, quite annoying all over. I often get kmahjong as first hit when searching for kmail -- kmail is autocompleted (but I didn't press end, tab or whatever yet), the first hit is kmahjong. I never ran that application -- it looks like krunner isn't taking my history into account.

Btw, the layout is again getting screwed up -- I know that's a different bug, and I think I've even reported that bug myself.

(In reply to comment #36)
> It's quite possible that it's the same thing as 181453 -- although it often
> happens that opening krunner for the second time and choosing the command again
> still doesn't do anything.

Ok, this indeed sounds different from 181453, but there are possibly lots of other ways to reproduce that bug.
 
> About the other behaviour: if this means that I have to press an extra key just
> to open an autocompleted url (like in KDE 3.5) then that is quite
> disappointing. 

Again, the previous behaviour was a bug rather than a feature; please note that this does not mean that this feature will not be implemented in the future. You are welcome to open a wish for that so that people can vote for it (and, personally, I will ;) ) and we can implement it with some grain of salt.

The previous behaviour had some nasty flaws: the bug was that that we were querying _only_ the autocompleted string, so that, for instance, if you mistyped once your favourite url like "www.kde.org\", you will not be able to run "www.kde.org" until that entry goes out of the history. Also, consider the case you have two legit apps (like {firefox,firefox-bin} or {quassel,quasselcore}) that share the first letters and you run first the longer one, there is no way you would be able to run the short one.  


> In KDE 4.2.2, the behaviour of krunner is, I'm afraid, quite annoying all over.
> I often get kmahjong as first hit when searching for kmail -- kmail is
> autocompleted (but I didn't press end, tab or whatever yet), the first hit is
> kmahjong. I never ran that application -- it looks like krunner isn't taking my
> history into account.

in fact, it does not. Again, please open a wish.

-- J