Created attachment 109214 [details] Screenshot example BEHAVIOR The 4k scaling for gtk3 apps on GNOME (naturally) doesn't take effect in Kdenlive after opening the program: icons, text, widget buttons, and menus are all scalled down considerably in the interface. EXPECTED BEHAVIOR That's tough, since I'm sure Kdenlive uses some KDE scaling setting in HiDPI cases. But expected behavior would be that the icons, text, widget buttons, etc would be appropriately scaled, whether that be an in-program scaling parameter in "Configure Kdenlive", or it scales based off of screen resolution, etc. BUG DISCOVERED USING Kdenlive (timeline refactoring) alpha6 Appimage Ubuntu 17.10 GNOME shell 3.26.1 Nvidia GTX 1080 graphics Nvidia 384.90 proprietary drivers Linux kernel 4.13.0-17-generic 4k Acer monitor, screen resolution 3840x2160
Try QT_AUTO_SCREEN_SCALE_FACTOR=1 as a workaround. This works for me.
Created attachment 109394 [details] Update on 17.12: some of the icons are scaling properly, while others (like the timeline preview) aren't. This is an update. The 17.12 Appimage release does appear to fix this issue, in part. Some of the icons like the Clip/Project monitors are showing properly.
(In reply to Peter Eszlari from comment #1) > Try QT_AUTO_SCREEN_SCALE_FACTOR=1 as a workaround. This works for me. I tried running the following command in a terminal: kdenlive QT_AUTO_SCREEN_SCALE_FACTOR=1 Unfortunately, it didn't fix the issue.
Created attachment 109404 [details] Example 2 - Kdenlive 18.04 alpha 2 Appimage 4k scaling problems What is scaling properly: - Monitor playback controls & buttons. - Buttons at the top of the Effects, Transitions, Effects, and Library widgets. What isn't scaling properly: - Everything else. (e.g. tab text, all other icons/buttons, ALL text inside timeline widget, icons in main toolbar, timeline ruler in Clip & Project Monitors, monitor overlay elements like fps, audio meter)
What is the output of: $ xdpyinfo | grep resolution I think setting QT_AUTO_SCREEN_SCALE_FACTOR only helps, when you set your screen DPI. (e.g. "192") The following should work (tested with the offical AppImage under Gnome): $ QT_SCREEN_SCALE_FACTORS=2 ./kdenlive-17.12-x86_64.AppImage
(In reply to Jesse from comment #3) > kdenlive QT_AUTO_SCREEN_SCALE_FACTOR=1 In a shell, you set environment variables before executing the command: QT_AUTO_SCREEN_SCALE_FACTOR=1 kdenlive
(In reply to Peter Eszlari from comment #5) > What is the output of: > > $ xdpyinfo | grep resolution > > I think setting QT_AUTO_SCREEN_SCALE_FACTOR only helps, when you set your > screen DPI. (e.g. "192") > > The following should work (tested with the offical AppImage under Gnome): > > $ QT_SCREEN_SCALE_FACTORS=2 ./kdenlive-17.12-x86_64.AppImage The output from the command you requested is this: resolution: 96x96 dots per inch
Created attachment 111346 [details] Screenshot example of issue on Kdenlive 18.08 beta0 appimage All of the red highlighted areas are the ones that I can see that aren't scaling properly on 4k UHD monitors running non-KDE desktop environments.
(In reply to Peter Eszlari from comment #5) > What is the output of: > > $ xdpyinfo | grep resolution > > I think setting QT_AUTO_SCREEN_SCALE_FACTOR only helps, when you set your > screen DPI. (e.g. "192") > > The following should work (tested with the offical AppImage under Gnome): > > $ QT_SCREEN_SCALE_FACTORS=2 ./kdenlive-17.12-x86_64.AppImage I ran the command you suggested to set QT_SCREEN_SCALE_FACTORS, and it looks like this fixed the will (with attach a screenshot in a following comment). Now the question is: how can this be implemented in Kdenlive so it does this by default on 4k UHD screen resolutions?
Created attachment 111350 [details] Screenshot of fixed ui after setting enviroment variable Following Peter's suggestions in comment #5 and setting the environment variable before running ("$ QT_SCREEN_SCALE_FACTORS=2 ./kdenlive-18.08-beta0.AppImage"), everything appears to be scaled appropriately.
Thanks for your report! Can you please check if this report is still relevant?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!