Presentation mode: go to previous page when left-clicking on left half of the page
AcceptedPublic

Authored by sander on Tue, Jan 8, 8:40 PM.

Details

Reviewers
ngraham
Group Reviewers
Okular
Summary

Previously, touching a touch screen would advance the presentation to the next page no matter the cursor position. With this patch, touching the right half of the screen still leads to the next page being shown, but touching the left half leads to the previous page now.

The actual action happens on mouse-release. For touch screens this means less interference with swipe gestures (which also allow to go to the previous/next page).

CCBUG: 346979

Test Plan
  • Open a pdf in presentation mode
  • Touch the right half of the touchscreen
  • Result: the next page is shown
  • Touch the left half of the screen
  • Result: the previous page is shown

Diff Detail

Repository
R223 Okular
Lint
Lint Skipped
Unit
Unit Tests Skipped
sander created this revision.Tue, Jan 8, 8:40 PM
Restricted Application added a project: Okular. · View Herald TranscriptTue, Jan 8, 8:40 PM
Restricted Application added a subscriber: okular-devel. · View Herald Transcript
sander requested review of this revision.Tue, Jan 8, 8:40 PM
ngraham added a subscriber: ngraham.Tue, Jan 8, 8:46 PM

Lovely! Probably CCBUG: 346979

aacid added a subscriber: aacid.Tue, Jan 8, 8:58 PM

I'd be terribly unhappy about this, i never look at where my mouse is when clicking in presentation view.

aacid added a comment.Tue, Jan 8, 9:05 PM

I understand this can be helpful for some configurations, so having a configuration option (that defaults to the old behaviour) would be more than acceptable for me.

But now, if you do, if will go back. :) This is pretty much mandatory for touch friendliness, which is important with more and more laptops being convertibles.

sander edited the summary of this revision. (Show Details)Tue, Jan 8, 9:19 PM
sander added a comment.Tue, Jan 8, 9:24 PM

How about we let the new behavior apply only to touch events, and leave the mouse handling as it is?

aacid added a comment.Tue, Jan 8, 9:32 PM

How about we let the new behavior apply only to touch events, and leave the mouse handling as it is?

I don't know, it is still a behaviour change, and given how nervous people usually are when doing a presentation i wouldn't like the behaviour of a software i've used lots of times be changed on me, suddenly "the wrong" page shows up and i get even more nervous and i press again and "randomly" sometimes it goes backward and sometimes forward...

It's not an experience i would want to suffer myself.

I totally agree that presentations are stressful enough. But we can't use this observation to preclude any possible user interface changes to presentation mode. That can't be right.

Idea: swiping back and forwards might be better, especially if you can touch or swipe to go forward, but to go back you need to swipe. That would make it hard to accidentally go back.

aacid added a comment.Tue, Jan 8, 9:41 PM

I totally agree that presentations are stressful enough. But we can't use this observation to preclude any possible user interface changes to presentation mode. That can't be right.

Idea: swiping back and forwards might be better, especially if you can touch or swipe to go forward, but to go back you need to swipe. That would make it hard to accidentally go back.

Swiping is already implemented.

sander added a comment.Tue, Jan 8, 9:42 PM

Changing pages by swiping on a touchscreen works already (Qt requires you to swipe with three(!) fingers, though). But if I were a piano player using Okular to show me the music sheets I'd rather not swipe for fear of smashing the entire screen off the piano.

Qt requires you to swipe with three(!) fingers, though

Oh, no wonder I never discovered it. Anything other than single-finger swipe is pretty useless and non-discoverable IMO.

That's the standard Qt swipe gesture. Anything else would require writing your own gesture recognizer.

Well, a single-finger swipe is the same thing as a click-and-drag when the input device is a touchscreen rather than a mouse or touchpad. If we have the ability to see that information, then single-finger swipe wouldn't be so hard, right?

The problem is that three-finger swipe is totally nonstandard and nobody would even think to try it, so it's practically pointless.

Anyway, not trying to hijack your patch. It just occurred to me that a single-finger swipe for navigation would perhaps obviate the need for this. Either way, I'm supportive of this patch, perhaps with some UI improvements like a full-screen message explain that you can click or tap on the sides of the page to control the navigation that displays for a few seconds the first time you enter presentation mode after this lands.

