A few "is it just me" issues before submitting to tracker
I've started using 2.0 builds more seriously of late. Really, really, loving it. Sure, there are issues to be wary of, as is to be expected of any pre-beta or even beta software, but the improvements are more than making up for this for me.
A few things I am noticing that I haven't submitted as actual issues because I get the sense they might be unique to something on my (WIndows 7, US English) system, wondering if anyone has ideas:
1) when a score opens at 100% magnification, it is *much* smaller than life size. This started right around the move to Qt 5, I think. I gather some others see this, but not everyone?
2) A number of shortcuts don't work. Two that come to mind: Ctrl+O for File / Open and Ctrl+Shift+B for Add / Measures / Append Measures...
3) A few of the palettes are messed up. In the Advanced workspace, Repeats shows squares instead of coda and segno. In the Basic workspace, Barlines shows an empty element at the beginning of row 2. Tooltips for horizontal and vertical frames are in German. Could be old preferences lying around; I'm never clear on how to best reset.
4) Drag and drop from the palette is non-responsive the first time I try to do it. I have to wait maybe 10 seconds after first opening a palette before I can use it. Then all is normal. Happens again on each restart.
5) I no longer see an option to set default paper size. This would fine if it meant the default was now locale-aware, but I'm getting A4 instead of Letter. Is this supposed to work, and if not, why was the ability to set this removed?
Comments
1/ Need more investigation indeed. On mycomputer a score at 100% is larger on MuseScore nightly than on MuseScore 1.3. I do think it's closer from "real life size" in nightly. See attachment.
2/ Ctrl + O is fixed and Append measures is not Alt + Shift + B. Ctrl + Shift + letter are reserved for future user (insert a note)
3/ We might need to regenerate the default workspace. If there is no issue filed, could you?
4/ I cannot reproduce this. Curious if anyone else can?
5/ The preferences is gone indeed. The page format is now part of the style. The way to go is to define a style with Letter and use it as default style in Preferences -> General -> Score. There is currently nothing done to set this style according to the locale AFAIK.
In reply to 1/ Need more investigation by [DELETED] 5
1/ defintly differen or me (i.e same issue as Marc), on Windows 7 Enterprise 64bit., See attached.
In reply to Size by Jojo-Schmitz
I made a change in f60feb6d28. Can you try to see if it changes something? Also, what's your screen resolution in windows settings? What's the native resolution of your screen?
For the record my screen is 1920*1080
In reply to I made a change in by [DELETED] 5
1280x1024, which is the native resolution of that scree and no difference with your change
In reply to 1280x1024, no difference by Jojo-Schmitz
Do you happen to have 2 screens connected to your computer?
In reply to Do you happen to have 2 by [DELETED] 5
No, not on that Desktop PC, where I generated the screenshot. I do have on my Laptop though (where that screen is the secondary monitor), so could test there too
In reply to No, not on that Desktop PC, by Jojo-Schmitz
I never have two screens.
FWIW, I do occasionally change resolution - or more particularly, the remote desktop app I use to access my PC from my iPad (Splashtop) changes it for me. But it changes back when I'm done using remote access, and I see the problem when running directly on my PC, immediately after a reboot so there is no way I can Splashtop having caused the confusion. I mention this only on the very off chance that it turns out to be significant. Like somehow use of Splashtop has caused something to get permanently changed within Windows.
In reply to I never have two by Marc Sabatella
I added (a lot) more debug information when MuseScore starts. Can you report what you see?
Debug: Information for screen: "\\.\DISPLAY1"
Debug: Available geometry: 0 0 1920 x 1032
Debug: Available size: 1920 x 1032
Debug: Available virtual geometry: 0 0 1920 x 1032
Debug: Available virtual size: 1920 x 1032
Debug: Depth: 32 bits
Debug: Geometry: 0 0 1920 x 1080
Debug: Logical DPI: 120
Debug: Logical DPI X: 120
Debug: Logical DPI Y: 120
Debug: Physical DPI: 143.907
Debug: Physical DPI X: 143.435
Debug: Physical DPI Y: 144.379
Debug: Physical size: 340 x 190 mm
Debug: Refresh rate: 60 Hz
Debug: Size: 1920 x 1080
Debug: Virtual geometry: 0 0 1920 x 1080
Debug: Virtual size: 1920 x 1080
In reply to I added (a lot) more debug by [DELETED] 5
Here's output on my system. My actual resolution is 1366x768, and my ruler measures my screen as 345x195mm. As mentioned before, actual DPI should work out to around 100. I have no idea where Qt is getting it's physical size from; my monitor isn't close to that big.
Debug: DPI 71.983260
Debug: Information for screen: "\\.\DISPLAY1"
Debug: Available geometry: 0 0 1366 x 728
Debug: Available size: 1366 x 728
Debug: Available virtual geometry: 0 0 1366 x 728
Debug: Available virtual size: 1366 x 728
Debug: Depth: 32 bits
Debug: Geometry: 0 0 1366 x 768
Debug: Logical DPI: 96
Debug: Logical DPI X: 96
Debug: Logical DPI Y: 96
Debug: Physical DPI: 71.9833
Debug: Physical DPI X: 71.9842
Debug: Physical DPI Y: 71.9823
Debug: Physical size: 482 x 271 mm
Debug: Refresh rate: 40 Hz
Debug: Size: 1366 x 768
Debug: Virtual geometry: 0 0 1366 x 768
Debug: Virtual size: 1366 x 768
In reply to Here's output on my system. by Marc Sabatella
Looks like the 'Logical DPI' is pretty close to your calculation.
How to get to see that extra Output?
In reply to Looks like the 'Logical DPI' by Jojo-Schmitz
Logical DPI is indeed closer for me, but it seems likely to not have been calculated - too conveniently round a number to believe. And my understanding is that logical can be affected by OS settings asidefrom just actual screen resolution. So it's probably not a great choice in general - unless it turns out it just happens to be.
I got the output from the application output tab in QtCreator when running underthe debugger. I assume it's also available in the terminal window when running standalone.
In reply to Logical DPI is indeed closer by Marc Sabatella
Well, for my screen these 96 DPI is the user defined setting, and MuseScore should honor that, shouldn't it?
In reply to 1/ Need more investigation by [DELETED] 5
1) My screen looks just like Jojo's, no change with your fix. My screen resolution is 1366x768, the default for my computer (a 15" widescreen laptop). The debug statement in startup code reports the DPI as 71.983, which by my calculation is way off. My actual screen width is 13.5", and 1366/13.5 yields 101.185. So, I guess at least we know the source of the problem.
2) Ah, that explains it. Menu was wrong, but I see you've fixed that. I'm thinking the other non-effective shortcuts were probably of the same form - probably mostly probably ones I tried creating myself. I'll keep my eye out to see if there are any others that are off.
3) So are you saying this one is *not* just me? I deleted my workspaces again (AppData/Local/MuseScore, rename MuseScore folder to MuseScore.old) and still see same issues. BTW, my description of the location of the bad icon in the Barlines palette in basic workspace depends on screen layout, of course. It's the fourth one - after plain double bar, before start repeat.
4) Let me try to explain what I see a little better to see if that helps anyone else reproduce. Basically, when I first start the program, if I immediately try to drag something from the palette, it's as if I failed to initiate the drag. I can move the cursor, but the icon doesn't follow it, and nothing happens when I release. I can try this several times with no results. After about 10 seconds, all is well and remains so until I restart. BTW, it doesn't matter how long I wait after opening the program before accessing the palette - the first access to the palette always causes this. It also doesn't matter if I open the palette and then wait before trying to drag. The 10-second countdown starts on my first drag attempt.
5) I had actually tried using saving a default style, but it didn't seem to take effect on my next new score. In the past, I think page layout settings weren't part of style, so I chalked it up to that. I tried again just now and am finding that specifying a default style doesn't work, period. I can look at the style file I am using and see the settings I've made, but no new scores actually pick up any of those settings. I tried restarting, no change.
So it seems the default style mechanism just isn't working? I'd also say that while I love having this facility, we really should consider whether there is way to make a locale-dependent default - perhaps something like providing "Default.mss" that gets set as the default style and having the installer copy "Letter.mss" to that for the US and other (non-metric?) countries.
In reply to 1) My screen looks just like by Marc Sabatella
If I were to want to tackle the locale / page size thing myself, I can see another way to go if modifying the installer is not viable. We could have the program startup code check locale and adjust the page size parameter in global style if it was loaded from the built in default rather than a style file.
If for some reason it is considered too hard / unreliable to figure this out automatically, we could have a dialog pop up on first run (or after a factory reset) asking user to select default page size, and the answer could be stored in the INI file as a hidden preference to be used if user doesn't define his own style file. Really, I don't see any harm in adding it back as an explicit preference as well. This would provide a default if the user doesn't define his own style. But that in iteself is not the goal. I don't care so much about how the user *changes* the default; I am more concerned with getting a good default in the first place. Either automatically or by forcing the user to choose during installation or first run.
If there is no objection to this in principle, I'm happy to try to do the work myself. I am sure I could figure out how to do what I am describing here. Any solution based on modifying the installer I'd be less comfortable doing myself.
In reply to If I were to want to tackle by Marc Sabatella
Modifying the installer is not an option. The Mac installer for example can't ask questions, or do this kind of stuff...
The style thing is doable. I would prefer to have Werner thoughs on it. I will ask tomorrow. My first discussion highlighted that it's not a good idea to modify the bundled style. This style is used in the UI, for example in time signature property dialog. Let me get back to you on IRC.
In reply to Modifying the installer is by [DELETED] 5
Yeah, I kind of figured the installer might not be the way to go. But I wonder how other programs deal with this? Seems on Windows I am accustomed to beng asked either in install or on first run.
Anyhow, the specifics of how we handle this don't concern me much, so whatever Werner says is fine by me - as long as we do *something*. It was already bad enough in 1.X that US users got a useless paper size by default and wondered why their scores kept getting cut off until someone clued them that they needed to change the default paper size. But at least it was easy to change the default. The current situation - even once the bug in default styles is fixed. Users should not need to go through two or three different dialogs just to get a usable default paper size. Its got to be automatic or very obvious and easy.
In reply to 1) My screen looks just like by Marc Sabatella
Looks like https://github.com/musescore/MuseScore/pull/505 could fix this issue
In reply to Looks like by Jojo-Schmitz
Running build with pull request 505 (using logical DPI) installed and it fixes my overall score size issue as well as the issue it was intended to fix (chord symbol sizes different on input versus after entry). No bad side effects yet that I can see.
In reply to Running build with pull by Marc Sabatella
Looks good to me too