Skip to content

Revert "UI: make the layout scrollable when there are many buttons"#18

Open
orivej wants to merge 1 commit intopanzi:masterfrom
orivej:scroll
Open

Revert "UI: make the layout scrollable when there are many buttons"#18
orivej wants to merge 1 commit intopanzi:masterfrom
orivej:scroll

Conversation

@orivej
Copy link
Copy Markdown
Contributor

@orivej orivej commented Dec 31, 2017

This reverts commit 0957dc3.

The scroll area adds ugly scroll bars to the button configuration part of the dialog. Here is how it looks after start:
qjoypad

This reverts commit 0957dc3.

The scroll area adds ugly scroll bars to the button configuration part of the dialog.
@hydrargyrum
Copy link
Copy Markdown
Contributor

hydrargyrum commented Jul 15, 2018

As the author of the commit you want to revert, I'll explain the rationale: when there are many buttons, without scrollbars, it's even uglier than what you show. It can even be completely unusable, if the window is higher than screen resolution. Those scrollbars are here for a good reason.
Of course the behavior can certainly be improved, for example using more than 2 rows, or by not showing scrollbars at all when there are not enough buttons. But simply reverting the change is not improving anything. It will reinstate a bug that was worse than just cosmetic and was already fixed years ago. It's simply not constructive.

@orivej
Copy link
Copy Markdown
Contributor Author

orivej commented Jul 15, 2018

when there are many buttons, without scrollbars, it's even uglier than what you show

How can it be worse (unless the window is higher than the screen)?

It can even be completely unusable, if the window is higher than screen resolution.

I expect that in almost all cases the window fits on the screen. Using the proportions of this screenshot (45 px per row and 300 px for the rest, including decorations), 30 axes+buttons fit on a 1000p screen. If a window does overflow, it can still be panned to access the hidden areas. (In Plasma, with Alt+mouse drag.)

But simply reverting the change is not improving anything.

I think that qjoypad is better without that change, not only for me but also in general. If the issue of the overflowing window has to be fixed, it should be fixed without sacrificing the look in the common case.

@hydrargyrum
Copy link
Copy Markdown
Contributor

I expect that in almost all cases the window fits on the screen. Using the proportions of this screenshot (45 px per row and 300 px for the rest, including decorations), 30 axes+buttons fit on a 1000p screen.

Just as an example, my system detects one of my joypads improperly, with too many buttons. Without the scrollbars, here's what it looks like (real joypad): 2018-07-16-083637_440x1079_scrot

If a window does overflow, it can still be panned to access the hidden areas. (In Plasma, with Alt+mouse drag.)

You're overly optimistic, only a very very small fraction of users know this shortcut. And if the window is too high, it's clearly a UI problem, the app should be fixed.

I think that qjoypad is better without that change, not only for me but also in general. If the issue of the overflowing window has to be fixed, it should be fixed without sacrificing the look in the common case.

You could remove the scrollbars AND replace them with another fix. But you don't fix it at all, so you just add a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants