Bug 462709 - Desktop ServiceName, StartupType Don't appear to work
Summary: Desktop ServiceName, StartupType Don't appear to work
Status: RESOLVED FIXED
Alias: None
Product: libplasma
Classification: Frameworks and Libraries
Component: libplasma (show other bugs)
Version: 5.100.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-06 14:35 UTC by Gerald Cox
Modified: 2022-12-07 14:11 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Cox 2022-12-06 14:35:57 UTC
SUMMARY
There are two fields in the desktop file:

X-DBUS-ServiceName
X-DBUS-StartupType

Here is a link that explains how they work:

https://api.kde.org/frameworks/kservice/html/classKToolInvocation.html

My understanding being that if X-DBUS-StartupType = Unique, then if X-DBUS-ServiceName is defined and already started, Unique will prevent it from being started again until no other instances are active.

The problem being though that X-DBUS-ServiceName doesn’t appear to work.

This was reported on Reddit and another user confirmed here:
https://www.reddit.com/r/kde/comments/zd7cu3/desktop_servicename_startuptype_dont_appear_to/?utm_source=share&utm_medium=web2x&context=3
Comment 1 Nicolas Fella 2022-12-06 16:50:36 UTC
Can you please give some context on what you are trying to achieve?
Comment 2 Nate Graham 2022-12-06 18:31:47 UTC
What desktop file where? What's the problem?
Comment 3 Gerald Cox 2022-12-06 19:02:00 UTC
(In reply to Nicolas Fella from comment #1)
> Can you please give some context on what you are trying to achieve?

I'm creating a front-end script to automate ykman processing, it runs konsole in the background.  I only want 1 instance of the script to run at a time.  My understanding from the doc previously mentioned, using Unique in the desktop file will accomplish this.  

Here is the desktop file I've created:
[Desktop Entry]
Comment[en_US]=
Comment=
Exec=/usr/bin/ykocli ykobkg
GenericName[en_US]=
GenericName=YkoCLI
Icon=/usr/share/pixmaps/ykocli.png
MimeType=
Name[en_US]=YkoCLI
Name=YkoCLI
Path=
StartupNotify=true
Terminal=true
TerminalOptions= --background-mode --profile ykocli
Type=Application
Categories=Utility;
X-DBUS-ServiceName=org.bitbucket.gbcox.ykocli
X-DBUS-StartupType=Unique
X-KDE-SubstituteUID=false
X-KDE-Username=
~

However when I start using this desktop file, multiple instances are created.  
Maybe I'm missing something, but if you look at the reddit question I posted, another person tested this under both Wayland and X11 and reported they couldn't get it to work either.
Comment 4 Gerald Cox 2022-12-06 19:03:34 UTC
(In reply to Nate Graham from comment #2)
> What desktop file where? What's the problem?
Please see my reply to Nicolas Fella.
Comment 5 Nicolas Fella 2022-12-06 19:11:52 UTC
X-DBUS-ServiceName and X-DBUS-StartupType are only relevant in the context of KToolInvocation/KInit, which are deprecated/obsolete. They don't do what you expect them to do.

If you want your app to have single-window behavior you'll need to implement that yourself, e.g. by using a lock file on disk that the app checks during startup
Comment 6 Gerald Cox 2022-12-06 22:25:20 UTC
(In reply to Nicolas Fella from comment #5)
> X-DBUS-ServiceName and X-DBUS-StartupType are only relevant in the context
> of KToolInvocation/KInit, which are deprecated/obsolete. They don't do what
> you expect them to do.
> 
> If you want your app to have single-window behavior you'll need to implement
> that yourself, e.g. by using a lock file on disk that the app checks during
> startup

OK, Nicolas, thank you very much for your quick reply.  I'll do the lock file approach.  It appears that the TerminalOptions= is also now deprecated, yet Terminal=true/false is still there.  Do you know what is supposed to be used as the replacement?  It appears the solution is to completely bypass the terminal option and specify the Terminal in Exec= with the "-e" option but that seems sort of hackish IMO.
Comment 7 Nicolas Fella 2022-12-07 14:11:32 UTC
> It appears that the TerminalOptions= is also now deprecated,
> yet Terminal=true/false is still there.  Do you know what is supposed to be
> used as the replacement?  It appears the solution is to completely bypass
> the terminal option and specify the Terminal in Exec= with the "-e" option
> but that seems sort of hackish IMO.

I don't know of any replacement, but I kind of see why it was deprecated. You can't know which terminal will actually be used, so you can't know which options are available/supported.