search

kiwix / kiwix-desktop

Kiwix for Windows and GNU/Linux desktops
https://download.kiwix.org/release/kiwix-desktop/
GNU General Public License v3.0
762 stars 101 forks source link

What is the strategy to deal with high density screens #157

Closed kelson42 closed 1 month ago

kelson42 commented 5 years ago

How do you secure that the application layout is displayed properly on high density screens on Windows & Linux?

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

alex-ie commented 3 years ago

I have a laptop with 3K screen, I do not currently see issues. What did you mean?

kelson42 commented 3 years ago

@alex-ie would you be able to make a screenshot?

alex-ie commented 3 years ago

kiwix @kelson42 Now I see an issue, I did not think of it as related to high density. When many tabs are open, buttons on the right to move them left-right are small. They were small (upper window) but on nightly build (lower window) they became tiny and very hard to locate with pointer and click. Maybe you will see others.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

kelson42 commented 5 months ago

@ShaopengLin Are these arrows handled by Kiwix or Qt?

ShaopengLin commented 5 months ago

@kelson42 This is handled by Qt, but we can modify the stylesheet for it. I will look into it.

ShaopengLin commented 5 months ago

@kelson42 From what I saw, the button isn't well supported as it is more of a native feature. Most browsers do not have something like this. A small improvement on it was made to resolve the buttons being transparent, but from what I tried in 6.7.0 it is still barely usable in high resolution.

If we are sure we need the scroller buttons, I would suggest a refactor to separate the tab bar and the scroller buttons.

kelson42 commented 5 months ago

If we are sure we need the scroller buttons, I would suggest a refactor to separate the tab bar and the scroller buttons.

I believe we must have these buttons as I don't no any other way to navigate in the tabs. Do you know an other one?

If we can replace these ugly buttons with a proper one appearing left and right of the tabs when necessary, that sounds to me a good plan.

ShaopengLin commented 5 months ago

@kelson42 Yep I think a refactor will be the way to go.

You can scroll without buttons with a touch pad but not everyone has that.

ShaopengLin commented 4 months ago

@veloman-yunkan @kelson42 I confirm we can do our own scroll buttons. There are two approaches and issues that come with both:

  1. Scroll has the same behavior. This will need us to connect click signals to the right and left-click tool buttons that can only be found by explicitly looping through the children of QTabBar. By forwarding the clicked signal, a scroll can be triggered.

    • I don't recommend this as it depends on Qt source code behavior, but at least from what I can see in the Qt5/6 source files, we can still find and distinguish them consistently. See qtabbar.cpp: void QTabBarPrivate::init() for what I mean.

  2. We scroll through the tabs by moving to the next and previous tabs. This is straightforward but doesn't keep the previous scroll behavior. User can also do this on their own with Ctrl + Tab and Ctrl + Shift + Tab, though not everyone prefers shortcuts.

You can see the video below on the two different behaviors:

https://github.com/kiwix/kiwix-desktop/assets/39098000/39c9a167-b5ac-4daf-a7a1-6f567aee356f

What are your opinions on which one we should go with?

ShaopengLin commented 1 month ago

@veloman-yunkan @kelson42 Could you take a look at the above comment and potentially greenlight one of the above approaches? Would want to start the design in parallel as it is the last two TODOs to be realized.

veloman-yunkan commented 1 month ago

Sorry for the late reaction only after you had to proceed with a PR without receiving any feedback.

  1. Scroll has the same behavior. This will need us to connect click signals to the right and left-click tool buttons that can only be found by explicitly looping through the children of QTabBar. By forwarding the clicked signal, a scroll can be triggered.

Can't you just call QTabBar::scroll()?