This is actually by design, and the same thing happens with sub-docks, sub-menus, etc. Functionally opening a sub-dock and then immediately closing it as you move away is not very good, as it prevents you from dragging an item from the parent into it.

The menus, sub-docks, grid-stacks, launch pads will close as soon as you click away from them OR you open another sub-dock, grid-stack, etc, by mousing over it.



Sub-docks inherit their settings from the parent dock by default (this can be changed though) but this make sense because a sub-dock is, as the name implies, just another dock.

Grid Stacks and Launch Pads on the other hand are very different beasts with different purposes. Each has it's own Properties screen (right click -> Grid Stack Properties), and you can set their icon size, etc, there on an individual basis.

Even if you don-t like the defaults, you only have to change them once.



Yes. Just change the icon as you would for any other item. Right click, item properties, change the icon there. Or drop a PNG image file into the Grid Stack/Launch Pad icon.

You can even change the default icon if you really want, but for that you would have to overwrite/replace the default icon in Public Documents\Winstep\Icons\Samples\.

I only have one operational system set up at the moment (as I'm rebuilding my home lab) so if I backup the Winstep settings can I easily roll back from installing the Beta?

If necessary.

Updates always backup the executable files they are about to replace (e.g. workshelf.exe, nextstart.exe, etc) to

\Public Documents\Winstep\Backup\

Going back should not be necessary, but if you need to do that let me know first please, so I can provide more detailed instructions.

Also, the beta is an UPDATE, so it MUST be installed ON TOP of an existing Winstep Xtreme installation. By all means backup your settings, but do not uninstall anything.

Is this really an issue if you are dragging an item from the parent to the sub-dock / grid stack /....? I would have thought that if you drag an item over the subdock / grid stack, which then displays (opens), then you could drop the icon before you move away.


I saw that the properties option was available (and indeed have used it), but they have to be changed per grid stack. So if I'm inserting a number of grid stacks into a workshelf these properties have to be set each time.

However I'm not going to be doing it frequently so its not a major issue.


Ok thanks I will give that a try.

And that's how it works too, regardless of the open on mouseover setting.



Might be an idea for a future update, a button in one of the Grid Stack's Properties screen saying "Make this configuration the new default".

Yes but then the grid stack remains open.

Not a big deal if thats your preferred manner of operation.
I would just prefer it to close again.

Beta installed.

Some initial feedback:

1) Selecting groups of items by Shift and Ctrl seems to work OK
2) Combining these operations across different lines in the shelf works OK
3) You have to remember to start by pressing the Shift or click button, otherwise the item activates. This is fine just needs to be clear, although people will soon work it out
4) Selecting an item / items then pressing ESC does not deselect them. Clicking elsewhere on the desktop does not deselect them. You need to click elsewhere on the workshelf. I would have expected ESC to allow you to exit from the selection process.
5) You can Shift select a group then again use Shift select to extend / reduce the group, but the original selected item always remains selected.
6) Pressing CTRL select enables the selected item to be deselected.
7) Grabbing the selected items while pressing CTRL allows you to copy the items into a grid stack or another workshelf provided the type is correct.
8.) Similarly grabbing the selected items while pressing Shift allows you to move the items (as above).
9) Strangely when moving / copying sets of items between workshelves and grid stacks the item order kept reversing - it was consistent in each location. Need to look at this more.
10) Deleting a group of selected items did put up a confirmation dialog box listing the number of items to be deleted.
11) Right context menu is not impelemented yet - just deselects all items then presents the context menu for the item that was right clicked.
12) Can't select items between workshelf tabs - selecting an item (or items) on one tab and then moving to another tab results in the same position items being highlighted as selected on the this tab.

I'll play with this a bit more, but don't have anymore time now.

The implementation looks good, with a few quirks (which may be intentional), however I haven't tried out any normal functionality during this brief testing - hoepfully this won't be impacted.

First and foremost, thanks for all the feedback!



ESC does not deselect items in an Explorer window either. I could make ESC deselect items but given this I am not sure if I should.

Likewise, clicking outside an Explorer window does not deselect the items in it - you need to click inside the window itself.

Plus, Windows does not forward clicks outside Winstep windows/screen objects to the Winstep application, you must either be "listening" for this or capturing mouse events at the time - the latter potentially leading to issues like the one in the other thread about desktop double clicks.



