Please polish the "limited functionality" mode

[Aleinus]

Hello,
I am one of Insiders since July who, as many, likes not every and all MS inventions and thinks more traditionally (sometimes). So, EP is a very good tool for me. I saw the discussions about problems and their origin. Unfortunately, nobody can predict when and whether the required data will be made publicly available by MS. So we need to live with the "limited functionality", and I should say that it's a very good idea. In this mode, EP will work as a "Taskbar Power Toy", which can change many Registry settings, change the Explorer look, and activate them immediately or after Explorer restart. So, improving this mode would allow people to work with many of existing settings even without those symbolic tables.

What can be improved:

1. Sometimes the access to EP UI may be lost. It would be nice to include the simple script to the installation directory, where it can be launched in Explorer (because EP setup doesn't create a traditional program group). Like this:
   start rundll32.exe %SystemRoot%\dxgi.dll,ZZGUI
   I called it dxgi_UI.cmd, but it can be named differently. And this may be implemented not in the form of a script at all. The only requirement is, a user should be able to get to UI with a single mouse click somewhere, if the taskbar menu isn't available.
2. I'd suggest to consider whether it's possible to grey out the options which cannot work when the functionality is limited. Well, I understand that it may take some time and require additional work on current UI where such approach was not designed initially. If so, maybe later.
3. However, the information about limited functionality should be visible in UI, where exactly, is a developer's decision. Maybe near a bottom of window or in "Updates"... But a user should be able to clearly see in which mode EP works right now.
4. Information of unsuccessful download of update or symbolic table should be delivered as notification too. Maybe it already works this way but I missed it... Sorry if so.

One bug is noticed in 22000.318.38.7: the menu by right-click on Taskbar looks good only in the dark UI mode. In light mode it works but looks partially broken (System tray > [x] Skin taskbar and tray pop-up menus). If it's hard to fix, please remove the option to switch the look in the limited mode.

Thanks and please keep up the good work!

[Anixx]

I totally agree. It would be also good if the "Check for updates" button had some feedback besides notifications, as the notifications depend on various services running, focus settings, etc, and are not reliable.

In classic theme pushing the "Check for updates" button does not make any, even visual feedback, it is just some black text, not looking like a button, you do not know even whether you missed it with mouse or not as it is not even highlighted or underlined on hover...

[valinet]

In classic theme pushing the "Check for updates" button does not make any, even visual feedback, it is just some black text, not looking like a button, you do not know even whether you missed it with mouse or not as it is not even highlighted or underlined on hover...

In all themes, the configuration UI is manually drawn, all the "widgets" in the UI represent just text drawn with DrawThemeTextEx or DrawTextW. The UI is all built from scratch, as it was quicker that way, for me personally, and wanted to learn how to do such a thing as well. Adding visual feedback and the bells and whistles to that is too cumbersome and functionally brings nothing. I won't work on that, on the short term, at least. Please consider contributing if you want to see quicker updates in this area.

It would be also good if the "Check for updates" button had some feedback besides notifications, as the notifications depend on various services running, focus settings, etc, and are not reliable.

Idk, when I will have the time to polish the UI for the updater as you mentioned, I will have a look at that, maybe.

Thanks

[valinet]

Hi

This is exactly part of the reason why I never wanted to provide this in the first place. I don't have time to work or support this in this manner. This started as an educational project, and initially I was just sharing the work with the world anyway. Nowadays, the requested scenarios far outgrow the purpose of this project. I don't have time to maintain a fully fledged app with a million alternatives and options and use cases. And for how long? We do all this work the next year and Microsoft removes the old taskbar code finally. Long term, I view this patcher as a stop gap until they actually implement something meaningful like labels in the new taskbar, at which point this will pretty much become obsolete. Fighting the upstream is never a good solution long term, or at least it's not some fight I want to take on long term. I also have to use my computers for work, rather than to spend all the time "fixing" the operating system's UI.

The options provided are already too many in my opinion. Pushing an update is starting to become scary. The support infrastructure is slowly outgrowing the program functionality itself, and this just adds to that. This program now has a configuration interface, an installer, an updater, support for classic theme, support for use as shell extensions and much more additional functionality which I don't use at all, are way beyond any of the scopes of this project, so it's less likely to get tested as frequently, but still has to be maintained. Adding to that only complicates matters a lot, considering the current situation.

Suggestions and bold plans are great, but actual contributions are even greater, and this project failed to attract those. It's simply impossible for a single person to maintain this kind of infrastructure considering this is working "against" the OS as well, so every change takes tons of research hours, in a manner where there is time left to do anything else at all. This project more than fulfilled its purpose: being a valuable educational resource and providing a productive working environment on Windows 11. I have limited time to work on this and I prefer to invest it in adding useful functionality, and learning new things, rather than endlessly polishing areas which will never be perfect, like how the UI looks, for example.

To reply punctually to your points, what I will personally do:

1. Running rundll32.exe %SystemRoot%\dxgi.dll,ZZGUI is fine. I will mention it in the README. It's hard to reach a folder if explorer does not load at all. Most people do not even know where EP is installed anyway.
2. Hard to do, some other thing to maintain, not the scope of this project, so won't implement.
3. The info is available in the debug console. It's confusing anyway. What does "limited functionality" mean? What's so limited anyway, 2-3 features out of 100 missing...? This "limited functionality" mode is another band aid that only generates other issues that are mostly tackled with other band aids, apparently.
4. Yeah, it doesn't say anything, I think. With the recent "fix", it is not needed anymore, since symbols are pretty much neutered for the sake of this partially working on all the builds out there.

These being said, I will gladly merge contributions that generally address these in a manner that's compatible with this project's goals and that is maintainable long term. I encourage you to consider that.

About the bug, yeah, an incomplete report, show some screenshot, tell me your OS build number etc. On the famous 348 it works fine:

The option won't be removed as it works just fine in the current Windows 11 build.

Thanks

[Aleinus]

Thanks for detailed answers! I understand that the complexity of this work became close to one person's abilities and may exceed it somehow, but as for me, I cannot make much contribution in the project simply because of lack of Win32 C programming (even if I can understand some easy code, it's not the case here). Maybe I can be more useful by testing some existing and new features...

