On Sat, 2013-12-21 at 08:17 -0600, Jeremiah Benham wrote: > On Fri, Dec 20, 2013 at 07:20:30PM +0000, Richard Shann wrote: > > Well, it seems that somehow the cycling between A and B is getting out > > of step. You could try turning that off by not compiling in these two > > lines (in print.c:78 and 79) > > > > get_print_status()->cycle = !get_print_status()->cycle; > > /*gint success =*/ g_unlink > > (get_print_status()->printname_pdf[get_print_status()->cycle]); > > > > I think these lines are only needed for Windows (which locks files so > > that they can't be overwritten). > > I just tested out deleting them, and there is no obvious problem on > > Debian. (It may be that in some case of bad LilyPond you get some old > > typeset rather than a blank ...) > > Well this improved the situation but it is not completely fixed. The files > are no longer going out of sync but the progressbar window needs closing > before Evince can refresh. Its strange that it works properly with exportpdf. >
So it would seem that the calls like this g_child_watch_add (get_print_status()->printpid, (GChildWatchFunc) printview_finished, (gpointer) (FALSE)); (which would close the progress bar when printview_finished got called) are failing to fire when the relevant pid is finished with - that is, LilyPond finishes and its pid fails to fire off the child_watch callback. It would be worth putting a break on the printview_finished to make sure it is failing to fire. Else it would be some problem with the progress_stop() call. When this is fixed it shouldn't be necessary to avoid the cycling of pdf output files... but how it would get fixed I don't know - possibly a bug fixed version of glib? Richard _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