Yes, this is what happens when you move/copy them to the END of the shelf. I don't like it either but that's also exactly what would also happen if you copy pasted shortcuts to the END of the Explorer folder window (try it and you'll see what I mean). It has to do with the order in which items are inserted and how they are inserted, which has to be reversed otherwise you would see this happening when dropping items into the middle of other items instead.

Anyway, it's something I will try to work around too.



Yeah, that's a bug, thanks, it should not happen. I reproduced it here by holding CTRL while switching tabs.

I'm fairly certain the term "Launch Pad" is used elsewhere already but alas don't have the time to do a search. That said, I think "Launch Stack" is clearly the more accurately descriptive term but it also doesn't roll off the tongue very easily or comfortably. But then, "Launch Pad" certainly also doesn't seem a fitting description anyway - it somehow recalls a traditional dock. Just food for thought.

Apple's Launchpad. It provides a simplified, grid-style interface for accessing all installed apps on a Mac—visually similar to the iOS Home Screen.



Yes, Launch Stack is a little bit more descriptive, but Launch Pad rolls off the tongue better and matches the actual icon better too because of the rocket.

Exactly my thoughts. I never can understand, why windows users asked for Mac stuff. My main interest is customising windows themes. The amount of people that ask for mac themes, or want mac buttons. Just buy a mac. Launch Stack i thought was pretty adapt, and different.

I'm tempted to try this version, lol

Been playing a bit more with multi-select this morning, so further feedback:

a) Selecting set of items from workshelf and CTRL dragging them to Nextstart task bar copies them to the quick launch area. Can't multiselect there so have to delete individually.
b) SHIFT dragging them to task bar also copies (not moves) them to the quick launch area. Don't know if that is intended?
c) Copying a set of items that includes a grid stack to the task works the same way, with the grid stack becoming an item that can have items added to it in the workshelf which then appear in the grid stack as seen from the task bar. Can't drag items to the grid stack in the task bar directly. This probably is expected but was interesting.
d) At different times Avast blocked Nextstart and then Workshelf stating that they had been identified as IDP.Generic. Creating exception solved this, but may want to be aware.
e) Interestingly moving / copying a set of items into the end of a Dock retains the item order.
f) Copying a grid stack from a shelf to the dock works similar to the taskbar except that subsequently adding a further item to the grid stack (in the shelf) does not enable that item to be seen in the dock version of the grid stack. However another item can be copied from the shelf to the grid stack on the dock. Presumably the task bar keeps a pointer to the grid stack whereas a dock gets a snapshot copy.
g) Items (or multiples thereof) can subsequently be added to this snapshot.
h) Items have to be deleted individually from the dock - it is not possible to select multiple items.

I don't use docks so am not really aware of their properties, but was interested to note that SHIFT clicking on multiple items launches them simultaneously once the SHIFT key is released.

i) Same behaviours seen for Launch pad as for grid stack (unsurprisingly)
j) If you drag an item / set of items over a grid stack or launch pad in a dock then the related stack window opens and you can choose to place the items in there. If you try to just drop the items onto the grid stack or launch pad icon then they just get added to the dock.
k) If you open a grid stack or launch pad (stack) and select a few items and try and copy/move it to the other then the target stack does not open - so this is not possible. Dropping the selection on the icon performs as above with items being added to the dock. I assume that there is a limitation on having two stacks from the same dock / shelf visible simultaneously - potentially related to the open / close when 'mouseover'ing' discussed earlier.
l) You can place a grid stack and a launch pad within another grid stack. You can't place a grid stack or launch pad within a launch pad. Interestingly though if you try to drag a couple of items that include a launch pad into the same launch pad window (or a couple of items that include a grid stack into the same grid stack) the icon gets a stop sign added and nothing can be added - presumably to stop recurrent nesting. However if you do the same with a group of items that include a different grid stack or launch pad then no stop sign is presented and dropping the selection results in all items other than the grid stack / launch pad being placed in the target launch pad. Similarly, if you try and drag a grid stack or launch pad to a second launch pad on its own then no stop sign is shown but action doesn't happen.
m) You can place a grid stack within itself if you do this via another grid stack, but the opening of grid stacks stops when it reaches itself again.
n) If you enable 'open sub-docks on mouseover' then a few strange things can occur, particularly if the popup delay is short:
_1] Placing the mouse on a launch pad causes the associated stack to be displayed, but then pressing on the launch pad icon just causes the stack to be hidden - a second click then operates the launch pad.
_2] However if the launch pad is nested in a grid stack, pressing on the icon causes the launch pads stack and the parents stack to close. One may be due to the selection, the other due to hiding stack when another stack is actioned? Either way you are unable to action the launch pad in this situation.
__2a] If you do the same with 'open sub-docks on mouseover' disabled then selecting the nested 'original' grid stack just closes all of the stacks back to the same named one.
_3] If you place a launch pad in a sub-dock then the same behaviour as _2] is observed.
o) If you copy a grid stack (GS1) into another grid stack (GS2) and then add an item to the original grid stack (GS1) it does not appear in the nested grid stack (within GS2). Similarly if something is added to the nested version it doesn't appear in the original - presumably the nested version is its own instance.
p) At some point I managed to get orphaned nested grid stacks, which when clicked made the activation noise / bounce but didn't display a stack grid. I got at least two of these, I think by deleting their original stacks, but was subsequently unable to reproduce this effect. So don't know currently!

