https://bugs.winehq.org/show_bug.cgi?id=57515
Bug ID: 57515 Summary: explorer mode did not show taskbar anymore Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: l12436.tw@gmail.com Distribution: ---
Created attachment 77548 --> https://bugs.winehq.org/attachment.cgi?id=77548 Code with latest master without revert
in latest master, when you open desktop with enabled shell feature. taskbar still not shown.
I found you when revert commit 4cc38f0f52284b1315ef0539327c3cfbc163c472 the task bar will shown again. This only happened recently. I do not know is that commit regression or not.
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #1 from TOM l12436.tw@gmail.com --- Created attachment 77549 --> https://bugs.winehq.org/attachment.cgi?id=77549 screenshot after revert code.
https://bugs.winehq.org/show_bug.cgi?id=57515
TOM l12436.tw@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|explorer mode did not show |desktop mode did not show |taskbar anymore |taskbar anymore
https://bugs.winehq.org/show_bug.cgi?id=57515
Patrick Hibbs hibbsncc1701@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hibbsncc1701@gmail.com
--- Comment #2 from Patrick Hibbs hibbsncc1701@gmail.com --- This is controlled by the registry key HKCU\Explorer\Desktops\Default\EnableShell.
Setting it to 0x1 will enable the taskbar. You can also enable it temporarily by running: wine explorer /desktop=shell
See also: https://gitlab.winehq.org/wine/wine/-/wikis/Useful-Registry-Keys
That being said, it would be nice to have it as a proper option in winecfg.
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #3 from Patrick Hibbs hibbsncc1701@gmail.com --- (In reply to Patrick Hibbs from comment #2)
This is controlled by the registry key HKCU\Explorer\Desktops\Default\EnableShell.
Derp. That's supposed to be: HKCU\Software\Wine\Explorer\Desktops\Default\EnableShell Sorry.
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #4 from TOM l12436.tw@gmail.com --- I know that registry. I have tried that already. It did not shown. I even change the code to force it return true. it still not shown. Only revert that commit will make the taskbar shown again.
https://bugs.winehq.org/show_bug.cgi?id=57515
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com Keywords| |regression Regression SHA1| |4cc38f0f52284b1315ef0539327 | |c3cfbc163c472
--- Comment #5 from Rémi Bernon rbernon@codeweavers.com --- I've opened https://gitlab.winehq.org/wine/wine/-/merge_requests/6994 with a fix, and a new winecfg checkbox.
https://bugs.winehq.org/show_bug.cgi?id=57515
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=57515
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |9d8d17e36c6fb17782c49846872 | |5e90433ff2c4a
--- Comment #6 from Rémi Bernon rbernon@codeweavers.com --- Should be fixed with 9d8d17e36c6fb17782c498468725e90433ff2c4a, the winecfg checkbox didn't make it sadly for some reason.
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- (In reply to Rémi Bernon from comment #6)
Should be fixed with 9d8d17e36c6fb17782c498468725e90433ff2c4a, the winecfg checkbox didn't make it sadly for some reason.
It should be a separate MR, with a convincing argument that it should go in during code freeze.
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #8 from mrdeathjr28@yahoo.es --- (In reply to Rémi Bernon from comment #6)
Should be fixed with 9d8d17e36c6fb17782c498468725e90433ff2c4a, the winecfg checkbox didn't make it sadly for some reason.
yeah error still appear in wine 10.0-rc2
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #9 from TOM l12436.tw@gmail.com --- Yes the issue itself is fixed.
https://bugs.winehq.org/show_bug.cgi?id=57515
--- Comment #10 from Patrick Hibbs hibbsncc1701@gmail.com --- (In reply to Alexandre Julliard from comment #7)
(In reply to Rémi Bernon from comment #6)
Should be fixed with 9d8d17e36c6fb17782c498468725e90433ff2c4a, the winecfg checkbox didn't make it sadly for some reason.
It should be a separate MR, with a convincing argument that it should go in during code freeze.
I would argue the following reasons:
1) This bug report (bug #57515) exists because a previous wine release changed the default behavior to show the taskbar. For some users this was probably seen as new major functionality for wine. (Given that the taskbar and start menu are core UI features of current Windows, and have been for decades.) Even though that functionality had been in wine for years, it's lack of visibility made users think it wasn't supported by wine until that change.
A subsequent wine release reverted that default behavior change with no obvious means of restoring that functionality. For some users, that reversion was seen as a wine _regression_. For such a core windows UI feature, that would naturally be viewed by some as a major loss for wine. Hence the bug report requesting it's reinstatement.
2) The default behavior must be preserved. Obviously, wine's developers prefer that the taskbar and start menu functionality be disabled by default. This is fine, but an obvious and easy to use option to enable the functionality for those wishing to use it should be available. Making a checkbox in winecfg that uses the preexisting enablement method fulfills this requirement with minimal effort, without compromising wine's current default behavior.
3) The UI checkbox doesn't add new functionality to wine. The functionality the checkbox enables already exists in wine, and as stated previously, the enablement method also already exists in wine in the form of the Useful Registry Keys. Adding a checkbox using existing methods isn't hard to test. It either works or it doesn't. Anything else that comes from that is purely the result of enabling functionality that already has other means of being discovered and used even without the checkbox.
I.e. Refusing to implement a checkbox during code freeze isn't going to prevent any new bug reports from being made. The only one that wine would even accept is the one I've already mentioned bug #57515. All others would either be marked as a duplicate of #57515 or as an independent bug affecting the taskbar / start menu that would have existed in wine regardless of the checkbox existing or not.
4) The only other method for enabling the existing taskbar and start menu functionality requires weird incantations that limit how wine can be started. Wine's explorer.exe _must_ be called. Directly launching a different program won't work, as enabling the functionality is a command line argument to explorer.exe. Not an environment variable. This means that things like the shortcuts created by winemenubuilder cannot be used out of the box if one wishes to have the start menu and taskbar enabled. It also means that this must happen on every wine invocation. It's not something that could be easily set by modifying a user's .bash_profile for example.
5) The UI checkbox resolves ambiguity. Although the wiki's Useful Registry Keys page does document the existence of the permanent method to enable the taskbar and start menu in a prefix, the naming of the keys used can cause confusion. Both a key named "default" and a string named default need to be created. (The key for creating the EnableShell DWORD, and the string to enable the virtual desktop mode it depends on.) Both of these are in the same location in the registry, and the end users may confuse the need for both. (The wiki isn't very clear, nor does it provide an importable registry file with the correct settings.) The result is that very few even bother to get it working.
6) Black magic and weird incantations are bad for end users. Even Microsoft tries to avoid using the registry these days, and Microsoft has had a long standing policy of encouraging end users to avoid editing the registry directly due to the instability it can cause when mishandled. Microsoft recently has also discouraged third party developers from using the registry, and has long had a policy of advising developers that a more user friendly UI option should exist within their own programs. (I.e. Developers should not rely on the Registry Editor as the primary end user means of configuring a setting.)
As a result, there are many Windows users who have no experience using the Registry Editor. Expecting them to delve into a place that is considered "forbidden" under modern Windows, that they have no experience using properly, to enable basic functionality that they all take for granted, is an ill advised UI design choice at best. And can cause other problems (much like the ones Microsoft themselves are trying to avoid) under wine.
7) Wine's upcoming release is a milestone release. 10.0 will probably get more attention than the normal releases. Which means that "missing" such core Windows functionality like the start menu and taskbar only degrades wine's image in the minds of the public. Not even having that functionality be an option in winecfg is likely to be regarded by the public as yet more proof that wine isn't mature enough for use. _Especially_ if they saw the functionality enabled by default during the wine release where the default was changed, and was looking forward to that change making it into a stable Wine version pulled in by downstream distributions.
In short, the biggest change that adding a UI checkbox makes is social. It makes it easier for end users to use the existing functionality that is already in wine. But because that functionality is so obscure for many, there's a big fear of accepting it during a code freeze. Fear shouldn't drive development decisions, nor should it preclude end users from being able to use something that's been "hiding under the wine prefix" for years. It should be faced head on, and as for the bug reports that come as a result, let them. (They need to be cut down to size anyway.)
https://bugs.winehq.org/show_bug.cgi?id=57515
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.0-rc3.
-
WineHQ Bugzilla