Re: Inconvenient Plasma / Akonadi behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday May 13 2020 14:55:54 Eleanor Hawk wrote:

>I run Plasma, as well as a few Akonaidi/PIM applications on my personal 
>computer. I like the PIM applications to run without intervention after I log 
>in. However, I run into a problem if I simply add them to the "auto-start" 
>list in system settings (i.e., add them to my XDG autostart directory).

As I replied to someone else recently, Akonadi/PIM related questions are best asked on the kdepim-users ML if not only because it's much more active than this one. Annoyingly there's only a Plasma developers ML that I know of, but if you really want to know if you are running into Plasma design issues you'd have to ask there I fear.

That said, you shouldn't have to bother with autostarting akonadi yourself - for most users the issue how to prevent the service from starting is much bigger. Ever since some Plasma4 version akonadi will start on-demand during the login process if you have the default clock/calendar widget in your panel/taskbar. This may well add a delay to the login procedure but so does anything else that is being started because the session needs it. If you see a big difference that may in fact be due to 2 more or less concurrent requests to start akonadi.

In order to start the PIM applications (or simply just Kontact, the catch-all interface) you should be able to use Plasma's session restore; this will start the applications at the right time after the UI shell has become available. FWIW, you can define a session "template" if you don't want actual session restore (that would also restart memory hogs like KDevelop or digiKam) but instead log in to a predefined session set-up.

>I've worked around this by setting a systemd timer to launch the PIM 
>applications a certain time after Plasma has loaded. This works: I don't need 
>the applications right away, I just don't want to manually launch them, but it 
>is nevertheless inconvenient and a bit kludgy-feeling. For example, every time 
>my distro's Korganizer package updates I have to remove the `korgac` desktop 
>file from `/etc/xdg/autostart` to maintain this.

>I bring this up to the mailing list because I get the impression that this is 
>actually deliberate on the part of Plasma, i.e., probably to accommodate PIM-
>related desktop gadgets.

My hunch is that your distribution (which one?) is trying to shoehorn some of its design approaches for different DEs into KDE's design. I'll admit that I have no idea how Plasma5 handles this kind of thing nowadays (I don't use it) so it is not completely impossible they decided to move to using XDG protocols. But why would they unless they bodged their own implementation that worked nicely in Plasma4 (and AFAIK, in the earlier Plasma5 versions I did try)? 
More importantly, why would your distribution (or indeed the XDG standard) not allow you to override the system-default DE definition, is it possible that you didn't figure out how?

I just checked, my Kubuntu/Plasma4 system doesn't have anything KDE related in /etc/xdg/autostart but does have a number of them in /usr/share/autostart but they're not all autostarted for me. Some of them I disabled via the KDED kcm (`kcmshell5 kcmkded`), for others (like klipper and kget) I must have found another way.

Does your ~/.config/korgacrc (or wherever that file lives on your rig) have an Autostart line? Try setting it to false; that's something updates can't touch. Idem for other things you want to autostart your way and that you can't turn off in the KDED settings.

R.




[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux