If you use one of the "Super User Mode" apps like konqueror file manager. The desktop can no longer launch applications as a normal user until Trinity is restarted. You get a Klauncher error message that "Klauncher could not be reached via dcop".

  It looks like after a super user app is run - the dcop is stuck in super user mode or something similar. I don't know how to go about chasing this down, but wanted to bring it to the lists attention. I also want to know if someone else can confirm this behavior.

  Just open System->Super User->File Manager-Super User Mode

  It will work fine. Then close it. No go try and open any other app as a normal user (i.e. kwrite). It won' work. You will get the error:

"Klauncher could not be reached via dcop"

  So what every gets changed when dcop runs a Super User mode app -- doesn't get undone when the app exits.

  This exists in current builds as of 5/13 and is also present in 3.5.12. (Bug 491 I think)

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

Fixed in SVN revision 1260900.

Thanks for reporting!

I needed to reverse this patch in order to resolve the problems reported in bug report 927.

I'm running GIT.

The problem reported in bug report 927 is caused by the patch pushed for this bug report.

I rebuilt tdebase with this patch reversed. Now I have no problems whatsoever using kate as normal user and concurrently as root through tdesu. The patches from bug report 692 have no ill effects either as I now have both my normal user kate and root's kate configured to use Calvin's patch for MDI usage. When I first start kate as root and then concurrently run kate from konsole as normal user, I no longer see any dcop warnings as reported in bug report 927.

Thus far I do not notice any xsession "Klauncher could not be reached via dcop" errors as originally reported in this bug report. (Could those original errors have been caused by inadvertent "tq" conversions?)

Reversing the patch restores the code to 3.5.10 status. I run both KDE3 and TDE and in KDE3 I notice none of these problems. With the reversed patch, behavior is now the same in both desktops.

Yet as I mentioned, I don't know whether the patch is valid. If the patch is required, then the change has nasty effects and needs a more robust resolution to avoid the problem reported in bug report 927.

I'm reopening the bug report because I don't know whether the patch remains valid. Additionally, should others experience the problems I reported in bug report 927, and they decide to reverse this patch, then this bug report serves as a conduit for troubleshooting should those original "Klauncher could not be reached via dcop" errors return.

Bumping to Critical because the proposed solution for reopening the bug report reverts a previous patch, which now requires some "root cause analysis."

Tim,

I have been using the reversed patch since April 10 (Comment 4). I am not noticing problems. Do we want to reverse the patch or do we need any special testing?

(In reply to comment #6)
> Tim,
> 
> I have been using the reversed patch since April 10 (Comment 4). I am not
> noticing problems. Do we want to reverse the patch or do we need any special
> testing?

We need to make sure that the original bug that prompted that patch does not return when it is reversed.

I no longer see the error messages of the original report. I don't know what other patch contributed to eliminating the messages.

I doubt this patch was the primary cure. I suspect two contributing problems at that time and one masked the other. When we applied this patch we thought we cured the problem but then we applied another patch elsewhere and that was the true cure. We never noticed because we thought the problem no longer existed.

Reversing the patch, GIT hash 2b178a53, has not resurrected these error messages.

Well, since you are the original bug reporter, and you would therefore know how to reproduce the original bug, I'll take your word for it that this patch is not needed.

Go ahead and revert it!

Okeydokey. Patch reversed in GIT hash 3d7141e5.

Should the error messages return or are reported by others we can look deeper next time. Fortunately, this is a small and uncomplicated patch.

I'll leave this bug report open for a while in case the problems reported return.

I'm closing this bug report. I have noticed no problems since reversing the patch in GIT hash 3d7141e5.