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

Support HiDPI screens #11

Closed
tillkamppeter opened this issue Oct 28, 2018 · 4 comments
Closed

Support HiDPI screens #11

tillkamppeter opened this issue Oct 28, 2018 · 4 comments
Assignees
Labels
enhancement New feature or request platform issue Issue is specific to an OS or desktop priority-medium

Comments

@tillkamppeter
Copy link

I have a QHD screen (2560x1440) and many users have even higher (4K and more) screen resolution.
The GUI of rasterview seems to use a hard-coded pixel count (or DPI) for menu font sizes, buttons, ... So these GUI elements get tiny on high-resolution screens.
Can this get fixed by using the actual DPI of the screen? Many GUIs, like GTK for example, do this and so one has useful GUI element sizes on any screen resolution.

@michaelrsweet
Copy link
Owner

RasterView uses FLTK, and at the moment it doesn't support any notion of hi-dpi/high-resolution displays. Ideally this should come from Cairo (which FLTK uses under the covers on Linux), but it likewise does not directly support the GNOME/KDE notion of identifying a screen as needing scaling.

Not sure what I'll do here, but I do know I won't be rewriting RasterView to use the various native UI toolkits - it just isn't that important.

@michaelrsweet michaelrsweet self-assigned this Oct 29, 2018
@michaelrsweet michaelrsweet added the enhancement New feature or request label Oct 29, 2018
@michaelrsweet
Copy link
Owner

Looks like FLTK 1.4 will end up with HiDPI support - will probably need to wait a bit for that to become available but maybe I can host a snapshot for the snap build bot...

@michaelrsweet michaelrsweet added platform issue Issue is specific to an OS or desktop priority-medium labels Jan 20, 2021
@michaelrsweet
Copy link
Owner

Trying this now - hopefully the snap, built against last week's FLTK 1.4 weekly snapshot, will do the trick...

@tillkamppeter
Copy link
Author

It is working now, thank you very much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request platform issue Issue is specific to an OS or desktop priority-medium
Projects
None yet
Development

No branches or pull requests

2 participants