Feature request: plastic scheme with faithful colors

[rs]

This is simply a feature request for later versions, however if there are any known work arounds I would be keen to hear them.

In short, I want to use the plastic scheme in FLTK. Uniquely to this scheme, however, in the low-level drawing functions is a color averaging step which makes every color choice made by the developer more "gray".

I feel this is a very restrictive and unnecessary thing to do for several reasons:

     1. It is unpredictable - if I choose fl_rgb_color(255,0,0) I do not get red

     2. More significantly, some colors are simply not obtainable - there are hard "dark" and "light" limits which can't be overcome.

The "usual" way to by-pass default drawing things (subclass the widget and provide its own draw method) isn't particularly helpful as the color averaging occurs deep deep down in the draw_box functions called at many points in the inheritance hierarchy, (Note also many widgets have their draw function set as private rather than protected, which sometimes makes that method awkward/not possible without replicated huge chunks of FLTK code even without the color issue).

As a concrete example, imagine I want to create a "dark theme" window with a black menu bar with white text whilst using the plastic theme, I simple can't make it darker than a middling grey color.

Moreover, the color averaging is unpredictable/inconsistent. I can set the menu bar box to FL_FLAT_BOX for aesthetic reasons (whilst keeping the plastic theme for the sake of the other widgets). If I do so the top level menu bar then *doesn't* perform the color averaging. But when you open the menus the pop up menu windows *do* perform the color averaging.

From my experience with trying to tweak the colors with this scheme the conclusion I keep coming to is that this color averaging simply should not be happening - its restrictive, not doing what the developer asks for, and not consistent.

Clearly backwards compatibility is an issue so I think a great feature would be some kind of "PlasticNeo" scheme where the color averaging is disabled.

I appreciate this comes across as a rant, which I don't really intend, so apologies for that. But if there are any ways around this I would be glad to hear them.

Thanks,

R.

[Albrecht Schlosser]

On 9/22/21 5:17 AM rs wrote:

This is simply a feature request for later versions, however if there are any known work arounds I would be keen to hear them.

In short, I want to use the plastic scheme in FLTK. Uniquely to this scheme, however, in the low-level drawing functions is a color averaging step which makes every color choice made by the developer more "gray".

This is one of the reasons I never use the plastic scheme.

I feel this is a very restrictive and unnecessary thing to do for several reasons:

     1. It is unpredictable - if I choose fl_rgb_color(255,0,0) I do not get red

     2. More significantly, some colors are simply not obtainable - there are hard "dark" and "light" limits which can't be overcome.

Good points.

The "usual" way to by-pass default drawing things (subclass the widget and provide its own draw method) isn't particularly helpful as the color averaging occurs deep deep down in the draw_box functions called at many points in the inheritance hierarchy,

Indeed, you'd have to subclasse *every* widget you're using. That's not really doable.

(Note also many widgets have their draw function set as private rather than protected, which sometimes makes that method awkward/not possible without replicated huge chunks of FLTK code even without the color issue).

That's not correct. All draw() methods are protected to emphasize that they should not be called from any context rather than a valid drawing context (I just examined all draw() methods in the docs). The docs tell how to use the virtual draw() method for a widget from another widget's draw() method (or in another vaid context):

"If you ever need to call another widget's draw method from within your own draw() method, e.g. for an embedded scrollbar, you can do it (because draw() is virtual) like this:

  Fl_Widget *s = &scrollbar; // scrollbar is an embedded Fl_Scrollbar

  s->draw(); // calls Fl_Scrollbar::draw()
"

https://www.fltk.org/doc-1.4/classFl__Widget.html#a1acb38c6b3cb40452ad02ccfeedbac8a

Well, I admit that it's not as easy as just calling draw() ...

As a concrete example, imagine I want to create a "dark theme" window with a black menu bar with white text whilst using the plastic theme, I simple can't make it darker than a middling grey color.

Moreover, the color averaging is unpredictable/inconsistent. I can set the menu bar box to FL_FLAT_BOX for aesthetic reasons (whilst keeping the plastic theme for the sake of the other widgets). If I do so the top level menu bar then *doesn't* perform the color averaging. But when you open the menus the pop up menu windows *do* perform the color averaging.

From my experience with trying to tweak the colors with this scheme the conclusion I keep coming to is that this color averaging simply should not be happening - its restrictive, not doing what the developer asks for, and not consistent.

Clearly backwards compatibility is an issue so I think a great feature would be some kind of "PlasticNeo" scheme where the color averaging is disabled.

If disabling the color averaging is all we need to do I'd rather add an option like Fl_Scheme::color_averaging(float average) (see below) to disable it (default would be enabled, of course). I believe this would be a better choice than duplicating the entire scheme.

... if there are any ways around this I would be glad to hear them.

I attach a patch which seems to mitigate the color averaging. I tried several values and the attached image shows the result of setting the average to 0.40f. You may want to play with the factor yourself. If that's what you want we could maybe add the option as described above or in a similar way.

The code shows that there is only one other occurrence of color averaging depending on the plastic scheme in Fl_Light_Button, which is not affected by the patch.

Please report if this is what you're looking for. Does it work? Which factor do you prefer?

[rs]

>That's not correct. All draw() methods are protected to emphasize that they should not be called from any context rather than a valid drawing context (I just examined all draw() methods in the docs). The docs tell how to use the virtual draw() method for a widget from another widget's draw() method (or in another vaid context):

