By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 927

Summary:	Kate: Can't concurrently run kate with tdesu
Product:	TDE	Reporter:	Darrell <darrella>
Component:	tdebase	Assignee:	Calvin Morrison <mutantturkey>
Status:	RESOLVED FIXED
Severity:	critical	CC:	bugwatch, darrella, kb9vqf, slavek.banko
Priority:	P1
Version:	R14.0.0 [Trinity]
Hardware:	Other
OS:	Other
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Bug Depends on:	394
Bug Blocks:

Description Darrell 2012-03-22 19:50:53 CDT

While running kate as normal user, I can't concurrently start kate with tdesu. Or vice-versa. I can run kate as normal user or through tdesu but not both.

I use a different colored background to know when I am using kate as root.

I believe kate is starting as root but uses the normal user's already open session rather than starting a root session because when I minimize kate and then try to start kate, the kate icon flashes or maximizes.

When I start kate with tdesu and then try to start kate as normal user from a terminal, I notice the following error messages:

WARNING: DCOPReply<>: cast to 'uint' error
WARNING: DCOPReply<>: cast to 'bool' error

The problem does not occur with other apps, such as kwrite, kedit, konqueror, kompare. Therefore I think the problem is related to the odd way kate functions.

I am not using any kate testing patches from bug report 692 that affect focus or multiple document interface. I rebuilt tdebase without those patches after noticing this bug.

Same results with a fresh profile.

I do not see this behavior in KDE3. In KDE3 I can open kate concurrently as normal user and root.

Comment 1 Darrell 2012-03-22 19:51:33 CDT

Note: This is with the latest GIT.

Comment 2 Darrell 2012-04-09 21:31:08 CDT

I toyed with this further. I still cannot open kate as root and then concurrently open kate as normal user. I always see the DCOPReply warnings. I can open kate in the sam order in KDE3 and everything works.

I did confirm an odd relationship to the MDI patch from bug report 692. I have to disable that option for both the normal user and root and then I can open a root session of kate concurrently after starting a normal user's session. Yet I still can't start a normal user session after starting a root session.

I back ported the same patches to KDE3 and do not see this problem there.

Comment 3 Darrell 2012-04-10 00:14:02 CDT

I found the problem. I don't know the correct long-term solution.

The problem is caused by the patch pushed in GIT hash 2b178a53, 2011-10-26 (SVN revision 1260900). The patch was pushed to resolve bug report 394.

I rebuilt tdebase with that 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 the weird dcop warnings.

Thus far I do not notice any xsession "Klauncher could not be reached via dcop" errors as originally reported in the bug report.

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 correct. If the patch is required, then the change has nasty effects and needs resolution elsewhere.

Comment 4 Darrell 2012-04-16 16:13:42 CDT

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

Comment 5 Darrell 2012-04-28 13:38:55 CDT

Calvin, Tim,

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

Comment 6 Darrell 2012-04-28 20:30:02 CDT

Patch from GIT hash 2b178a5320 11-10-26 (SVN revision 1260900) reversed in GIT hash 3d7141e5.

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

Comment 7 Darrell 2012-06-07 22:11:04 CDT

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