Monitoring updating directory for image for GUI

[Piet van Oostrum]

ciscorucinski at gmail.com writes:

> WOW...I am thinking that all of this was actually unnecessary, I don't think I need a Queue, or List / Stack, or any traversal of the file system to accomplish this!!
>
> I only need one image displayed at a time and don't care about them
> after a newer image is generated. So my prototype of just replacing
> the image over and over again SHOULD suffice. All I need the for the
> "monitor" now is to grab the image file (that might have or might not
> have been updated by Lilypond) at set amount of times and refresh the
> GtkImage object.
>
> The only reason why I originally suggested using multiple files was
> because I wanted to make sure that I had to most recent image and I
> was not sure if the threads would guarantee that. So my only remaining
> question (for now) is...
>
> I'm I guaranteed that if I have threads 1...n, that were all started
> in **quick** succession to call an OS command on Lilypond, that if I
> replaced the image file being generated with the completion of each
> thread that I would end up with the final image being from thread
> n...and that if I were able to update the GUI in a fast enough
> fashion, that I would see the images being displayed on the screen
> from 1 to n without anything being out of place?

No, I don't think so. You have no guarantee that the images will be
completed in the same order as the threads are started.

> All of my tests have shown that seems to be a reasonable assumption,
> but I need to know for sure. If that was the case were I am not
> guaranteed that, then when a user decides to stop the stream I could
> resend the note stream that I have saved on my end to Lilypond one
> last time to guarantee that all of the notes are displayed.
>
>
> So I would only create one image location at "images\sheetMusic.png"
> and that file would be continuously updated as new notes are streamed
> in. My "monitor" class (might be a legacy component now) would
> basically look for that one image - "images\sheetMusic.png", grab it,
> and update the GUI at an interval that is easy on the eyes (maybe a
> half second for example).
>
It could very well be that the image is being constructed and therefore does not yet contain a complete image when you want to display it.

> Could there be a problem where the image is being updated, so the OS
> deletes the image, and my program tries to update the image but cannot
> find it, and the OS reassigns that file location to that previous file
> location and name?

Maybe it can find it, but it might not be a valid image
>
> Let me know what you thing or if anything is confusing you.
> Thanks for the comments so far!

I think the way I described it in my previous message  still gives you the easiest solution:
I'll repeat it here in case you missed it.

I suppose you have two threads, one for producing the music by calling
Lilypond, and one for displaying the generated images. Because it is
multithreaded you should use a Queue from the module
Queue(Python2)/queue(Python3) to communicate between the threads.

Producing thread:
  send note to Lilypond
  wait until PNG file is generated (Lilypond completed)
  Q.put(filename)

Displaying thread:
  while True:
    fn = Q.get() # this will block until a filename is available
    # now check if there is more in the queue
    while True:
      try:
        fn = Q.get_nowait
        # here we got a newer one
      except Empty:
        break # stop the inner loop
    display the image in fn.

In this way you always display the most recent one.
You can make it more sophisticated by removing files that have been
displayed and files that you skip.

-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]