New FLTK scheme "oxy" is available in FLTK 1.4.0 (git)

[Albrecht Schlosser]

Hi all,

I just committed a new FLTK scheme called "oxy". This scheme uses decent
gradients in boxes and has its own arrow style. This scheme is
experimental, so be aware that it can still change and that there can be
drawing glitches etc.

You can use Git (branch master) or download the next 1.4.x snapshot that
will be available tomorrow (Fri Nov 25, about at 08:00 UTC).

Please test and report issues and things you would like to see improved.
All comments would be appreciated.

Suggested FLTK demo programs:

- test/menubar: menu buttons and 'File' menu and submenus
- test/unittests: scrollbar size and schemes test
- test/valuators
- test/demo: select scheme and launch other test programs
- maybe fluid ?
- your own applications ?

Most of the test programs can be executed with the commandline switch
"-s oxy" to test the new scheme. This should also work with your own
programs if you show the first window calling 'show(argc, argv);'.


Known issues (will be fixed later):

(1) "oxy arrows" (in scrollbars, menu buttons, counters, etc.) are not
yet drawn correctly on all platforms, particularly on Linux
(2) scaling with ctrl/+/-/0 (cmd/+/-/0 on macOS) does not yet work well
(see (1))


Have fun!

[Matthias Melcher]

That looks very nice! Thank you!

Albrecht Schlosser schrieb am Freitag, 25. November 2022 um 00:26:35 UTC+1:

Suggested FLTK demo programs:
- maybe fluid ?

Yep, works nicely. Thanks for even updating the pulldown menu to choose Oxy. 

[Greg Ercolano]

On 11/24/22 15:26, Albrecht Schlosser wrote:

Hi all,
I just committed a new FLTK scheme called "oxy". This scheme uses decent gradients in boxes and has its own arrow style. This scheme is experimental, so be aware that it can still change and that there can be drawing glitches etc.

    Great! I'll give it a spin with my own apps when I do a git update.

    Is this Dmitri's old submission from like a decade ago?
    (checks STRs) Wow, yeah, from 2011.. STR #2675 and #3477.

    Looks like you've (Albrecht) have been pushing on this for a while,
    glad to see it's coming through -- scheme options are nice to have.

[Albrecht Schlosser]

On 11/25/22 01:13 Greg Ercolano wrote:

On 11/24/22 15:26, Albrecht Schlosser wrote:

Hi all,
I just committed a new FLTK scheme called "oxy". This scheme uses decent gradients in boxes and has its own arrow style. This scheme is experimental, so be aware that it can still change and that there can be drawing glitches etc.

    Great! I'll give it a spin with my own apps when I do a git update.

    Is this Dmitri's old submission from like a decade ago?
    (checks STRs) Wow, yeah, from 2011.. STR #2675 and #3477.

Yes, indeed.

    Looks like you've (Albrecht) have been pushing on this for a while,
    glad to see it's coming through -- scheme options are nice to have.

Yes, I worked on it from time to time and wanted to integrate it in a bigger change ("Fl_Scheme" class hierarchy). I updated (rebased) my branch a lot and the latest was 'oxy-v8' - but now the time had come to integrate it (Fl_Scheme will come later, not in 1.4.0).

I used this chance for a general improvement of "arrow drawing" in all schemes and simplified the widget implementation. If you're working with FLTK schemes you may notice that all the "arrows" in scrollbars, counters, menus and menu buttons are now unified (per scheme) but change their look when you change the scheme. This made the last step to integrate the "oxy" scheme much smoother - and certainly also the integration of future schemes.

Your feedback from using it in your own app would be very much appreciated.

[Manolo]

Le vendredi 25 novembre 2022 à 00:26:35 UTC+1, Albrecht Schlosser a écrit :

Hi all,

I just committed a new FLTK scheme called "oxy". This scheme uses decent
gradients in boxes and has its own arrow style. This scheme is
experimental, so be aware that it can still change and that there can be
drawing glitches etc.

