Hi! Let me start by saying that I enjoyed reading your criticism and suggestions. It's obvious how much effort you put into it.



Great idea, makes sense, expect to see that in the next release.



Agree on lowering the limits, not so sure about the 10 ms intervals. Also, don't forget that to delays of auto-hiding and showing the dock, you have to add the duration of the show/hide animations - it all adds up. Animation speed is set in the General tab.



Great idea too, expect to see that in the next release.



Under Nexus all you need to do is quickly double-click the menu entry in the parent menu for the sub-folder. Double clicking it opens the folder in Explorer instead of showing it as a sub-menu.



You mean the width?

Under Winstep Xtreme, Nexus uses menu skins provided by the NextSTART component. Maximum menu width is set by the skinner itself.

Under Nexus free, the menu skin is fixed and so is the width. I'll see what I can do. I don't want screen wide menus popping up because of extremely long filenames.



Yeah, that was a bug. I actually spotted that and fixed it last week, unfortunately just after the v15.7 release.



Alas, that has always been a sore spot, the UI has already gone through some revisions.

As usual the problem has to do with simplicity vs. flexibility. For instance, Apple likes to make things very simple so even a child can use them, but then power users complain because it lacks options/flexibility. Microsoft Windows is the opposite.

Finding the right balance is very tricky.

Winstep software is extremely powerful and customizable. While that is a plus, it also means it must have many different options and settings, because what user A likes and uses is very different from what user B likes and uses.

