Opened 10 years ago

Closed 10 years ago

Last modified 5 years ago

#4874 closed bug (fixed)

Cant cut and drag on to desktop a piece of picture

Reported by: streak Owned by: julun
Priority: normal Milestone: R1
Component: Applications/ShowImage Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking: #726
Has a Patch: no Platform: x86

Description (last modified by mmadia)

On newest haiku builds [ nightlies ] i couldnt cut and drag on to desktop/folder a piece of picture selected in ShowImage.

Im getting error: " Sorry, the file 'Bitmap Clip 1' could not be written "

Attachments (1)

translator.diff (4.8 KB ) - added by julun 10 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 by streak, 10 years ago

How's it going? Any progress in correcting this BUG?

comment:2 by streak, 10 years ago

Component: Applications/ShowImageAdd-Ons/Translators/PNG
Owner: changed from leavengood to nobody

comment:3 by leavengood, 10 years ago

I have confirmed it but have not yet starting working on it. Any reason you removed me as the owner and changed the component to the PNG Translator?

comment:4 by axeld, 10 years ago

Component: Add-Ons/Translators/PNGApplications/ShowImage
Owner: changed from nobody to leavengood

Changing the component automatically changes the owner to the owner of the component.

comment:5 by streak, 10 years ago

Any progress since?

comment:6 by julun, 10 years ago

Owner: changed from leavengood to julun
Status: newin-progress

comment:7 by julun, 10 years ago

Fixed in hrev35139.

I've attached a patch that does introduce a new method to ask the translator if it really can handle the image output size, so it won't show up in the generated list for translators if unable to do so. Still I'm unsure if we can't find a different way.

by julun, 10 years ago

Attachment: translator.diff added

comment:8 by axeld, 10 years ago

In general I'd say I like this solution; however, it would make a much better impression to the user if each translator could support all sizes. Ie. in the case of the ICO translator, it could resize the image to something it can handle.

comment:9 by axeld, 10 years ago

Maybe ShowImage should in this particular case try to take over the source format? And if that fails (ie. if that cannot write), try well known ones first, like "PNG", "JPG"?

While the problem shows that ShowImage needs improvements in this area, it also shows that the heuristical ordering of the translators doesn't really make much sense at all.

comment:10 by julun, 10 years ago

Hi, thanks for having a look at the patch. I'm going to apply it next. For the second comment you added, this is how I implemented it in ShowImage now (hrev35139). It will add the current image format in the current translator list first, though if it can't write out it would fall back to the heuristic ordering of the translators. I'm going to open an enhancement ticket for this.

comment:11 by julun, 10 years ago

Resolution: fixed
Status: in-progressclosed

Applied in rr35186.

comment:12 by axeld, 10 years ago

What do you think about changing ICO to accept all sizes in the future again, and let it resize the image automatically? Should I open an enhancement ticket for this again? I'm a bit torn on the issue.

in reply to:  12 comment:13 by julun, 10 years ago

Hi,

Replying to axeld:

What do you think about changing ICO to accept all sizes in the future again, and let it resize the image automatically? Should I open an enhancement ticket for this again? I'm a bit torn on the issue.


Yes I think it's worth to extend the translater, so an enhancement ticket should be filed.

comment:14 by mmadia, 7 years ago

Description: modified (diff)

comment:15 by umccullough, 5 years ago

Blocking: 726 added
Note: See TracTickets for help on using tickets.