https://bugs.winehq.org/show_bug.cgi?id=51230
Bug ID: 51230 Summary: winecfg: Graphics tab - Per application settings don't work Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jkfloris@dds.nl Distribution: ---
"Wine can mimic different Windows versions for each application. This tab is linked to the Libraries and Graphics tabs to allow you to change system-wide or per-application settings in those tabs as well."
From this I understand that it should also be possible to also set the DPI or a
virtual desktop per application. Unfortunately, this does not work.
For example: winecfg Applications tab -> Add application -> "notepad.exe" (select notepad.exe) Graphics tab -> Select "Emulate a virtual desktop" (click "Apply" and "OK") wine notepad.exe Now I expect notepad to run in a virtual desktop.
https://bugs.winehq.org/show_bug.cgi?id=51230
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
--- Comment #1 from Zhiyi Zhang zzhang@codeweavers.com --- Settings in the Graphics tab are global.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #2 from Zhiyi Zhang zzhang@codeweavers.com --- There are indeed some wording errors in the Applications tab. It should also be possible to implement the per-app graphics settings.
https://bugs.winehq.org/show_bug.cgi?id=51230
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51230
subgraph93@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |subgraph93@gmail.com
--- Comment #3 from subgraph93@gmail.com --- This appears to be a 6.5 regression. Per-application overrides in winecfg ignore the options "Emulate a virtual desktop" and "Automatically capture the mouse in full-screen windows", apparently always using prefix defaults. Disabling window manager decoration still works. Didn't test or notice issues with any other options. 6.18 is still affected. My hopefully correct bisection points to:
commit 28fe84da45bea7de56539b50eac8ebcec54342de Author: Alexandre Julliard julliard@winehq.org Date: Wed Mar 24 10:53:53 2021 +0100
ntdll: Load the main image from the Unix side.
Steps to reproduce: 1) Create a new prefix with an affected Wine version. 2) Launch winecfg. 3) Add a per-application override for winecfg and change it to use a virtual desktop. 4) Apply the change, close winecfg and restart it. Note how it's not using a virtual desktop.
I'm not sure where the comment about the settings being global comes from, these options worked per-application before the listed commit. For example, on unaffected versions after step 4 above you would see winecfg use a virtual desktop, while notepad wouldn't use a virtual desktop. Even on affected versions the window manager decoration option works with per-application overrides. (You can have winecfg use WM decoration and have notepad use Wine decoration at the same time.)
https://bugs.winehq.org/show_bug.cgi?id=51230
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #4 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
I see possible issue with per application virtual desktop setting.
Case A (multiple application using virtual desktop):
1) Create a new prefix with an affected Wine version. 2) Launch winecfg. 3) Add a per-application override for winecfg and change it to use a virtual desktop. 4) Add a per-application override for notepad and change it to use a virtual desktop. 5) Apply the change, close winecfg and restart it. 6) Open another terminal and start notepad from same prefix.
Case B (application spawning child application):
1) Create a new prefix with an affected Wine version. 2) Launch winecfg. 3) Add a per-application override for Steam (or a file manager) and change it to use a virtual desktop. 4) Apply the change, close winecfg and start Steam (or a file manager). 5) Launch a game from steam (or any other application, from the file manager).
What do you expect from those scenario? A: One virtual desktop with both notepad and winecfg, or two independent virtual desktops? B: The main application in a virtual desktop and the other application managed by the WM, or both the main app and the child app in the same virtual desktop?
My opinion is that having per application virtual desktop will cause more trouble/confusion for users than a simple all-or-nothing global virtual desktop setting.
For DPI, i think that it doesn't matter if child/concurrent apps have different settings than the main app, so it makes sense to be a per-application setting like window decorations are.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #5 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Also, in case A, what about the size of the virtual desktop? Let say winecfg set a virtual desktop of 800x600 and notepad a virtual desktop of 1024x768?
Regards.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #6 from subgraph93@gmail.com --- Scenario A: Two independent virtual desktops. I think all winecfg VD parameters are already stored in the registry as expected (and if I'm not mistaken, the program name is used as the VD name).
The option to provide a common virtual desktop for two programs via command line parameters is still present, for example
wine explorer /desktop=test,1024x768 notepad wine explorer /desktop=test,1024x768 winecfg
and because the name "test" is the same, winecfg launches in the same virtual desktop.
Scenario B: I think the actual behavior is that child processes of a process that uses a VD launch in the same VD. Example:
wine explorer /desktop=test,1024x768 wineconsole (then in the console) notepad
this will open notepad in the same virtual desktop.
Virtual desktop sizes were (and I believe should be) independent, you could have
wine explorer /desktop=test,1024x768 notepad wine explorer /desktop=test2,800x600 winecfg
and it would launch two virtual desktops with different sizes
--------
I believe you can set per-application settings in new (affected) versions and revert to an older (unaffected) version to see them work, which means the corresponding registry entries are stored as expected. I am not sure why it is being presented as if it were an intentional change.
"Automatically capture the mouse in full-screen windows" is another regressed aspect.
Another mitigation strategy could be to allow to set up all these options in command line parameters (like desktop, its name and size). Maybe some of them already exist as command line options (I only learned about /desktop relatively recently), but even if so, I don't know what they are.
So the way I see it, there are several separate issues here: 1) Regression: the settings winecfg stores in the registry per-application aren't respected since 6.5 2) It's impossible to use just winecfg to set up a common virtual desktop for two separately launched programs 3) It's impossible to use winecfg or just about anything to force a child process out of its parent's virtual desktop 4) For advanced use cases, it's not clear whether it's possible to provide all winecfg option equivalents via command line parameters. Maybe they exist, but aren't prominently documented, or maybe they are missing.
I believe the original issue reported (and the one I reported) is only [1]. [2] can be resolved with different launch commands, I personally don't know a use case for [3], and a use case for [4] could be a backup against issues like [1].
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #7 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
I'm not saying that it is a change at all. I never knew that it worked like that, so, to me, it has always been global settings. I'm interested to see how that feature is implemented in the code and how it plays out in actual use.
While the feature makes sense from a technical perspective, now I wonder what realistic scenario would depend on mixing WM managed windows with multiple virtual desktops of various sizes, or mixing DPI/capture mouse settings within the same prefix.
I usually put each application in its own prefix and never met an application that had a dependency on another that had incompatible requirements in the settings.
Do any of you happen to have such dependent applications with incompatible requirements? Otherwise, could you each explain your actual need for that feature?
The problem is that the devs won't put effort into fixing this feature if there isn't a reasonable need for it. The fact that the feature existed at some point and is now broken won't be sufficient. They may even decide that it's too much effort to maintain and make the settings global.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #8 from subgraph93@gmail.com --- As for virtual desktops, in my personal experience, most programs either need a virtual desktop or don't have any requirements either way. Programs that absolutely must be outside a virtual desktop are not things I encountered.
However, I'd say virtual desktops are necessarily more disruptive to user experience than WM-decorated windows (especially for windowed applications), and there are circumstances where having multiple programs per prefix is needed, sometimes even concurrently running (not to mention multi-program prefixes are usually not an issue, at least in my experience), so for multi-program prefixes I prefer to default to "no virtual desktop" and set virtual desktops only when needed.
Unfortunately, apparently due to difficulties in adapting Windows "language" to non-Windows window systems, there are some input issues with Wine and multiple windows, such as clicks on one window passing through to another or not working at all if there's another window behind it. Most of the time virtual desktops help me work around them.
Otherwise, my use case for VDs is mostly for games (especially older games) that behave weirdly without them. Sometimes it's older games that also do weird things with screen resolution, so they may even need to have special VD sizes.
I don't have DPI requirements at all, so I can't comment about DPI. I don't have much information about when the mouse control feature needs to be on or off, except that it's useful to have it on in some games for proper input handling (sometimes only if the game is set to use virtual desktop, which is needed for unrelated reasons).
As for feature removal, I am aware this is a hypothetical possibility in the abstract. Do you believe it's a practical possibility for this specific feature?
Also, should the author of the commit that introduced the regression be added to the CC list? I'm kind of confused regarding what the answer to that is.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #9 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
I tested per-application virtual desktop with different sizes with wine 6.17 and it works like you described, but with a limitation.
The per-application VD settings are recognized only if the full path is provided.
I tested with: - VD disabled globally; - 800x600 VD for iexplore.exe (from C:\Program Files\Internet Explorer); - 1024x768 VD for winecfg.exe (from C:\Windows\System32); - 1200x900 VD for notepad.exe (from C:\Windows); (I didn't test the other settings) Those settings were set from the winecfg GUI.
Then I launched those, each in a different terminal, from the .\drive_c of the prefix: wine iexplore.exe → doesn't use VD winecfg → doesn't use VD wine notepad → doesn't use VD
So I thought of a possible path matching issue, so I tried: wine C:\Program\ Files\Internet\ Explorer\iexplore.exe → use 800x600 VD wine C:\Windows\System32\winecfg.exe → use 1024x768 VD wine C:\Windows\notepad.exe → use 1200x900 VD
I also tried with unix-style path with identical result.
Then, I cd'ed each terminal in the executable directories and ran: wine iexplore.exe → use 800x600 VD wine winecfg.exe → use 1024x768 VD wine notepad.exe → use 1200x900 VD
So, the path is not required when in the right directory.
Then I tried the shorter commands: wine iexplore → doesn't use VD winecfg → use 1024x768 VD wine notepad → doesn't use VD
So there is a problem when translating the path/name from the command-line to the one that would match the registry key. the winecfg command seems to be treated specially, as it behaves like wine winecfg.exe.
I guess the /desktop option doesn't work for the same reason.
Now I see in the commit diff that the logic that added ".exe" to a filename without '.' in get_image_path() was removed from ntdll/env.c. That may explain why 'wine whatever' doesn't match 'whatever.exe' since that commit.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #10 from subgraph93@gmail.com --- Thank you for the research. Unfortunately, it appears there was a bit of miscommunication: the /desktop option actually still works, I guess my comments just weren't clear enough about that.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- When launching the app without a full path, we now launch it through start.exe, which is most likely why explorer doesn't match it to the app settings. explorer will require some extra magic to figure out the real exe name.
https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #12 from subgraph93@gmail.com --- There appears to be a staging-specific aspect, maybe (speculation) due to new start.exe-related changes in server-default_integrity in 6.9-staging. On 6.18-staging with that patchset not even full paths work, while a compiled version of 6.18-staging with "-W server-default_integrity" works with the full path (but still has the other aspects of this issue). Should I report the staging-specific aspect as a separate bug?
https://bugs.winehq.org/show_bug.cgi?id=51230
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|-unknown |programs
--- Comment #13 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
(In reply to subgraph93 from comment #10)
the /desktop option actually still works, I guess my comments just weren't clear enough about that.
Oh, that's right. I missed that. Wine doesn't have to lookup the name of the application as the desktop name is directly taken from the option.
(In reply to subgraph93 from comment #12)
Should I report the staging-specific aspect as a separate bug?
Please, yes. It's better to separate staging bugs from upstream bugs. It's clearer and easier to track for the staging team.
(In reply to Alexandre Julliard from comment #11)
When launching the app without a full path, we now launch it through start.exe, which is most likely why explorer doesn't match it to the app settings. explorer will require some extra magic to figure out the real exe name.
Marking the bug confirmed. Setting the affected component to 'programs'.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=51230
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- Actually, in this case I don't think filing a new bug would help anything. The only thing wine-staging does differently is to start *all* new processes with start.exe, which I believe means that if the root cause of this bug is fixed, then it will be fixed for wine-staging as well.
https://bugs.winehq.org/show_bug.cgi?id=51230
imecth@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imecth@outlook.com
https://bugs.winehq.org/show_bug.cgi?id=51230
Todd Chester ToddAndMargo@zoho.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ToddAndMargo@zoho.com
http://bugs.winehq.org/show_bug.cgi?id=51230
Zdeněk Kopřivík zdenek.koprivik@post.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zdenek.koprivik@post.cz
-
WineHQ Bugzilla