|
Gianluca Administrator Posts: 1274
06/03/2022
|
Hello.
What's happening here? Why an 8 version?
Well this release is a sort of milestone for SyMenu.
Since the SyMenu first version the only requirement for the host PC was to have the .NET framework 2.0 or higher installed.
This version has been heavily rewritten to implement the new .NET 7 framework that allows to include in the SyMenu package the entire framework. This way SyMenu can be executed with no prerequisites at all because all the needed libraries are already included.
This means full portability for SyMenu.
There are two cons with this approach.
1) The program size has increased a lot. This version weighs almost 70MB while the stable version weighs only 4MB.
2) The modern .NET frameworks abandoned the support for the oldest Windows OS (bye bye XP and Vista). The oldest supported OS is Win 7 SP1 and SyMenu will be forced to do the same.
PLEASE BE CAREFUL
We are finally out from the alpha testing. A beta version is available since October 2022 and it means it could be used in a more extended way.
Anyway I can't assure, at this point of development, SyMenu is fully working, nor that your configuration files will be preserved with the next version, I can't assure the automatic update will be able to update this version in the future... So please don't use this version as your main one. Any help for testing will be welcome but don't do stupid things with it.
Enjoy.
2023.05.28 - v.8.00.8548 (.NET Core 8)
2023.06.06 - v.8.00.8557 (.NET Core 8)
2023.07.19 - v.8.00.8600 (.NET Core 8)
2023.07.21 - v.8.00.8602 (.NET Core 8)
2023.07.21 - v.8.00.8616 (.NET Core 8)
2023.08.11 - v.8.00.8623 (.NET Core 8)
2023.09.15 - v.8.00.8658 (.NET Core 8)
2023.09.15 - v.8.00.8672 (.NET Core 8)
2023.10.04 - v.8.00.8677 (.NET Core 8)
2023.10.13 - v.8.00.8686 (.NET Core 8)
2023.11.08 - v.8.00.8712 (.NET Core 8)
2023.11.08 - v.8.00.8723 (.NET Core 8)
https://onedrive.live.com/download?resid=D06528ECD5C93C26%21563&authkey=!ALysxsY6dHn6988
Here you can download a compatible version of the SyMenu plugin OpenFolder
2022.06.09 - v.0.9.0.0
https://onedrive.live.com/download?cid=D06528ECD5C93C26&resid=D06528ECD5C93C26%21214&authkey=AMg192GAC9nahjo
edited by Gianluca on 19/11/2023
|
|
|
link
|
|
scentse Posts: 27
16/09/2023
|
.NET 8.0 RC was released two days ago.
Will switch over to the beta now.
EDIT:
v.8.00.8658
Still a few graphical glitches.
- Icons are too small/not scaling correctly.
- Window contents jitter when resizing window.
- Fields are cutoff when the number of rows exceeds the amount of space in a fixed size element. On Programs without Virustotal Information, the text is displayed correctly. But fields are cut off when displaying programs with Virustotal data. Issue also present in Options.
 
