Problem: In Spectacle, the arrows in the end of the input box of "Delay" can be used to increase or decrease the time in seconds. When clicking the up-arrow and the time changed from "1 second" to "2 seconds", the input box width increases and the arrows moves toward right a little. This makes the user having to move mouse cursor right in order to click up-arrow again. Steps to re-produce: - Run Spectacle - Click on the up-arrow till the time increases to "x seconds" (not "second"). Expected result: No need to move mouse cursor to increase the time to multiple seconds.
Are you using a non-standard font? I can't reproduce this with Spectacle from git master, but using the standard font. I also can't reproduce it using 13pt Ubuntu fontusing 17.08 Can you provide a screen recording in the .webm format? I like SimpleScreenRecorder for this purpose.
Created attachment 110125 [details] Screen recording of changing "Delay" in Spectacle under a non-standard DPI setting Thank you, Nate. (In reply to Nate Graham from comment #1) > Are you using a non-standard font? [...] > That might be the cause. I forced a non-standard (168) DPI but with display scaling set to "1" so the GUI and font in it may not being scaled proportionally. I am in a non-standard use case because I have an external display that has lower DPI. I need to find an acceptable balance between my laptop and this external screen. > Can you provide a screen recording in the .webm format? I like > SimpleScreenRecorder for this purpose. Attached.
Wow, weird. Thanks so much for the screen recording. That really helps. What's the font and point size?
(In reply to Nate Graham from comment #3) ... > What's the font and point size? Hi, Nate, thanks for you encouragement. I realised this is an edge case. Therefore, you may not want to fix it. I understand that's completely natural. I am using default settings from KDE on openSUSE, which are Noto Sans 10 for General, Hack 9 for Fixed width, Noto Sans 8 for Small and Noto Sans 10 for Toolbar, Menu and Window title respectively. The DPI is forced to 168. When I reduce it to 144, then this problem disappears. Both cases have scaling set to 1.
Ah. Yeah, our preference is to set the scaling value, and we're actively working on making this work better with multi-dpi-multi-monitor settings. I hope you don't mind if I close this pending those improvements so you don't need to manually set DPI values!
Of course I don't mind. Thank you for your time. I should've tested the settings before report it. I am looking forward to a better multi-dpi-multi-monitor support from KDE as well.