denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Export .png is broken


From: Jeremiah Benham
Subject: Re: [Denemo-devel] Export .png is broken
Date: Tue, 18 Jan 2011 15:37:12 -0600

On Sat, 2011-01-08 at 15:39 +0000, Richard Shann wrote:
> On Sat, 2011-01-08 at 08:47 -0600, Jeremiah Benham wrote:
> > 
> > On Jan 7, 2011, at 4:10 PM, Richard Shann <address@hidden>  
> > wrote:
> > 
> > > On Fri, 2011-01-07 at 14:18 -0600, Jeremiah Benham wrote:
> > >>
> > >> I am going to use waitpid().
> > >>
> > > I think there is a glib version of this (so that it'll work
> > > cross-platform)
> > 
> > Yes. That is g_child_watch_add(). I looked at the code and saw that  
> > the viewer is launched when lilypond is done.
> right - it let's you get on with working in Denemo while lilypond is
> running. For an export I guess you would want to put up some sort of
> progress dialog, refreshed at intervals, to be taken down when LilyPond
> has finished.
> 
> >  If this is an export  
> > then why would we need to run anything after lilypond for a png or PDF  
> > except deleting the mess of files that are created in order to render  
> > a png. 

I realized that g_child_watch_add will only allow one function to be
assigned to a Pid. This creates a challenge when I want to delete the
temporary files (after lilypond has finished). Then I want to launch a
viewer application. I am passing GList to the function that contains a
list of filenames. The function goes through the list deleting the
unwanted files using g_remove() and then does a g_list_free(). This
frees up all the data used up by the strings in the list correct? I
suppose with a excerpt preview it would not matter so much to have a
bunch of files in the users .denemo folder. I think I would want to free
the string data after the viewer exited. I am also confused about
closing the pid for windows. Would I have to wait until the viewer
exited and then close the pid for it also?
 
I have changed many things (hopefully to the better) on my local git.
Can someone confirm for me what happens when I make a selection of the
music and then do a print. I am noticing when I do this only the
selection is printed. Is this a bug or a new feature? Perhaps it is just
something I changed inadvertently.

Jeremiah

> This used to be created in the .denemo directory and moved and  
> > renamed into the destination diretory.
> I would guess it still is being created there - I am fairly sure I
> haven't done anything in this export code.
> 
> >  The behavior I am observing on  
> > my system is that it creates a lily file with a filename.png.ly kind  
> > of name in the destination directory. The png is created via lilypond  
> > with a name like filename.png_.png. Then denemo is trying to do  
> > something else with it (I have not found this portion of the code).  
> > Then I see an error message on the terminal saying that file \blah 
> > \blah.png can't be found. Replace blah with hex.
> this is a clear sign that the code has gone wrong - some unintended
> memory is being accessed - typical is one of these g_strconcat with no
> NULL at the end.
> 
> >  Is denemo still  
> > trying to rename the png.
> I would expect so, unless you wrote something else. (It is my fault this
> is messed up, I changed to async running of LilyPond (good) but didn't
> look at the export code (bad)).
> Much better though than trying to do moving the file after creation
> (tricky in unknown filesystems) is to create the right filename in the
> first place. So I suggest you start from the call to export pdf or png
> and once the user has chosen a filename pass this (with an indicator
> png/pdf if needed) to some modified version of the current code -
> modified to tell LilyPond to output directly to the right place and not
> to call a viewer but to call the progress-indicator widget.
> Richard
> 
> 
> >  It also leaves a mess with all the temporary  
> > in the destination diretory. The png is actually being produced though  
> > but with an incorrect name.
> > 
> > Jeremiah
> > 
> > > Richard
> > >
> > >
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]