I've just noticed while playing with this that the sub-dock properties which I thought were associated with an individual Workshelf (as indicated by the big Yellow arrow pointing at it), are in fact global. If I change the 'open sub-docks on mouseover' on one workshelf then it is also applied to others. Is this intentional? Its not what I thought the arrow implies.

I don't know if you want to continue adding feedback in this topic or whether you would prefer it to be separate?

Sometimes its a case of not being sure what should happen - although there are instances where things happen that I wouldn't expect!

Keep going, you are doing a great job, thanks! I'll reply to your points above as soon as I can.

By design.



You can but you have to open it first (press ALT + Left Click on the Quick Launch icon). There is no open on mouseover for QL items.

Having Docks, Grid Stacks and Launch tabs (which are WorkShelf objects) available from NextSTART is a "quality of life" improvement, but we must keep in mind that this objects are not native to NextSTART.

In fact, those items in NextSTART are simply pointers to the real thing in WorkShelf. And for them to do anything WorkShelf must be running (you get an error message if it isn't).



Exactly!



Didn't try it yet, but I did just fix the order when adding items to the end of a shelf.



LOL I actually had no idea it would do that until you pointed it out.

This is the by product of a "safety feature", pressing SHIFT opens a new instance but if the SHIFT key is being pressed when the item is launched via ShellExectuteEx the application you just launched does NOT get the focus. So to prevent the dock holds off launching it until the shift key is released. This in the mean time allows you to add more items to the queue, but this was not intended. Not a bad thing, so I won't fix it.



Yes, but I probably will change that. If you drop an item into a sub-dock icon, the item gets added to the sub-dock, so the same thing should happen if you drop an item into a grid stack or launch pad icon.



This and the fact that the source grid stack, launch pad or sub-dock MUST remain open to complete the drag & drop operation. If the source object unexpectedly closes (and it is possible to make this happen although not by design) the application won't crash, but what should be a move operation can end up becoming a copy operation instead.



By design. Launch Pads only accept items that can be launched/executed.



Yes. There are safeguards in the code to prevent the user from dropping a container object into itself (or anything hosted by it).



Again by design. The alternative was to forbid everything, but I thought it worked better this way. Filter out what the Launch Pad does not allow.



To simplify things so the above is allowed to happen. I can add code to actually test for that specific case (i.e. where none of the objects being dragged would be accepted by the target Launch Pad), but I'm not sure it's worth it.



A click when a Launch Pad is open ALWAYS closes it. To activate the launchpad it must be closed to start with. Better this than launching a bunch of items by mistake when your intention was to close an open Launch Pad you had just been editing the contents of.



AND that is a bug. Well caught, fixed it thank you.



A copy is a real copy, everything included whatever is nested within it gets a new individual and independent instance.

The only exception, as noted above, is when you drop a Grid Stack or Launch Pad into NextSTART, since what you get then is a "pointer" to the real thing.



Hmmm... this would be one well worth being able to find a way to always reproduce.

Also, since this happened: Preferences -> Advanced tab -> Troubleshooting Options -> Check Integrity of Docks & Shelves.



Yes, it is intentional. Some options are global.

The big yellow arrow allows you to immediately know which object that Properties window belongs to, since you can actually have multiple Properties windows open at the same time.

Settings with a small globe next to it are ALL global (hover over the small globe and you should get a tooltip pointing this out).