Bug 391370

It uses modified QtSingleApplication, so you can't build it against system version.

On some distros you can, because they carry the required API addition patch in QtSingleApplication, e.g.:
https://src.fedoraproject.org/cgit/rpms/qtsingleapplication.git/tree/qtsingleapplication-qupzilla.patch

We have been building QupZilla against the system QtSingleApplication in Fedora all this time.

For QupZilla, we used:

# unbundle qtsingleapplication
rm -fr src/lib/3rdparty/qtsingleapplication
ln -s %{_qt5_headerdir}/QtSolutions src/lib/3rdparty/qtsingleapplication
sed -i 's,include.*qtsingleapplication.*,,' src/plugins.pri
sed -i 's,include.*qtsingleapplication.*,,' src/lib/lib.pro

but now I have to adapt this for CMake.

Created attachment 111189 [details]
falkon-3.0.0-system-qtsingleapplication.patch

This patch, along with "rm -fr src/lib/3rdparty/qtsingleapplication", works for me on Fedora. (Of course, this will only work if you use a system QtSingleApplication with the aforementioned API patch.)

„qtsingleapplication-qupzilla.patch“ is sucks, because QupZilla does not clean tmp file on quit with it.

Huh? Are you sure? The patch adds the missing removeLockFile function to the system QtSingleApplication. This looks no different to me from what the bundled QtSingleApplication in QupZilla/Falkon does. Am I missing something?

No, that patch is fine.

I'm absolutely sure. „qtsingleapp-qupzil-xxxx-xxx-lockfile“ is always remains in /tmp with this package: http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/q/qtsingleapplication-2.6.1-32.fc28.src.rpm
If build QupZilla with bundled qtsingleapplication, it is always deleted.
So what is the reason that file to stays undeleted!?
Sorry for the bad English!

I noticed that the QupZill/Falkon qtsingleapplication source has a lot of corrections which are not applied in the original source, so probably there is the reason.

Can you please file a bug against qtsingleapplication at bugzilla.redhat.com?

(In reply to Kevin Kofler from comment #9)
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1551678

QtSingleApplication also leaves temporary files on Tumbleweed (e.g. for SMPlayer and Otter Browser), so it does not look like a downstream bug.

Created attachment 111214 [details]
Difference

Ah ha, when it works in Open suse the same way, we should accept that is the right way!?
I just attached a diff file between original „qtlocalpeer.cpp“ and Falkon „qtlocalpeer.cpp". You can see the difference yourself.

Comment on attachment 111214 [details]
Difference

The added braces around one-line conditionals do not change anything. QT_VERSION >= QT_VERSION_CHECK(4,5,0) is also always true. The addition of removeLockedFile() is already in the patch that we carry. The socket-related changes, I doubt they make any difference either.

I was focused most likely to the added „curly braces“....
Also, i'm not a developer, so i really don't know what makes that difference.
I only can see the fact that the bundled app cleans the tmp file, which is the right behavior for me.
If i'm wrong, really sorry!

So I think I see where the issue is. First, we construct the QtSingleApplication with the default appId, which calls sysInit() once. Then, setAppId is called, which calls sysInit(appId) and creates a new socket, without deleting the old one first.

I would blame the modifications from QupZilla/Falkon adding that setAppId method. But the bundled version in QupZilla/Falkon has that too, so I don't see why you are not seeing this bug with that version.

That's a list of the functions colled from the embeded api:

On start:

QtSingleApplication
setAppId
sysInit
QtLockedFile
QtLocalPeer
open
isRunning
isClient
isLocked
lock

On exit:
removeLockFile
removeLockedFile
~QtLockedFile

Unfortunately, i failed to get that from the external library.

It now uses DBus on Linux, so it's now completely different from upstream QtSingleApplication.

When will this (and the other post-3.0 changes) get released? The 3.0.1 release is now more than 10 months old.

In next few days.