Created attachment 77549 [details]
screenshot after revert code.

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.

(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.

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.

I've opened https://gitlab.winehq.org/wine/wine/-/merge_requests/6994 with a fix, and a new winecfg checkbox.

Should be fixed with 9d8d17e36c6fb17782c498468725e90433ff2c4a, the winecfg checkbox didn't make it sadly for some reason.

(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.

(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

Yes the issue itself is fixed.

(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.)