settings in $HOME/.kde/config/kdeglobals doesn't respect XDG_DATA_DIRS

Bug #379053 reported by Marc Gariépy
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KDE Base
Fix Released
Medium
kdelibs
Invalid
Undecided
Unassigned
kde4libs (Ubuntu)
Invalid
Low
Unassigned

Bug Description

I'm on a ltsp setup, i can use different .desktop files depending of the user, i set XDG_DATA_DIRS to set desktop file to be used for the users. In my $HOME/.kde/config/kdeglobals i set BrowserApplication[$e]=firefox.desktop but kde doesn't use the environment variable XDG_DATA_DIRS to launch the right firefox.desktop.

I think that kde should look at XDG_DATA_DIRS to launch the applications.

affects: kdebase (Ubuntu) → kde4libs (Ubuntu)
Changed in kde4libs (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

This would probably need a report forwarded to bugs.kde.org

Changed in kde4libs (Ubuntu):
importance: Medium → Low
status: Triaged → Confirmed
Changed in kdebase:
status: Unknown → New
Revision history for this message
In , Benoit des Ligneris (benoit-des-ligneris) wrote :

Version: (using KDE 4.0.5)
OS: Linux
Installed from: Ubuntu Packages

I'm on a ltsp setup, i can use different .desktop files depending of the user, i set XDG_DATA_DIRS to set desktop file to be used for the users. In my $HOME/.kde/config/kdeglobals i set BrowserApplication[$e]=firefox.desktop but kde doesn't use the environment variable XDG_DATA_DIRS to launch the right firefox.desktop.

I think that kde should look at XDG_DATA_DIRS to launch the applications.

https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/379053

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

I doubt that this would ever be fixed for KDE3's kdelibs, but thanks for forwarding it all the same. Is it possible that you could test with a more recent version of KDE4? The version listed in the upstream bug is rather.... old, to say the least.

Changed in kdelibs:
status: New → Invalid
Changed in kde4libs (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Harald Sitter (apachelogger) wrote :

I cannot reproduce this issue, at all.

What I do:
* mkdir -p ~/xdgdata/applications/
* cp /usr/share/applications/arora.desktop ~/xdgdata/applications/
* vim ~/xdgdata/applications/arora.desktop
* change the Exec to konqueror
* export XDG_DATA_DIRS=$HOME/xdgdata/:$XDG_DATA_DIRS
* kbuildsycoca4 .... to ensure the cache is up-to-date
* kfmclient openURL 'http://kubuntu.org'
||
v
opens Konqueror! not Arora.

Please provide more information on how you archive the wrong behaviour?

Changed in kde4libs (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in kde4libs (Ubuntu):
status: Incomplete → Invalid
Changed in kdebase:
importance: Unknown → Medium
Revision history for this message
In , 8-kde-7 (8-kde-7) wrote :

Unless this is still present in current versions, this should be closed.

Revision history for this message
In , Shmerl (shmerl1) wrote :

Interestingly, Debian recently removed kde4libs, which was one of the lingering causes for usage of $HOME/.kde

https://tracker.debian.org/pkg/kde4libs

But something still creates $HOME/.kde/config/kdeglobals for me (it's the only file remaining there now).

KDE Plasma 5.14.5.

Revision history for this message
In , 8-kde-7 (8-kde-7) wrote :

(In reply to Shmerl from comment #2)
> But something still creates $HOME/.kde/config/kdeglobals for me (it's the
> only file remaining there now).
See Bug 405750.
(This is off-topic for this bug.)

Revision history for this message
In , Shmerl (shmerl1) wrote :

(In reply to Erik Quaeghebeur from comment #3)
> (In reply to Shmerl from comment #2)
> > But something still creates $HOME/.kde/config/kdeglobals for me (it's the
> > only file remaining there now).
> See Bug 405750.
> (This is off-topic for this bug.)

Ah, I see. Thanks. I commented there. Not sure why there is some resistance to actually fixing this for good.

Revision history for this message
In , Nate-b (nate-b) wrote :

Bug 405750 is the cause, and the issue here has been fixed in Frameworks 5.

Revision history for this message
In , Shmerl (shmerl1) wrote :

(In reply to Nate Graham from comment #5)
> Bug 405750 is the cause, and the issue here has been fixed in Frameworks 5.

I meant I was wondering, why there is some resistance to fix #405750 for good. Or you mean that one was actually fixed in latest Frameworks 5?

Revision history for this message
In , Nate-b (nate-b) wrote :

Bug 405750 cannot be fixed because then it would break the remaining KDE4 apps that some people are still using (believe it or not). Once nobody is using any KDE4-era apps anymore, then the issue will finally go away. But until that time, we can't change the config file path without breaking old apps.

Revision history for this message
In , Shmerl (shmerl1) wrote :

(In reply to Nate Graham from comment #7)
> Bug 405750 cannot be fixed because then it would break the remaining KDE4
> apps that some people are still using (believe it or not). Once nobody is
> using any KDE4-era apps anymore, then the issue will finally go away. But
> until that time, we can't change the config file path without breaking old
> apps.

I got that part, but I commented how that can be handled without breaking them, while allowing users to avoid cluttering $HOME. I.e. make it a runtime switch. Those who need such old applications (few users likely), will flip the switch, while the rest (majority) can avoid cluttering $HOME by default.

Revision history for this message
In , Shmerl (shmerl1) wrote :

And if you really think the majority is using such old KDE4 applications, and only minority is not, you can make the opposite - by default it will be enabled, and those who don't want to clutter $HOME can opt out by flipping the switch.

Revision history for this message
In , Nate-b (nate-b) wrote :

Making it a user-facing option doesn't make sense IMO. No regular user cares about a hidden file created by obsolete software not being in the correct hidden folder. This is the kind of option that adds visual clutter to the UI and mental clutter to people trying to find things that are more useful.

Let's just wait until Qt 6 rolls around and then we can put this long national nightmare behind us. :)

Changed in kde-baseapps:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.