8.2-757: Copy-to-clipboard broken in Journal

[bert]

When copying an entry from Journal to clipboard, it cannot be opened using the "Open" or "Open with" menu items in the frame.

To test, copy an image to the clipboard and try to open it from the clipboard icon's palette in Paint or Browse.

This must be broken for quite some time, #6262 is a symptom.

[bert]

Apparently, the "open" menu item creates datastore entry containing a filename (mimetype text/uri-list) instead of opening the actual datastore entry.

[mstone]

Is this a regression? Is it the same problem as #8285? More information would be appreciated.

[tomeu]

Replying to bert:

Apparently, the "open" menu item creates datastore entry containing a filename (mimetype text/uri-list) instead of opening the actual datastore entry.

That's actually intended, the journal won't put in the X selection all the data from the entry, but will copy to a file on disk and put the path in the selection instead.

Looks like that file is being prematurely deleted, checking now.

[bert]

Replying to tomeu:

Looks like that file is being prematurely deleted, checking now.

I don't think that's the problem - after I implemented support for text/uri-list in #6262 it worked fine.

But that text/uri-list entry remains in the journal which is ugly and also points to the filename that will become stale very soon.

[bert]

Replying to mstone:

Is this a regression? Is it the same problem as #8285? More information would be appreciated.

#8285 is not about the clipboard ... which ticket did you mean?

[tomeu]

The journal wasn't putting uris into the clipboard in the right format.

[tomeu]

|TestCase|

Take an screenshot with alt+1, go to the journal, with the palette on the screenshot entry, select Copy. Go to the new item in the clipboard in the right frame and select Open, check that it opens correctly in Browse or Paint.

[joe]

Replying to tomeu:

|TestCase| Take an screenshot with alt+1, go to the journal, with the palette on the screenshot entry, select Copy. Go to the new item in the clipboard in the right frame and select Open, check that it opens correctly in Browse or Paint.

---

Re-tested. After I selected "Open" (with Browse), nothing happened. Further hovering over the item in the clipboard didn't even produced a menu of choices.

[joe]

Replying to joe:

Replying to tomeu:

|TestCase| Take an screenshot with alt+1, go to the journal, with the palette on the screenshot entry, select Copy. Go to the new item in the clipboard in the right frame and select Open, check that it opens correctly in Browse or Paint.

--------- Re-tested. After I selected "Open" (with Browse), nothing happened. Further hovering over the item in the clipboard didn't even produce a menu of choices.

[bert]

Replying to joe:

Re-tested. After I selected "Open" (with Browse), nothing happened. Further hovering over the item in the clipboard didn't even produced a menu of choices.

That might be a different bug. I noticed the "open with" submenu listing the activities sometimes closes on its own if you do not click fast enough. It may even look like you clicked the item when in reality it vanished right before you clicked. If you can confirm this, please file another bug.

I applied the patch by hand in jhbuild and it worked there (provided I'm really fast to click the menu item). So r+ from me.

[joe]

Replying to bert:

Replying to joe:

Re-tested. After I selected "Open" (with Browse), nothing happened. Further hovering over the item in the clipboard didn't even produced a menu of choices.

That might be a different bug. I noticed the "open with" submenu listing the activities sometimes closes on its own if you do not click fast enough. It may even look like you clicked the item when in reality it vanished right before you clicked. If you can confirm this, please file another bug. I applied the patch by hand in jhbuild and it worked there (provided I'm really fast to click the menu item). So r+ from me.

---

No, in my case the menu stayed put, until I clicked on "Open" -> Browse. Nothing happened. I think it's the same bug.

[bert]

(In #6262) So it turns out this actually was a Sugar bug (#8287). So 2130revertSugarClip-bf retracts the workaround.

[tomeu]

Replying to joe:

No, in my case the menu stayed put, until I clicked on "Open" -> Browse. Nothing happened. I think it's the same bug.

As it worked for me, I'll need more details so I can reproduce it, or attach logs to the ticket. But I guess this should go to a new ticket so we don't make this one even more confusing?

[tomeu]

Thanks a lot for testing the patch, Bert. The r+ should be given by a peer sugar developer, though. (And 'package' only once the code is in git)

[tomeu]

Replying to joe:

No, in my case the menu stayed put, until I clicked on "Open" -> Browse. Nothing happened. I think it's the same bug.

Joe, have you manually applied the patch? If not, you are still running the old code that doesn't contain the fix. If I understood the recent changes correctly, once it has gotten into a build, the action-needed field of this ticket will be set to 'test in build' (or is it 'qa signoff'?) and we'll appreciate your testing.

If at that point your test reveals something unexpected, please attach logs as well:

http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets

Thanks!

[joe]

Log file (8.2-759)

[joe]

Retested with 8.2-759. Tried to open the image with Browse, Etoys and Point - activities started, but the image wasn't shown.

The log file is attached.

[marco]

We might be able to use gtk_selection_data_set_uris() here.

If that doesn't work for some reason, I think we should add a function to create a uri-list in sugar.mmime (we have one to extract them already), and make it follows the spec.

[tomeu]

set_uris seems to work fine

[bert]

Hehe, it even is one character less than before. Great call, Marco :)

[marco]

|Testcase|

To test, copy an image to the clipboard and try to open it from the clipboard icon's palette in Paint or Browse.

[marco]

sugar-journal-99-4.olpc3

Approved.

[cscott]

Added sugar-journal-99-4.olpc3 to stable repository:

http://mock.laptop.org/gitweb/gitweb.cgi?p=repos;a=commitdiff;h=2ee3f46bc72182b72bc5cf94f71637fdd10f2a57

Should by in stable build 760 and later. Please test.

[bert]

Tested working in 8.2-760.

[mchua]

assigning to frances to verify in 763 - see test case in original ticket (identical to the one in marco's later comment).

[mchua]

Tested working in 765. I'm marking this one as closed.