Hmmm... Found another potential problem with NextSTART only docks being docks that are disabled:

As you know (or not) I'm very careful about not wasting CPU cycles. Therefore certain functions (for instance, stuff like measuring CPU activity, RAM usage, etc...) are ONLY performed if there is a dock or Shelf item set to use them.

For instance, if there isn't a battery module anywhere, then the function that monitors battery status is disabled (i.e.; doesn't run at all).

Battery modules in docks that are currently disabled (or in any sub-docks of that dock) ARE NOT TAKEN INTO CONSIDERATION.

And here lies the problem. For instance: music will play until you stop it or exit the application while there is at least ONE valid instance of the Media Player somewhere in a dock or Shelf. But if you delete the last instance of a Media Player IC while it is still playing music, the music will stop automatically. And this is how it should be.

But what if you put, for instance, a Media Player IC in a NextSTART only dock (i.e.; one that WorkShelf sees as disabled)? As soon as you close that dock the music will stop playing, because that single instance of the Media Player IC, being on a disabled dock, will not be taken into account. WorkShelf will think there are no instances of the Media Player IC anywhere and stops the music.

Taking disabled docks into consideration is not a valid solution IMO, since then we would run the risk of wasting CPU cycles running stuff that isn't actually used anywhere on docks that are active.

So it seems we need a way to distinguish between NextSTART only docks and docks that are actually disabled.

Alternatively, I can ask NextSTART if it is hosting that particular disabled dock. A bit more complicated but probably worthy it.

maybe sub category of disabled dock, like 'nextstart only'? and when nextart tuns itr flags (while running only) docks attached to ql as 'nextstart only', on exit it removes the flag

Vlad, not sure I can fix this in time for the next beta, since I'm in a hurry and I need more info.

Is the shift you are talking about the same shift that happens when you click and hold the button? How about a screenshot?

Wow. Now THAT is an hotspot button. lol

And yeah, nothing to do with the pressed position. Any idea what triggers that shift?

Problem: going to Dock Proprieties - Position Tab - offset slider, if you change the value to anything else then 0, you get the desired result on screen, it works ok when you click apply, but when you click ok to close the Proprieties windows, it resets to 0.

I think it is incredibly cool and also useful to activate docks via buttons.

- the same bug applies when it comes to icon and labels on the button, everything gets shifted to the left.

- If you change the name of a dock after you have created the hotspot, the hotspot does not pick up the new name, although it still works and activates the dock.

- The grouping does not seem to work, meaning: I have 2 diffent docks at the top, I have created the hotspots and linked them to the desktop buttons, 2 different buttons both in the same group named "Docks Top Side". As I understand from the description, clicking one button from the group will activate the coresponding dock and close any other from that group. It does not happen, both docks remain activated until the second press of the corresponding button.

- When I created the hotspots and linked them to the buttons, when I was clicking Apply or Ok, all the buttons got placed on top of one another every time I prest those buttons. But now this is no longer happening, clicking apply or ok keeps the existing buttons in place. They do not get disturbed not even if I create a new button, weird. I only mention this because there is a reason why this is happening and maybe it is something in the code related to the first time creation,session or whatever is going on in the "Matrix"