SUMMARY **NOTE THAT I SELECTED "QUICKLAUNCH" AS COMPONENT AS I HAD TO SELECT ONE AND THE CORRECT ONE (APPLICATION DASHBOARD) WAS NOT PRESENT.** If I edit an application in the Application Dashboard to add an environment variable, when I re-open the settings for that application the environment variable is gone. Note that the .desktop file on disk is correctly updated, but the Application Dashboard does not show it. Also, when launching the application from the Application Dashboard it behaves as if the environment variable is not set. If I use kmenuedit to update the application (instead of directly editing it in the Application Dashboard) the behavior is the same. STEPS TO REPRODUCE 1. Open Application Dashboard 2. Right click on a launcher and choose "Edit application..." 3. In the properties for the application, click on the "Application" tab 4. Enter an environment variable in the "Environment Variables:" entry field 5. Click the OK button 6. Go through steps 1..3 again and verify the absence of the environment variable you just set OBSERVED RESULT The environment variable is not visible in the application properties. The environment variable is saved in the .desktop file on disk. Launching the application from Application Dashboard, it behaves as if no environment variable was set. EXPECTED RESULT The environment variable is visible in the application properties. The environment variable is saved in the .desktop file on disk. Launching the application from Application Dashboard, behaves correctly based on the environment variable that was set. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20241217 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.11.8-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 550 / 550 Series ADDITIONAL INFORMATION n/a
Does it work as expected if you reboot the system after setting the environment variable? Does it work as expected in a different launcher, like Kickoff or Kicker?
Hi Nate! After a reboot, launching the applications behaves as if the environment variable was set, so this is an improvement. However, looking at the application properties shows no environment variable. The .desktop file on disk does have the environment variable in the Exec directive. Changing the launcher does not change the behavior, which is exactly as above (i.e. no environment variable is shown in application settings, but the variable "works").
Changing status back to REPORTED as information was provided.
...after another reboot we're back to square one :-( - desktop file on disk still contains the environment variable in the "exec" directive - application behaves again as if the environment variable was NOT set - application properties in the launcher show no trace of the environment variable This bug seems completely random, I find no consistence in the behavior.
After a few weeks, it seems to me that the behavior is as follows: - environment variables, though present in the .desktop files, are never shown in the GUI when choosing "Edit application..." in the launcher - applications which have environment variables in their launchers only behave correctly every other boot Is there any activity being done on this bug?
I'm not able to replicate this on Plasma 6.2.5 or git-master For instance, I edited Firefox to have GTK_USE_PORTAL=1 After saving, closing, and re-editing the menu entry, the environment variable is still shown. I want to do some further testing with Tumbleweed. Can you please let me know what application you edited, what variable you added, and what behavior you expect to see in the app as a result? Thanks.
Hi TraceyC! I have a new 4K monitor, and I'm using 150% scaling. Unfortunately not all applications behave correctly. Especially Java applications, but some GTK applications too. I have also experimented with the settings for X11 apps, setting "Apply scaling themselves" or "Scaled by the system", but whatever I set it to it fixes some apps and breaks some other apps. At last, I settled to "Scaled by the system" and used some environment variables to fix the applications that behave badly. For example, LibreOffice behaves bad. I am able to fix it by using QT_FONT_DPI=192 as environment variable. So I have for e.g. LibreOffice Writer, this line in the .desktop file: Exec=env QT_FONT_DPI=192 libreoffice --writer %U But when I open the settings for the launcher, the Environment Variables field is empty. When I launch it, every other boot it behaves correctly. The other times, the fonts are so tiny that it is unusable. Another example is DBeaver (a software for working with databases written in Java). I can make it work correctly by setting the variables GDK_BACKEND=x11 and GDK_DPI_SCALE=1.5. Its .desktop file contains this line: Exec=env GDK_BACKEND=x11 GDK_DPI_SCALE=1.5 /usr/share/dbeaver-ce/dbeaver But when I open the settings for the launcher, the Environment Variables field is empty. The behavior is the same as LibreOffice: it works only every other boot. Another software I use is Rednotebook. It is available in Tumbleweed's repos, but it is not up to date, so I am using the Flatpak version. It has some problems with my dark theme, so I forcce another theme by using the variables GTK_THEME=Adwaita:dark and GDK_BACKEND=x11. In this case, the launcher do show the variables, and it always behaves correctly. Its exec line is this: Exec=env GTK_THEME=Adwaita:dark GDK_BACKEND=x11 /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=rednotebook app.rednotebook.RedNotebook I have other applications for which the launcher does not show the variables, but they seem to work correctly every time. It is very difficult to find a common pattern.
Thanks for the additional details. This does help me to understand the use cases and see which specific shortcuts are affected. I need a few more details to find out exactly why things are misbehaving and reproduce here. 1. How are you editing the menu entry *exactly*? Are you right clicking the menu entry and going to "Edit Application" or are you editing a file directly? 2. If you are editing a file, where is the file on disk? 3. In Edit Application for LibreOffice in the menu, on the General tab, what is the full path shown in Location? I tested this out on OpenSuse Slowroll, and here's what I see: 1. I edited Calc from Edit Application and added "QT_FONT_DPI=192" in Environment Variables on the Application tab, then clicked OK 2. The original .desktop file was copied to ~/.local/sahre/applications/libreoffice-calc.desktop. This file contains the env variable I set. 3. If I go to Edit Application for Calc again, I still see the environment variable Thanks!
Hi TraceyC (In reply to TraceyC from comment #8) > 1. How are you editing the menu entry *exactly*? Are you right clicking the > menu entry and going to "Edit Application" or are you editing a file > directly? I am clicking the menu entry and going to "Edit Application". Sometimes, just to see if it makes any difference, I go to the menu launcher and click on "Edit applications...", which opens the KDE Menu Editor and I make the modifications from there. Both methods usually "fail" in the same way (but the file on disk is updated correctly). > 2. If you are editing a file, where is the file on disk? I don't think I ever tried to edit the files directly. > 3. In Edit Application for LibreOffice in the menu, on the General tab, what > is the full path shown in Location? The full path shown in Location is: /usr/share/applications However, now that you made me notice this, I *also* have desktop files for libreoffice in .local/share/applications, and these are the ones that are modified. Those in /usr/share/applications do not have the environment variables in the Exec statement. Does this shed some light on the problem? Thank you Cris
(In reply to Cristiano Guadagnino from comment #9) > > 3. In Edit Application for LibreOffice in the menu, on the General tab, what > > is the full path shown in Location? > > The full path shown in Location is: /usr/share/applications > However, now that you made me notice this, I *also* have desktop files for > libreoffice in .local/share/applications, and these are the ones that are > modified. Those in /usr/share/applications do not have the environment > variables in the Exec statement. > Does this shed some light on the problem? > > Thank you > Cris Thank you, Cris, this does shed light. What's *supposed* to happen is 1. The application in the menu, by default, shows the .desktop file "Location" as /usr/share/applications 2. After editing and saving the menu entry (with either menu editor GUI) the Location changes to ~/.local/sahre/applications The right thing happens for me on a fresh install of OpenSuse Tumbleweed Can you try reproducing the bug with a new user? If things work as expected with a new user, a config file in your normal user might be affecting things.
(In reply to TraceyC from comment #10) > Thank you, Cris, this does shed light. What's *supposed* to happen is > 1. The application in the menu, by default, shows the .desktop file > "Location" as /usr/share/applications > 2. After editing and saving the menu entry (with either menu editor GUI) the > Location changes to ~/.local/sahre/applications > > The right thing happens for me on a fresh install of OpenSuse Tumbleweed > Can you try reproducing the bug with a new user? If things work as expected > with a new user, a config file in your normal user might be affecting things. Thank you, this is very enlightening for me. Knowing what it is supposed to happen allows me to better understand. Today I created a new user and did a few tests. The behavior is the same as with my primary user: i.e. after changing the "Environment variables" field, the correct file is created in ~/.local/share/applications, but when re-opening the "Edit application" dialog I see that it still points to /usr/share/applications, and the "Environment variables" field is empty. I tried logging out and back in, but it made no effect at all. The only thing that I have not tried is a reboot, because I am executing a lengthy process with my primary user and I don't want to interrupt it. As soon as that process finishes I will reboot and see what happens.
> The only thing that I have not tried is a reboot, because I am executing a > lengthy process with my primary user and I don't want to interrupt it. As > soon as that process finishes I will reboot and see what happens. Ok, I just has the chance to reboot. After reboot nothing changes: using the new test user, even after a reboot, the application launcher still points to /usr/share/applications. Is there something else that I can check to find out the cause of this behavior?
Thanks for the update. That's odd. I don't know what the difference is between your Tumbleweed system and mine that's causing this. I'll have to let a more experienced maintainer take it from here.
It's been a long time, now I'm on Plasma 6.3.4, but the problem is still there. Actually, it is worse. At some point, KDE developers decided that when you click on "Edit Application..." KDE Menu Editor will open, instead of the dialog that was previously shown. This way, I'm not able anymore to tell if what I'm seeing is the .desktop file in /usr/share/applications or the one in /home/<user>/.local/share/applications. Also, now the applications are behaving *always* as if the environment variables weren't present, not every other boot like before. Well, at least that's more consistent then before. As a last note, I've now noticed that the problem is not only with environment variables, but also with command-line arguments. i.e. it seems my KDE installation refuses to acknowledge the existence of .desktop files in /home/<user>/.local/share/applications and instead it always uses (or at least, it always shows) desktop files in /usr/share/applications.
I wonder if your XDG paths are set up wrong. Are you able to reproduce the issue in a new clean user account on the same system?
(In reply to Nate Graham from comment #15) > I wonder if your XDG paths are set up wrong. Are you able to reproduce the > issue in a new clean user account on the same system? Yes, it's a test I already made in the past. However, I just did it again now. I created a new test user, rebooted, logged in the new user and tried updating an application in the launcher menu. Soon after saving the changes I re-opened the menu editor and the changes were lost. I also tried to start the application and it behave as if the environment variables were not there. Regarding my XDG paths, I am attaching images of the paths of my primary user and of the paths of the test user.
Created attachment 180325 [details] XDG paths for my primary user
Created attachment 180326 [details] XDG paths for the test user
Aha, that appears to be your problem: XDG_DATA_DIRS is missing /home/cris/.local/share. So any .desktop files in /home/cris/.local/share/applications are indeed simply being ignored, hence the problem. Since the test user has the same problem, this is a distro configuration issue.
(In reply to Nate Graham from comment #19) > Aha, that appears to be your problem: XDG_DATA_DIRS is missing > /home/cris/.local/share. So any .desktop files in > /home/cris/.local/share/applications are indeed simply being ignored, hence > the problem. > > Since the test user has the same problem, this is a distro configuration > issue. Thank you Nate, this would be great, if it worked. Before reporting the problem to the distro maintainers I tried "fixing" the problem by myself. I edited my user's ~/.profile by adding this to the bottom: > # Added by me (Cris) on 2025-04-16 to try to fix the problem of uneditable applications (see https://bugs.kde.org/show_bug.cgi?id=497714) > #export XDG_DATA_DIRS=$XDG_DATA_DIRS:$HOME/.local/share > export XDG_DATA_DIRS=$HOME/.local/share:$XDG_DATA_DIRS You can see I did two tries, just to be on the safe side (I didn't know if ordering would affect things). Unfortunately none of the two tries solved the problem. When logging in I can see that XDG_DATA_DIRS is correct now, but modifications to the applications are still ignored.
Even after rebooting? It's possible there are deeper setup issues, but I think it would be best if you asked your distro for help with it at this point. There's no evidence of KDE's code being at fault here, and we aren't seeing other reports of this issue unconnected to configuration issues. Thanks!