GNOME Bugzilla – Bug 165155
text graphics and drag mouse modes
Last modified: 2018-05-22 12:45:25 UTC
It would be cool if evince could have following three modes for clicking and dragging the mouse. 1. Text mode would only select only text so it could be pasted in a text editor. 2. Graphics mode would take a snap shot of the current selection (both images and text?) for pasting as a raster image (or some other image format). 3. Drag mode would allow for just clicking in the document view and dragging to navigate around the page.
Some ideas for the mode-o-phobics: Xpdf and the GIMP have dragging on mouse button 2 and selection (or any tool) on mouse button 1. Isn't it possible to copy to the clipboard in multiple formats at once? (plain text, raster graphics, rich text) /me shows his X11 clipboard ignorance.
*** Bug 167352 has been marked as a duplicate of this bug. ***
*** Bug 168664 has been marked as a duplicate of this bug. ***
*** Bug 170565 has been marked as a duplicate of this bug. ***
*** Bug 170880 has been marked as a duplicate of this bug. ***
from bug 170880#1 ------- Additional Comment From Grant Farnsworth 2005-03-19 02:37 ------- I was just looking at the kpdf implementation and it's quite convenient. When you release the mouse button after highlighting, it asks whether to copy the text, copy the image, or save the image as a file.
*** Bug 165470 has been marked as a duplicate of this bug. ***
3 is done with button 2 now
I'm unclear on the scope of this bug, at this point. What exactly remains to be done?
Hi Marco, I filed some time ago: http://bugzilla.gnome.org/show_bug.cgi?id=168664 This bug was resolved as DUPLICATE of this one. In short: It would be nice, if it would be possible to mark text with an text cursor line by line. Like it works in all text editors. Only in this way it is possible to mark only a sentence (which stops in the middle of a line) or to mark some text which is bigger than a page. A complete description is in #168664. I've tried evince 0.3, but my bug is not solved yet. Best regards, Christian
*** Bug 304153 has been marked as a duplicate of this bug. ***
*** Bug 306727 has been marked as a duplicate of this bug. ***
I think this bug should probably be closed and we open a new bugs for images. We have text selection so far, and mouse drag. Since I'm still mode-phobic ;-) I've been leaning towards doing selection similarly to how a web browser works. The two things that are missing are getting text+images if you highlight text across images and text. And being able to right click on an image and save it.
About images http://bugzilla.gnome.org/show_bug.cgi?id=310008
*** Bug 331195 has been marked as a duplicate of this bug. ***
The problem here is that middle button drag is badly discoverable and even more badly accessible. I think adobe people realized that :) Bug 331195 has the patch btw.
Created attachment 59404 [details] [review] Patch that creates 'Hand Mode' Patch attached in Bug 331195, which creates the 'Hand Mode'. The idea is to provide a way for user switch between text selection and scrolling modes.
Comment about the patch from Bug 331195 > This feature is also very useful on Maemo/Nokia 770. In this case it will be > enabled by default, so the user can scroll the document using the stylus.
Created attachment 59405 [details] [review] Another solution, hardcoded. This other patch would easly solve the problem in Maemo/Nokia 770, but it would be a hardcoded solution.
Btw, acroread suggests another interesting solution on that. It has "hand selection mode". It's usual hand dragging mode but if mouse stays on text for some time, hand became text selection tool. I've tested it a bit and it seems it's not very useful, but at least we should also consider this behaviour
I've had experience with this adobe design, it's really hard to use. Changing the mouse drag action so drastically depending on what you're hovering is a pretty poor idea. The reason I'm 'mode-o-phobic' is because it's always so hard to convey to people what mode they are in and what that means. If someone was expecting to be able to select text but can't because a button with an icon was toggled it adds to the complexity of the UI. By making everything a different action we avoid this problem inherent with modes. When thinking about this modes problem you have to also consider that on a normal desktop we have a mouse cursor that hints to what action will take place when you use the mouse (hover over text you get the I bar, otherwise the pointer). In a tablet device you don't have the added hovering mouse that aids in this, therefore you have to be much more explicit about the actions that will be performed. Not having a 3rd mouse button is a pain, but I don't think we need to add modes to our interaction to solve it. There is probably a simpler way to solve that problem if we want to take it on. For the 770 or similar devices I think you could get away with modes because your default action on drag should be to move the document around. Most people don't attempt to do lots of cutting and pasting when using small devices like that; they should be designed for consuming more than producing information. Since your default action is drag you'd want to enable people to select text somehow, having a toggle on 'text-selection' button seems like a good idea. I'm interested in a11y issues with the middle drag, if billh or others have suggestions on how to solve this. I think a different UI and interaction for the 770 makes a lot of sense compared to regular evince, I don't know how you want to separate those in the codebase.
Bryan, do you really believe the "primary" function people do when they read pdf files is to copy/paste text? I think the primary action is to scroll. In fact, my guess is that the majority of people hardly ever copy/paste text, though have nothing to base that on beyound my sample size of 1.
Created attachment 59423 [details] [review] Another solution This solution is a mix of attachment 59404 [details] [review] and 59405. In my opinion this is a better solution than both other.
(In reply to comment #22) > Bryan, do you really believe the "primary" function people do when they read > pdf files is to copy/paste text? Nope, actually I don't really believe that. I think my message might have been confusing if that's what you understood it as. I think your guess, even based on the limited sample size is correct.
so as a followup Q. Shouldn't drag be bound to button1 while select be bound to button3?
Actually I am +1 to Bryan, moreover we are in freeze now, so we have about a month to think about that problem and try to create real solution.
It might seem to logically follow that drag is button 1, but actually you'd be creating a different paradigm from web browsers and word processors. Since I don't think the gain of switching drag vs. copy is worth diverging from what people are used to we designed it the way it is. Plus you'd be in the reverse perdiciment, without the additional support of paging buttons, the scroll bar, and hardware devices like the mouse wheel; all of which aide in changing pages but not in copying text.
So we have a difficult decision to take. In one side we have the paradigm from other applications. In the other there is what do people really want when they use evince for reading documents. I think in this case they are absolutely the oposite. And having the 'Hand Mode' almost discarded, which one would we choose?
I would like to put in a vote to mimick 'GV's behaviour, or at least be able to switch to a mode like that (_everyone_ around me uses this program). Scrolling with the middle button is annoying if your brain has been hardwired to the GV way of doing things, not to mention that pressing the middle button is tricky if it is a badly designed scrollwheel. Apart from using button 1 for scrolling, it would also be nice to have a 'reverse direction' scrolling as in GV.
We don't care about your prehistoric gv habits ;) Anyway, better text selection is welcome. I doubt the "save rectangle as image" is problematic: it depends on the zoom size etc. Perhaps the screenshot tool can be used for this?
In my experience, Adobe's interface of changing the mode on hover is obvious and easy to use. Most of the time users want to scroll, and when they want to select they know how to do it because the "I" pointer is associated with text selection. I don't make mode errors because the pointer indication is clear, and I habituated to moving the mouse before panning.
Just signing up to the CC list and referencing enhancement bug http://bugzilla.gnome.org/show_bug.cgi?id=557956 in which I raise the same issue specifically for tablet users without a middle mouse button. Are there any patches against current versions of evince out in the wild?
*** Bug 570486 has been marked as a duplicate of this bug. ***
at the bare minimum at least allow alt-left click, which is is deactivated from the window manager in full screen mode, to then scroll the image. Evince is vey unusable for large poster of diagram stuff where i end up enlarging the window to 5x the size of the screen and then using alt-left clieck to pan/grab/hand mode it PLEASE ADD DRAG FUNCTIONALITY at least to alt-left click while in full screen mode, this adds absolutely no key bindings and is works exactally as users should expect.
well i kinda take that back, i finally found middle-click, but alt-left click would be nice in full screen as its more obvious
Shouting is not helpful for anyone. Additionally, Alt-clicking interferes with the window manager.
*** Bug 554989 has been marked as a duplicate of this bug. ***
In pdfs it is very difficult to distinguish between a text and an image. Two different behaviours associated to the same action, under a context which is difficult to tell are not good. I reported a bug in ubuntu about the current way evince handles left-drags. Here is the bug and a cut and paste of the description. NOTE: IF you think that what I am saying is a separate bug, please tell me as soon as possible so that I will report a new bug in evince/gnome instead of adding comments here. https://bugs.edge.launchpad.net/ubuntu/+source/evince/+bug/379403 The description in the ubuntu bug is reported below for your convenience. === In the new evince in jaunty, dragging starting from an image actually drags the image, while dragging over text will select it. There are at least three problems in this. - the operation may harm the user: if I click and drag a page of a pdf which is a scanned document, and I release the document over evince, evince will load the page as an image. This is VERY bad. First, do not know why, this will trigger high memory allocation and eventually trash the system. This happens to me frequently in jaunty. Just a small mistake, a click too much (easy to happen by pure mistake using touchpads) and you have to hard-reboot the machine. While you were working. - usability: if the drag does NOT trigger high memory usage, it may load a whole pdf page as a separate document. This may be unnoticed because the user continues to see the same page as before, just a bit zoomed in. Then the user zooms out, tries to go to the next page. Does not work. Then finally realises that he is looking at a new window. This happened to me frequently too. - usability, ii: without knowing about the implementation of PDF, as there are pdfs with text rendered as image, you can not understand why "sometimes it lets me select text, some other times it drags an image". This may be particularly frustrating: you try to select a text, you see that you are dragging something instead, release mouse, and end up with evince loading an image as described above. The problem may be summarised as follows: Selection should be selection. Dragging should be dragging. These are separate actions. You may eventually drag _after_ you have selected, as in openoffice for example. The current behaviour of enabling a potentially dangerous and confusing operation with the right button should be disabled.
I notice that the new behaviour in evince is probably inspired by that of web browsers such as firefox. However, in firefox, I can't drag an image from the current document over the SAME firefox window to have it loaded. Making each window not a target for its own drags would likely fix the bug. I would still dislike the behaviour also present in firefox to treat text and images differently on drag; I would consider clearer for the end user to select images when dragging, too but maybe I don't see obvious drawbacks.
I agree with Vincent in principle, but I'm not sure how it would best be implemented. If you have to select images before dragging them, how can you select exactly the image that is in the document and no less? Selecting images is more cumbersome than selecting text, even though it is more rare. On the other hand, perhaps there can be some aid for selecting the whole image. For example, there can be handles around the selection. This idea of rectangular selections can also be extended to selection of regions in the window. The selected region can then be cropped, saved or dragged as a whole. Operations can also be facilitated by a small menu that pops up when a region is selected. Selection of text would still be possible possible when you drag the pointer over the text (or when you double-click on the text).
I think that proper selection of (sub)images from the pdf as seen in acroread and okular is limited by some poppler capability missing (correct me if I am wrong). However, to make my last comments clear, I think that most of the problems would be mitigated by just disallowing dragging from an evince window over itself; makes few sense anyway as dragging over a window is typically used for loading entire documents, not for loading a sub-document of an already-opened one.
What makes this whole thing even worse is that some images, notably vector figures, cannot be selected OR dragged at all for copying. I believe that's one of the reasons why kpdf and adobe reader have the rectangle selection tool.
The part of the bug reported in my latest comment is fixed by current code (and it is also fixed in ubuntu karmic). Am I missing something?
I just reported the following comment on bug #557956 but it is relevant also here, since we are talking about a "drag mode", and I know modality is not so appreciated in gnome for the usual reasons. On netbooks with two buttons mouse it is often very difficult to press the buttons simultaneously. Moreover chording is not discoverable by new users. I see a trivial and elegant solution to this problem: drag pages when clicking on blank areas. That will not work with all pdfs of course, but it is an enhancement which is orthogonal to alternative solutions, and would be useful even if we had e.g. chording with the ctrl key.
(In reply to comment #21) > I've had experience with this adobe design, it's really hard to use. Changing > the mouse drag action so drastically depending on what you're hovering is a > pretty poor idea. > > The reason I'm 'mode-o-phobic' is because it's always so hard to convey to > people what mode they are in and what that means. If someone was expecting to > be able to select text but can't because a button with an icon was toggled it > adds to the complexity of the UI. > > By making everything a different action we avoid this problem inherent with > modes. When thinking about this modes problem you have to also consider that > on a normal desktop we have a mouse cursor that hints to what action will take > place when you use the mouse (hover over text you get the I bar, otherwise the > pointer). In a tablet device you don't have the added hovering mouse that aids > in this, therefore you have to be much more explicit about the actions that > will be performed. > so the only problem with modes will be with tablets. but in tablets currently it is doing selection and not scrolling anyways. so wont it actually improve the situation to have drag mode? somebody who actually uses evince on a tablet should probably comment on this. but the summary is people on desktop/laptop will benefit with modes especially without a middle button. and for tablets also modes will help to switch between drag and text selection. though only problem is feedback on which mode we are in has to be conveyed properly. in all cases it seems modes are useful. just the implementation has to be discussed. > Not having a 3rd mouse button is a pain, but I don't think we need to add modes > to our interaction to solve it. There is probably a simpler way to solve that > problem if we want to take it on. > > For the 770 or similar devices I think you could get away with modes because > your default action on drag should be to move the document around. Most people > don't attempt to do lots of cutting and pasting when using small devices like > that; they should be designed for consuming more than producing information. > Since your default action is drag you'd want to enable people to select text > somehow, having a toggle on 'text-selection' button seems like a good idea. > > I'm interested in a11y issues with the middle drag, if billh or others have > suggestions on how to solve this. I think a different UI and interaction for > the 770 makes a lot of sense compared to regular evince, I don't know how you > want to separate those in the codebase.
Regardless whether drag and selection are implemented using modes (like in acroread), or with modeless actions, please put scrolling on mouse button 1. It just makes sense because users very rarely want to select. The argument against it was that in browsers and text editors, scrolling is done with button 2. But Evince does not *scroll* on button 2 anyway; instead it pans in the same direction as the mouse drag. So that's already different than other types of apps. A discoverability solution is a tool bar button to activate Select mode that lasts only until the user makes a selection. A tool tip on the button would show the key combo to do the same thing or the key + mouse_drag combo to select without modes at all. This also solves the problem for tablets.
What is the status of this? Has anything be implemented? I would like a rectangle select. Especially two-column latex documents are impossible to copy. Example: copy something from the left column on page 2 of http://www.ctan.org/tex-archive/macros/latex/required/tools/multicol.pdf Rectangle-select would solve this issue and should be easy to implement (look at blocks within the selection, and copy only glyphs in it).
*** Bug 495341 has been marked as a duplicate of this bug. ***
Review of attachment 59423 [details] [review]: Instead of a new mode, I would rather use a solution that changes the behaviour automatically depending on whether evince is running in a touchscreen device or not, we could use touchscreen-mode gtk settings for that. http://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-touchscreen-mode
*** Bug 557956 has been marked as a duplicate of this bug. ***
*** Bug 677573 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/1.