oxy theme

[LM]

So, I'd still like to see Dmitrij's oxy theme added in FLTK as a fourth theme.  Not that familiar with the FLTK internals, but I'm attempting to make the oxy additions function more like the gleam or other theme additions, so they can work with the current methodology FLTK uses for adding themes.  I downloaded the latest version of 1.4.x, since there are so many changes and improvements to organization in that version.  Most of the oxy routines look like they'll match to the routines used by other themes.  All the themes seem to have their own up_box, down_box, etc.  However, oxy has a routine to draw its own arrows for scrollbars, dropdowns, etc.  Was thinking it would be helpful to add oxy's arrow drawing routine and a few other drawing functions that are only used by oxy to all the different themes.  That way, the code can call the theme to draw and customize those items rather than using generic code for all themes and having to add an if statement to check for oxy and do something different.  Any suggestions or recommendations on how best to fit at least parts of the oxy theme code into FLTK 1.4.x so that it works properly with the how FLTK handles themes would be greatly appreciated.

[LM]

I've put together a subset of the oxy theme as a patch that I hope fits the FLTK theme guidelines.  I've submitted it as STR 3477.  Hoping we can finally come up with some version of oxy that will become a part of FLTK 1.4.x.

[Albrecht Schlosser]

Thanks, I'll take a look at it...

[LM]

Keeping my fingers crossed.  If you think it will still need further changes to be acceptable, let me know.

[Albrecht Schlosser]

On 14.06.2018 20:57 LM wrote:
> Keeping my fingers crossed.  If you think it will still need further
> changes to be acceptable, let me know.

I modified a few things and attached the latest patch to STR #3477. I
encourage everyone to test this great new scheme and to comment on it
here or at the STR:

http://www.fltk.org/str.php?L3477

For a quick view see one or both of these images:

http://www.fltk.org/strfiles/3477/oxy_v5.png
http://www.fltk.org/strfiles/3477/oxy_vs_gleam.png

The latest patch can be found here:
http://www.fltk.org/strfiles/3477/oxy_v5.diff

Comments and test results would be appreciated.

[LM]

On Saturday, June 16, 2018 at 3:42:45 PM UTC-4, Albrecht Schlosser wrote:

I modified a few things and attached the latest patch to STR #3477. I
encourage everyone to test this great new scheme and to comment on it
here or at the STR:  

http://www.fltk.org/str.php?L3477

Thank you very much for all the work you put in to get the patches compatible with FLTK standards.  I love the idea of adding another theme and a little more choice to FLTK.  The comparison oxy/gleam graphic looks great.

Still looking through the oxy_v5.diff changes, but I like the direction you went with the arrows.  I was thinking it needed to be more generic like the box types.  I really like the addition of the arrow types to enumerations.

I think I personally prefer the dropdowns with one arrow instead of two, but that's just aesthetics.  I'm hoping Dmitrij will join in with some comments or suggestions as well because he's very good with getting a nice look and feel to a design.

I was able to build FLTK with the oxy_v5.diff patch on Windows using MinGW.  Had no problems getting it to build.  Is there anything specific you'd like to see tested?

Thanks again.

[Albrecht Schlosser]

On 18.06.2018 15:05 LM wrote:
> On Saturday, June 16, 2018 at 3:42:45 PM UTC-4, Albrecht Schlosser wrote:
>
> I modified a few things and attached the latest patch to STR #3477. I
> encourage everyone to test this great new scheme and to comment on it
> here or at the STR:
>
>

> http://www.fltk.org/str.php?L3477 <http://www.fltk.org/str.php?L3477>

>
>
> Thank you very much for all the work you put in to get the patches
> compatible with FLTK standards.  I love the idea of adding another theme
> and a little more choice to FLTK.  The comparison oxy/gleam graphic
> looks great.

My goal was and still is to make building and integrating new schemes
easier, but I got stuck on my way to do this together with the
integration of Dmitrijs Oxy scheme. So your new patch with a minimal Oxy
scheme w/o too many widget changes was a good starting point for me to
make at least the new scheme work.

> Still looking through the oxy_v5.diff changes, but I like the direction
> you went with the arrows.  I was thinking it needed to be more generic
> like the box types.  I really like the addition of the arrow types to
> enumerations.

Thanks. I took up your starting point to use fl_draw_arrow(), and at
this point in development, use it only for the Oxy scheme. I agree 120%
;-) that this is something that must be more generic. In the future,
with the new Fl_Scheme class hierarchy, this will call a virtual method
of class Fl_Scheme, and each Fl_Scheme_Something will have its own arrow
drawing method - or inherit it from its parent class. In the latter case
you don't even have to develop one if you're happy with the parent's
arrow drawing code.

The same should be true for other GUI elements like check marks, radio
button marks, etc.

Now that we have fl_draw_arrow() we can extend its functionality to all
the other schemes and places where arrows are drawn. I found that it was
really hard to see where exactly the arrows are to be placed. The new
bounding box logic makes this much easier: the widget code has to find
the place relative to the widget's box, and the arrow drawing code
places the arrows centered into the given bounding box. Again, same
logic for all other GUI elements.

Thats (part of) the plan...

> I think I personally prefer the dropdowns with one arrow instead of two,
> but that's just aesthetics.

That's the point where you could subclass Fl_Scheme_oxy and change just
the box drawing code for FL_ARROW_CHOICE. ;-) I'm kidding... It was just
a proof of concept how simple the change could be. It's only a switch
statement in the arrow drawing code that makes it draw one or two arrows.

case FL_ARROW_CHOICE:

calls single_arrow(..) twice with a small offset. The original code
would call it only once.

> I'm hoping Dmitrij will join in with some
> comments or suggestions as well because he's very good with getting a
> nice look and feel to a design.

Yep, I'm also looking forward to his comments. I'd like to know what he
had in mind with drawing the arrows, particularly with the second and
third line with fl_color_average() values 0.58 and 0.78. Should they be
arranged with a light and shadow effect? Why these values? I know that
my drawing code does not exactly replicate Dmitrijs code...

> I was able to build FLTK with the oxy_v5.diff patch on Windows using
> MinGW.  Had no problems getting it to build.  Is there anything specific
> you'd like to see tested?

No, not really. I'm not yet entirely satisfied with the parameters of
the fl_draw_arrow() function because it shall be usable for all schemes
in the future. Do we need all parameters? Are they generalized enough
that they can be used everywhere for all schemes?

> Thanks again.

Welcome. And thanks again for your efforts, the patch, and the good
ideas implemented in your modification of Dmitrijs patch.