The new LilyPondProcessor is finally writing its files to a more appropriate location, but it's not cleaning up its garbage after running.
I sat down to knock this one out, and I ran into a surprising number of issues with such a simple thing as taking out the trash. I decided to back out all of that code and have a good think before going any further. BACKGROUND When you Print or Preview with LilyPond, RosegardenMainWindow exports a disposable, uniquely-named .ly file, and LilyPondProcessor picks it up for processing. In order to avoid blocking the entire GUI while it runs, LilyPondProcessor has to use a chain of slots. The first slot starts a QProcess, that QProcess takes as long as it needs to take to complete, and then fires off a signal which triggers the next slot in the chain. In this fashion, we can process really large jobs without the entire application appearing to have died. LilyPond takes .ly input and produces a .ps file, which it then turns into the .pdf file we're after. Once processing is complete, we're left with three junk files that no longer need to serve a purpose beyond the life of whatever final stage processor picks them up. THE PROBLEM Let's say you've done a preview, and you want Okular to start up with the rosegarden_tmp_T12345.pdf file for you to examine. Once Okular has a copy of that file in memory, you can go ahead and delete it, but not before then. At this stage the other two files can safely be deleted, but the .pdf must be deleted *after* Okular has picked it up. BROKEN SOLUTIONS If we block on Okular, the GUI freezes for 30 seconds, or until the user closes Okular. Unacceptable. The way around that is to add another link in the chain, and have some cleanup code fire as the final link. The LilyPondProcessor dialog could remain alive in the background indefinitely waiting on this code to fire. Now, however, we have to worry about the case where the user closes Rosegarden in the interim, but not Okular. We could try to finagle things around so the LilyPondProcessor stays alive after the apparent life of Rosegarden, waiting on this external process to complete so it can fire off its cleanup code and expire, but that's a fat gob of complication for something rather trivial. The final solution that occurred to me was to just not try to keep track of the lifecycle of the process at all, and just delete all the Rosegarden files in /tmp at some fixed point in time. Say right at startup, and again right before going down. There may be a more elegant way, but one method that would work would be to QProcess out a rm /tmp/rosegarden_tmp_* However, this last solution can't account for active files in /tmp that might be owned by another Rosegarden process, or by another user. We could fix the user part by writing these files to /tmp/$USER_NAME, but it's a lot more likely that a single user will be running multiple instances of Rosegarden at the same time, and that's the case we really have to watch out for. THOUGHTS So the thing that comes to mind as the most solid way to handle this is to write another external script to encapsulate some bit of hackery built around running fuser on these files in /tmp. If a process still has one open, don't delete it, otherwise do garbage cleanup at startup and again at shutdown. That could work, but it's an extra layer of complication, and it's also just very seriously hideous. I keep having some idea that if I were more familiar with using QProcess and/or other Qt classes to do this kind of thing, I would see an obvious solution that makes all prior thinking look silly. I'm going to throw this out for discussion and go work on another project for now, leaving the garbage situation as it is for the time being. -- D. Michael McIntyre ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
