View Single Post
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#52
Originally Posted by gidzzz View Post
Preventing Qalendar from being terminated on D-Bus activation timeout is as easy as registering a dummy service (one line of code). The real problem is that when the application is closed, the service is unregistered and the calendar is automatically restarted. I have no idea how to stop that.
Could you have a little daemon written in pure C to keepalive and stop the restarts and the actual program started from there when called correctly? QT would be loaded only then, so hopefully memory footprint would be minimal

Disabling the respawning can be the best solution because of simplicity (?) and resource usage, but as I have already mentioned a few times, I am afraid that there is some reason why Calendar is running in the background and mediaplayer or worldclock are not.
The reason could be interaction with other osso-programs, if they want to add event or some such (address book adding birthday? something like it), nothing critical to qalendar functioning. We should emulate for compatibility reasons, all events are in the alarmd according to its documentation, calendar just registers an event there, no reason to keep it alive if we don't want to interact with it rather than its db.
IIRC, even a hello world in Qt can take over 30 MB of memory, but the libraries are shared, so 2 Qt applications could take for example 35 MB total. But I guess that's still bad if Qt is not used in any of the startup applications.
Qt-less launcher.


Adding an option to run Qalendar in background would be only the first quick step, just to check if there are any problems after dumping the default calendar (stopping the respawning could serve that purpose as well, but I wouldn't be surprised if it is hardcoded somewhere). Later it could be replaced by some kind of non-Qt stub which would launch the real thing when required.
Yes!
 

The Following 3 Users Say Thank You to szopin For This Useful Post: