I agree with this completely with one addition. I STILL believe that the ability to add config lines that can be overridden by the user selecting colorization, to allow a skinner to colorize every workshelf and tab at skinner level is not a silly idea. Some themes could really benefit from perfectly matched tabs and shelves with different variants of the same colors that sit with the theme or as you have done, all different colors. If they want fluorescent purple and lime green they still can. I'll rephrase that, I know it is a good idea, you just do not seem to want to do it.

You THINK it is a good idea, but it isn't - and that is why I will not do it. Not because I simply don't want to. The fact that I also don't want to is merely a happy coincidence.

Besides, I think we're talking past each other a little here.

The problem is not whether a skinner can come up with a nice set of colors. Of course he can. The problem is that the skinner has no control whatsoever over the actual tabs the user has on his Shelf.

You don't know whether the user has 3 tabs, 8 tabs, 20 tabs, whether he has renamed them, reordered them, added new ones or deleted existing ones. So if the theme contains something like:

Tab 1 = blue
Tab 2 = green
Tab 3 = red
Tab 4 = orange

those colors are being assigned purely by position, not by meaning.

Suppose the user's Projects tab happens to be tab #3 and therefore becomes red. After using the theme for a while, he naturally starts associating red with Projects.

Then one day he deletes tab #2.

Projects immediately becomes tab #2 and is now green instead of red.

Nothing about the Projects tab changed. Only its position changed. Yet the skinner's color assignment changed with it.

That is exactly the kind of thing I want to avoid. Tab numbers are not tab identities.

And beyond that, I really do not want theme-level colorization choices overriding the user's own choices. The theme author defines the skin. The user decides how that skin is colorized.

The user is king.

If the user wants every tab blue, every tab a different color, all tabs in shades of the same color, or fluorescent purple tabs on a lime-green Shelf, that is his choice. Loading a theme should not silently replace appearance settings the user has deliberately chosen just because the skinner prefers a particular palette.

It would also make the theme format more complicated for very little practical benefit, because now themes would have to carry around arrays of possible tab colors for an unknown number of tabs, even though the skinner has no way of knowing what those tabs represent or how the user's layout will evolve.

What absolutely does make sense is for skinners to create themes that respond particularly well to colorization. That is exactly what these Chroma themes are about. You can design the artwork so that Hue Shift, Tint, etc., produce beautiful results.

But deciding what colors the user's actual tabs should have is, in my opinion, one step too far into user territory.

I understand all of this. I know we sometimes get ahead and behind each other, but that happens with creative people because the brain is perpetually on the go, and VERY normal.

I figured you may have missed the 30 TABS I mentioned before. In other words it would be more work for the skinner which I fully understood when I suggested it. It is extremely unlikely anyone would have more than 30 tabs, they'd be getting so small they'd Be unreadable nearly with "Control Panel" and other two word tabs. They also be set to cycle after 20 colors if you wanted to simplify it further.

I get what you were saying but I figured if the skinner wanted to bypass the normal two, then they had to make 30 so the hard work wouldn't have been yours post creation. All good. Some of my themes, they cannot color no matter how much they may wish because they're dark and you have no lightness/luminosity slider for the user anyway. So I agree to disagree. I stand by it and you stand by yours.

So there's a useful one - up the user control on color which you have said perpetually is your focus and give them fine tuning on saturation, hues/tinting and luminosity (3 sliders) like your disk monitor has.

This is a fascinating conversation. Is it not complicating things, where there isn't a need. The whole point is to provide the user, with a way to style it, how they like. Generally everyone thinks they now, what the end user wants, without actually asking them.

It maybe, that once there is a beta out, to be hands on, then its unknown. A set of customisation options for shelves and docks, is an interesting addition. The issue is will the user stay using the tabbed approach. Some of us, use own own made dock. I know many like myself windows 11 theme makers, do too.

I normally use dark windows 11 theme, with the dark dock, with a touch of transparency. So my first thought, would be a dark tabbed dock. But i'm an old boring sod, so reds, yellow, purple wouldn't appeal.

No I did not.

The fact that you meant 30 tabs rather than, say, 10 doesn't really change the problem I was describing.

The issue isn't running out of colors. The issue is that those colors would still be assigned by tab position, and tab position is not identity.


No, three Hue/Saturation/Luminosity sliders would actually be a pretty bad fit for per-tab colorization.

At the moment the user chooses one color for a tab. Simple, immediate and predictable.

With three separate H/S/L controls, the user would have to adjust three sliders for every single tab, and the final result could not even be represented accurately by the controls themselves because it depends on the colors and tonal structure already present in the source bitmap. You would have to keep looking back at the actual Shelf while tweaking three different values just to arrive at the color you wanted.

That is a considerable increase in complexity for something that is currently accomplished by simply picking a color.

Once you're independently manipulating hue, saturation and luminance, you're also no longer really selecting a color - you're effectively doing image-processing adjustments against an unknown source image.

And again, multiply that by however many tabs the user has.

So for per-tab colorization, I very deliberately prefer one color = one choice. The colorization method then determines how that chosen color is applied while preserving the important characteristics of the original artwork.

Picking the right color for each tab is already troublesome and time consuming enough. Now imagine having to pick the right hue, the right saturation and the right luminosity for every single tab - while the actual result of those settings still depends on the source bitmap anyway!

That is not “more user control” in any useful sense - it is just making a simple task three times more complicated.

So, more controls are not automatically better controls.

