File Transfer don't work: the transfer never finish

[Dcastelo]

When you transfer a journal entry between two machines the transfer suddenly break out . The icon in the destiny machine show that all the data have been transfered, but the process never finish.

If you see the shell.log it shown:

datastore.write(self._ds_object.object_id, update_mtime=False)

File "/usr/lib/python2.6/site-packages/sugar/datastore/datastore.py", line 355, in write

properties = ds_object.metadata.get_dictionary().copy()

AttributeError: 'NoneType' object has no attribute 'metadata'
Traceback (most recent call last):

File "/usr/lib/python2.6/site-packages/jarabe/frame/activitiestray.py", line 547, in notify_transferred_bytes_cb

datastore.write(self._ds_object.object_id, update_mtime=False)

File "/usr/lib/python2.6/site-packages/sugar/datastore/datastore.py", line 355, in write

properties = ds_object.metadata.get_dictionary().copy()

AttributeError: 'NoneType' object has no attribute 'metadata'
Traceback (most recent call last):

File "/usr/lib/python2.6/site-packages/jarabe/frame/activitiestray.py", line 547, in notify_transferred_bytes_cb

datastore.write(self._ds_object.object_id, update_mtime=False)

File "/usr/lib/python2.6/site-packages/sugar/datastore/datastore.py", line 355, in write

properties = ds_object.metadata.get_dictionary().copy()

AttributeError: 'NoneType' object has no attribute 'metadata'
Traceback (most recent call last):

File "/usr/lib/python2.6/site-packages/jarabe/frame/activitiestray.py", line 532, in notify_state_cb

datastore.write(self._ds_jobject, transfer_ownership=True,

AttributeError: 'IncomingTransferButton' object has no attribute '_ds_jobject'

[tomeu]

Should have been fixed by:

 http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/177cbfa
 http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/fbd1f1e

Could you please test and verify?

We should maybe backport it to 0.88 for destrose.

[Dcastelo]

I have tested it in Dextrose 353 and now it works fine.

However after the transfer is finished and the journal entry is created in the destiny machine, an arrow remains active in both machines with the label "Dismiss". If you click in this option nothing happen. The log doesn't show any relevant message. This is the normal behavior?

Thanks.

[garycmartin]

Replying to Dcastelo:

I have tested it in Dextrose 353 and now it works fine.

However after the transfer is finished and the journal entry is created in the destiny machine, an arrow remains active in both machines with the label "Dismiss". If you click in this option nothing happen. The log doesn't show any relevant message. This is the normal behavior?

No, the icon should disappear on selecting dismiss. Sorry, I haven't had a chance to test this myself yet in recent builds.

[tomeu]

Dcastelo, do you think you could give it a look and see why it doesn't work? It must be some simple omission.

[Dcastelo]

2111-File-Transfer-don-t-work-the-transfer-never-fi.patch

[Dcastelo]

Seems like it was a simple omission as you said. Ive atached the patch
Thanks

[tomeu]

If I understand what has been said in this ticket, the problem is that after a transfer finishes, the user cannot dismiss the icon in the frame.

If I remember correctly, the idea was that after the transfer finishes the icon remains in the frame until the user clicks on "Dismiss" or maybe on the icon itself.

What this patch does is to remove the icon without user intervention after a transfer finishes. I myself don't think this is too wrong but I think it doesn't match the expected user experience.

Daniel, Gary, is this correct?

[Dcastelo]

Ok, I think that I made a mistake when i applied/tested the patch before, I tested it again and if user clicks "Dismiss" the palette is closed. Another mistake was that I forgot my original report and I changed the palette behaviour to hide it without user intervention. :)

However I think that is not clear for user, talking with teachers here in Uruguay they prefer remove the palette without user intervention (the patch that i sent), or modify the palette for express that the transfer is complete in a clearly way. Maybe is just a problem with the "dismiss" label text, maybe if we show in this label "Transfer Complete" will be more clear for users.

[erikos]

Replying to Dcastelo:

Ok, I think that I made a mistake when i applied/tested the patch before, I tested it again and if user clicks "Dismiss" the palette is closed. Another mistake was that I forgot my original report and I changed the palette behaviour to hide it without user intervention. :)

However I think that is not clear for user, talking with teachers here in Uruguay they prefer remove the palette without user intervention (the patch that i sent), or modify the palette for express that the transfer is complete in a clearly way. Maybe is just a problem with the "dismiss" label text, maybe if we show in this label "Transfer Complete" will be more clear for users.

I agree here absolutely. Either make the labelling clearer or remove the notification by itself. At least I had problems to understand why the notification sticks around. If the labelling of the new entry in the Journal is clear I guess we are fine.

As I think that in the original discussion there was a reason why the notification should stay around I would like to hear Gary on this one.

Daniel - thanks for getting feedback directly from teachers for us!

[sascha_silbe]

FWIW, I'd prefer the notification to stay until explicitly dismissed. There's no (other) place the user could check to verify the transfer actually finished successfully.
Other IM clients (e.g. Psi) do the same (show the progress dialog until manually closed).

Long term we should record the export of data store entries in the Journal (Actions View). Once we do that, we can reconsider automatically dismissing the notification.

[Dcastelo]

Finally we decide to give a notification to the user. This are the screenshots:

Screenshot_Transfer_Destiny_Completed - When the transfer is completed, shows the "ok" icon and the message "Transfer Completed" in both machines.

Screenshot_Transfer_Origin_Canceled- When the transfer in the destiny machine is cancelled we show "Transfer Canceled" message in the origin machine.

Do you think that is a good solution to include in the upstream version?

[tomeu]

Replying to Dcastelo:

Do you think that is a good solution to include in the upstream version?

Whatever people agree on is good with me.

[erikos]

The labeling is better indeed. As we do similar with downloads that seems ok to me. Actually from my experience with kids, they are confused by the download alert too, that they have to dismiss it when the download finishes :) Just from observing, have not done concrete testing here.

Actually, maybe having a button like with the downloads where you can do 'ok' or 'show in journal' would be good to get the link where to find the file?

[tomeu]

Removing from the queue because I understand that the patch is not being proposed any more for inclusion.