There is an app that has an app-id of X.Y.ActualAppName but it needs to own X.Y.SingleApplication specifically, to be able to establish a quasi leader-follower relationship between it’s instances via D-Bus.
Can an exception from the finish-args-own-name-cpt be granted for such a case or does the app have to be patched to only use X.Y.ActualAppName instead, potentially breaking coordination between instances installed from non-flatpak sources?
Without knowing the specifics (as you didn’t gave them), the answer would be to use the proper application id in the Flatpak.
In most cases, users will only install an application from one source anyway on the same system. So, I don’t think that should be that much of an concern.
It is very specfic, that there is literally, the exact string suffix SingleApplication, verbatim hardcoded inside the application, that is specifically the problem.
to use the proper application id in the Flatpak.
I am using a proper application id. That is part of the problem. A proper application id IMHO can’t literally end with SingleApplicationas this exact verbatim string doesn’t carry any meaning and nobody names applications literally that, and if they did it would be a rather useless name from user perspective. So I am excluding the possibility to rename the application id to end literally with SingleApplication.
Now, the way I see, the ominous flathub rule, would require one of these 2 options:
- Get an exception from this rule.
- Patch the application with one more patch, to not use literally the
SingleApplicationsuffix, but to match the actual application id. And at the same time lose the coordination capabilities with let’s say AppImage instances, which still literally use theSingleApplicationsuffix
The question is which one it has to be? Obviously I would prefer to have one less patch, because that would simplify maintenance, and keep compatibility.
But if there is no exception granted, then there is no other option left.
then the app is wrong. Let me guess. Tauri. It’s a bug.