[Shotwell] Final call for testing Shotwell 0.5

[Martin Olsson]

Adam Dingle wrote:
> (I know this may result in lots of email; if you'd rather not
> be cc-ed on tickets we file for bugs you've reported then just let me
> know.)

Nah I really enjoy see that you fix the bugs.

>> * Launch Shotwell using "rm -rf ~/.shotwell ; SHOTWELL_LOG=1 gdbr
>> ./shotwell" and import
>> the photos from this tarball:
>> http://temp.minimum.se/shotwell_crashers/catbug.tgz
>> Click "Photos", select cat.jpg and then Events::NewEvent. At this
>> point the event tree
>> first expands but is then automatically collapsed again and it leaves
>> me in this weird
>> state where no new event node has been added at all to the event node
>> tree? In the terminal
>> I can see this (below) but it's unclear to me _why_ Shotwell destroys
>> the event "Event" ?
>> [DBG] LibraryWindow.vala:221: Creating new event page for Event 2
>> [DBG] Event.vala:192: Destroying event Event [1/6] Event 1
>>   
> 
> This is expected behavior.  The event previously containing cat.jpg is
> destroyed (that was Event 1) since it no longer contains any photos:
> cat.jpg has been removed from it.  A new event is created for cat.jpg
> (which happens to look just like the old one).  If you find this unduly
> confusing, what alternative behavior would you suggest?

Not sure, will post if I come up with something good.

Anyway, I ran some really large sets of files through the import now
and it looks very stable. I did notice one semi-annoying issue when
exporting though and some minor related stuff, see below.

--

"Can't re-export images originally imported from CD"
Repro steps: fetch, unpack and import these:
http://temp.minimum.se/shotwell_crashers/bugs.tgz
Export both images to a new folder, switch back to
Shotwell, drag saturation to bottom on both photos
and re-export to the same folder. The export of
bug400.jpg now fails because Shotwell can't overwrite
the previously exported bug400.jpg (because since this
file was chmod 400 apparently the exported version of
it is also chmod 400 which doesn't really make sense).
For example on CDs files are often all chmod 400 or 444
and in some cases I've seen files chmod'd +x on CDs.
I don't think it's entirely clear what is the correct
behavior here but I think reusing the chmod from the
imported file for the exported file is definitely not
the right way to go.

A secondary issue here is that Shotwell should bails
out with a generic "file error" for something as simple
as a "chmod -w"ed file. I think it's better with a
"really overwrite read-only file?" confirmation question
than expecting users to chmod +w and re-export yet again.

If an export fails it would be nice to have some warning
printed "per file" to the terminal for debugging purposes
because the Shotwell message box only says "X photos failed
to export". For example, in the catch where you do failed++
you could also do:
warning("Failed to export photo '%s' due to file error '%s'.", basename, err.message);

CRITICAL should be printed to the terminal by default
(giving better bug reports from people who are not that
familar with Shotwell and who don't bother learning about
SHOTWELL_X envars). Maybe WARNING as well but you seem to
be using that quite a lot for stuff which is not Shotwell bugs.



		Martin