I would like to see more dock behaviours like:

- dodge windows like in Linux distros, which allows to keep dock visible, until either window will touch it, and when one or more windows are filling up whole screen, then just hover over the screen edge where the dock is hidden to show it



- the one I've requested while ago, allow for dock to have an offset which allows to interact with the dock

@lubierzca - that is a cool feature Nice.


@Jorge - I'll keep asking for skinners who make graphic aesthetic main menus to have the feature of "Do not rescale main menu on drag" = True/False in the *.wst files
A simple 'more' addition at the base enabled if true, like in the huge menus would compensate I think?

Ok, just so you know I implemented this request but I am not sure I am going to keep it, at least not as is since the current solution does not work well.

There is something very important you need to realize: Windows is not MacOSX.

For one, OSX does not have a taskbar at the bottom of the screen, the dock IS the taskbar. I imagine many if not most users run the dock together with the Windows taskbar, possibly sitting right above it.

Anyway, the dock, like any other window, only receives mouse actions/notifications when the pointer is over it.

To get notifications when the mouse pointer is not over it you basically have use a mix of polling via a timer together with SetCapture. The problem with SetCapture is that it captures mouse input for the specified window only if the mouse is over that window or a button was pressed while over it and remains down.

When that is not the case, as most often isn't, then the mouse position must be polled with a timer. Since a timer has a minimum resolution (something like 30 ms), the icon magnifying effect will never be as smooth as actually moving the pointer over the dock.

Another issue is that even if you capture mouse clicks into the dock, this clicks still "pass through" to whatever window is underneath. So, for instance, if you have the dock offset from the edge so it sits a bit above the Windows taskbar as mentioned above and you left click, this will also activate any button in the taskbar underneath the mouse pointer.

So, the solution I came up with with SetCapture and the timer is nowhere near a good solution. There is something else I can try though which would probably work better and solve all these issues, but it's more complicated than I would like.

Ok, implemented the other possible solution and it works great, none of the drawbacks of the previous solution.

There are still a few specific drawbacks/limitations though:

1. If a window is overlapping the dock, mousing over the part of the window that overlaps the dock will not activate the dock.

2. You cannot access/click any part of a window or other screen object that is behind the dock in the space between the dock and the screen edge. You can see whatever is behind the dock, but clicking on that space will direct the click to the dock and not to whatever is behind it.

For the purposes you want (i.e. a small gap between the edge of the screen and the dock) this should work fine, but I have a feeling this setting can potentially cause a tremendous amount of confusion for users who do not understand how it works.

I see, I appreciate that you try to figure this out. I'm not crazy about that feature, but I thought that people may like to have it as an option, more customization options are always better for consumers. I would like to know what you think about the other feature I've suggested.

Not necessarily.

This is one of the reasons why I don't implement every single thing that is suggested to me, only the stuff I find genuinely useful for a good portion of the users.



It's smarter than a simple auto-hide based on a timer, but I'm not sure yet how feasible this would be on a Windows system. I want to avoid having to poll for stuff (such as the position of all visible windows) as this further consumes CPU cycles.

That's almost exactly my point always! Too many options/choices are never a good thing. Just look at the utter madness and mayhem of today's consumerist society.


Ye gods! Who needs that! If you want Mac features, use a feckin' Mac. :/

Good grief, yes, of course it's going to confuse the heck out of a lot of users! I think it'll cause more problems than it's worth.

Could be. To somewhat mitigate this that setting only becomes visible if the offset from margin is set to something larger than 0.

Something I noticed with modules from skinning in different resolutions copying themes to different machines 1920 / 3120 / widescreen 8K

The "Lock" for a module is Global. Great for people with a theme here and there where they want the identical module types to appear in the identical position regardless of theme...
That said... A "lock" option per theme because honestly, "Desktop Modules /Save Module positions" does not work all too often. I do not know whether it is tied to having a lot of themes or what but it definitely at random does not always save with recall per theme the module positions, or resets them? No fricking idea why. I have no idea what triggers that so a lock where it cannot be dragged per theme or moved on recall seems like a better idea?

Can confirm that here - mentioned it (at least to Jorge) in the past. Per theme lock of mods would definitely be great, if it isn't too much hassle/causing problems.

Thanks for the support


I also found an 'almost'(loosely) workable batch of settings for all resolutions for skinning. 'If at first you don't succeed..."

I found that keeping the main font around no larger than 10 and the vertical button menu to between 16-22(max) seems to keep the look and feel. Only one them of all I have done it hasn't. I can live with that because it's a heck of a lot better than redoing all of them.

"If at first you don't succeed, give up!" (Homer Simpson) 10 seems pretty small though. But, if it works as a workaround...