Comment 24 for bug 379403

It does seem odd that evince deals with it in this way fullstop.

If we want to drag text on the same page, we have to select and then drag
otherwise nothing happens, whereas with an embedded image it can just be
dragged and will open up another version of evince with it inside.

Surely if we're matching behaviours then evince should not even be opening a
second instance containing an image but instead just storing the image in
the clipboard (or turn it into a png if dragged to a nautilus window) - or
perhaps, even opening it in eog?.

2009/6/12 Vincenzo Ciancia <email address hidden>

> Sebastian, I just ask for the *drop* to be disabled on the *same*
> window. This is surely feasible. Firefox does this. Of course it is nice
> that you can drag an image e.g. on the desktop. Then I will report the
> other bug on some graphics being able to be dragged, some other not.
>
> This is certainly not unfeasible. Firefox implements this with html.
> Evince is a viewer and should do the same. Openoffice, which is an
> editor and not a viewer, instead allows you to drag on the same
> document, because it makes sense there. In evince it does not make
> sense. The current way evince does it is an implementation driven, not
> interface driven, feature.
>
> So you say: "there is [NO?] easy way to make a graphical distinction
> between real text and a bitmap showing text so people will always be
> confused in the second case when trying to select text which will not
> work"
>
> Indeed, precisely because there is no easy way, it is bad if we load a
> page of the document in front of the user when he drags from the same
> window. The user is confused by not being able to tell the difference in
> a second. When I first noticed this bug I was really confused myself, as
> others have confirmed above.
>
> and: "there is just no good way around this annoyance out of making
> impossible to select text at all in any document"; no, there must be as
> firefox does that. Try for yourself, it will not accept drops of its own
> image, but it will allow you to select text and images, and also to drag
> an image over *another* firefox window.
>
> Note in passing that evince already distinguishes drags over text from
> drags over an image and behaves differently: in the case of an image, it
> initiates a drag and drop operation, in the case of text, it initiates a
> selection. So if you ever wished to disable drag of graphics without
> disabling selection of text you could. In fact, evince in hardy did not
> drag images, but allowed to select text. However this paragraph is not
> aimed at convincing you to disable drag and drop of images. I am not
> asking for that.
>
> The way to disable the *drop* is to modify the list of accepted *drops*
> on the window and has nothing to do with the "on drag initiate" code.
> Should really be a trivial patch, do you see this now?
>
> If you agree that this can and should be fixed, I can try better in the
> source of evince as it is easy to find the relevant code; studying a bit
> of gtk can be good for me.
>
> --
> Drag and drop of images is dangerous in evince and too easy to perform
> https://bugs.launchpad.net/bugs/379403
> You received this bug notification because you are a direct subscriber
> of the bug.
>