Ok, happy to announce that on the next release Nexus Ultimate will, it too, display the full blown calendar when you click on the iconic calendar module in the dock or the Shelf.

Also, you're probably as sick of reading about the moon module as I am of writing about it, but just to wrap it up here is the Moon Phase Settings dialog:

Fixed the problem with thumbnails of some running applications appearing black.

The good thing is that we can still get thumbnails for windows we previously couldn't (with the old original method, that is).

The moon calendar is really nice. Going to be a lot of fun playing around with it. Thanks for all the work on it sir.

A beta of v17.1 is now available for Winstep Xtreme users. Feedback is, as always, most welcome.

Grr, the moon zodiacal signs have a bug. Don't trust it if it's Pisces.

Another example why I've renewed my subscription several times already.
There's hardly any program in which I don't find a lot of things to improve.
In Winstep it's about nothing. (except Next Start - but I'm happy with the Win 10 Start Menu and Task Bar anyway)
If you have an idea, you do it right. I like that.
Great update!

Thanks! Still has some bugs, which I've been fixing in the mean time (I guess that's why they call these things 'betas' ).

As for NextSTART, it recently got some much needed TLC, but it needs a lot more (per-monitor taskbars, reserve screen space in multiple monitors, etc...). Priority, however, goes for WorkShelf/Nexus, as that one is not only more useful as a general utility, as it has a tremendous potential for further improvement.

Things high on my list are multiple Shelves (tabbed docks), vertical Shelves, and, perhaps, Drawers (single-tabbed Shelves, kind of a mix between a Shelf and a dock, i.e.; what you would get if the two were allowed to breed).

I will probably release another beta soon - this last beta includes a change I made to the Winstep Update Manager that I want to test too: the Setup wizard is no longer shown (you just get a UAC prompt, then a progress bar and everything else happens automatically, kind of a one click upgrade). Small detail but one I hope makes upgrading to a newer version a lot less intrusive/disruptive.

Agree. While a more customizable task bar wouldn't be a bad thing, it's no comparison to Workshelf/Nexus, which completely change the way you interact with your computer.

Suggestions for NextSTART:
-an option to hide the system tray icons in the task bar, but only visually. To not have them twice, if you already have a tray area in your dock or shelf. And to not waste the space in the task bar.
-support for the Aero Glass blur effect, just like Workshelf/Nexus
-support for the progress bar (if you download a file or render a video for example, the Windows task bar shows a progress bar inside the tab of the respective program - that's what I mean)



Sounds good! Looking forward to it.



I think it already is quite comfortable in comparison to many other programs. (having to download the update via web browser, or having to kill listed processes manually, or having to reboot or log-off to update... to name just a few things)
But I have no problem with further improvements.

You can do this already: NextSTART Preferences -> Taskbar tab -> Taskbar Settings -> Taskbar Sections -> Uncheck 'System Tray'



NextSTART also already supports the Aero Glass blur effect under Windows 7, just like Nexus/WorkShelf. There's even a 'Blur Settings' button in the Themes tab of NextSTART Preferences.



This is one of those things that I don't think can be pulled off, because to do this applications directly communicate with the Windows taskbar - unfortunately the NextSTART taskbar has no way to know this communication is going on.

WorkShelf/Nexus now plays all MP3 files (such as voice announcements, alarm musics, etc...) via a 'proxy' executable (WsMMPlay.exe), so if you ever see it pop up on Task Manager momentarily, don't be scared.

This was done to isolate the main application from buggy/badly coded MP3 codecs and audio filters, and it obviously works since the user complaining about crashes is no longer suffering from them.

Just an example how badly implemented 3rd party applications/drivers/AV Solutions/etc can make other applications crash and, worse, make them look bad/buggy because it's not at all obvious that they're crashing through no fault of their own.

Also fixed a visual glitch with the calendar in the Moon Calendar on high DPI systems.

We're looking good for an official release soon.

Added a couple more options to the weekly alarm schedule, so you can run an alarm only every other weekday, for instance.

Hey Chuck! Guess what I'm currently working on?

Won't be adding individual taskbars just yet, though, but at least you will now be able to reserve screen space in different monitors *and* the NextSTART taskbar will do the same even if it's not positioned in the primary monitor.

There is one problem with setting reserved areas on multiple monitors that I'm still wondering how to solve, though: what if a monitor gets added (or removed) and that shuffles the order of the monitors? The reserved areas will then no longer be in sync with the actual monitors.

See? Things are generally not as simple or easy as they look at first sight.

I think I just had a brain fart (pardon my French)!

I was watching a video on Youtube comparing RocketDock Stacks docklet with Nexus sub-docks and saw a comment from a user saying something like 'I wish Nexus would not unmagnify the dock before opening the sub-dock', which is how RocketDock does it.

Something else that caught my attention is that the author of the video had his Nexus dock background almost transparent, so the Nexus sub-docks popped up almost as icons with no background... and it looked so much better!

That got me thinking... exactly why does the main dock unmagnify when opening a sub-dock? Why does it have to stay that way while the sub-dock is open (the answer is so that it does not overlap the sub-dock when magnifying)? And why are sub-docks forced to use the same background as the parent dock?

The reasons go back to the origins of docks, well before Apple came up with a magnify effect.

Back then docks were made of square tiles, i.e.; each dock icon had a tile background - so, when you opened a sub-dock it made sense to have those tiles align. It was almost as if the sub-dock was sliding out of the parent tile.

But that was then. These days you will only very rarely see a tiled dock background. And since most of the dock backgrounds are free-form, it makes no sense trying to 'glue' a sub-dock to the parent dock as if they were pieces of the same puzzle.

Also, there really is no practical reason why sub-docks should not have themes/settings that are independent from the parent dock. Internally their data structures are exactly the same as those of main docks, with exactly the same abilities and properties.

So, here is what I am thinking about adding: first a global setting which allows you to control if sub-docks *always* inherit the settings of the parent dock (i.e.; the old way).

If this setting is off, then a 'Sub-Dock Properties' option appears in the right click menu of sub-dock icons. This would pop up a tabbed properties dialog (like the one you get for in-shelf docks) allowing you to apply specific themes to sub-docks, lock their themes (so they wouldn't change when applying a new theme to the parent dock), make their background fully transparent, etc... all independent of the parent dock.

As for the main dock not magnifying when a sub-dock is open (so it doesn't overlap the sub-dock when you accidentally move the mouse over it on your way to the sub-dock, making a huge mess), this is only a problem if the application is trying to 'glue' sub-docks to their parent docks.

If, instead, magnification is taken into account, the sub-dock would open sufficiently far away from the parent dock that the main dock magnifying would no longer be a problem.

This would also allow me to keep the sub-dock icon magnified (as a sort of indicator as to is the parent icon of that sub-dock) when the mouse pointer moves away from the dock into the sub-dock. Of course, if the user then moves the pointer to the main dock, then it will resume normal magnification.

The best part of this is that if the user does not use the magnification effect, then docks and sub-docks will still be 'glued' to each other, just like old times and when it makes sense for this to happen.

All these could be pulled off easily and still in time for this release. What do you guys think of the idea?

And by the way, this is a precursor to native Stacks docklet support. But that won't happen yet.

Sweet! It may not be as easy as first thought, but know where there's a will there's a way!