| |
| |
>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).
On Thursday, September 23, 2021 at 10:18:53 PM UTC+10 Albrecht Schlosser wrote:
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
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?
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/9b77f3b8-0b42-4979-b5ce-b167708e6b07n%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |
