Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Puavomenu lowres support #687

Merged
merged 9 commits into from
May 28, 2024
Merged

Puavomenu lowres support #687

merged 9 commits into from
May 28, 2024

Conversation

tuomasjjrasanen
Copy link
Contributor

@tuomasjjrasanen tuomasjjrasanen commented May 4, 2024

This PR consists of different logical parts:

  • The first commit just reformats the whole codebase to get consistent formatting (black).
  • Commits 2-6 refactor the codebase to make semantic changes easier to make. They do not introduce changes to UX.
  • The 7th commit is the beef: it replaces the constant dimensioning with resolution-based "dynamic" dimensioning: puavomenu selects optimal dimensions based on the display resolution during startup.
  • The 8th commit makes puavomenu relaunch itself when resolution is changed. Resolution changes are quite expected and this makes puavomenu react to them appropriately.
  • The final 9th commit is just a bonus: make puavomenu exit with non-zero status in abnormal exits

Because the first commit touches all Python files, I strongly recommend to review this PR commit by commit.

@tuomasjjrasanen tuomasjjrasanen self-assigned this May 4, 2024
@tuomasjjrasanen tuomasjjrasanen linked an issue May 4, 2024 that may be closed by this pull request
Because consistency is key to good quality. And why black? Because we
already have it installed in our images, it does very good job out of
the box and it's easy to integrate to any editor/ide/whatnot.

Just:
```
black .
```
…lays

lowres  = <1280x800
highres = >=1280x800

1280x800 seemed to be pretty good divider resolution. Height is the
more important dimension. I tested with 864x486 and low res dims still
allowed puavomenu to fit the screen.

I could have squeezed the horizontal dimension too, for example by
decreaseing the number of program cols from 4 to 3, but because 4 cols
is the "standard" and 4 cols still fit 800x600, I left it alone to
keep to UX pretty much the same as with high res dimensions.
Because resolution changes are quite common. But why this is handled
in `launch` command? Because it's the safest and easiest way to ensure
EVERYTHING get's re-initialized correctly with new dimensions in both
dev and prod modes. New runtime, new everything.

Quitting and restarting Gtk main loop does not give good results. And
destroying the existing PuavoMenu and creating a new one when
resolution is changed did not seem a safe option either. And
dynamically changing dims is definitely not a good idea, the whole
reason why we have these semi-static dimensions is that we create
everything once based on the common set and then just live with it.

So, restarting the whole runtime seemed the best option.
Because non-zero exit status for abnormal exits is a good thing.
@tuomasjjrasanen
Copy link
Contributor Author

@jarmopi @juhaerk Please review.

@juhaerk juhaerk merged commit 4ae82b2 into bookworm May 28, 2024
@juhaerk juhaerk deleted the puavomenu_lowres_support branch May 28, 2024 07:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Puavomenu scaling on low resolutions
2 participants