sander added a comment.Wed, Jan 9, 5:38 AM

Actually, the necessary gesture recognizer exists, as part of a GwenView patch: https://phabricator.kde.org/D13901 . If that code was accessible from Okular, moving to one-finger swipes would be trivial.

I'd also prefer to leave the current behaviour of a left-click as it is, regardless of the exact position. That is also in line with what e.g. LibreOffice Impress does. Allowing to go back by doing a single-finger swipe sounds great.

I'd also prefer to leave the current behaviour of a left-click as it is

Do you speak for both mouse clicks and touch screen 'clicks'? Because the original wish is really only about touch screens, and the effects of this patch on mouse clicks was at least partially caused by my laziness (it's currently easier to treat them both the same).

Do you speak for both mouse clicks and touch screen 'clicks'? Because the original wish is really only about touch screens, and the effects of this patch on mouse clicks was at least partially caused by my laziness (it's currently easier to treat them both the same).

My idea was that single-finger swipe might be an appropriate and better alternative after all, making a change in the single mouse click behaviour unnecessary, also for the touch screen case. In this case, I'd suggest to leave it "as is" for touch screens as well. However, I must admit I never actually used Okular on a touch screen device. What do you think?

I think that swiping is a separate issue. One-finger swipes should actually be easy to implement as the difficult part already exists in the Gwenview patch mentioned above. And we probably all agree that one-finger swipes are better than three-finger ones.

However, if I imagine myself sitting in front of a grand piano and having to switch pages very fast, I'd probably still want to touch rather than swipe.

OK, I understand. I don't have any strong opinion on this then.

I'd be terribly unhappy about this, i never look at where my mouse is when clicking in presentation view.

Perhaps a "pedal mode" for mouse and a pedal needs to be added. I think you do have a point as I believe the way page turning pedals for musicians are based on mouse clicks, and it's obvious that you can't orient the pointer with a pedal. I also see that if your are projecting you presentation on large screen it would be most convenient to just click back and forth using the left and right buttons. But for someone using a tablet style computer some form of accurate touch is mandatory. This particularly the case with pianists or other instrumentalists that really can't be fooling with a mouse, and need to be able to quickly reach up to the tablet and have certain page turns. Is it possible that the mouse buttons would work without needed to be oriented on a specific spot, but touch would related to one half of either side of the screen? Another issue would be that you don't want touch so generalized that the page would accidentally be turned by inadvertent touch. To conclude, I am an advocate of much better touch operation, but like everything else proper smooth implementation is critical. It would be best if it doesn't interfere with the way a mouse works now.

Swiping is already implemented.

On my machine I can only swipe forward, not backwards in presentation mode. The wheel is too small and inaccurate for quick, rapid, touch control. Swiping left and right would be a acceptable to me, but you need to be able to swipe the pages forward or backwards.

Changing pages by swiping on a touchscreen works already (Qt requires you to swipe with three(!) fingers, though). But if I were a piano player using Okular to show me the music sheets I'd rather not swipe for fear of smashing the entire screen off the piano.

For piano players they are mostly going forward so a simple touch anywhere on the screen moves the page forward. The problem is there needs to be a much better way of backing up a few pages. The wheel is good with a mouse, but not very good at all with just a finger. I see simple touching once on the left side of the screen as being the best most simple solution. What is really needed is to be able to do this with the finger, but not force this behavior on the mouse.

Qt requires you to swipe with three(!) fingers, though

Oh, no wonder I never discovered it. Anything other than single-finger swipe is pretty useless and non-discoverable IMO.

I just learned about it myself just now. I tested it. It's not too bad as the three fingers can be placed in a horizontal line. It works pretty well, but I think I would still prefer just a singe touch on the left side of the page. I think there just needs to a button for "pedal mode" which activates mouse clicks with a static mouse pointer position.

I'd also prefer to leave the current behaviour of a left-click as it is, regardless of the exact position. That is also in line with what e.g. LibreOffice Impress does. Allowing to go back by doing a single-finger swipe sounds great.

I agree with this 100 %. All I care about is easy touch navigation. Not any changes or extra requirements for mouse or pedal operation.

gbodley added a comment.EditedFri, Jan 11, 1:02 PM

I think that swiping is a separate issue. One-finger swipes should actually be easy to implement as the difficult part already exists in the Gwenview patch mentioned above. And we probably all agree that one-finger swipes are better than three-finger ones.

However, if I imagine myself sitting in front of a grand piano and having to switch pages very fast, I'd probably still want to touch rather than swipe.

I agree that a single touch on one side works best. It actually works perfectly now as long as you are going forward. The issue is wanting to turn back a page when you don't have a mouse, and only have your tablet and fingers. I just tested it again, and actually the three finger method of going backwards is not at all difficult and seems to work just fine. So maybe no changes are needed in the program at all, just a better understanding of how it works. That said I would still like to see the possibility of side by side page display in presentation mode. I do understand that's not the exact issue being addressed in this particular thread, but inasmuch as it turns out that touch is actually working pretty good, maybe attention and effort should be directed toward side by side page display in presentation mode.

If we can implement this for touch only, +1 on touching the left side to go back.

If we can implement this for touch only, +1 on touching the left side to go back.

I experimented a bit more with 3 finger swiping. While it works, it's not really great. To get the page to go back on, it seems you have to swipe slowly, and I'm not sure of the distance. It seems sluggish at times and nowhere as certain as the tap forward method. Clearly a single touch on the left side without affecting how the mouse functions at the present time would be best. It's interesting that swiping down from the top with a single finger brings out the menu' so there does seem to be the potential of single finger swiping.

It's interesting that swiping down from the top with a single finger brings out the menu' so there does seem to be the potential of single finger swiping.

No, that is simply triggered by moving the mouse/your finger on the top two rows of pixels.

sander updated this revision to Diff 49288.Fri, Jan 11, 8:04 PM
sander edited the summary of this revision. (Show Details)
sander edited the test plan for this revision. (Show Details)

New patch version:

  • You can go back by touching on the left half of a touchscreen, touching the right half will go forward
  • Mouse behavior is unchanged---left-clicking anywhere on the screen will go forward.
ngraham accepted this revision.Fri, Jan 11, 8:22 PM

Lovely. Tested with my convertible laptop and it works correctly for both the click and touch use cases. Code looks sensible to me as well.

This revision is now accepted and ready to land.Fri, Jan 11, 8:22 PM
aacid added a comment.Fri, Jan 11, 8:45 PM

I still object to this, you're changing the default behaviour of the software for the 0.03% of users that use okular to play in a touch screen while playing the piano.

The change is an improvement: Right now when using a touchscreen for presentation mode there is no way to go back. Since this doesn't affect the mouse use case at all, I don't understand the problem here.

aacid added a comment.Fri, Jan 11, 8:56 PM

The change is an improvement: Right now when using a touchscreen for presentation mode there is no way to go back. Since this doesn't affect the mouse use case at all, I don't understand the problem here.

That is not true as already discussed, you can swipe back.

I already explained how changing the behaviour of presentation mode to accommodate a very narrow use case doesn't seem the best of the ideas to me, we're nice people so adding an option in the config dialog for that narrow use case would be the ideal solution IMHO.

Of course when i said "i object" i mean "i disagree", I'm not the maintainer so I can't object.

The change is an improvement: Right now when using a touchscreen for presentation mode there is no way to go back. Since this doesn't affect the mouse use case at all, I don't understand the problem here.

That is not true as already discussed, you can swipe back.

Oh right, I forgot about the three finger swipe backwards because it't non-discoverable and awkward and therefore in practice fairly useless. :(

I already explained how changing the behaviour of presentation mode to accommodate a very narrow use case doesn't seem the best of the ideas to me, we're nice people so adding an option in the config dialog for that narrow use case would be the ideal solution IMHO.

I'm okay with that.

I still object to this, you're changing the default behaviour of the software for the 0.03% of users that use okular to play in a touch screen while playing the piano.

As a starter, I'd like to know where you developed the data that this only affects .03% of the users. I could make the same claim that only some very small number of users don't look at the computer screen when giving a presentation or get nervous during the presentation. It's obvious that only a few people are skilled enough to play the piano in the first place. Whether or not it's a small number is not a reason to cripple the software. It should be equally obvious that better software is designed to meet a variety of needs in various situations. I translate French books. Probably only a small number of people do that. Does that mean Libreoffice should drop the ability to handle multiple languages in the same document? Since the behavior of the mouse clicks is unchanged it seems like you are in no way adversely affected. It's not an arguable point or even worthy of valid discussion. It seems to be a problem for some that has been addressed, and that's a very good thing. It makes the software infinitely more useful from my perspective.

The change is an improvement: Right now when using a touchscreen for presentation mode there is no way to go back. Since this doesn't affect the mouse use case at all, I don't understand the problem here.

That is not true as already discussed, you can swipe back.

**Oh right, I forgot about the three finger swipe backwards because it't non-discoverable and awkward and therefore in practice fairly useless. :(

I thought the 3 fingered swipe back might be a solution. It sort of works, but honestly it's not ideal. It seems slow and sluggish, and it times it doesn't seem to work. When it does work, it requires careful deliberate and not too quick movement of the fingers on the screen. People are able to become skilled at various magic tricks over time, but the best software is intuitive and logical. The user interface has always been one of the most difficult issues to address. If it wasn't, we would all be using a terminal, and would have no need for a GUI interface or touch screen at all. The fact is tablet style touch screen computers are the immediate future. After that, it's much better voice control, and perhaps retina mouse tracking and movement. Maybe a quick movement of the head to the right or the left could result in a page turn.

aacid added a comment.Sat, Jan 12, 5:28 PM

I still object to this, you're changing the default behaviour of the software for the 0.03% of users that use okular to play in a touch screen while playing the piano.

As a starter, I'd like to know where you developed the data that this only affects .03% of the users.

I made it up, i thought it was obvious.

I could make the same claim that only some very small number of users don't look at the computer screen when giving a presentation or get nervous during the presentation.

You could make the same claim, but it would be a stupid comparison to make, so let's pretend you did not make it.

It's obvious that only a few people are skilled enough to play the piano in the first place.

So ? congratulations ?

Whether or not it's a small number is not a reason to cripple the software.

We're not crippling anything

It should be equally obvious that better software is designed to meet a variety of needs in various situations.

Yes, that's what options are for.

I translate French books. Probably only a small number of people do that. Does that mean Libreoffice should drop the ability to handle multiple languages in the same document?

Useless comparison.

Since the behavior of the mouse clicks is unchanged it seems like you are in no way adversely affected.

As the person that has been working on this software for more than 15 years, any decision that changes the default behaviour is going to affect me, because when people get angry because we have changed (broken for them) how the software works, they will come to me complaining (like you are doing now)

It's not an arguable point or even worthy of valid discussion. It seems to be a problem for some that has been addressed, and that's a very good thing. It makes the software infinitely more useful from my perspective.

Yes, you are an user, you can only see your bug, it's the most important thing ever for you, which makes you biased.

I still object to this, you're changing the default behaviour of the software for the 0.03% of users that use okular to play in a touch screen while playing the piano.

As the person that has been working on this software for more than 15 years, any decision that changes the default behaviour is going to affect me, because when people get angry because we have changed (broken for them) how the software works, they will come to me complaining (like you are doing now)

Yes, you are an user, you can only see your bug, it's the most important thing ever for you, which makes you biased.

If you have been working on this project for 15 years, I congratulate you. I tested every Linux PDF reader I could find and believe Okular is head and shoulders above the rest. And you are 100% correct that this "feature enhancement" is extremely important to me. And at the same time I do not wish anyone to be adversely affected by the change. Changes that break the software are obviously not a good thing. If it has been of some effort for you to make this change, I'm deeply grateful.

Guys, stop fighting. I'll make it optional in the next patch upload, all I need is a bit of time.

Guys, stop fighting. I'll make it optional in the next patch upload, all I need is a bit of time.

Please make it so that once you click the box, it stays locked in through relaunches until you uncheck it.