……

Known issues (will be fixed later):

(1) "oxy arrows" (in scrollbars, menu buttons, counters, etc.) are not
yet drawn correctly on all platforms, particularly on Linux
(2) scaling with ctrl/+/-/0 (cmd/+/-/0 on macOS) does not yet work well
(see (1))

Very nice.

It seems background gradients rescale well even at non-integer factor values.

[Tigercat]

$ fltk/fltk-config --cxxflags
-Ifltk -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/includ
e -I/usr/include/sysprof-4 -I/usr/lib64/libffi/include -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/harfbuzz -pthread -I/usr/include/libpng16
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/sysprof-4 -I/usr/lib64/libffi/include -I/usr/include/harfbuzz -I/
usr/include/freetype2 -I/usr/include/libmount -I/usr/include/blkid -I/usr/includ
e/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 -
pthread -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/inclu
de -I/usr/include/sysprof-4 -I/usr/lib64/libffi/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/harfbuzz -pthread -I/usr/include/libpng1
6 -DUSE_SYSTEM_LIBDECOR=0 -I../libdecor/src -D_LARGEFILE_SOURCE -D_LARGEFILE64_S
OURCE -D_THREAD_SAFE -D_REENTRANT

The cxxflags now outputs "-I../libdecor/src", a relative path which breaks my build with a local fltk install. Not to mention there's a lot of duplicate include entries. Did something break when "oxy" was added to the latest git?

[imm]

The cxxflags now outputs "-I../libdecor/src", a relative path which breaks my build with a local fltk install. Not to mention there's a lot of duplicate include entries. Did something break when "oxy" was added to the latest git?

 I think that's Wayland support rather than Oxy which is causing that.

Does a cmake build work on your setup?

--
Ian
From my Fairphone FP3

[Manolo]

Le samedi 26 novembre 2022 à 07:49:21 UTC+1, Tigercat a écrit :

The cxxflags now outputs "-I../libdecor/src", a relative path which breaks my build with a local fltk install. Not to mention there's a lot of duplicate include entries. Did something break when "oxy" was added to the latest git?

This libdecor-related flag should now be absent from `fltk-config --cxxflags` after commit  1d04c75

[Tigercat]

Thanks Manolo. That fixed the build issue.

I had a few other issues crop up with my latest git submodule fetch of FLTK 1.4. I'll open new threads to avoid unfairly tarnishing oxy any further :-)

[Paul Hahn]

In all honesty, I like the appearance of this new scheme except for one aspect. The problem for me is the gradient in menu lists. To my brain, the gradient tends to communicate something about the items that is not intended. Namely, the items at the top, located in a lighted field, are in some mysterious way preferred to those at the bottom, located in a darkened field. It's just something psychological for me, I suppose. But that was my immediate reaction when I ran test/menubar with ocy.

Be it far from me to imply any lack of appreciation for this new scheme, but is it possible to have some sort of option to utilize the scheme with the exception of the gradient in the menu lists?

[Albrecht Schlosser]

On 12/11/22 15:12 Paul Hahn wrote:

On Thursday, November 24, 2022 at 5:26:35 PM UTC-6 Albrecht Schlosser wrote:

I just committed a new FLTK scheme called "oxy".

[...]

In all honesty, I like the appearance of this new scheme except for one aspect. The problem for me is the gradient in menu lists. To my brain, the gradient tends to communicate something about the items that is not intended. Namely, the items at the top, located in a lighted field, are in some mysterious way preferred to those at the bottom, located in a darkened field. It's just something psychological for me, I suppose. But that was my immediate reaction when I ran test/menubar with ocy.

Be it far from me to imply any lack of appreciation for this new scheme, but is it possible to have some sort of option to utilize the scheme with the exception of the gradient in the menu lists?

I see your point and I'll take a closer look at this. I imagine we could use a different boxtype for menu windows.