As for themes that don't colorize well because they are too dark - that's fine. Not every theme has to work equally well with every feature. A skinner can deliberately design a theme to take advantage of colorization, as I just did with the Chroma set, but I'm not going to force older or unsuitable themes into it.



Yes, but too much choice can be just as bad as too little choice - sometimes worse.

There are plenty of cases where deliberately removing choices, after deciding what works best for the vast majority of users, actually produces a better experience. Apple under Steve Jobs is probably the classic example of that philosophy.

A good analogy is going to a supermarket and choosing between three or four brands or flavors of the same product. Easy.

Now imagine that instead of choosing the product, you had to configure it at component level: how much sugar, how much caffeine, how much artificial flavoring, how much acidity, how much coloring, and so on.

Suddenly one simple decision has turned into ten or twenty decisions, some of which you would practically need a PhD in chemistry to make properly.

That is not necessarily empowering the user. At some point it just becomes work.

Too much choice creates friction, complexity and eventually choice paralysis.

Good UI design is not about exposing every possible variable simply because you can. It is about exposing the choices that are actually useful, while making sensible decisions for the user everywhere else. It's a balance act.

It's your baby.
One fact remains you cannot recolor much darker textures well in Winstep unless there is some kind of visible color in there and you certainly cannot make it lighter or pastel. I made what I felt was a useful suggestion, if you do not, fair enough. I'll leave you to it. I am sure many people will find it very useful as it is.

A small but important addition has been made to the WorkShelf theme format: a new "ShelfThemeOnly" setting.

Historically, a ".wsw" file was enough for WorkShelf to treat a theme as a complete Winstep theme. Selecting it from the general **Winstep Themes** category therefore meant applying that theme name to all supported objects - Shelves, docks, modules, etc.

That assumption no longer works now that we have themes which are deliberately designed for Shelves only.

The new Chroma themes, for instance, need a "wsw" file because that is the Shelf theme configuration file, and they should still appear in the normal **Winstep Themes** category and on the Themes Shelf. But selecting one of them there should not cause WorkShelf to also change docks, modules and other objects to that same theme name when no matching skins were ever intended for them.

That is what `ShelfThemeOnly=True` fixes.

A theme marked this way still appears normally in the general theme lists, but when selected it is applied only to Shelves. The user's existing dock, module and other object themes are left alone.

This allows true Shelf-only themes to integrate normally with the existing theme system without changing the long-standing behavior of older, complete Winstep themes.

Also reduced the true minimum vertical icon spacing for Shelves by 9 pixels.

Previously, the slider’s minimum value of 10 actually meant a 19-pixel gap between stacked icons. The slider now includes the internal padding in its displayed value, so the minimum still reads 10 but now means an actual 10-pixel gap at 100% DPI, excluding any extra space needed for labels and reflections.

Existing settings retain their spacing, but will show a value 9 pixels higher in the UI.

The following screenshots show a Shelf with 16×16 pixel icons, no labels or icon reflections, and the minimum horizontal and vertical icon spacing. Even at this compact size, it remains fully functional with no visual glitches.

The only compromise is that the scroll arrows overlap slightly (but I will probably fix that too). With 16-pixel icons and a 10-pixel vertical gap, the row is only 26 pixels high, while the two arrows need 32 pixels.

And fixed! If there isn't enough room the software now decreases the size of the scroll arrows until they fit.

I Guess that is why, users would be able to change all aspects of the colours for tabs etc, you posted. The design is good. But i would be changing it to dark colours. The new tab dock has eased my fears, that the whole thing, would me to big, height wise.

@JORGE - Boom - I always meant to suggest smaller icons but never got around to it. Great stuff!! Will the user have a choice on smaller or bigger too, or scaling? You did it differently to how I might have imagined which is why I asked, because the way you did it I am not sure if accommodates scaling? I do not know or I would not ask. It seems with how you mentioned the DPI it can, but I am unsure.

What do you mean “suggest smaller icons”?! You were always able to use small 16x16 icons in the Shelf, remove the icon reflection and not use a label below the icons - that has been there since forever.

The only thing I changed was the minimum icon spacing, so icons can now be squeezed a bit tighter together than before.

And yes, DPI scaling is already taken care of. The icon size setting is still the logical size selected by the user, and WorkShelf scales the actual rendered size appropriately for the monitor DPI. Nothing about this change prevents larger icons either - the existing icon size controls still work exactly as before.

So this is not really a new “small icon mode” or a different scaling system. It is simply allowing the existing small icon sizes to be packed more tightly when the user wants that.

I thought by my post you might have understood that I did not understand and was unaware of that you could due to the lack of themes that use tiny icons in the workshelf.
I tend not to treat someone so flippantly or someone or treat them like a fool just because they do not know something I do or do not understand something I do. You have written a very involved application and while I know more than some I certainly know a lot less than others and this is true for anyone in any field.
If you came to me and asked if counterpoint was important in music and did not understand it I would not treat you this way just because you had no concept of it or had not used it to date., or were unaware it was present in all good music.

You say you do not speak English well, I think you understand it very well, you write too intelligently not to. I am taking a break. As for how long, If I post anything again, that will give a sufficient answer. That's the third time you have bypassed benefit of doubt.

I have turned all notifications to OFF, that way there is zero temptation to even look. BYE

No offense was intended, it's a pity you decided to take it that way. I was obviously surprised you thought small icons were a new feature, that’s all.

Just like with docks, icon size has always been a user choice and has nothing to do with themes (the only exception are NextSTART menus, IMO for obvious reasons).

Anyway, moving on...

What's going on with the guys? You are talented people! Too bad, too bad!