Version: (using KDE KDE 4.0.0) Installed from: Compiled From Sources Compiler: gcc 4.1.2 OS: Linux I installed KDE4 as detailed in http://techbase.kde.org/Getting_Started/Build/KDE4 , so I have a normal KDE installation beside it. Now, if I do 'ssh -X kde-devel@localhost' then I issue "plasma", if I click on the simple menu's "system configuration", the KDE3's system configuraition gets launched. However, if I do the same with the 'normal' plasma menu, it launches the system config dialog of the KDE4. This is a mix-up due to the fact that both KDE3 and KDE4 are installed - I however think that KDE3 and KDE4 might be installed in this way for a longer amount of time, so this issue needs to be solved. Also to note is that this bug could point at something more sinister than a typo, so it is worth investigating anyways. BTW: reploducing this bug is trivial, just install as in the techbase, click on the simple menu, click on system settings, and voila!
Hi Máté :) is the "System Settings" item displayed at the root of the menu? So, not in a submenu? If yes, this may a duplicate of bug #155587 and the KDE3 settings are displayed since Kickoff only finds the KDE3 settings and if the KDE4 settings can't be found, the old ones are displayed.
Well, possibly yes, but I am not sure. The same icon in the Simple Menu and the "normal" menu don't activate the same thing even if both menu types are loaded. What I find strange is that if the "normal" menu finds the KDE4 settings, why doesn't the "simple" one? If you find my reasoning unsatisfying you can mark the bug as duplicate, though. I can't think that this bug will be the most important one in KDE4, but, it's kind of strange behaviour. PS: Is there a way of explicitly launching KDE3 or KDE4 system config from either of the menus? Or is this by chance/(meant-to-be)deterministic in some way?
Guess you are right and it's clearly not related to bug #155587 since both menus are using the same model and therefore they launched application should be the same. So, I would suggest to leave it open a while and look if there may anybody else who has the same problem. re reproducing; I can't reproduce this on my system but on the other hand I've some other not related issues nobody else can reproduce. Heh, probably the fate of slightly changing the default installation-method ;) re explicit launching; it's deterministic. If a KDE4 version of the same program is found, the KDE4 version is displayed else the KDE3 version got displayed. Through I agree, that for the system-settings it doesn't really make sense.
Sebastian: was this bug fixed recently? i seem to recall seeing a commit along these lines ... ?
Aaron: not that I know of and I still can't reproduce this at all. Through there is another issue probably related to this one that doesn't got reported yet afaik. If something got added to the favorites or if an application got started, the favorite- and recentlyused-models don't got updated. Guess we would need those "changelistener" (sorry, forgot the right kde-name and I am a bit to finished atm to look through the kopete-code to remember how it was named ;) ) for the configfile there to do a model->reset(); if something changed. In the current situation the not-changed model may lead to a case, where you click on an item and something else starts :-/ Maybe better to create a new report for this one?!
KDirWatch, i suppose. however, in this case there is no single file. what one probably wants to do is connect to KSycoca::self()'s databaseChanged() signal and reset the models when that happens.
assigned bug to myself to take the discussion in bug #157969 into account ;)
ah, even better. I found a duplicate of what I described at comment #5 @ Máté Soós If you can still reproduce this with 4.0.1 please reopen. Thanks in advance. *** This bug has been marked as a duplicate of 154503 ***