Machine Specs
4K display at 150% scaling
.NET 8.0
Windows 11 22H2
edited by scentse on 16/09/2023
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
18/09/2023
|
Thank you for your report.
I'm very happy there is someone who's testing SyMenu 8.0 on a 4K display because the scaling problems on different screen resolution and zoom settings are the main reason for which I'm delaying the release of the 8.00 version so much.
Anyway I'm a bit relieved to notice the problems do not harm too much the SyMenu use but I'll do my best to solve these glitches too.
|
|
|
link
|
|
scentse Posts: 27
18/09/2023
|
O sure, functionality is great.
Even the settings and configuration folders were copied over & retained.
The only folder which I didn't copy over was the 'Lib' folder for obvious reasons.
Text is certainly sharper than in 7.0.
But you'll notice with the icons in the Item Manager, some of them only take up the upper left quadrant of the hitbox.
Also previously unmentioned are some issues with the title bar.
The text on the title bar is too large and gets cutoff.
But the title bar elements (Maximize,Minimize Close) are too small & have tiny hitboxes.
Graphical elements aside, seems stable enough.
I'll begin using the 8.0 release going forward...
Many thanks!!
edited by scentse on 18/09/2023
|
|
|
link
|
|
lupusbalo Posts: 76
24/09/2023
|
I'm currently testing it
Already installed roughly 200 progs (no problem so far  )
but as I use extensively V7.. I have still many more to install
Question:
I have a bunch of portable apps in an "other portable apps" folder in the 7... installation
May I just copy this folder from 7.. to 9.. then import programs??
Thanks
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
24/09/2023
|
From 7 to 8!
Yes you can do that even if the import is a sort of manual operation and can create a lot of noise. You risk having hundreds of executables to choose among.
I think that if your program collection is not so large you can proceed with manual import (go to the folder and drag the executable to SyMenu).
|
|
|
link
|
|
lupusbalo Posts: 76
24/09/2023
|
OK thks
I'll give it a try
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
29/09/2023
|
Dear scentse,
Let me know if the new version fixes the Options - Structure glitch please.
The other problems are probably gone now.
edited by Gianluca on 29/09/2023
|
|
|
link
|
|
scentse Posts: 27
29/09/2023
|
ITEM MANAGER
- The program information elements are now cutoff. Only way to install SW is by right-click in the program lost
- Hitboxes now match icon size. However the icons remain tiny. They do don't appear to be respecting Window's scaling settings.
- Title bar is now cutting off more text than before.
- The sort row for list of programs is now cut off
- Free space bar is cut off.
CONFIGURATION MENU
- Free Space bar is cut off.
- Save & Exit Button is cut off.
- Certain checkboxes are overlaying the text fields.
OPTIONS MENU
- Checkboxes are partially overlayed on the text fields
- Graphical assets
- Textboxes are cut off
|
|
|
link
|
|
lupusbalo Posts: 76
29/09/2023
|
Suprisingly I see none of the problems that Scente posted
I'm running Symenu 8.0.8658 on W10, with a 4K screen at 125%
[EDIT] Just tried at 150% with same results
edited by lupusbalo on 29/09/2023
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
29/09/2023
|
Me too I tested at 125%, 150%, and 175% with no issues.
I have a question for you scentse.
When you set the zoom to 150% did you use the Windows dropdown selector or you set a custom scaling at 150%?
Strange enough it seems to me that Windows behaves in different ways when you go with the suggested scaling respect to a custom one, even if you choose the exact same values as the suggested ones...
|
|
|
link
|
|
scentse Posts: 27
29/09/2023
|
Using default 150% Scaling.
Tried at 125%, same issues.
Unaware if the scaling logic is performed via the OS or on the GPU??
On AMD's most recent stable driver w/ the 23H2 update enabled.
EDIT:
I tried disabling/enabling GPU Scaling in the AMD Radeon SW. Made no difference.
Tried uninstalling the SW/driver. Made no difference.
Just tested on a VMWare VM 11 23H2, 150% scaling. Zero problems. VM using the VMWare Tools graphics driver.
The issues are also present on a another HP tower with different chipset AMD dGPU at 200% scaling.
Both HP towers are using Intel processors w/ AMD GPUs. (i5-12400, RX5500 & i5-8400, RX550
Perhaps this might be an issue with the AMD GPU, differing instruction sets form Intel/AMD, or something to do with HP's hidden BIOS settings (only the most basic toggles are visible).
edited by scentse on 29/09/2023
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
30/09/2023
|
Great test and good assumption.
The scaling is on the .NET Core framework and I don't know if it uses the OS or GPU features but, according to what you discovered, I guess the second one, if a GPU is available.
All my tests take place on office PCs (I'm not a gaming guy) so I have never tested SyMenu on a dedicated graphic board.
Anyway I think it's a thing bigger than us. Let's see if some Windows updates fix the problem.
In the meanwhile, if you want, you could do some tests with the execution properties of the SyMenu executable. Among them, in the Compatibility tab, there are some settings that maybe can fix the problem (High DPI scaling override for example). If some of your tests solve the issue, totally or partially, I can put the workaround in the manual.
|
|
|
link
|
|
scentse Posts: 27
30/09/2023
|
Various compatibility overrides make some improvements, but far from the intended output with several cutoff areas remaining.
Furthermore, the overrides introduce major artifacts when resizing the window.
I would not hold out hopes on Microsoft resolving the issue.
Per-application settings for iGPU vs dGPU were once handled via the GPU driver/software for both Nvidia & AMD.
Back in the 20H2 update, Microsoft usurped control of per-application settings. Their implementation of the feature is a mess.
So many issues with Windows not recognizing a GPU. Or recognizing a GPU, but disallowing selection of a GPU for per-application settings.
In this specific instance, Windows is recognizing both GPUs and allowing the setting for SyMenu to use the iGPU.
BUT, it is not respecting the setting.
When viewing the Performance Resource graphs, the dGPU spikes when selecting and moving the SyMenu window.
When the SyMenu window stops moving, the dGPU values return to 1%.
The iGPU remains at a static 0% throughout.
On the older HP tower, the Intel processor is an F variant (no iGPU on the processor).
This was an office PC, way before HDMI 2.0 was even available on motherboards.
Hence the need for a dGPU to enable 4K output.
The more configurations testing the 8.xx release will surely reveal more.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
03/10/2023
|
Well if the situation is as you describe, SyMenu is not alone in this mess. I hope MS can fix this behaviour soon because I can do nothing.
|
|
|
link
|
|
scentse Posts: 27
03/10/2023
|
A shared mess indeed. I previously encountered this problem with Autodesk's AutoCAD.
Windows wouldn't respect the Nvidia GPU setting because the older laptop's monitor was only connected to the onboard graphics.
Newer laptops branch this connection.
What I suspect has happened is that Microsoft changed the Windows graphics stack to force all rendering output to the "3D engine" where the monitor is connected.
Plugged into the motherboard, rendering occurs on the processor.
Plugged into the PCIe card, rendering occurs the GPU.
Certain GPU engine settings are respected by Windows. For instance VLC.
Windows will delegate certain tasks to the "Video Decode engine" on the user-selected graphics, but the rendering output is handled by the "3D engine" where the monitor is connected to.
Were you planning on introducing additional features into the 8.xx release which would break something in 7.xx?
Or could both versions remain interoperable with the database?
EDIT:
While lacking knowledge of how to write code, I understand some base concepts.
Perhaps this documentation might illuminate,
https://learn.microsoft.com/en-us/windows/win32/learnwin32/render-targets--devices--and-resources
edited by scentse on 03/10/2023
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
03/10/2023
|
Thank you for the MS source but the interaction with the low level drawing devices it's on the .NET Core framework.
I only use the high level graphical components the framework supplies.
Sometimes I have to draw something with a so-called unmanaged code that is a simple Windows API call. But even with this technique I can't change the drawing stack that, in this case, it's on Windows OS.
Probably I could draw everything with unmanaged code explicitly using the Direct2D libraries and methods you refer to but it's not the way the software is developed nowdays.
Anyway this is a really interesting thread, I'm learning a lot thanks to you. Feel free to contact me in private if you want a deeper view of the SyMenu project.
BTW the SyMenu database is perfectly interoperable among 7 and 8. It means you could even downgrade to 7 if you like. Naturally in this case you will lose all the customization introduced with 8 but it's not a big issue IMHO.
|
|
|
link
|
|
scentse Posts: 27
03/10/2023
|
If the backend dependencies will remain functional, then I suspect leaving the 7.xx branch for unsupported configurations is the way forward.
Probably not what you had in mind after dedicating so much time when porting over to .NET 8.
As you rightly highlight: At some point, Microsoft may identify the issue & patch.
And of course, this could be a very limited aberration - the AMD GPU w/ the Intel CPU.
- AMD onboard graphics might be fine.
- Intel onboard graphics might be fine.
- AMD GPUs w/ AMD CPUS might be fine.
- Nvidia GPUs w/ AMD CPUs might be fine.
- Nvidia GPUs w/ Intel CPUs might be fine.
More tested configurations are truly required to ascertain how many machines are impacted.
Given the unknowns, I'd be weary of updating 7.xx installs to 8.xx.
Perhaps the 8.xx is better for new installs??
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
03/10/2023
|
At certain point I'll force the update from 7 to 8, because it is not feasible for me to maintain the two branches forever.
But naturally, as an end user, it will be possible to refuse the automatic update and stay with the 7 even if the things will probably start to fail.
Anyway I hope in some sort of MS fix sooner or later.
|
|
|
link
|
|
scentse Posts: 27
03/10/2023
|
Understandable.
Will you be able to get enough testing configurations with 8 tucked away in this thread though?
A beta link on the homepage might solicit additional installs/feedback...
|
|
|
link
|