Hi,

I will open a bug following my comment on this thread: http://doingmyprogramming.com/2013/12/06/dmp-photo-booth-beta-1/#comments

I have compiled dmp-photo-booth on Fedora 19 with:
$ cd ~/git
$ git clone https://github.com/christetreault/dmp-photo-booth.git
$ cd dmp-photo-booth/dmp_photo_booth
$ make
$ cd ~/git/dmp-photo-booth/dmp_photo_booth/dist/Debug/GNU-Linux-x86
$ .$ LANG=C ./dmp_photo_booth
g-file-error-quark 4: Failed to open file 'dmp_photo_booth_ui.glade': No such file or directory

I have added the LANG=C in order to get the order in English as my computer is setup in French. I do not know if you understand it.

Thanks for your commits and software. I will try to build it also in an Ubuntu VM as soon as possible.

If the camera is unplugged/turned off, the camera module's status should be set to bad. Currently, nothing happens.

As of commit 53be235, the photo strip temp file is not being deleted. The explanation from the commit:

At some point the behavior of cups' cupsPrintFile changed to return immediately instead of waiting for the job to finish queueing up.

As a result of this, the temp file was getting deleted too soon causing the print job to fail. For the time being, I've commented out the code that deletes the temp file. In the long run, there needs to be a better solution that allows for the deletion of the temp file. A bug will be opened against this in github.

A potential solution might lie in checking the job status using the job id returned by that function. An alternative lazy solution could be hardcoding this file to be created in /tmp, but this is obviously not ideal.

After the camera takes a picture in the photo strip process, there is a delay before the trigger begins counting down again.

This is likely due to how the trigger module handles picture taking. Libgphoto has an event queue for camera events, and it is necessary to wait for certain events before continuing with the photo download.

I can either shorten this delay, or add some sort of working indicator to the trigger, or both to resolve this issue.

If the user selects Help > Help, the Core just launches a web browser and brings up doingmyprogramming.com. While my blog is awesome, this isn't terribly _help_ful

If a call to dmp_cm_capture fails, the photo strip process should abort and an error should show. As it stands, all that happens is an error is logged to the console.

If the Trigger is unplugged when the trigger module is loaded, and the core tries to call a function on the Trigger Module (if a photo strip session is running), an assertion failure occurs.

This sort of thing should not crash the program. Cables get unplugged, the Core should gracefully handle this by logging an error and stopping.

Calls to _tm_show_error do not appear to do anything. The LED's do not flash on the trigger as they are supposed to.

If photo strip position 1 is not toggled in the preferences, the first assertion in dmp_pb_photo_strip_calculate_whitespace:

g_assert(total_height > 0 && image_height > 0);

fails because image_height == 0. This is because the whitespace is calculated based on the height of the last image. The variable for last image is initialized to 0 at the beginning of dmp_pb_photo_strip_assemble, and if the first position is NULL, then it will remain 0 when dmp_pb_photo_strip_calculate_whitespace is called.

This value needs to be calculated upon initialization. All photo strip positons should be the same size, so this can be calculated once and then left alone.

The start and stop photo booth buttons block the UI.

Previously, I had shown a splash screen to mitigate the effect, however updating my dev machine to GTK 3.8 has broken my splash screen.

Need to implement a way to keep these buttons from blocking the UI.

If the Photo Booth is started, and you unplug the trigger, the Photo Booth doesn't recognize that the trigger has been unplugged.

The indicator status for the Trigger Module stays up, and no errors are shown. However, this does break serial comms, and the termios isn't reset. If you try to stop the photo booth after this, it will fail. You will also be unable to re-start the Photo Booth.

Since the termios doesn't get set back to defaults, it stays broken until a reboot.