Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#4418 closed defect (fixed)

Copying an image does not work

Reported by: dsd Owned by: humitos
Priority: Unspecified by Maintainer Milestone:
Component: Paint Version: Unspecified
Severity: Unspecified Keywords:
Cc: humitos, erikos, godiard, dsd Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description (last modified by erikos)

Tested on 13.1.0 build 28 on XO-4, copying an image from Browse or Paint doesn't work.

shell.log includes an exception:

clipboardpanelwindow.py line 87, in _owner_change_cb
data_hash = hash(selection.get_data())
AttributeError: NoneType object has no attribute 'get_data'

For copying a clipping from Paint the steps are as follows:

  • open Paint and draw something
  • select parts of the drawing
  • in the edit section push the copy button

---> in the clipboard an entry is created that has the copy icon and is labelled image clipping, it has only one option for opening it

  • try to resume that entry

---> Paint is opened but the canvas is empty

  • go to the edit toolbar and push the paste button

---> the clipping is pasted fine into Paint

For copying a clipping from Browse the steps are as follows:

  • click on an image in Browse (e.g. Wikipedia picture, a Google searched picture...) and select 'Copy image' in the Palette

---> in the clipboard an entry is created that has the copy icon and is labelled image clipping, it has only one option for opening it

  • select 'open' in the clipping Palette

---> Paint is opened but the canvas is blank

  • go to the edit toolbar and push the paste button

---> the clipping is pasted fine into Paint

Attachments (1)

0001-Allow-to-open-multiple-mimetype-SL-4418.patch (2.1 KB) - added by humitos 8 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 8 years ago by humitos

  • Cc humitos added

comment:2 follow-up: Changed 8 years ago by erikos

First things to check here:

  • check if there is some info in the existing clipboard tickets
  • is it a regression to 12.1.0
  • does it happen on other XO hardware
  • and then check the traceback

comment:3 in reply to: ↑ 2 Changed 8 years ago by humitos

  • Cc erikos added

Replying to erikos:

  • does it happen on other XO hardware

I tested this in XO 1.5 os27 and it did not happen; anyway, after the icon appears in the frame and I click on 'open', it's opened with Paint but there is no image at all: blank canvas.

The difference that I noticed is the order of the file types to check:

  • XO-4:
    • TIMESTAMP
    • [...]
    • image/png
    • image/bmp
    • [...]
    • image/jpeg
    • image/x-win-bitmap

and there the message no data for selection target image/x-win-bitmap appears in the shell.log and the variable selection is pointing to None.

  • XO-1.5:
    • TIMESTAMP
    • [...]
    • image/png
    • image/bmp
    • [...]
    • image/x-win-bitmap
    • image/jpeg

here the selection variable is assigned to something significant because there is selection target for image/jpeg.

So, I use cb_selections[-1] to get the last significant value. Here is the diff:

diff --git a/src/jarabe/frame/clipboardpanelwindow.py b/src/jarabe/frame/clipboardpanelwindow.py
index ba86775..79cfb7e 100644
--- a/src/jarabe/frame/clipboardpanelwindow.py
+++ b/src/jarabe/frame/clipboardpanelwindow.py
@@ -78,6 +78,7 @@ class ClipboardPanelWindow(FrameWindow):
                     continue
                 cb_selections.append(selection)
 
+        selection = cb_selections[-1]
         if target_is_uri:
             uri = selection.get_data()
             filename = uri[len('file://'):].strip()

This diff solves the traceback but I see a blank canvas when I open it with Paint, like in XO-1.5.

NOTE: on XO-4 (with this patch applied) and on XO-1.5, if I right-click on the clipboard icon, then click in 'Keep' and finally open the image from the Journal, it opens with ImageViewer and I see the image.

comment:4 Changed 8 years ago by humitos

  • Owner changed from erikos to humitos
  • Status changed from new to accepted

comment:5 follow-up: Changed 8 years ago by humitos

  • Cc godiard added

I tried this again in 13.1.0 os30 and the error in shell.log disappeared (without applying my patch).

I researched this a bit more and I found that the problem seems to be in Paint Activity instead of the Clipboard because Paint fails when I try to open the clipboard object from the clipboard menu: with "Open" (there is no Activities to select, it opens only with Paint).

