Open action in the clipboard menu not working

[Zack]

I was in the developer console copying tracebacks to paste into bug reports. I noticed that clipboard objects created there correctly were of the 'Text' type, and had three context menu entries: Remove, Open, Add to Journal.

Remove works, but Open and Add to Journal each do nothing.

[Zack]

Is this relevant?

STDERR - Traceback (most recent call last):

File "/usr/share/sugar/shell/view/clipboardicon.py", line 165, in _popup_action_cb

self._save_to_journal()

File "/usr/share/sugar/shell/view/clipboardicon.py", line 207, in _save_to_journal

os.write(f, datadata?)

KeyError: 'data'

[Zack]

Maybe this too...

WARNING - sugar.presence.presenceservice: Unable to retrieve activity handle for dbus.String(u'd86b34839b1d76ca1af4f1dfce0bd1c60f47a36d') from presence service: org.laptop.Sugar.Presence.NotFound: Traceback (most recent call last):

File "/usr/lib/python2.5/site-packages/dbus/service.py", line 498, in _message_cb

retval = candidate_method(self, *args, **keywords)

File "/usr/share/sugar-presence-service/presenceservice.py", line 569, in GetActivityById

raise NotFoundError("The activity was not found.")

NotFoundError: org.laptop.Sugar.Presence.NotFound: The activity was not found.

[jfuhrer]

As of build 485, Add to Journal works. It will add an entry to the journal entitled "Clipboard selection." Open is still broken, though.

[tomeu]

Please open new tickets for other kinds of data.

[tomeu]

"Add to journal" should be working now.

Eben, the HIG doesn't mention this "Open" action, and I think we put it there temporarily for opening pdfs and installing bundles when we didn't had the Journal yet.

Do you think it is worth implementing? or it's enough with "Copy to journal" and then "Resume" from the journal?

I'm lowering the priority as the only defect remaining provides redundant functionality.

[Eben]

Well, "Open" is certainly a lower priority, though I think the functionality would be quite useful. It is redundant, but it can make the process much quicker, providing it from anywhere rather than solely from the journal. Perhaps I copy an image from the web. I could then jump to the clipboard and pull up some "open with" functionality to pull it right into Draw, for instance. This is actually better than the more general "Save to Journal", since it automatically associates the object with the activity I care about.

That said, there is a much more glaring omission here. This is a visual clipboard, and yet there's no mention of a "Paste" action. This should be available whenever the current view supports pasting, and I would put this as a high priority item. We can't assume shortcuts will be learned up front, and not everyone can manage drag'n'drop operations easily.

Finally, once we have support for it, we may want some other actions such as "Send" to friend, "Print", and "Post" to bboard, but those are also low priority for now.

[Eben]

I've separated the "Paste" action out into a new ticket #1954. This one will remain open with lower priority for the "Open" action.

[tomeu]

Pushed a fix, please test in the next image after 496.

[Zack]

Copied text to the clipboard from Write via Ctrl-C; closed Write; selected Open on the clipboard object. Nothing happens.

[Zack]

Still broken in 502.

[Zack]

Should I file bugs on the fact that 'Stop Download' appears in the context menu, as does some sort of large white oval thing (possibly a nonworking text entry)?

[Zack]

Also, Add to Journal -> Resume from Journal on a text object copied from Write opens the clip in... Web.

[tomeu]

Replying to Zack:

Should I file bugs on the fact that 'Stop Download' appears in the context menu, as does some sort of large white oval thing (possibly a nonworking text entry)?

Yes, please open bugs about everything that looks wrong. If you are not sure if something is wrong or not (but looks confusing to you), then ask Eben after consulting the Human Interface Guidelines in the wiki.

But please please, open separate tickets for separate issues and check before there is not already a ticket about that.

[Zack]

Will do tomeu, just getting a feel for how you like to work (I'm glad you wanted separate tickets ;)

[tomeu]

Have tested in jhbuild and Browse is opened. We have a problem here, as Write offers copied text as UTF8_STRING, STRING, text/html, TEXT, text/rtf, COMPOUND_TEXT, application/rtf, text/plain, application/xhtml+xml.

The algorithm for choosing one data type is choosing the first text/*, that in this case is text/html.

In this case choosing text/plain or application/rtf looks more appropriate, but this algorithm perhaps should not know anything about Write or abiword.

Eben, Marco: should we add a rule to the HIG or whatever that says something like "activities that offer editable text should offer text/plain and optionally application/rtf"?

[marco]

I tend to think the simplest solution for Trial-2 is to not allow to Open clipboard objects (except downloads). It opens a particularly complicated can of worms...

[tomeu]

Perhaps a fix equally simple and more effective would be for Write to not offer html targets when copying or dragging text out. What do you think, Marc?

And also note that we have this exact problem when copying clipboard items to the journal (we have to choose one target as the most significant one).

[marco]

I'm not sure that's the right solution and it's probably an invasive change. Favoring rtf over html in the algo might make sense though.

[tomeu]

We have lowered the priority for text/plain and text/html, so it chooses now the right format. Will be in after 511.

Note that you'll have to close the first instance of Write before trying to open it due to #2176.

[Zack]

This isn't working even if I close Write before attempting to Open, in 514.

[tomeu]

It just worked for me in 526.

[coderanger]

Adding reporter to CC list

[coderanger]

Adding reporter to CC list