Respected Jorge Coelho Good evening! I'm going to ask a stupid question too. Is it possible to change the size of the Start menu in the future? More or less? (Perhaps this question has already been asked on the forum.)



BassdudeNZ

But we do not know each other. I believe he is Ukrainian or Russian? - which is approximately 30,000 miles north of me

I'm from Russia!

@ppetroff60

I know you asked Jorge, but the issue is the skinner and in the screenshot, that is on me. The physical size of that particular menu is because the album covers shrunk to such a small size became completely unreadable any smaller. So consequently, this means the actual menu size became bigger to accommodate the covers surrounding the edges of the menu.

If I made them smaller, they would have looked like blotches of color added as an afterthought, so blame me.

Respected BassdudeNZ! I think the Start menu has a minimum size right now. Can it be increased? Create a changing size? As in Windows (use the arrow to resize the Start menu). There was the Aston program, the original replacement for the standard Explorer desktop shell for Windows. This does not work in Windows 11. There were many interesting topics in this project. But the project was closed. Winstep Xtreme is a very interesting program! And it is constantly being updated! Many thanks to Jorge Coelho for creating this program! And thank you so much for your topics! I think Windows looks much more interesting! (This is my personal opinion!)

Jorge is the Guru here with what windows can and cannot do. He knows more about Windows changes, what works, what won't work , much more than I have had hot breakfasts I am just a skinner - well, I am more than that, but as far as Winstep goes, that is accurate enough.

HI Jorge. i noticed the fixed issue of sub docks icons taking time to show. Just testing beta 6. I have the issue of half the icons, don't load straight away. 5-10 seconds to fully all load. It happens each time i login.

Ok, but if I understood correctly this is not related to beta 6, that is, it was already happening before, right?

Usually that has to do with what is in the sub-docks - if one or more shortcuts in the sub-dock is on slow (e.g. a hard disk that goes to sleep and needs to spin up again) or non-local storage (for instance, somewhere in the LAN), then that kind of thing is to be expected.

no its not beta 6 issue. Thanks for the answer. I guess non local storage is my answer.

New Betas of v26.8 (Beta 7) are out:

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

Nexus Ultimate beta:
https://www.winstep.net/ultimate-beta.zip

Nexus free beta:
https://www.winstep.net/nexus-beta.zip

This is a beta and MUST be installed ON TOP of a full v26.6 OR LATER installation. Do NOT uninstall anything first, just exit all running Winstep applications and run the beta setup file.

It should not be necessary, but THIS TIME I do recommend MAKING A BACKUP of your settings before installing the beta!!!

###

New features in this beta: new and improved scroll bars for non-standard UI modes, startup passive integrity check, added shared Appearance, Effects and Theme settings for temporary Grid Stacks, Shelf hotkeys now respect the Activation acts as a toggle setting, either opening/closing the Shelf or bringing an already open Shelf to the foreground.

Fixes: an issue that could cause the dock to jerk when switching insertion points while dragging icons with magnification disabled, problems caused by Unicode characters in icon filenames that could not be represented in the current ANSI code page, unchecking "Allow parent dock magnification when sub-docks are open" was not disabling parent dock magnification as intended, several issues related to how docks and shelves behave when "Launch applications with a double click instead of a single click" is enabled, an issue where Internet-dependent features could continue attempting network operations after an automatic connection attempt had failed, issue where canceling Preferences after applying a global theme failed to restore the individual themes of Shelves not locked and not using the global theme, and Shelves, Drawers, Grid Stacks and Launch Pads no longer appear as black "blobs" if the associated theme does not exist or has been deleted. Instead it will use the default OPENSTEP_EUI theme.

@Jorge - I generally come online here for around15-20mins max. So I did not see the Menu thread until just now.

I won't raise it again here. If you'd be so kind to mail me about v9.11 I will not raise it again, just so I know why it changed. It also helps me in the long run if I understand why... If I saw that thread first several days ago I would not have posted here. I do not live here so I do not read every single thread daily. I was surprised at the conversation so I have opted to step right back. Cheers.

No worries. It's just Picco being Picco.

Also, 9.11? Do you mean v9.5? What do you mean by "why it changed"?

yes I believe it is 9.5 but it says 9.11 at the bottom - there's a screenshot on the previous page.

I was not trying to be cryptic with that question - In 9.5, when you clicked on the Main Menu and have a SubMenu, if you drag the SubMenu away from the Main menu, it stays as the submenu and does not change into the mainmenu. Now and for quite a while now, if you drag the submenu away, it turns into the mainmenu graphics. I am trying to understand why you changed that, nothing more because I thought the earlier version made sense being Mainmenu graphics stay in mainmenu and dragging a submenu kept only submenu graphics.

I figure you had a good reason for changing that, so forgive me for not knowing what that reason was.

Possibly, because a sub-menu dragged away from it's parent logically becomes a stand-alone parent menu.

Anyway, I have not forgotten your request and I do think it makes sense (a theme setting that prevents dragged sub-menus from assuming the theme of parent menus).

Also, keep in mind that v9.5 (or even v9.11) was released back in 2009, or 17 years ago. My memory is good but not that good.

In v26.8 I have been doing a fairly deep overhaul of the monitor-profile handling code because of reports of docks and Shelves occasionally ending up in the wrong place after startup or after resuming from sleep/hibernation.

The first step was to harden the existing display-change handling itself.

Windows can generate a lot of display-related activity during startup, resume, monitor connection/disconnection, DPI changes and resolution changes. Several notifications can arrive in rapid succession while the display subsystem is still settling, so I tightened the code to make the whole process much more resistant to re-entrancy, overlapping timers and partially processed display changes.

The display-change path now serializes processing more carefully, avoids entering the same logic again while a previous change is still being handled, debounces successive notifications, and performs an additional validation pass afterwards in case Windows changed the monitor configuration again while the first pass was still being processed.