On the other hand, if I click on "Keep" from the clipboard menu and then open it with ImageViewer I can see the image properly but if after I click on "Keep" I open it with Paint I see a white canvas.

In both situations (open it with Paint) I'm getting this error in Paint log:

1360928680.318162 DEBUG root: reading file /home/olpc/.sugar/default/data/856be15a-66bf-4ca9-948c-663e572c663c_wi4b7O.bmp, mimetype: image/bmp, title: Image clipping
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/sugar3/activity/activity.py", line 538, in __canvas_map_cb
    self.read_file(self._jobject.file_path)
  File "/home/olpc/Activities/Paint.activity/OficinaActivity.py", line 144, in read_file
    self.area.load_from_file(file_path)
  File "/home/olpc/Activities/Paint.activity/Area.py", line 244, in load_from_file
    cairo.ImageSurface.create_from_png(file_path)
MemoryError

I see two things here:

  1. the path does not exist immediately after Paint is opened
  2. Paint is trying to open a 'png' and the image is 'bmp'

comment:6 in reply to: ↑ 5 Changed 8 years ago by humitos

  • Component changed from sugar to Paint
  • Summary changed from Can't copy images to clipboard to Paint only allows 'png' files

Replying to humitos:

I see two things here:

  1. the path does not exist immediately after Paint is opened

I put log to see if the file_path exists at the moment that it's tried to be read and it exists. So, this is not the problem.

  1. Paint is trying to open a 'png' and the image is 'bmp'

I tried opening a simple bmp example downloaded from Internet with Paint and I got the same error. So, Paint only allows opening 'png' file because the way that cairo loads the stream.

(I'm changing the Summary of this ticket)

comment:7 Changed 8 years ago by humitos

  • Keywords r? added

Patch attached. Waiting for review.

comment:8 Changed 8 years ago by erikos

  • Component changed from Paint to sugar
  • Description modified (diff)
  • Summary changed from Paint only allows 'png' files to Copying an image does not work

I think this ticket went a bit off track. First of all we should define the use case again from the original request from Daniel:

He reported that he can not copy an image from Browse or Paint (this copying is using the clipboard). I added test cases to the description.


comment:9 Changed 8 years ago by erikos

While testing this issue I had some issues when copying images in Browse: one is described here #4431

comment:10 follow-up: Changed 8 years ago by erikos

Humitos, it is true that your patch makes the use cases defined in the ticket description work, I can resume clippings from Browse or from Paint with the Paint activity.

One thing I am confused with is that Paint is the only option that is offered for resuming clippings. There should be ImageViewer as well and probably Browse if the image format is png/svg/jpeg.

As a quick test, if you define in the activity.info in Paint only those (png/svg/jpeg) no resume option is available.

Can you debug which mime type the clipping code decides the clipping is of?

comment:11 in reply to: ↑ 10 Changed 8 years ago by humitos

Replying to erikos:

Can you debug which mime type the clipping code decides the clipping is of?

When you try to open the image clipping with Paint is says its mimetype is image/bmp in its log.

I confirmed that using sugar3.mime.get_from_file_name. But if I add image/x-MS-bmp to the mimetypes supported by Browse, the option to open it with Browse appears in the palette.

comment:12 Changed 8 years ago by godiard

  • Cc dsd added

I have pushed a simpler version of the patch as 16495674277dfed5241d0bf6711d475765e731a8

dsd, Is this needed for 13.1.0 or 13.2.0?

comment:13 follow-up: Changed 8 years ago by dsd

Thanks for the fix. Keeping the current stated scope of 13.1.0 (XO-4 production requirements only - and now wrapping up), I would say 13.2.0.

comment:14 in reply to: ↑ 13 Changed 8 years ago by godiard

  • Component changed from sugar to Paint
  • Keywords r? removed
  • Milestone changed from 0.98 to 1.0
  • Resolution set to fixed
  • Status changed from accepted to closed

Replying to dsd:

Thanks for the fix. Keeping the current stated scope of 13.1.0 (XO-4 production requirements only - and now wrapping up), I would say 13.2.0.

Ok. Moving to milestone 1.0 and closing.

comment:15 Changed 8 years ago by dnarvaez

  • Milestone 1.0 deleted

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.