I believe the new 'oxy' scheme is much better than the older 'gleam' scheme. You would probably not like the 'gleam' scheme as well.

Can you please make an experiment (test) and report what you see and recognize (or feel)?

Please run test/unittests with the oxy and gleam schemes. In this demo you can switch schemes at runtime if you select the "Schemes Test".

What I see (and don't like personally) with the gleam scheme is the left side menu (an Fl_Browser) that has a dark gradient at the top and bottom. I never liked this.

The oxy scheme is IMHO much better. The left side "menu" (Fl_Browser) doesn't show any gradient. I imagine we could use this in menu windows as well, but I didn't investigate this further yet. I don't know if this is doable, but it's maybe worth a check.

What do you think, would this be better?

[Paul Hahn]

Yes you are so right about the gleam scheme. When examining the left side menu / browser as you suggested, I get a negative reaction for the same basic reason.

But even further, in terms of all the widgets appearing in the "Scheme Test" demo , I definitely prefer the oxy scheme over the gleam scheme! So yes, I do think the oxy scheme is a big advance over the gleam scheme. To me, the oxy scheme looks more "professional", if you will, than the gleam scheme (I would have used the word "polished" there, but ironically, too much "polish" -- in the visual vs. figurative sense -- is gleam scheme's problem, IMHO).

FWIW, perhaps the issue with the gleam scheme browser (or menu list) could also be resolved by special treatment to improve it specifically. But even in that case, I personally would still choose the oxy scheme over the gleam scheme.

[Albrecht Schlosser]

On 12/12/22 17:49 Paul Hahn wrote:

On Monday, December 12, 2022 at 8:42:53 AM UTC-6 Albrecht Schlosser wrote:

What I see (and don't like personally) with the gleam scheme is the left side menu (an Fl_Browser) that has a dark gradient at the top and bottom. I never liked this.

The oxy scheme is IMHO much better. The left side "menu" (Fl_Browser) doesn't show any gradient. I imagine we could use this in menu windows as well, but I didn't investigate this further yet. I don't know if this is doable, but it's maybe worth a check.

What do you think, would this be better?

Yes you are so right about the gleam scheme. When examining the left side menu / browser as you suggested, I get a negative reaction for the same basic reason.

I agree. When we introduced the scheme there were some discussions, but some users and devs liked it as it was and voted for its integration. Nobody needs to use it though. ;-)

But even further, in terms of all the widgets appearing in the "Scheme Test" demo , I definitely prefer the oxy scheme over the gleam scheme! So yes, I do think the oxy scheme is a big advance over the gleam scheme. To me, the oxy scheme looks more "professional", ...

Again I agree. It's my personally preferred scheme, particularly because the gradients look like "natural light effects".

FWIW, perhaps the issue with the gleam scheme browser (or menu list) could also be resolved by special treatment to improve it specifically.

We don't have many choices except changing the boxtype of the browser widget which might be bad for existing programs.

But even in that case, I personally would still choose the oxy scheme over the gleam scheme.

So do I.

I didn't have a chance yet to check the issue you mentioned with the oxy scheme in menu windows but I'll try to look into it when time permits.

[Greg Ercolano]

On 12/12/22 15:07, Albrecht Schlosser wrote:

On 12/12/22 17:49 Paul Hahn wrote:

But even further, in terms of all the widgets appearing in the "Scheme Test" demo , I definitely prefer the oxy scheme over the gleam scheme! So yes, I do think the oxy scheme is a big advance over the gleam scheme. To me, the oxy scheme looks more "professional", ...

Again I agree. It's my personally preferred scheme, particularly because the gradients look like "natural light effects".

    For myself, I've been using "gtk+" as the default scheme in my commercial apps.
    Kinda improved on the old FLTK look without getting fancy with gradients.

[Gonzalo Garramuño]

El 12/12/22 a las 20:14, Greg Ercolano escribió:

+1 for gtk+.  It is the best looking scheme.