Lovely! Probably CCBUG: 346979

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

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.

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

In D18118#389500, @sander wrote:

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.

In D18118#389511, @ngraham wrote:

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.

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.

In D18118#389517, @sander wrote:

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.

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).

In D18118#391100, @sander wrote:

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.

In D18118#389490, @aacid wrote:

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.

In D18118#389517, @sander wrote:

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.

In D18118#389518, @ngraham wrote:

In D18118#389517, @sander wrote:

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.

In D18118#391065, @michaelweghorn wrote:

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.

In D18118#391119, @sander wrote:

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.

In D18118#391388, @ngraham wrote:

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.

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.

In D18118#391654, @ngraham wrote:

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.

In D18118#391655, @aacid wrote:

In D18118#391654, @ngraham wrote:

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.

In D18118#391651, @aacid wrote:

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.

In D18118#391667, @ngraham wrote:

In D18118#391655, @aacid wrote:

In D18118#391654, @ngraham wrote:

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.

In D18118#391950, @gbodley wrote:

In D18118#391651, @aacid wrote:

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.

In D18118#392035, @aacid wrote:

In D18118#391950, @gbodley wrote:

In D18118#391651, @aacid wrote:

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.

In D18118#392071, @sander wrote:

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.

UI-wise, here's what I might recommend:

Touchscreen: [ ] Tap left side to go to previous page
             [ ] Tap right side to go to next page

That way we have all the same functionality, but the labels explain how to use the feature, too.

Not sure I fully understand your proposal. What happens if I uncheck the first option, check the second one, and then tap on the left half of the screen?

Nothing happens.

I'm kind of wondering why we need to enable them separately in the first place though. Couldn't we just have a single checkbox that enables and disables both?

If I understand Albert correctly he wants to have the current behavior as an option. Your proposal does not offer that, does it?

Oh, I think I see what you mean now. How about this, then?

Touch navigation: ( ) Tap left/right sides to go back/forward
                  (0) Tap anywhere to go forward
                  ( ) Disabled

That's the current behavior, only with different UI text, right? That's fine with me. I will provide an updated patch within the next few days.

That's the current behavior, ...

Meaning: That is the current behavior *of the patch*, ...

In D18118#425420, @sander wrote:

That's the current behavior, only with different UI text, right? That's fine with me. I will provide an updated patch within the next few days.

Exactly!

What is the behavior of the mouse buttons? In other words can the left
mouse button make it go forward without being anywhere on the screen, and
the right button make if go backwards. I'm asking this because there are
programmable pedals for turning pages as well. I believe they are related
to left and right mouse button clicks. I don't have one though so I'm not
positive how they work, but one would think there is some kind of standard.

Whatever I have now moves it forward when touching the left or right.
side. I guess that's the way it's always been. The mouse works as I would
expect. I'm only interested in modifying the touch behavior. The mouse
works fine as it is now.

What is the behavior of the mouse buttons? In other words can the left mouse button make it go forward without being anywhere on the screen, and the right button make if go backwards.

Yes, doesn't that work for you?

The complete logic is in the method mousePressEvent in the file presentationwidget.cpp, if you care for the details.

Albert, is this okay for you now?

What is the exact language? I find the parenthesis to be an awkward
sentence structure. If that is the actual language in the tool-tip.
I would think something like "Tapping: Left half = previous page, Right
Half = following page
would suffice. or *Tapping: Left side = Previous, Right side = Subsequent*