Closed kelson42 closed 1 month 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.
I have a laptop with 3K screen, I do not currently see issues. What did you mean?
@alex-ie would you be able to make a screenshot?
@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.
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.
@ShaopengLin Are these arrows handled by Kiwix or Qt?
@kelson42 This is handled by Qt, but we can modify the stylesheet for it. I will look into it.
@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.
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.
@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.
@veloman-yunkan @kelson42 I confirm we can do our own scroll buttons. There are two approaches and issues that come with both:
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.
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?
@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.
Sorry for the late reaction only after you had to proceed with a PR without receiving any feedback.
- 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()
?
How do you secure that the application layout is displayed properly on high density screens on Windows & Linux?