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 3106

Summary: K3b integration present in Konqueror despite removing k3b
Product: TDE Reporter: Jan Stolarek <jwstolarek>
Component: non-core programsAssignee: Michele Calgaro <michele.calgaro>
Status: RESOLVED INVALID    
Severity: normal CC: bugwatch, jwstolarek, michele.calgaro
Priority: P5    
Version: R14.0.x [Trinity]   
Hardware: Other   
OS: Linux   
Compiler Version: TDE Version String:
Application Version: Application Name:
Attachments: Konqueror context menu

Description Jan Stolarek 2020-05-05 02:49:02 CDT
Created attachment 2957 [details]
Konqueror context menu

I purged all k3b packages from my system but despite that k3b integration is still present in Konqueror. Right-clicking on a file to bring the context menu and then going into "Actions" submenu shows "Create data CD/DVD with k3b..." entries - see attached screenshot. Removing k3b_*.desktop files from ~/.trinity/share/apps/konqueror/servicemenus solves the problem.
Comment 1 Michele Calgaro 2020-05-05 08:31:01 CDT
Hi Jan,
I don't think this is a bug. If you had k3b files in ~/.trinity/share/apps/konqueror/servicemenus, probably sometime in the past for some reasons a copy of the files in /opt/trinity/share/apps/konqueror/servicemenus was made there (updates, manual editing in k3b, ...). In that case even if you remove the k3b packages, kdesktop still find the files in your local folder and correctly add them to the list of known services, although they may be non existing anymore.

If you still have a copy of those deleted files, you could try to compare them with the files in /opt/.... to see what the differences are. That may give some clue.

As for this bug itself, I don't think there is anything that needs fixing :-) What do you think?
Comment 2 Jan Stolarek 2020-05-05 08:36:13 CDT
My thought was that it would make sense for an uninstall script to remove such files, but on a second thought it is probably not a good idea to touch things in user's home directory during package removal. I definitely didn't create these files by hand, but my ~/.trinity folder dates back to the days of.... well, I don't even remember how old it is. 5-8 years would be a good guess, so a lot of stuff from older days could actually be there.

Anyway, if you feel this is not a problem on TDE side please close this report.
Comment 3 Michele Calgaro 2020-05-06 11:41:50 CDT
Hi Jan,
as you also said, it is not a good idea to touch things in the user's folder. 
A copy of those files is usually done automatically under some specific circumstances, usually related to some updates. I can't remember exactly when, I would have to check the code, but it happened to me as well in the part  (something related to versioning of the files). So if your user folder is that old, I am not too much surprised :-)

I am going to close the bug, for the simple reasons there the software is working as expected and we definitely don't want to interfere with user folder staff :-)