After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 171004 - drag to scroll
drag to scroll
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
0.3.x
Other Linux
: High enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-03-20 16:23 UTC by Tommi Komulainen
Modified: 2005-07-26 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (3.04 KB, patch)
2005-03-20 16:27 UTC, Tommi Komulainen
none Details | Review
rediffed against HEAD (3.16 KB, patch)
2005-03-24 05:04 UTC, Tommi Komulainen
none Details | Review
rediffed again (3.01 KB, patch)
2005-04-08 17:53 UTC, Tommi Komulainen
none Details | Review

Description Tommi Komulainen 2005-03-20 16:23:37 UTC
It should possible to scroll the page with mouse by dragging the page rather
than reaching out for those tiny scrollbars.
Comment 1 Tommi Komulainen 2005-03-20 16:27:17 UTC
Created attachment 38964 [details] [review]
proposed patch

Use middle mouse button for scrolling.	Added new set of variables rather than
reusing existing ones to keep them clearly separated.

It should probably be checked more closely whether the drag threshold should be
checked, also the cursor should be changed to something more appropriate while
dragging.
Comment 2 Bryan W Clark 2005-03-24 00:43:43 UTC
Sweet!

Tommi could you check that your patch still syncs up with the latest in HEAD. 
We've just merged in the threads branch.
Comment 3 Tommi Komulainen 2005-03-24 05:04:29 UTC
Created attachment 39179 [details] [review]
rediffed against HEAD

Only one chunk needed tweaking.  Seems to compile and scroll a little, but I
can't test it properly as HEAD breaks with 'Xlib: unexpected async reply
(sequence 0x1234)' or simply crashes.
Comment 4 Martin Kretzschmar 2005-03-24 09:40:19 UTC
I got 'Xlib: unexpected async reply (sequence 0x####) with HEAD (unpatched) too. 
Comment 5 Marco Pesenti Gritti 2005-04-08 11:04:22 UTC
/* XXX do we want to check the threshold, or scroll regardless? */

Bryan what do you think about this? I'd say check the thresold

Tommi, is this working correctly now?
Comment 6 Tommi Komulainen 2005-04-08 17:53:54 UTC
Created attachment 39843 [details] [review]
rediffed again

Patch against 0.2.0, seems to apply cleanly against HEAD as well.

Scrolling works, though compared to 0.1.9 it is now much more lagging.	Whereas
with 0.1.9 dragging was pretty much instantaneous, with 0.2.0 there's a
noticeable lag between cursor movement and page scrolling.  Probably because of
the locking needed for the new threading model.
Comment 7 Bryan W Clark 2005-04-08 18:17:17 UTC
Marco, I agree
Comment 8 Marco Pesenti Gritti 2005-05-09 08:56:14 UTC
I reworked this a bit, fixed the FIXME and checked in. Thanks!
Comment 9 Stephen Kennedy 2005-07-19 12:45:41 UTC
This seems to be broken in 0.3.0 (debian unstable version)

All mouse buttons are wired to select region.
Comment 10 Nickolay V. Shmyrev 2005-07-21 21:32:08 UTC
Stephen, this was fixed in 0.3.0, middle button (or left+right button
simultaneously) should do the work. Can you test once again, please check that
you are using exactly 0.3.0 version or better even latest evince version.
Comment 11 Mike Sowka 2005-07-24 01:38:16 UTC
I would like to put in my 2 cents worth ;) :

Given that 
1) Evince is meant to be a pervasive "oooohh... I didn't even know I was using
tool X" type of appp
2) Most folks are still used to using acr*read

Could we get an _option_ of having the left mouse button to drag?

For instance, have two modes:
view mode: left mouse button drags, middle highlights
edit mode: left hightlights, middle drags

Heim?

That's my 2 cents worth,
Mike
Comment 12 Marco Pesenti Gritti 2005-07-24 08:40:55 UTC
We have been trying to stay away from modes and switching mouse buttons behavior
doesnt seem like a strong reason to introduce them... though up to Bryan.
Comment 13 Marco Pesenti Gritti 2005-07-26 12:33:45 UTC
Marking as fixed on the base of #10