OK, this is a way to reproduce that bug:

1. Go to "Choose your mode" setting in Settings, which allows to select Dark or Light default modes. With any desktop background picture, set these: Custom (common mode), Dark (default Windows mode), Light (default app mode). I also have the settings Transparency: On and Accent: Manual, but apparently they don't affect this problem, only the difference in Windows/app modes.
2. By default, the "Skin taskbar and tray pop-up menu" in EP is on (ticked), so the Taskbar context menu is dark. It looks good.
3. Switch off the "Skin" menu and look at the context menu again. It becomes light and looks not good. Before the last EP build, I didn't notice this problem.
4. If you switch the first option in Settings from Custom to either Dark or Light, the bug disappears.

.

[valinet]

Yeah, well, this is one of the side effects of this "limited functionality" mode. The menu in its untouched state is skinned. To remove the skin, I use a function from twinui.pcshell.dll called ImmersiveContextMenuHelper::RemoveOwnerDrawFromMenu. If symbols are not available, I don't know where that function is, so it is not used. Instead, from the advanced classic theme mitigations I have some other function which attempts to remove the owner draw from the menu. That partially works here as well, it seems, although yeah, it's incomplete, so it renders the above...

The need for functions from twinui.pcshell.dll (and their addresses, so symbols) can be overcomed by reimplementing said functionality in EP, which is doable, like reimplementing the owner drawn add and removal function, reimplementing a builder for the Win+X menu etc. This is reasonably doable, although in practice, it takes a lot too. So getting rid of the need for symbols from twinui.pcshell.dll is kind of doable since I mostly use dormant functionality from there, not hook in order to improve stuff (also, emphasis on mostly). It's doable. Also, since is mostly legacy functionality, an old version of twinui.pcshell.dll, one with known address locations, would work as well, like loading that at runtime and using the things from in there. The problem here mostly is where to get such a file from, at runtime...? I can't redistribute Microsoft's binaries with the app... Or I mean, technically I could, like, are they going to bother, but still...

