Bug 419377

Yeah, Kate and Gwenview have this. Okular probably should too. I can look into it.

*** Bug 427457 has been marked as a duplicate of this bug. ***

Hi! To help clarify the scope of this report before working on a fix:

When you mention “fullscreen”, do you mean Okular’s regular Full Screen Mode (View -> Full Screen), or Presentation Mode?

Also, for touch-only / tablet use, is the expectation to have a clearly visible on-screen way to exit fullscreen, or is another interaction (e.g. gesture / long press) preferred?

I’m new to Okular / KDE and interested in taking a look at this, so I just want to make sure I understand the intended behavior before starting.

Hi Tanvir,

It's a good thing that you mentioned presentation mode: I just tried that and the issue does not affect presentation mode in the same way. In presentation mode, one can touch the upper screen edge and a toolbar appears that can be used to exit presentation mode. This is not very discoverable, but having an always-visible UI element would not work well for presentations and there is an explanation text when entering presentation mode. So I guess that works well enough.

I meant the regular full screen mode. My expectation would be to have an easily discoverable on-screen way to exit fullscreen, not a gesture.
Discoverable could mean either always visible, or maybe hidden unless there is a touch event.

I meant the normal fullscreen mode. It is possible to exit the presentation mode, but not the normal fullscreen mode. I am not sure about what would be the best way to realise this. In any way, it should not distract from reading. So either a small constantly visible button or one that is activated by a gesture. Maybe pulling down from the top could slide down something.

I guess you can't right click?

No, I can't right-click.
My tablet unfortunately can't tell my fingers apart ;-)

I agree for the need to exit "full screen" mode with a gesture or long press menu or swipe to a particular side, etc.  Doesn't need to be something always visiable.  Commentary - I'm a musician and use Okular as my sheet music viewer on a 2-in-1 flip laptop.  I bought a 1-button bluetooth keyboard that when pressed just transmits ctrl-Q so i can exit out.  Then bought a 3-button for page up, page down, and quit...

Thanks for the clarification, that helps a lot!

Based on this, I’m planning to try adding a small, discoverable on-screen exit control for regular Full Screen Mode. The idea would be a lightweight overlay in the top-right containing an “Exit Full Screen” action (icon button with tooltip / accessible name), which auto-hides to stay unobtrusive.

It would appear when the cursor approaches the top edge on desktop, and also on user interaction events (e.g. touch begin) so it remains discoverable on touch devices where hover or right-click may not exist.

I’ll start with a minimal implementation and report back with a draft MR.

I’ve opened a draft MR for this here: https://invent.kde.org/graphics/okular/-/merge_requests/1305

This is an initial implementation and likely needs some polish; feedback or guidance would be very welcome, and I’m happy to adjust the approach if needed.

Sunil Kumar, don't assign bugs to yourself.

(In reply to Albert Astals Cid from comment #11)
> Sunil Kumar, don't assign bugs to yourself.

I am extremely sorry about that. I am a KDE person but new to this Bug tracking System. I thought it would make a request to be approved; I thought it is there to show interest in being a volunteer to solve it.
I will take care of it next time.
Also, curious to know, if one can start working to a bug fix, if it is not assigned to them yet.

You thought to start working on it *AFTER* someone else said they were working on this?

(In reply to Albert Astals Cid from comment #13)
> You thought to start working on it *AFTER* someone else said they were
> working on this?

Nah, there was a misunderstanding, As I said in the last comment, this is my first time using BugTracking System. I saw the large comment box to add comment, I thought it's the end of the page, and I missed that there are discussions at the end. And started working on the solution, then saw your comment in my mailbox and came to know that there is discussion at the bottom,

Btw, during that time, I prepared the solution, and I'm happy to share if @Tanvir Leon wants to adapt that or wants me to implement it if needed, I have attached a video showing how final output should look like in the Attachments Section. Hope that isn't restricted to do.
Again, I apologize, I think, I should have been more careful at the first time.

Created attachment 188729 [details]
Showing final output after the implementation of Zoom in/Out Button UI.

Any suggestions are welcomed.

I like Tanvir's idea of something appearing say after an inital press somewhere, a button appears in a corner that when pressed exits.  OR maybe a little scope creep, but a whole pop-up menu appears after an inital tap that presents "exit full screen" (like esc), "quit app" (like ctrl q), "page up", "page down", "top", "bottom", then autohides after a time, and after a button is pressed it stays for 2 seconds so you could press page up or page down multiple times before the menu disappears.  (That would certainly meet my personal needs for sheet music viewing).  Yes, I'm a UX designer but only a C/C++, Python, Java developer.

I did review the video from Sunil and that solution would meet the basic needs.  It does create a static blocking on the screen of the arrows.  Maybe if they were outlines they would be less intrusive, or translucent.

Not sure who is going to ultimatley address this feature request but those are my thoughts for a touch pop-up menu.

*** Bug 472185 has been marked as a duplicate of this bug. ***