The UI is huge and zoomed in.
LMMS 1.2.0-rc8
Linux Mint 19.1 Cinnamon 64bit
1920x1080

Try this:
as root user create a file name it
gnome-qt.sh
and place it in the
/etc/profile.d directory
In this file type :
export QT_AUTO_SCREEN_SCALE_FACTOR=0
did it work?
Thank you for your assistance, but I believe Open Source needs to be held to a higher standard. I will only accept a new version of LMMS which resolves this issue.
@theluckyfellow The problem is most probably in your configuration, as most people with 1080p don't get this behavior.
But if you believe LMMS should be able to detect and fix this problem, you can contribute to this open-source project yourself, and raise the standard :)
rc7 did not have this issue. I doubt that it is a complicated fix for anyone knows the codebase. I have my own projects to work on. "Fix it yourself" is not the correct response. I am running a fairly standard install of a popular Linux OS.
I'm a highschool teacher. I teach all my students how to use LMMS. Shall I tell them to fix all their own bugs too? "Found a bug, kid? Report it?! Why would you ever do that? Fix it yourself, kid!"
"I will only accept a new version of LMMS which resolves this issue" is not the correct question.
The right way to do this is:
In the meantime, you can downgrade to RC7, which will work just fine, instead of coming here and ranting that open-source should have a higher standard. You've done your job for this bug, and you also got a way to fix it on your configuration. Don't like it? Use RC7.
Remember these are all beta versions.
Yes, that's what I'm doing. Thank you for your understanding of the situation. Maybe it is only an issue on my system. I'll have to wait and see. Also, you're right. I should not have replied to any of the comments. My apologies. Let's end this pointless discussion and let the bug fixing process proceed.
Hmm, I just had something very similar happen on Master after I upgraded from Debian Stretch to Debian Buster, which likely included a Qt5 upgrade:

