Okay, so I'm not quite done with QDaemonApplication to the point where it's even testable yet. However, I wanted to at least announce it to get feedback on the structure I am using. Questions are good, and it'll help it be more robust in the end.
Also, I'd like to note that I'm not quite use to PIMPL so if there's something I did wrong in that respect, please let me know so I can correct it. I also use a slightly different programming style; however, I tried to keep it similar to what I am finding in other areas of Qt for consistency. Please let me know if there is anything inconsistent in that respect too.
So with that said...
I originally wrote about the effort in a previous blog post (see Calling Contributors and Qt5 & a major update for QtService - QDaemonApplication), and I finally found some time to be able to work on it, still with the goal to get it in intime for Qt5.
As a user of Qt5, a programmer would simply use the QDaemonApplication class much like the presently do for the QCoreApplication or QApplication classes. Though it they will also be able to do some more things between instantiating the QDaemonApplication and calling its exec() function - check parameters, etc - potentially even fully by-passing the exec() if they chose (of course, then they won't get a daemonized application, and the main program won't run - but that can be useful in certain scenarios).
Behind QDaemonApplication is a series of APIs that provide the functionality. These APIs start off with some very basic Interface classes (QAbstractDaemon*) for the Interface (e.g. command-line, systemd, Win32 SCM, etc.), Communication between the Interface program and the daemonized program, and platform integration (e.g. Win32 SCM). This structure will allow us to easily switch between different components to do different tasks - e.g. Win32 SCM vs LaunchPad vs SysV vs systemd vs upstart - and communicate in different ways - e.g. Win32 SCM, File Pipe, Network Socket, etc.
Eventually as we add more, and support more, then the interfaces, etc will be chosen when Qt5 is built, and we'll try to keep sane defaults; however, presently I am simply trying to replicate the same level of functionality that is in the existing Qt4 QtService Add-on component.
So, if you're interested in looking at what's there, even though the code documentation is thus far pretty much non-existent, you can see it at BRM-Qt5-Service on Gitorious.