Created attachment 64021 [details] Patch: Make middle mouse button activate the inverse search feature Version: unspecified (using Devel) OS: Linux In KDE3, kdvi supported the use of the middle mouse button to jump to the line in the latex source file of the current document. In okular this has only been possible when using the shift + left mouse button combination. In my eyes, the new way of activating the inverse search is not very comfortable, since two hands are needed. This patch adds the middle mouse button activate the inverse search feature, while at the same time keeping the shift + left mouse button support. The patch makes sure the feature is only activated if the user did not drag the mouse to zoom while the middle mouse button was pressed. Previously, a simple middle mouse click had no effect at all. If the document does not contain any reference to a source file, the click with the middle mouse button will have no effect. (The same behavior as shift + left click.) It would be great if this feature could be added to Okular, this would make working with LaTeX a lot easier. Reproducible: Always Steps to Reproduce: Use your favourite LaTeX editor and configure both it and okular properly that inverse search works (i.e. choose build type "Modern" in Kile + choose the editor "Kile" in okular configuration), generate a DVI and/or PDF file from a sample latex source file in your editor, open it with okular and then 1) Middle-click on a paragraph 2) Hold shift and left-click on a paragraph Actual Results: 1) nothing happens (cursor may turn to "up-down-arrow" for a very brief amount of time) 2) you jump to the corresponding line in the source code in your editor Expected Results: You also jump into the editor when using the middle mouse button Attached patch was made against current git master branch, but should be trivially backportable to about any previous okular version.
Sorry, but no, the middle button already has a different feature so we can not make it do two things.
To perhaps make you understand where I'm coming from: Personally, I've only used the middle-mouse-drag-zoom feature when playing around, never when actually using okular. Whereas I regularily use the inverse search for LaTeX documents. That said, I get that this is probably a huge matter of personal preference and how people use the software. So, if you don't like the idea, are you open to having some sort of compromise? I'd suggest making the the way okular reacts to the mouse* configurable. My idea would be to categorize mouse events in "clicks", "drags" and "scrolls", (and distinguishing between different keyboard modifiers and mouse buttons) and then be able to associate these events with different actions ("scroll document", "zoom", "activate link", "inverse search", ...) in the configuration dialog. The default would then obviously be the current behaviour (principle of least suprise for people who then upgrade), but if somebody wants to configure it differently, they are able to. * Except for the association right mouse button <-> context menu. That should always be the case IMO. I'll implement this myself and provide you with a patch if you signal that you are in principle amenable to this feature.
In principle yes, i am against configuration for the sake of configuration. In my opinion it is going to make people confused to have such a huge configuration dialog. Giving support to okular will also be a hell since you no longer can say, left click on the link since left click might very well be zooming for him since his kid was playing with the configuration while he was watching TV. Also pageview code is already a huge beast of switches and ifs regarding mouse+key handling and i am afraid you will make maintainance harder that it already is. That said, if you can make it simple enough both codewise and user wise, I would probably have a look and consider its inclusion.
I never knew about using middle-button for zooming, thanks for the tip! That's going to make bug 240150 a bit more bearable. Having said that, I agree with Albert that assigning such widely different actions as zoom and inverse search to middle-drag and middle-click is too confusing. I'd be all for being able to configure mouse shortcuts for actions, as available on Mac OS (where pressing a shift/cmd/opt modifier automatically adds that to the selection menu). But it doesn't look like there is built-in support for that in KDE's shortcut settings framework.
Actually, I'm partly with Christian on this one ;) I think it would be really great to make it configurable what actions the mouse buttons trigger. I agree with Christian that it's not very comfortable having to use two hands to activate source references. But that's of course personal preference, and I think this is one of the situations where a configuration option make sense. And maybe it would also be good to give some feedback to the user whether source reference information is available and whether some reference has been activated? In fact, if Christian hadn't done it, I would have proposed such a feature myself ;)
One the main things I use okular for is proof-reading LaTeX documents on a tablet PC. Inverse search is essential for quickly locating and correcting small mistakes in the source. However, with no physical keyboard available, the shift-click binding is unusable on a tablet. (Mouse-only bindings are easy on a tablet, keyboard-only bindings are still usable via an on-screen keyboard, hence any action that can be accessed via a menu and perhaps some typing is usable. But keyboard+mouse bindings are essentially impossible to use on a tablet.) So the choice of inverse-search binding, and the complete lack of customisability, makes okular a major step backwards from kdvi for me. There are numerous other ways to zoom using only the mouse (menu bar, toolbar buttons), so the middle-click+drag zooming is not essential to using okular on a tablet. But there is *no* way of doing inverse search other than shift+click. So making the inverse-search binding shift-click cripples Okular on tablets. Whereas changing the inverse-search binding to middle-click, or at least allowing it to be customised, would allow *both* zooming and inverse-search to be used on a tablet. You've closed this with WONTFIX, and given it only "wishlist" severity. But, for my usage at least, this is not just 'nice to have', but a major usability issue. These days, you need to think about other computing form-factors than the standard PC. KDE itself is already doing so e.g. with its plasma tablet interface. You need to think about this in Okular too.
What about a left double-click to do dvi-search? The existing shift-click could be kept too, to avoid upsetting people who liked that, or there could be an option of which to use. It wouldn't have to do anything in non-dvi files. I have only small agreement with the (often expressed) idea of it being bad to have more configurability. It's worth a lot more for users to be able to have everything as they want it, for their next x years of work, rather than worrying about how a dialogue might confuse a new user during their first hours... I'm delighted to spend a day getting things just as I want them, /if/ I then can have everything working just right for the coming years and thousands of hours of use. A new user could just accept the defaults and not need even to look at the configuration. But yes -- I see it could feel a bit strange to have such totally different uses of middle-click, and a pity to have to lose this new zoom function if one wants mouse-only dvi-search. Bizarre though it may sound to some, my needs (and I guess plenty of others too -- we hear of some under this bug) make such a little detail as a need for keyboard+mouse surprisingly important: it's a trouble when frequently having to move one hand from a book or pen, to the keyboard, while left-clicking for dvi search! This summer KDE4 had progressed enough to seem worth moving over from KDE3 for some weeks to give it a good try, instead of the few-hour attempts in previous years. It had its definite good points, as well as some unfortunate ones. Okular had indeed several desirable features, particularly for pdf. But when the summer ended and I started working a lot with kile and okular, this apparently tiny problem really hit; most time since then has been spent in the old system. Probably not a typical "user case", but an indication of the importance of minimising movements for common tasks.