It seems like Qt guesses or computes the screen DPI, uses it to scale all GUI elements, and then, on top of all that, it takes the system DPI setting and scales all fonts (and some other elements) once again, making them overly big. The funny thing is, when I drag the window to my secondary low DPI screen, it gets scaled down (making the fonts the correct size and all icons too small). So there must have been some changes to the default Qt settings -- it is obviously trying to use per-monitor aware DPI scaling and I am pretty sure this is the first time I saw it in action.
If I reduce the system DPI to 96 (my screen is about 180), the problem goes away and LMMS renders almost exactly the right size for my screen. Obviously that does not solve anything, since every other application is now unusable. Setting the auto screen scale factor to 0 does not help either: the window just gets smaller but the relative sizes remain messed up.
Have you also tried if this happens to other Qt applications?
I tried to look around and did not find any obvious problems in other applications. But I'm not even 100 % sure which of them are using Qt, so I may need to collect some more representative sample.
The ones that stand out are Qt5 Assistant and Qt5 Designer (didn't even know I had these installed) -- both exhibit the per-monitor scaling behavior and both seem somewhat large on my main (high DPI) screen. But all the GUI elements are scaled properly, the text is not too large compared to icons (as expected, these should be as close to the "reference implementation" as it gets).
The fact is is too large on my main screen seems to unrelated to the LMMS issue -- Qt is simply going from 1x scaling directly to 2x, while my main screen would need something like 1.5. So the issue with LMMS is probably not that some parts are _bigger_, but that some components react to the scaling and some do not.
Update: I just downloaded and tried 1.2.0 RC8 and it renders correctly on my system. So the issue on Master is not the same as originally reported in the first post.
EDIT: As a workaround for the "big fonts" problem on master, setting QT_FONT_DPI to 96 seems to do the trick.
Xenoslyce#6243 on discord has reported this issue happening. They are using 1.2, though they didn't specify which one.
Here's the related conversation:



Linked issue: #4831
I had the exact same problem. Se my last comment on #2510 for a solution that worked for me and does not affect other applications.
i've had this same problem here, and it happened before on another software. cool thing about the other software is they had something in the settings that let you change the user interface scale.

since both of these programs started out with the 2x scale on first launch, i'm going to assume they both use qt for their ui.
i don't know how hard an option like this would be to implement, since i've never looked at any of the code for lmms, but i don't imagine it being too difficult.
edit: should also note that the export QT_AUTO_SCREEN_SCALE_FACTOR=0 from above DOES fix this problem, so i'll just be using that on my computer. it solves the problem of automatic scaling actually working
I'm a highschool teacher. I teach all my students how to use LMMS. Shall I tell them to fix all their own bugs too? "Found a bug, kid? Report it?! Why would you ever do that? Fix it yourself, kid!"
Absolutely! Please! Or buy software that doesn't have bugs! There's no warranty here!
This bug you mention is specific to Linux only. We've patched it on Windows (using a workaround) and MacOS (proper HiDPI support).
The workarounds mentioned are correct, Linux still is the black sheep because different machines behave differently. Eventually, the Qt framework that we bundle will support HiPDI better. It's still bad (so is Java in many instances, HiPDI is actually tricky for these frameworks to support)
Believe it or not the reason RC7 didn't have the issue is it didn't have our patch which was intended to fix HiDPI (not make it worse).
Some machines work 100% with this setting, others do not. Not many people have dedicated any time to testing and working on this (I have helped, and I use MacOS, not Linux). I digress.
Anyway, it is and should be part of culture to help open source projects. It's also a fantastic learning experience as a music student to understand the tools that make the software, not unlike organ specialists that were responsible for both playing and repairing.
That said, it's not your responsibility to fix anything, but please be kind when asking volunteers to fix problems. It's just a bunch of hobbyists here, many of which just want to make music too.
Sometimes all it takes is one student to fix a problem for thousands of users. You could even offer extra credit for it.
So the specific "regression" that occured from RC7 to RC8 was the following code:
QT_AUTO_SCREEN_SCALE_FACTOR=1 from our launcher. This was done after complaints that the software was unusable QT_AUTO_SCREEN_SCALE_FACTOR setting, so this requires testing.What's a bit concerning is that the OP isn't mentioning if they're running the AppImage or not, meaning we may be chasing a unicorn here.
@theluckyfellow did you install from Mint or from our AppImage? Can you screenshot the About dialog?
_LMMI:_ 1.2.1 AppImage (Linux/x86_64, Qt 5.9.7, GCC 4.8.4)
_OS:_ Ubuntu 19.10 64-bit
_Screen:_ 13.3" QHD screen, running at 1920 x 1080 (40Hz)
Just for another data point, I am having the same issue, with the UI being very zoomed. I used the export QT_AUTO_SCREEN_SCALE_FACTOR=0 workaround above and it works fine.
I'm on a HP Spectre x360, which has some issues in Ubuntu with the high screen resolution (specs say 2560脳1440 max.) I've largely worked around this by slightly zooming text in other applications to make it comfortably readable.
I have a newer Spectre I can test on. I think it runs Windows 10 at 300%, so should be a good candidate. I'll see what I get.
I'm able to reproduce this on my HP Spectre 360 running LMMS 1.2.1 Qt 5.9.7, Ubuntu 19.10 using X11 at the "natural" 200% zoom that Ubuntu chose for me.
I'm curious whether or not this issue occurs with all Qt versions. The fact that it occurs with a stock version of Ubuntu at 200% zoom is quite troubling.
I can say with certainty that this isn't as bad as the issues we had reported prior, but now I'm not sure what combination of settings we should be using moving forward.
I used the export
QT_AUTO_SCREEN_SCALE_FACTOR=0workaround above and it works fine.
Really? Not here. Check it out, it's horrible. This horrible experience is what the aforementioned patches aimed to correct.
The interface is absolutely too large, I can agree with that, I'm just not sure if this is something that the latest Qt will eventually fix. I don't think it's unusable, but I agree it's too big. Here's what it looks like on my Spectre with no changes to the environment:

Really? Not here. Check it out, it's horrible. This horrible experience is what the aforementioned patches aimed to correct.
Same with 1.2.0-RC6, 1.2.0-RC7 it's too small to be usable on a 13" display for both versions.
Interesting. The difference could be that I'm running at 1920x1080.
With QT_AUTO_SCREEN_SCALE_FACTOR not set. This also makes it very hard/impossible to use any dialog windows, as they go off-screen:

With QT_AUTO_SCREEN_SCALE_FACTOR=0:

My 13" screen is a bit tough to work with for an application like this, but I feel the second one is usable.
Edit: Let me know if there are any settings (LMMS or system) that you would like me to check.
I'm running at 1920x1080.
I'm skeptical of that value as that'd be a standard 1080p resolution. Something's going on if HiDPI is affecting the experience. That must be your virtual resolution. I'm interested what your zoom is. Mine's 200% in Gnome Settings.
Interestingly I have a near identical problem to yours on my Ubuntu VMs running in Parallels (I have some VMs setup using HiDPI) so I'm sure there's a way to fix this, but I'm not really sure what's causing it to begin with.
I'm a little confused as well. My resolution and zoom are 1920x1080 and 100%, according the Screen Display window:

I did have the Gnome desktop interface text scaling factor set to 1.25 to make things easier to read:

I reset this to 1, but the only difference is in some text areas (such as the menu bar):

I happy to work with LMMS as it is, but let me know if there is anything else I can do to help track down the source of the issue.
I'm skeptical of that value as that'd be a standard 1080p resolution. Something's going on if HiDPI is affecting the experience.
A 1080p screen at this size definitely should be considered HiDPI: if you compute the DPI of a 1080p 13.3 inch screen, you get:
sqrt(1920^2 + 1080^2) / 13.3 = 2203 / 13.3 = 166 DPI.
Or, compared to the 96 "reference DPI", the correct scaling factor for such display would be 173 %.
In my opinion, the problem here is simply that both Ubuntu and Qt prefer scaling either to 100 % or 200 % and nothing between. Qt likely has a threshold at 150 % and rounds the computed scale factor to either 100 or 200 % depending on what is closer. I personally hate this "integer multiples" behavior, but I understand there is not really any other clean solution that would preserve the sharpness and quality of bitmaps, which are still very common in GUIs.
If you have a screen near the 150 % scale, it might be best to just let the user choose if they want to round up or down, depending on what they hate the most: UI that is too small to see, or too big to fit to the screen. Unfortunately, there seems to be no configuration standards -- every desktop environment does its HiDPI settings differently. So perhaps Qt may be falling back on its own DPI calculation, based on the pixel count and physical size of the screen, ignoring the user settings. So far it looks like the only reliable way to make sure the user always has a choice would be an override switch inside every app..
In my opinion, the problem here is simply that both Ubuntu and Qt prefer scaling either to 100 % or 200 % and nothing between.
The entire Linux desktop, actually. Fractional scaling isn't really supported on anything but Windows. MacOS handles this by controlling the hardware and defaulting to 2x on Retina (their name for the HiDPI displays). Linux is forced to try to emulate the Windows fractional scaling, which is a terrible experience.
So if it's a font-size caused issue, I think adding a toggle for the code snippet linked above will do it.
I'm curious if there's a Qt setting we're missing, or a case where we can handle both HiDPI and large fonts together.
i've opened surge synth source and they got GuiEditor
https://github.com/surge-synthesizer/surge/blob/master/src/common/gui/SurgeGUIEditor.cpp
so there is a template switcher for fonts and bitmaps and they use different workarounds for mac/linux/windows, but it is made in C++ i guess.
but it is made in C++ i guess.
Yes, it is, I see no references to Qt other than a note in the readme about potentially porting the UI over to Qt. If there are specific portions of that code you think will help, please point them out.
i think that creating profiles to make GUI bigger or smaller is a way that can solve it.
So that code can be useful in terms of how they did it.
Fractional scaling isn't really supported on anything but Windows.
I just thought I'd let people here know that Linux Mint Cinnamon 4.6 is getting fractional scaling soon.
Please don't throw any rotten food at me; trying to be helpful. eeekk runs
Can we move to #2510?
This fixed the large lmms gui that occurs when dragging from a 24inch to a 22inch in a dual monitor environment. Hope it helps:
echo "export QT_AUTO_SCREEN_SCALE_FACTOR=0" >> /etc/X11/Xsession.d/99gnome-qt
Most helpful comment
@theluckyfellow The problem is most probably in your configuration, as most people with 1080p don't get this behavior.
But if you believe LMMS should be able to detect and fix this problem, you can contribute to this open-source project yourself, and raise the standard :)