The idea was to make sure that each monitor transition is handled as one coherent operation rather than several overlapping ones fighting with each other.

That significantly reduced the number of possible race conditions, and an issue that occasionally also happened here when returning from sleep never happened again, but it still left one uncomfortable possibility: during startup or resume and depending on hardware, Windows can briefly expose an intermediate monitor configuration, resolution or DPI before finally settling on the real one. WorkShelf may correctly end up with the final monitor configuration in memory, yet a dock or Shelf may already have been repositioned while the temporary configuration was active and the final monitor profile may, for whatever timing reason, never have been re-applied.

At that point there is nothing obviously wrong with the monitor collection itself - WorkShelf and Windows agree on the current monitor configuration - but the objects on screen may still be carrying geometry inherited from an earlier transient state.

That is why I just added a delayed monitor-profile reconciliation check.

About 30 seconds after startup, and again after resuming from sleep or hibernation, WorkShelf performs a one-shot sanity check after Windows has had plenty of time to settle.

The reconciliation first compares the monitor configuration Windows is actually reporting at that moment with the configuration currently stored internally by WorkShelf. If those differ, WorkShelf treats it as a missed or incomplete display change and sends it back through the normal WM_DISPLAYCHANGE processing path.

If the monitor configurations already agree, the reconciler can then check whether the appropriate monitor profile still needs to be re-applied.

A user today reported that two floating Shelves were not only being moved after reboot, but also being shrunk. That exposed a separate omission in the monitor-profile format: although Shelf positions were being saved, the user-defined Shelf length was not.

That meant that if Windows temporarily reported a smaller desktop and WorkShelf shortened a floating Shelf so that it would fit, restoring the monitor profile could put the Shelf back in the correct position but would not restore its original size.

Monitor profiles now also save the Shelf size. Older profiles remain fully compatible - if the new Size entry does not exist, it is simply ignored.

The reconciliation itself also had to be made conservative.

A monitor profile is not necessarily an exact frozen copy of the current desktop at every instant. Legitimate things can move docked objects slightly. For example, stopping NextSTART removes its reserved taskbar area and can move bottom-docked objects by 40 pixels or more even though nothing is wrong with the monitor configuration.

So reconciliation does not treat every one-pixel difference as a failure. Position and Shelf-size changes must exceed a threshold of 148 pixels before they are considered suspicious enough to justify restoring the profile, as this will move all objects back the position and size they were when the profile was saved. Changes to actual object state, such as docking mode or orientation, remain significant immediately.

The threshold is intentionally large because the failures this mechanism is intended to catch are usually visually obvious - objects being shifted because Windows briefly reported a fallback resolution, another monitor arrangement or another DPI state. Those errors normally produce differences of hundreds or thousands of pixels, not a few dozen.

There are also a couple of safety conditions around the delayed check. If the user interacts with a dock or Shelf before the timer fires, the reconciliation is cancelled, because an explicit user change takes priority over the saved startup/resume state. Likewise, if a fullscreen game is already running when the check fires, reconciliation is skipped because the game itself may have changed the display mode.

If reconciliation actually restores a WorkShelf monitor profile, the desktop modules are also repositioned from the same profile and then validated against the current monitor layout. This prevents the docks and Shelves from being corrected while desktop modules remain at coordinates inherited from a temporary display state.

While tracing all of this I also found a separate, much older monitor-profile problem.

Nexus, Nexus Ultimate and WorkShelf were all generating the same profile filename for the same monitor configuration. The filename depended on monitor geometry and DPI, but not on which Winstep application had created it.

That meant Nexus could inherit a profile last written by WorkShelf, Ultimate could subsequently overwrite it with its own dock list, and so on. Unique dock and shelf ID names prevented this from turning into an outright disaster, but the applications clearly should not have been sharing the same object profile.

Monitor-profile filenames are therefore now application-aware as well:

NX...ini - Nexus
UT...ini - Nexus Ultimate
WX...ini - WorkShelf / Winstep Xtreme

Backward compatibility is handled automatically. If a new application-specific profile does not yet exist, Winstep first looks for the previous DPI-aware shared profile and, failing that, the much older non-DPI-aware profile. If one exists, the complete INI is copied to the new application-specific filename.

Copying the complete file is important because these profiles can contain more than just dock and Shelf coordinates. WorkShelf profiles can also contain theme-specific desktop-module positions and other settings which must not be lost during migration.

The old shared profile is left untouched, while each application subsequently updates its own independent NX, UT or WX copy.

During this work I also found that the old compatibility check itself had a bug: some existence checks were being made against the profile filename alone instead of the full ...\Profiles\ path. Depending on the current working directory, that meant legacy-profile fallback could silently fail. That has now been corrected too.

If this doesn't finally put an end to these issues, I sincerely don't know what more I can do.

New Betas of v26.8 (Beta 8 ) are out:

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

Nexus Ultimate beta:
https://www.winstep.net/ultimate-beta.zip

Nexus free beta:
https://www.winstep.net/nexus-beta.zip

This is a beta and MUST be installed ON TOP of a full v26.6 OR LATER installation. Do NOT uninstall anything first, just exit all running Winstep applications and run the beta setup file.

It should not be necessary, but THIS TIME I do recommend MAKING A BACKUP of your settings before installing the beta!!!

###

This beta adds the fixes to multi monitor profiles I discussed in the previous post.

I see no need to raise it again because you are not only aware of it, I know you intend to add it. Please be so kind when added, to email me in personal email with the line to add in the wst file with = True or False (as an educated guess).
Many thanks, I appreciate it.

P.S. - i can see by the MASSIVE amount of work you have done above that the mechanics are much more important at the moment. When you get around to it is fine