hotspot
hotspot copied to clipboard
KDAB
The welcome message and brand text renders over content when the "Loading Results..." window is 1/8 of total display resolution (at 100% scale).
Describe the bug
The welcome message and brand text renders over content when the "Loading Results..." window is 1/8 of total display resolution (at 100% scale).
To Reproduce
Resize to 1/8 of 2560 × 1440 px at 100% scale.
Expected behavior
It should disappear or reduce to 1em.
Screenshots
Version Info:
-
Linux Kernel version:
kernel-6.14.3-300.fc42.x86_64:Name : kernel Epoch : 0 Version : 6.14.3 Release : 300.fc42 Architecture : x86_64 Installed size : 0.0 B Source : kernel-6.14.3-300.fc42.src.rpm From repository : <unknown> Vendor : Fedora Project -
perfversion:perf-6.14.3-300.fc42.x86_64:Name : perf Epoch : 0 Version : 6.14.3 Release : 300.fc42 Architecture : x86_64 Installed size : 10.8 MiB Source : kernel-6.14.3-300.fc42.src.rpm From repository : updates Vendor : Fedora Project -
hotspotversion:(appimage? selfcompiled?)
The
hotspot-1.5.1-5.fc42.x86_64RPM:Name : hotspot Epoch : 0 Version : 1.5.1 Release : 5.fc42 Architecture : x86_64 Installed size : 2.3 MiB Source : hotspot-1.5.1-5.fc42.src.rpm From repository : updates Vendor : Fedora Project
I cannot reproduce this, here's a screenshot of the window at its smallest scale for me:
that said, probably we could hide the background info when loading results. but is this issue only affecting that page for you? how does the welcome screen look like for you? it's probably totally broken too then?
I cannot reproduce this
@milianw, that's probably because of your typeface configuration DE-wide. If using KDE Plasma, if you set kcm_fonts to the undermentioned preferences, I presume that this shall reproduce:
In this case, fc-match monospace returns google-noto-sans-mono-fonts-20250301-1.fc42.noarch.
how does the welcome screen look like for you? it's probably totally broken too then?
It's acceptable at 1⁄4 of 2560 × 1440 px:
However, the text is cut-off (and doesn't wrap, nor render a QScrollBar when at 1⁄8:
my font settings are close, but I'm on a 4k screen with 2x scaling. but even when I set the scaling to 1x then I cannot reduce the window size as much as you can. what are the window sizes you can get? maybe we should just enforce a minimum height/width that works...
maybe we should just enforce a minimum height/width that works...
@milianw, that would probably be a terrible idea, since on low-DPI displays (tablets or small laptops), it would cause windows to either display outside of the viewport on window managers which fail that way, or cause the window manager to ignore the restriction.
GUIs in 2025 should, ideally, adapt to all feasible form-factors.
I cannot reduce the window size as much as you can. what are the window sizes you can get?
@milianw, if I resize using the window decorations' handles, I can resize it to:
Consequently, perhaps you've already set some, or Qt does implicitly?
However, if I utilise Meta + T:
...I can get it to:
That's 382 × 213 px. If not for the text, it would render at even that size correctly.
try setting the text in pixels instead of points, they will still get scaled automatically by Qt's dpr stuff, and imho works better.
iiuc, only in the old days window-managers would control scaling via the font dpi
so it seems like your window manager allows you to resize below the minimum size? what is meta + T even doing on gnome?
oh and regarding the min size: if we set a min size of say 600x400 or similar then it would still work in most places... I don't care too much about people trying to use this app on tiny screens to be frank
What is Meta + T even doing on GNOME?
@milianw, dunno... I'm using cpe:/a:kde:plasma. (How does GNOME relate to this?)
Your window manager allows you to resize below the minimum size?
It appears to be kwin-wayland-6.3.4-3.fc42's default behaviour.
I don't care too much about people trying to use this app on tiny screens.
If you ensure that every screen either creates QScrollBars or reflows its text when resized, you shan't need to care what display they're using. It's solely because the design is static that you're forced to.
ah, my bad - your screenshots didn't look like kde to me. I really wonder how you manage to make the window so tiny then, doesn't work for me on kwin, even with wayland.
anyhow, patches welcome to improve this corner case :)
I really wonder how you manage to make the window so tiny then, doesn't work for me on kwin, even with wayland.
@milianw, I shan't be surprised if it's a fault of KWin's, which doesn't appear unless the user is on a low-DPI display. If you're willing, if you set your monitor's resolution to 2560 x 1440 (and the same in kcm_kscreen), then set your display scale to 100%, are you then able to?
anyhow, patches welcome to improve this corner case :)
I can do Python, but I can't do CPP (yet). :(
No, even at 1600x800 the window gets a sane minimum size automatically and doesn't allow me to shrink it as absurdly as you seem to be able to.
Maybe a bug with the AppImage, if you are using that? Can you try a distro package instead with proper wayland support?
No, even at 1600x800 the window gets a sane minimum size automatically and doesn't allow me to shrink it as absurdly as you seem to be able to.
@milianw, in case it's of use, I've recorded a screencast of how I achieve it:
https://github.com/user-attachments/assets/283b53bc-a4a9-4acb-be39-f1a902cb316e
Maybe a bug with the AppImage, if you are using that? Can you try a distro package instead with proper wayland support?
I'm using the RPM (per the original report):
Installed packages Name : hotspot Epoch : 0 Version : 1.5.1 Release : 5.fc42 Architecture : x86_64 Installed size : 2.3 MiB Source : hotspot-1.5.1-5.fc42.src.rpm From repository : updates URL : https://github.com/KDAB/hotspot Vendor : Fedora Project