Getting rid of the symbols for the Start menu is more impossible, because I have to hook some functions in order to do some of the tricks. Without some advanced pattern matching that is more prone to breaking, the things can pretty much only be achieved using the symbol files.

[Aleinus]

Very well, I supposed that lack of needed symbols may result in something like that. But it's not a big problem, after all. Whether you (or someone else involved) will be able to solve this in the future or maybe will find less time-consuming approach, currently it doesn't work as expected, so broken functionality should be switched off for good.

Like I tried to explain above: EP in the limited mode is a kind of "Power Toy" and its existing functionality by manipulating the Registry even without the ability to change something on-the-fly is very valuable. So, need only to add some code, which will always select the "safe" options or do nothing, when the symbolic table required for fully functionality isn't available. For me it's some if-else operators (it may be more complex in reality, but shouldn't be as hard as need to implement a copy of Windows UI functions).

[valinet]

It won't be implemented at the moment, the infrastructure in the backend is not suited for such a thing at the moment, and it's not a big deal anyway. As I said, I cannot support all builds out there. If it doesn't work, it doesn't work, you don't use it, confirm by testing it manually, what's the big deal? If you load latest dev insider build, the network flyout doesn't work there, what should I do, remove UI when running there as well etc. I said it once, supporting all builds in this manner is not feasible and I sincerely doubt it is worth the hassle at all.

Thanks

[valinet]

For me it's some if-else operators (it may be more complex in reality, but shouldn't be as hard as need to implement a copy of Windows UI functions).

Besides the much needed programming lesson about if operators, I don't understand the second part of this sentence. "Shouldn't be as hard as need to implement a copy of Windows UI functions" - what does that mean?

[Aleinus]

About "if" operator, you may count this as a figure of speech.
Literally I supposed something like: if (table exists) { call Windows API functions using this table, depending on user's choice } else { use the safest choice which is possible without table or do nothing if no safe choice is available }.

Because in the "limited" mode EP will not work with Windows by catching and redirecting some functions (I hope I used this expression correctly), this "if" may work during the startup, when EP reads its current configuration with user-selected options, and then fixes them, replacing the potentially bugging choices (like in the bug above) with safe ones. Something like that.

[valinet]

About "if" operator, you may count this as a figure of speech. Literally I supposed something like: if (table exists) { call Windows API functions using this table, depending on user's choice } else { use the safest choice which is possible without table or do nothing if no safe choice is available }.

Because in the "limited" mode EP will not work with Windows by catching and redirecting some functions (I hope I used this expression correctly), this "if" may work during the startup, when EP reads its current configuration with user-selected options, and then fixes them, replacing the potentially bugging choices (like in the bug above) with safe ones. Something like that.

it's already something like that, I explained above. You can look on the latest commits as well, it's easy to deduct from there as well. Thanks.

[l0oo]

@Aleinus
I am one of Insiders since July who, as many, likes not every and all MS inventions and thinks more traditionally (sometimes).

So - you have a great opportunity to inform them that UI changes they've made in W11 are not good.
Also - please ask them to bring back Windows Classic interface. Thanks in advance!

[valinet]

Please refer to this material I have published as well, it mainly describes the behavior regarding symbols which will be introduced in the next version which will be published soon: https://github.com/valinet/ExplorerPatcher/wiki/Symbols

Thanks

[Aleinus]

Very informative article, I should say, it answers a lot of possible questions and eventually makes the users support much easier. Great work, thanks!