What happens is following:
1. Tracker receives pre-unmount signal for /home/user/MyDocs
2. It removes all affected images (and other documents) from the list of
available resources, does not, of course, remove images themselves.
3. Image Viewer gets this notification and displays it.

We can probably separate meaning of "unmounted" and "deleted" within Image
Viewer so that when pre-unmount signal is sent, we note for URIs representing
resources "being unmounted" to change the notification text.

Would this help?

Comment 2 Tim Samoff (reporter) 2009-10-17 15:56:29 UTC

That solution would help for clarification, but might not completely solve the
"problem."

After thinking about this for a while, I thought: Why not allow mounted
images/docs to be viewed, but only in read-only mode? That way, the UX wouldn't
be interrupted at all. At the point that someone tried to alter the file, the
message would be:

Your file system is currently mounted and this file cannot be changed. Would
you like to save it as a new file?

(Or, something like that.)

Or, maybe I don't completely understand the technicalities.

(In reply to comment #2)
> That solution would help for clarification, but might not completely solve the
> "problem."
> 
> After thinking about this for a while, I thought: Why not allow mounted
> images/docs to be viewed, but only in read-only mode? That way, the UX wouldn't
> be interrupted at all. At the point that someone tried to alter the file, the
> message would be:
> 
> Your file system is currently mounted and this file cannot be changed. Would
> you like to save it as a new file?
The problem with this approach is that we unmount VFAT partition before
exporting it as block device via USB (or user removes additional MicroSD card,
this does not matter as end result is the same). This effectively means Maemo
system has no file-system level access to the referred data. Thus, we cannot
show anything but "This file is currently cannot be accessed from within the
device".

Comment 4 Tim Samoff (reporter) 2009-10-17 23:03:38 UTC

Ah, ok. That makes more sense to me then.

Honestly, I don't really care how the user is notified about this occurring.
What I do care about is the fact that users shouldn't:

1. ...be taken to a black screen that has no pertinent info
2. ...be taken to a black screen that needs interaction in order to return to
windowed view
3. ...think that their photos/file have been deleted

Triggering a yellow info banner upon clicking on a thumbnail (or file), without
navigating away from the current view seems optimal.

Good points. A similar "everything disappeared" issue is also in MediaPlayer
when metadata is in transitioned state.

The changes you are proposing are more of UI behavior. We need to clone this
bug to internal bugzilla and propose these changes to UI designers first.

Comment 6 Andre Klapper 2009-10-21 12:33:52 UTC

Internal proposal is to use the string “Memory not available\nUSB cable
connected” instead.

Comment 7 Tim Samoff (reporter) 2009-10-21 14:45:20 UTC

Ok. It's a start, but there's still an expectation that users will know exactly
what that means. We'll see when tech support calls start drizzling in. ;)

After thinking about this further, I was wondering if this might be a better
scenario (for images):

When memory is unavailable, the image thumbnail is still in the device cache
(I'm assuming, since you can still see it in the thumbnail view of the Image
Viewer). Why not blow that up to full-screen when it's tapped (yes, it's very
low-res). The message could be the same as suggested.

This would be better than a black screen imo.

But, even better would be to have that message appear in a yellow banner when
the thumbnail was clicked and not navigate the user to another screen (i.e.,
leave them at the thumbnail view).

Comment 8 Andre Klapper 2010-02-23 22:57:33 UTC

So yeah, 
“Memory not available\nUSB cable connected” will be displayed in the next
public update (PR1.2) when in Image Viewer and mass storage mode is activated.

Closing as FIXED.

Comment 9 Andre Klapper 2010-03-15 20:56:48 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).