Hey, just wanted to remind you about a feature I've suggested, and was wondering if there are any plans to implement it?

+1 for this feature.



[Edit] Moderator's note - Spam removed - nexter [/Edit}

Spammer bot votes don't count.

Nah, they're far too smelly. And nasty too - Hidden spam in text. Never gets past me though.

@Jorge,

I think I may have found something useful "IF" where the Moon Phase module gets its information gives it?

"Next Eclipse" : Date : Time.

Finally something seemingly useful from moi

Hmm, sounds complicated. a) could be solar or lunar eclipse, b) assuming just lunar, partial or full? Add the complication this is locale dependent. Somehow, I suspect this would be well beyond the scope of this mod and its info source. Nice idea though, but there are quite a number of astronomy related apps available for both Windblows and Linux and I'm sure there's something that might cover this.

Incidentally, Fedora even has an 'Astronomy' Spin!

I also found a feature for skinners that would be very useful for the workbench.

Currently, there are options for two tabs, Active (wsFullTabA) and Inactive (wsFullTabI). I would not suggest it if I had not tried it for myself.
I thought I'd try some image trickery and it works for me, but the odds on it working for anyone else are the flip of a coin. I have enclosed an image to demonstrate. I personally only use five tabs. If someone uses any less or more than that exact amount it will fail and look terrible. This is because there seems to be around 22 tabs at once available for selection- probably more with folders etc...

If per se, the way it is was left as the default setting (which it already is), with an option of additional tab inactive *.png buttons in the *.wsw settings, with something (pseudo) like ButtonCount=0 that could go to say 12? - Even if it went to 12, it could do an inactive TAB cycle sequentially, so if the user decide to really clog up their workbench with 13 or more tabs, #13 onwards would get them in sequence e.g. TAB#1=TAB #13, TAB#10=TAB#22...so on and so forth. Am pretty sure this would not be a difficult array? In other words, whatever is selected as the TAB count cycles from settings of the ButtonCount=* in the *.wsw file, and if the skinner chooses only 6 tabs, then the 7th becomes #1.
I hope I am making sense?????

Simply, it won't be used all of the time, but for example in this, I am glad I did it in layers, because all but the official save file will have to go.

Here's what I am hinting at:

Cheers




@NEXTER - Thank you for the informed information

To be honest, I find this somewhat confusing. But, basically it seems to me that you're advocating having different inactive tab bitmaps. But why would anyone want them? AFAIC, it would only confuse things.

Oh, just a by the by FYI - it's Workshelf. Workbench was the GUI of the Amiga OS. (Daft name for it really, just like Desktop. Workspace or Workplace are more apt.)

My pleasure. Would be nice though if it turned out it could be done relatively easily.

Actually I like the idea and I understand the reasoning behind it, it's a way to color code the tabs. That makes locating the tab you are looking for much faster than having to read the tab titles.

ObjectDock Plus tabbed docks had this. In fact, I think this only really makes sense if the user can select which color to use for each tab.

That being so (and I am just thinking, would have to look at several themes since I guess this would not work properly with most of them), providing individual differently colored bitmaps might not even be necessary: the application itself could optionally colorize individual tabs based on user selection using one of several methods.

Your application of color coding is smart - That said the way you already have done the coding and looking at it I can speak with a small amount of accuracy; You have options for solid, gradient, bitmap and transparent bitmap on many features.

That idea of yours is the simplest. However, if you add a simple inactive bitmap option it would be easy enough to change one letter of the bitmap file? - for example - You have wsFullTabI.png as the inactive. As long as we know how many there are in color variations, the "I" would represent the first with each one after adding a replacement number - wsFullTab2, wsFullTab3, wsFullTab4 - so on and so forth.
That would kind of make sense? The user could also select the bitmaps the skinner created if they exist too - Yes, it makes it more convoluted, but simultaneously, provides options which is along the same lines
~OR~ to use the K.I.S.S method being me, itstays as is, with one inactive and one active which means easier navigation because the active is the only one with a different bitmap.


@NEXTER - Yes we are Troopers- AMIGA - Yes I had one of those and an ATARI 1024STE - I feel really old now So please allow me to claim a senior moment

Well, looks like one way or another it's in, Mr. Bassman. I still don't like the idea, especially not colourisation - it could really make an ugly mess of some themes and destroy the whole effect. Dedicated alternative bitmaps sounds the lesser of two evils to me.

Personally, when I was still using the Shelf extensively, I didn't need to read the tab to know which was which, I just knew it. Colour would have just confused things and gone against my minimalist grain for me.

Anyway, I've always held the view - and still do - that a theme that somebody's gone to the trouble to create should be immutable, not altered in any way. Like the theme or move on. Fortunately, themes in Linux can't be messed about with by the user.

LOL! Hey, I claim seniority, well ahead of you @BassdudeNZ. I'll reply further in 'Off Topic' forum, under 'Workbench' subject - don't want to go too far off topic here.

You already have full shelf etc colorization if that is your objection. Tab colorization would not work with every theme (e.g. the tabs in some themes have a transparent background as they are "incorporated" into the shelf body, for instance), but on those (few?) themes that it would work, this would at least become an option.

Going for the alternative bitmaps reduces that choice to nill at this point, AND it would make things a lot more complicated for me.

This way the colorization would be a property of each tab (e.g. right click, select Tab Properties) set by the user and NOT a specific theme. Same way global colorization (Shelf Properties -> Appearance tab -> Color Settings button) are currently a property of the whole shelf (set by the user) and not of a theme.

As luck would have it, editing a theme, I had to manually go into Workshelf and change the text type and coloration - It seems you have empty and inactive Button3= , Button4= etc already like a placeholder?

I see both sides here... Honestly if it comes down to user choice, it has often been said that more than two choices should be avoided. One one hand, if you are giving one choice being coloring and no bitmaps, it kind of forces the user into default settings or coloring. If the skinner only creates an active and inactive like it is currently, then nothing changes - However, if in some of the newer themes that 'might' come out, the user has the option of thematic or coloring.

- just an observation


All of that said, I know you have far more important things that take precedence and so they should, so if you can do the coloring without taking too much time away, we can always revisit the bitmaps another time

P.S - I could have got really convoluted and suggested that if a skinner created 12 different TAB buttons, the user could select their favorite from those 12 as their main TAB

@NEXTER - Coloring in different colors I am not huge on either with coloring bitmaps, but it depends on whether it's an actual color change or simply a glow around the buttons, the latter would likely work better.... especially if the user has a color wheel to choose from so they can do variants of the dominant color of the theme they are using and save per theme.

Since I'm actually adding tab colorization to the next release, further discussion on this subject should be on the What's next after v25.7 thread...

And done forthwith.