How to properly make a program's dbus methods discoverable?

[timo]

I discovered this with krita. In particular, the krita-4.2.9-x86_64.appimage with sha1sum 61933e6b86a348f155824b588ecdddf235133492.

grabbing krita's PID with xprop on its main window, then looking the peer address up in busctl --user list lets me get at all the "actions" that it has, which includes entries in the menus, and buttons on toolbars i think.

I can now do silly things like

busctl --user set-property   :1.20637 /krita/MainWindow_1/actions/options_configure org.qtproject.Qt.QAction text s "what even is this"
busctl --user set-property   :1.20637 /krita/MainWindow_1/actions/options_configure_toolbars  org.qtproject.Qt.QAction text s "why are you making my krita unusable like this"

resulting in the menus changing their texts:

However, having to find krita by obtaining its PID, and then the peer address on the user bus is much less convenient than accessing it via a proper name.

For one, the entry shows up with the name "AppRun", where i would expect "krita".

Compare how krita and the xfce4-appfinder (not an appimage) show up in busctl --user list

NAME                PID PROCESS         USER CONNECTION
:1.20637          17624 AppRun          timo :1.20637
:1.19664           5312 xfce4-appfinder timo :1.19664
org.xfce.Appfinder 5312 xfce4-appfinder timo :1.19664

and i can call it with its "proper name" as well:

busctl --user call org.xfce.Appfinder /org/xfce/Appfinder org.xfce.Appfinder OpenWindow bs 0 ""

I'm not exactly sure what can or has to be done, but at the very least the process name should be fixed to read "krita". In order to have the proper name, I believe some kind of schema would have to be installed on the system. Going even further, the service could be made activatable, so that when a dbus message is sent, it gets launched if it's not running yet.

Thanks for your time.

PS:

why? because i can.

[azubieta]

I believe some kind of schema would have to be installed on the system. Going even further, the service could be made activatable, so that when a dbus message is sent, it gets launched if it's not running yet.

Last time I tried registering a dbus service for an AppImage I had to deploy some files to well-known dbus locations. So, in this case, the Krita AppImage will have to do this "deployment". Tools like AppImageLauncher and appimaged can also gain this ability.

Regarding the name of the application at runtime. This depends on how the AppImage/AppDir was built in this case it's using a custom AppRun that doesn't set the binary name right. AFAIK Krita developers use a custom build script, so there is no much we can do there. I could recommend using appimage-builder, which have been used to successfully pack complex applications such as OBS-Studio. But it will require to create a new recipe.

[probonopd]

Hi @timo, interesting, I hear about using dbus to access Qt applications like Krita for the first time. May I ask what you are using this capability for?

Last time I tried registering a dbus service for an AppImage I had to deploy some files to well-known dbus locations.

The issue with "Desktop Linux" is that some specs were made at a time when each application had to be installed, and only one version of an application was on a system at any given point in time.

Today, we can have applications at any location (including network shares), and as many versions as we like.

Having to copy around files (like icons, MIME types, and - it seems - dbus files) always seemed a bit archaic to me. Perhaps it should be discussed with the people who make the FreeDesktop specs to find a model where applications can be registered with the system without having to copy stuff around. Like it works on the Mac (LaunchServices).

[timo]

hi, accessing programs over IPC is useful for augmenting the capabilities of accessibility utilities.

For example, with talon (talonvoice.com) you could have voice commands or extra GUI that directly work with things in krita itself, like selecting brush presets by saying its name, setting opacity / radius / flow of the brush with a voice command, etc.

It'd already be all right to just use at-spi2, but krita doesn't appear on the accessibility bus at all (at least with the appimage, i haven't tried another way since i started looking into accessibility stuff).

Another example is qtransmission which does appear in the accessibility bus, but doesn't offer even a single object beside its "application" object. and when setting the env var from below lets you access its widgets:

Getting krita to access the accessibility bus would be a separate issue; normally setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 was supposed to have qt's built-in at-spi2 support (QAccessible) turn on, but it doesn't seem to do anything.

[probonopd]

Wow, this is interesting. Please do test with e.g., deb-packaged Krita and let me know if it works there but not in the AppImage. It is well possible that it is not working with the AppImage simply because the AppImage people haven't been aware of it so far. Thank you!

[timo]

i've tried it with a manual build of latest krita where the accessibility stuff is reachable, but many of the more "custom" widgets aren't usable with it. for example, the layer list docker has an "opacity" slider with a text input for numbers, the possibility to click anywhere to set a value, and spinbox controls on the side. none of them seem to react correctly to changes via the accessibility api, nor do they broadcast changes via it

[probonopd]

Sorry I can't help because I know nothing about this stuff, but if you can pinpoint me to what would need to be changed in the AppImage tools I'll be happy to look into it.

I'd be especially interested in what is supposed to happen if you have, say, 3 different versions of Krita somewhere in the system and/or $HOME.