Organizing the UI thus becomes a nightmare: if I bury least used settings in secondary dialogs, users who don't like to explore will think no such settings exist and complain the program doesn't do this or that (when it actually does, it's only the settings for it that are not immediately visible). If I show those settings in the front line, the UI becomes cluttered and users become lost in the midst of all those options.

Then you also have those settings that belong in more than one category: for instance, they are related to behavior but also to some other options that have to do with, say, appearance. Or a positioning setting that influences whether a behavior setting is available or not.

If you organize them by category alone, settings end up scattered all over the place, if you organize them logically, they either end up in the wrong category or repeated several times throughout the UI. Not sure what is best.

Then we also have aesthetics. Another nightmare when I add more options/features and then have to find room in/reorganize the UI to make them fit. Scrolling interfaces/option panels might be a solution, but personally I really dislike them: for instance, it's very easy for the user to miss that there are more settings buried below the visible threshold.

Hello there!
I want to suggest you 2 small features:
1. add ability to change system tray position to the other side
2. add ability to set item absolute position ie always first/last/third from left/etc

Cannot do or find such simple thing: flip over windows taskbar. my dream is (clicable):

Ok, I changed the code so that in the next release you can set individual folder shortcuts to open as a menu when clicked on (via the Item Properties Editor), prevented the docks (and the tabbed dock) from auto-hiding while the mouse pointer remains in the edge bump position, auto-hide delay now ranges from 100 ms to 5,000 ms in 100 ms increments, and the activation/edge bump delay now ranges from 0 to 2,000ms also in 100ms increments.

No need to have increments smaller than 100 ms, average human reaction time is about 215 ms, you would never notice the difference.

Tweaking these settings, together with the animation speed setting, should now provide the lightning quick responses you want.

Yes, this wishlist is still being looked at.

I've gone one step further than capturing the Windows language bar to the Winstep taskbar: I completely emulated what it does. So in v15.9 (upcoming new release) you have a new 'Language bar' internal command which you can add to the taskbar, docks, menus, Shelf, hotspot buttons, etc...



As for shortcuts to Metro apps, v15.7 already does that but only under Windows 10, since MS finally added the bare minimum support necessary for something like that. Windows 8 is hopeless.



The problem is the taskbar coming forward on the z-order when it detects a mouse bump on the screen edge it's attached to. It doesn't do that if it thinks a full screen game or application is running, but some games must be 'special' and fool NextSTART (and WorkShelf) into thinking a full screen application is NOT running (which explains why you only had this problem on some games).

Anyway, for v15.9 I just added a new 'Bring taskbar forward when the mouse pointer bumps screen edge' setting to the Taskbar Advanced Settings dialog to control if the taskbar is given focus when the mouse pointer bumps the
associated screen edge or not. This should solve your problem.

As for the other z-order problems you had, with docks sometimes coming to the foreground when they shouldn't because they're set to 'Always on bottom', I know why this happens and it's a tough one to crack.

The problem is related to WIN+D (Show Desktop) and detecting when Show Desktop is active, because you want the docks, taskbar, etc, to remain visible when the user presses WIN+D.

Windows deliberately does not send applications any notification that 'Show Desktop' is in effect. Instead it silently raises the desktop window above all other windows, and everything behind is thus 'hidden from view'. For the docks to remain visible, they must detect when this happens and 'transfer' themselves (in the z-order stack) to the top of this desktop window.

So, the problem is detecting when Show Desktop is active. Before Windows 7 there was one way, the Desktop window (usually ProgMan) would become owned by a full screen window with a 'Worker_w' class. So, when this happened you would know Show Desktop was active and do the necessary work to make the docks come up as well.

Windows 7 itself already put a wrench in this: when wallpaper slideshow is active, Progman becomes a permanent guest of that Worker_W window. At least under Windows 7 this only happens in that case, under 8 and 10 it's worse.

So, even when 'Show Desktop' is not active, if you click on the desktop (say, to launch a shortcut in it), Progman becomes the active window. Winstep goes to look if it is owned by Worker_w (which it is when slide show is active, or almost every time in 8 and 10) and thinks that Show Desktop is active, thus raising all the docks in the z-order, including Always on Bottom docks. They are sent back as soon as you click somewhere else, but in the mean time the user has already seen confusing behavior.

Unfortunately I still haven't found another reliable way to detect when 'Show Desktop' is active, so I am left with this problem: either the docks become hidden when you press Show Desktop *OR* you see unexpected z-order behavior from time to time.

Still working on solving this, as I mentioned.



I liked it so much that I implemented all that in v15.9. You can now activate docks by either bumping or swiping, and you can control swiping distance, timeout for a swipe to be recognized as such, and also limit the distance the mouse pointer can travel in the opposite axis for an edge bump to be detected as such.

This should help immensely with accidental dock activation.



Alas, unfortunately this cannot be done, because edge bumps, swipes, etc, are not detected by the docks themselves but by a global monitoring routine running in the background. It is this routine that dispatches edge bumps etc to all the docks that will respond to it. Because this routine is global, so are the timings that rule it.

This said, whether a dock now responds to a swipe or an edge bump is an individual dock setting. So you can have some docks being activated by a swipe and others by an edge bump. Limiting the distance the mouse can travel when bumping a screen edge should already help a lot with bringing down the number of accidental activations.

You just have to be careful in not using very low values, as edge and swipe detection then become a bit unreliable from what I am observing here (this seems to be a limitation of the mouse driver itself, not Winstep). For instance, imagine you do a quick horizontal swipe of the top screen edge: instead of returning a pretty linear progression of the mouse pointer coordinates, the mouse driver returns something like this for the x coordinate: 0,0,0,0,0,0, 11, 37, 83, 159, 246, 321, 380, 408, 422.

Even though I was moving the mouse pointer the whole time, notice how, in the first 60 ms (coordinates are fetched every 10 ms) the mouse pointer (according to Windows) was standing still, and then quickly accelerated. There seems to be some kind of interpolation being done on the mouse driver level.

So, if you set the swipe time limit in this case to, say, 60 ms (the software will not let you go that low because of this issue), the swipe would fail because, as far as Windows was concerned, the mouse pointer wasn't even moving during that time (even though it was).

Hello,

I am a new user of the free version and noticed a missing functionality since Windows 7 era.

If we Ctrl+Click on the taskbar, it does a fast switching between windows of the same application. Similary, a Shift+Click launches a new windows (provided that the launched application settings allow multiple windows).

Sadly, in the dock, a Ctrl+Click and Shift+Click closes that Window - which is annoying for usability as I would be using computers with and without WinStep.

Could you please consider adding this functionality.

Sorry, you're too late. I added it already, perhaps a couple of weeks ago.

I also felt for some time that there was some key functionality missing, especially when talking about the NextSTART/taskbar component, so on v15.9 (which should be out this Monday or Tuesday) I focused a lot on that.

Besides a ton of other important features that were missing until now (such as support for high-DPI screens and resolutions, a language bar, etc..), the dock can now act a lot like the Windows taskbar: icons in the dock double up as application and tasklist icons (so you only get 1 icon for, say, Firefox, instead of one in the dock and another in the tasklist portion of the dock).

And yes, provided 'Do not launch multiple sessions of the same application is enabled', left clicking the icon will bring the application forward, Shift+Left clicking (or double clicking) will launch a new instance, and CTRL+Left clicking will cycle between all open windows of that application.

How's that for customer service?

Wow, that's excellent.



I wished that as well (undocumented).

Speaking too early or may be too late (again) - so probably, jumplists would be the only remaining feature from the Win 7+ taskbar.

Sigh, I looked into that as well, but I ended up getting nowhere. Microsoft implements less and less stuff using pure Win32 API, which makes my life very difficult.

I did work on something which would associate recently open documents to a particular application, but it wasn't the same thing so I gave up on that idea... for the time being.

As I see development is still going on (nice ) I would like to see a possibility to organize Nexus' sub-docks by rows and columns (like stacks) or just make them sizable and auto arrange the icons. That would be a killer-feature.

That will never happen in a *dock* because that is not what docks are. Docks are, by definition, single row and non-scrollable.

Also, remember the Shelf in Nexus Ultimate and Winstep Xtreme already does much of that.

This said, a new feature I have been thinking of for an upcoming release would be something like Apple's Launchpad (check it out on Youtube), a cross between what you are describing and a Stacks docklet, with the ability to have one level of nested folders.

It would NOT be available in the free version of Nexus, though.

First of all, really nice work with last update

Now, I'm going to just quote myself. In this very same thread, about two pages ago, I wrote this unnoticed comment:


Do you think it could be possible? Or there is any '.ini' file I can change to get vertical taskbars to tile bitmaps correctly?
Right now I'm getting really strange bitmap tiling with vertical taskbar in NextStart. Plus I can only shrink them up to a very wide size (for my tastes). No matter what theme I use, I can't get what I want: an about 48px wide vertical taskbar.

Great work. How about the pinned items to dock showing thumbnails when they are launched. Just a thought to keep harmony.

Thanks for the update.

Lol. I was wondering when someone would ask me that.

Id love a larger zoom for the magnify effect, current is 255 pixels, if it could go up to 300 that would be perfect

Any chance of that in a update?

I have kind of switched from taskbar to Nexus. The key to make the switch was to reduce the vertical icon spacing to 1 and remove the reflections.

There are few things bothering
1. The separator that separates dock items from running items cannot be removed. Please allow to remove it
2. The action center icon from system tray doesn't show up in the system tray. I know that there is an internal command but it commands too much of space in the dock
3. The taskbar has a very thin bar besides the system tray that allows to peek the desktop (which also ends up as a show desktop toggle). Would be really nice to have that bar besides the systray.
4. Some stuff is available as internal commands (task manager, show/hide taskbar, minimize windows, cascade windows, restore windows, hide/show desktop icons ) but they command far too much space. In my opinion they would be better placed in a right click menu. Definitely not all because it would be too cluttered. 7-8 quick launch can be good number.

Also, is there any way that the cascading menu opens on hovering rather than a click