Yeah, ok, I'm wrong there. I think maybe I was thinking about some other helper functions in Fl_Tabs (something else entirely), but yes the "subclass every widget" thing was something I ran into, for sure.

Your proposed solution is indeed far better than mine - I'm not sure how I got it in my head, but was operating under the idea that the color averaging was happening locally somewhat sporadically in every widget, but that isn't true, as you patch shows (and I just looked up).

>Please report if this is what you're looking for. Does it work? Which factor do you prefer?

I would say, absolutely that is what I'm looking for. I'm going to hold off changing the FLTK code for my implementation as I'm distributing source code and don't want to mess with users' versions of FLTK if they want to compile themselves. However, I would have thought this would be a good solution to include in future versions.

But in terms of what I prefer, I view that the less averaging  the better - i.e. 0.0f, as then I can specify the whole color gamut and do it precisely (unless I misunderstood what you were asking). But this is probably not suitable as some default value (perhaps). I very much see the best solution as setting that averaging value manually by the user, as you propose, when they want to get into precise color design (which is what led me to this issue in the first place).

[Ian MacArthur]

As regards the "plastic" scheme, I'd guess it's possibly not that widely used (any more) and it has a number of quirks that are tied into its history...

It was specifically created (by Mike.S. I guess, IIRC) to look "nice" in OSX back in the 10.small_number Aqua theme days, and it enforces a number of features that were specifically intended to make it blend into the Aqua look. (And to prevent users from doing things that would not fit in...)

Like the unusual colour averaging behaviour, and the strip tiled backgrounds, and so forth...

It can also be "hard" to render in some cases, though why is not clear (on Win32, with GDI+ enabled, some machines, but by no means all, make a real chore of redrawing the "plastic" theme and can be quite sluggish. No one knows quite why.)

So I'd suggest not to use it, Just In Case! 

The "gtk+" theme is somewhat similar to look at, but seems to be cheaper to draw. Though it was styled to play nice with the Gnome Humanist style, and as a result also has some quirks pertaining to colour settings...

[Albrecht Schlosser]

On 9/23/21 4:06 PM rs wrote:
> Your proposed solution is indeed far better than mine ...

>
> >Please report if this is what you're looking for. Does it work? Which
> factor do you prefer?
>
> I would say, absolutely that is what I'm looking for.

Great!

> I'm going to hold off changing the FLTK code for my implementation as
> I'm distributing source code and don't want to mess with users'
> versions of FLTK if they want to compile themselves. However, I would
> have thought this would be a good solution to include in future versions.

Yes, of course, the patch was only intended as a proof of concept.

> But in terms of what I prefer, I view that the less averaging  the
> better - i.e. 0.0f, as then I can specify the whole color gamut and do
> it precisely (unless I misunderstood what you were asking).

That was indeed what I was asking. I was asking specifically because I
found that setting the factor very small (e.g. 0.0f) made the boxes look
like normal flat boxes (at least that was my impression). The "border
effect" at the top and bottom borders vanished completely. That's why I
made the screenshot with 40% average.

Just for my curiosity: Did you test your app with factor 0.0f and see
how it looked or do you only assume that 0.0 would be your best choice?

I also didn't test what happens when you use a dark mode with inverted
brightness of background and foreground colors. There may be significant
differences...

> But this is probably not suitable as some default value (perhaps). I
> very much see the best solution as setting that averaging value
> manually by the user, as you propose, when they want to get into
> precise color design (which is what led me to this issue in the first
> place).

I agree that a variable factor is likely the best. My first idea was to
switch averaging on and off (1 or 0) but then I found that some other
average values might look better. It's definitely a matter of taste.
Hence my proposal to use a user settable factor.

[w1hkj]

The gleam theme might also benefit from such a user adjustable parameter.  It would be nice to control the amount of glint.









David

[rs]

>Just for my curiosity: Did you test your app with factor 0.0f and see
how it looked or do you only assume that 0.0 would be your best choice?

>I also didn't test what happens when you use a dark mode with inverted
brightness of background and foreground colors. There may be significant
differences...

You got me, I did just assume. But, for some reason now I'm trying it, I'm not having any joy implementing the patch (the behaviour isn't any different to before - I've tried different weightings). I may have borked some element of my build, so I can't see it.

However, in terms of what I personally want, I'm not so concerned about the border effect, generally I tend to use the plastic theme more as a "soft" gtk, i.e. without the black borders. However, you are right to point out that, in spirit, removing it completely is not very "plastic"-y. But I think that just lends more weight to the user specified degree of "plastic-averaging" that can be altered from the default value.

The idea of such a possibility in the gleam theme looks good too.

[Bill Spitzak]

The history of "plastic" and the fact that they are box types rather than some sort of theme that changes all the boxes is indeed a bit problematic.

It grayed things out just to make color schemes designed to look like Windows 8 look nice on OS/X. Besides making the full gamut unavailable this also screws with code that attempts to make labels legible on various background colors and with fake antialiasing (and even real antialiasing) around images. This is hardly necessary now as in general design has become much more muted everywhere.

Technically it would be much better to always draw all boxes so the pixels in the largest area in the middle are the assigned color. There should also be no way to access the plastic boxes except by changing the theme.

It *may* be desirable to add a few box types that seem to be duplicates but don't change with the theme.

I also believe the default should be slimmed down to look more modern, but keep perfectly rectangular edges and interiors! (ie don't copy the crazy designers, keep this really clean looking).

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/938f89a9-18c4-4ccf-8995-8fb29a583240n%40googlegroups.com.