RFC: FLTK 1.4.0 release schedule and Doxygen 1.12.0

[Albrecht Schlosser]

Hi all, FLTK developers and users,

I'd like to release FLTK 1.4.0 RC1 on Sunday Oct 20, 2024.

If there are any reasons not to do this, please comment here in this thread, particularly if ...

(a) you believe that one or more high priority issues need fixes before the release

  or

(b) you are still working on one or more fixes for release 1.4.0 (devs only).


I'm aware that we have open issues (and old STR's) but I don't think that any of these should be show stoppers.


If I don't see negative comments until 10 am UTC on Saturday (Oct 19, 2024) at noon
I'll prepare the release as written above for Sunday (likely afternoon).


I'm also asking you (devs and users) to test and verify the current docs on our server (uploaded yesterday: Oct 15). See links below.

I'm asking this because I upgraded my build system to the latest Doxygen version 1.12.0 [1] and generated the new docs with this version. I'd like to use doxygen 1.12.0 for generation of online docs and release tarballs. Please let me know if you find any Doxygen related issues in this new documentation version.

New docs online, generated by doxygen 1.12.0 on Oct 15:
HTML: https://www.fltk.org/doc-1.4/
PDF: https://www.fltk.org/doc-1.4/fltk.pdf

For comparison: docs on our GitLab mirror, generated daily by doxygen 1.9.4:
HTML: https://fltk.gitlab.io/fltk/
PDF: https://fltk.gitlab.io/fltk/fltk.pdf

PS: Positive feedback would be appreciated as well so I know that at least some persons took a look at the new doc version. Thanks in advance.

[1] Note: I can still use older doxygen versions if necessary

[Albrecht Schlosser]

On 10/16/24 16:38 'Albrecht Schlosser' via fltk.general wrote:

If I don't see negative comments until 10 am UTC on Saturday (Oct 19, 2024) at noon
I'll prepare the release as written above for Sunday (likely afternoon).

Sorry, this should read (remove "at noon"):

If I don't see negative comments until 10 am UTC on Saturday (Oct 19, 2024)

[Basile STARYNKEVITCH]

On 10/16/24 16:38, 'Albrecht Schlosser' via fltk.general wrote:

Hi all, FLTK developers and users,

I'd like to release FLTK 1.4.0 RC1 on Sunday Oct 20, 2024.

Great. Please document the differences (notably incompatible API) between FLTK 1.3.9 and FLTK 1.4.0

--
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/bbf6cf9f-3a92-4059-afa6-d79c4643d417%40aljus.de.

-- 
Basile STARYNKEVITCH           <bas...@starynkevitch.net>
8 rue de la Faïencerie
92340 Bourg-la-Reine           mobile: +33 6 8501 2359
France                         http://starynkevitch.net/Basile/

[Albrecht Schlosser]

On 10/16/24 16:58 Basile STARYNKEVITCH wrote:

Please document the differences (notably incompatible API) between FLTK 1.3.9 and FLTK 1.4.0

Thanks for your comment.

There should be very little API changes, and notable changes are documented here:
https://www.fltk.org/doc-1.4/migration_1_4.html

I'll also update the file CHANGES.txt with general information, i.e. the "highlights" of the new release. Listing every single change would be way too much...

[Greg Ercolano]

On 10/16/24 07:38, 'Albrecht Schlosser' via fltk.general wrote:

Hi all, FLTK developers and users,

I'd like to release FLTK 1.4.0 RC1 on Sunday Oct 20, 2024.

    Has the ABI checker been run yet to check for API issues?
    I figure results of that should be shown and resolved before an RC.

    I just gave it a casual run, and got this:

Wed 10/16/24 08:40:05 /usr/local/src/fltk-1.4.x.git
[erco@harris] 370 : abi-compliance-checker -lib fltk -old fltk-1.3.9.xml -new fltk-1.4.x.xml
Preparing, please wait ...
Using GCC 9 (x86_64-linux-gnu, target: x86_64)
WARNING: May not work properly with GCC 4.8.[0-2], 6.* and higher due to bug #78040 in GCC. Please try other GCC versions with the help of --gcc-path=PATH option or create ABI dumps by ABI Dumper tool instead to avoid using GCC. Test selected GCC version first by -test and -gcc-path options.
Checking header(s) 1.3.9 ...
Checking header(s) 1.4.x ...
Comparing ABIs ...
Comparing APIs ...
Creating compatibility report ...
Binary compatibility: 33%
Source compatibility: 91.6%
Total binary compatibility problems: 527, warnings: 198
Total source compatibility problems: 322, warnings: 89
Report: compat_reports/fltk/1.3.9_to_1.4.x/compat_report.html

    I put a copy of my report here:
    https://www.seriss.com/people/erco/tmp/fltk-1.3.9-vs-1.4.x-compat-report.html

[Albrecht Schlosser]

On 10/16/24 17:46 Greg Ercolano wrote:

    Has the ABI checker been run yet to check for API issues?
    I figure results of that should be shown and resolved before an RC.

Hmm, these are interesting questions. Thanks for your comments and your checks.

Short answer: no, I didn't use the ABI checker (yet) because FLTK 1.4 definitely breaks the ABI (that's what minor version changes in FLTK are intended and allowed to do). Hence, why bother? ...

Longer answer: I'm not sure if you really meant "to check for API issues" which is a totally different question but an interesting byproduct of the ABI checker.

    I just gave it a casual run, and got this:

Wed 10/16/24 08:40:05 /usr/local/src/fltk-1.4.x.git
[erco@harris] 370 : abi-compliance-checker -lib fltk -old fltk-1.3.9.xml -new fltk-1.4.x.xml

...
Binary compatibility: 33%
Source compatibility: 91.6%
Total binary compatibility problems: 527, warnings: 198
Total source compatibility problems: 322, warnings: 89
Report: compat_reports/fltk/1.3.9_to_1.4.x/compat_report.html

Thanks for running the check anyway. I notice that you marked "source compatibility problems: 322, warnings: 89" in red color which is good because we can safely ignore binary compatibility.

    I put a copy of my report here:
    https://www.seriss.com/people/erco/tmp/fltk-1.3.9-vs-1.4.x-compat-report.html

Thanks, I took a look at the report and I didn't find any "real" issues at a first glance. There seem to be a lot of false positives in this report. It's hard to find real issues.

A few examples:

(1) "removed symbols": lots of these symbols (functions) got additional parameters with default values, and this was intentional. These functions appear also in "added symbols" with the extended parameter list. This makes it confusing but it's harmless.

(2) Some issues arise because of changes in virtual methods. I checked a few random samples (or let's say: some that looked unexpected) but I always found real reasons. This doesn't mean that I checked everything though. One example is that four overridden virtual methods of Fl_Menu_Window have been removed. Comparing the source code reveals: we removed conditional code related to overlay windows, and thus these methods became obsolete and have been removed. This should be "fixed" by recompiling the code, I don't think that someone (could have) called these virtual methods explicitly (I mean like: Fl_Menu_Window::<method-name>).

(3) Many issues have been flagged because new features have been added, for instance Wayland.

(4) Did you compile your 1.3.9 version with ABI version 10309 enabled? If not it's obvious that new ABI (and API) features added to 1.3.9 are now flagged.

That all said, I'll try to build and run the ABI checker myself and report back if I can find anything suspicious, under following build features:

(A) 1.3.9 (branch-1.3, i.e. 1.3.10) with all ABI features enabled
(B) 1.4.0 (master) without Wayland and Cairo graphics drivers
(C) maybe more, I don't know yet.

This should issue less warnings and errors and show "real API" issues if there are any.

Any help would be appreciated...

BTW: as a "simple API test" ...
- I converted all test/*.fl files from 1.3 with fluid from 1.4
- I compiled all test/*.cxx (including those from *.fl) with `fltk-config --compile` from FLTK 1.4

Again I didn't see much suspicious stuff, but there were (IMHO benign) compiler warnings and even some errors, but those were to be expected, e.g. missing '#include <config.h>' and some (intended) DEPRECATED warnings. I was too lazy to dig deeper into this but I may give it another try.

Don't get me wrong: this compiler test was only a plausibility check: if we don't find issues with our own FLTK test and demo programs that doesn't mean that users can't have issues. However, the opposite (if we found unexpected API errors in our 1.3 code) would show real API compatibility issues.

[Greg Ercolano]

On 10/16/24 10:30, 'Albrecht Schlosser' via fltk.general wrote:

On 10/16/24 17:46 Greg Ercolano wrote:

    Has the ABI checker been run yet to check for API issues?
    I figure results of that should be shown and resolved before an RC.

Short answer: no, I didn't use the ABI checker (yet) because FLTK 1.4 definitely breaks the ABI (that's what minor version changes in FLTK are intended and allowed to do). Hence, why bother? ...

Longer answer: I'm not sure if you really meant "to check for API issues" which is a totally different question but an interesting byproduct of the ABI checker.

    Yes, that's why I mentioned it -- it makes note of API breaking changes as well,
    and lists removals of any public function/method/structs/etc.

    Would help towards Basile's request too for documenting API changes.
    Obviously wouldn't help document changes in behavior unrelated to the API,
    as that's probably something worth distilling from the release notes.

[Manolo]

It's great to read that 1.4rc1 is coming soon!

I have browsed the new on-line HTML doc without seeing problems.

I'd like to commit a small doc-only change to class Fl_Callback_User_Data

in an attempt to make it less cryptic. Can I do that?

[duncan]

New docs online, generated by doxygen 1.12.0 on Oct 15:
HTML: https://www.fltk.org/doc-1.4/
PDF: https://www.fltk.org/doc-1.4/fltk.pdf

I scanned through quickly: First comment I like the Light/Dark option.

The link to the Frequently Asked Questions does not currently work.

I left a lot of TODO comments in the UTF-8 chapter years ago when

the docs had their last major update because I don't wok with non-ASCII

characters and had no experience of working with exotic characters.

This chapter should be reviewed by someone with that experience.

You can also remove my name from the credits: I did very little.

D.

[Albrecht Schlosser]

On 10/17/24 09:34 Manolo wrote:
> It's great to read that 1.4rc1 is coming soon!
>
> I have browsed the new on-line HTML doc without seeing problems.

Great, thanks.

> I'd like to commit a small doc-only change to class Fl_Callback_User_Data
> in an attempt to make it less cryptic. Can I do that?

Sure, please go ahead. The next upload to fltk.org is planned for the
release (rc1) date though.

[Albrecht Schlosser]

On 10/17/24 10:10 duncan wrote:

New docs online, generated by doxygen 1.12.0 on Oct 15:
HTML: https://www.fltk.org/doc-1.4/
PDF: https://www.fltk.org/doc-1.4/fltk.pdf

I scanned through quickly: First comment I like the Light/Dark option.

Thanks for checking, and good to read the latter. This option is (IIRC) available since doxygen 1.10, thus it has been online on our server for a while. It's not available yet on the GitLab mirror though (1.9.4). Maybe we can update the CI build to a newer version but that's something for later.

The link to the Frequently Asked Questions does not currently work.

It does for me: I mean the link from the main page of the HTML docs below "Appendices": FAQ (Frequently Asked Questions) to the FAQ within the HTML docs: https://www.fltk.org/doc-1.4/FAQ.html

Maybe you need to reset/clear your browser cache? Or are you talking about another link?

I left a lot of TODO comments in the UTF-8 chapter years ago when

the docs had their last major update because I don't wok with non-ASCII

characters and had no experience of working with exotic characters.

This chapter should be reviewed by someone with that experience.

Yes, that's something we need to do, but not for 1.4 yet.

You can also remove my name from the credits: I did very little.

Which "credits"? The list of "By ..." on the main page?

I can do that if you really want, please confirm.

[duncan]

New docs online, generated by doxygen 1.12.0 on Oct 15:
HTML: https://www.fltk.org/doc-1.4/
PDF: https://www.fltk.org/doc-1.4/fltk.pdf

The link to the Frequently Asked Questions does not currently work.

It does for me: I mean the link from the main page of the HTML docs below "Appendices": FAQ (Frequently Asked Questions) to the FAQ within the HTML docs: https://www.fltk.org/doc-1.4/FAQ.html

 

Sorry, I should have been clearer. I was navigating through using the Next buttons

at the bottom of the main pages, and the Next [FAQ] at the bottom of examples.html

fails with "The requested URL /doc-1.4/faq.html was not found". Note that I have

not been through checking all of the Prev/Next buttons at the bottoms of pages.

You can also remove my name from the credits: I did very little.

Which "credits"? The list of "By ..." on the main page?

Yes, at the top of the FLTK Programming Manual. I was surprised when my name

appeared and it still makes me a bit uncomfortable. It makes it look like I'm an active

core developer, but in fact all I've ever done is update the Resizing and Unicode docs.

D.

 

[Albrecht Schlosser]

On 10/17/24 13:37 duncan wrote:

The link to the Frequently Asked Questions does not currently work.

It does for me: I mean the link from the main page of the HTML docs below "Appendices": FAQ (Frequently Asked Questions) to the FAQ within the HTML docs: https://www.fltk.org/doc-1.4/FAQ.html

 

Sorry, I should have been clearer.

No need to apologize, all help is appreciated. I'm glad that you found the wrong link and reported it.

I was navigating through using the Next buttons

at the bottom of the main pages, and the Next [FAQ] at the bottom of examples.html

fails with "The requested URL /doc-1.4/faq.html was not found".

OK, I see. This one was a simple typo: 'faq' instead of 'FAQ'. Fixed now.

Note that I have not been through checking all of the Prev/Next buttons at the bottoms of pages.

I took the opportunity to check *all* links at the bottom(s) of the "tutorial" pages and fixed a few more. Some pages have been moved around w/o updating the navigation links, some titles had been changed, and at least one that is now in the appendices section still had old links.

I tried to fix all links and I'll upload a new version ASAP. [1]

You can also remove my name from the credits: I did very little.

Which "credits"? The list of "By ..." on the main page?

Yes, at the top of the FLTK Programming Manual. I was surprised when my name

appeared and it still makes me a bit uncomfortable. It makes it look like I'm an active

core developer, but in fact all I've ever done is update the Resizing and Unicode docs.

OK, then I'll remove your name from the docs but leave it in the CREDITS.txt where you are mentioned under "The following people have contributed fixes or enhancements for FLTK" which is IMHO correct. ... Unless you want me to remove your name from this as well.

You'll notice that the upload happened when the generation date on the title page changes to 'Oct 17' or any later date (after clearing the browser cache, maybe).

-------------------
[1] I'm still working on some more documentation updates and the next uploaded version will have all the links fixed - hopefully.

[Matthias Melcher]

Thanks, Albrecht. I am really looking forward to getting RC1 out. I don't have anything the must be fixed before Sunday, just minor stuff, maybe some FLUID documentation, but nothing that would stop RC1.

I just updated the FLUID documentation on fltk.org . They are nice the way they are. I may want to add two or three undocumented features, but there is no rush to do that.

In one of the descriptions, you mention that the box types no longer need the underscore and that the box types were simplified. Unfortunately this patch did not stay in master for some reasons that I forgot. I believe I went too far with some other enums and needed up reverting everything because I thought it was too drastic. The boxtype changes did work fine though. Question: do you want me to reapply the boxtype underscore changes before Sunday? Or do you want to keep things as they are and just remove the mentions?

Matthias

[Albrecht Schlosser]

On 10/17/24 15:18 'Matthias Melcher' via fltk.general wrote:

Thanks, Albrecht. I am really looking forward to getting RC1 out. I don't have anything the must be fixed before Sunday, just minor stuff, maybe some FLUID documentation, but nothing that would stop RC1.

Great, thanks for your feedback.

I just updated the FLUID documentation on fltk.org . They are nice the way they are. I may want to add two or three undocumented features, but there is no rush to do that.

I just updated the FLUID documentation on fltk.org once again after my recent changes (commit cb6ee39852d2a3ddeba1a68fab3086c487b998bc). Some of my fixes apply to fluid (docs), hence I uploaded my latest docs.

Please check if anything is wrong with my version of the fluid docs: I saw some fluid windows popping up while creating the docs, and I suspect that the "autodoc" feature might create screenshots on the running system. You may want to check if my screenshots broke any of yours which were obviously created on macOS.

If this is the case we need to find out how I can create the distribution tarballs w/o having to use my Mac or whatever we need...

In one of the descriptions, you mention that the box types no longer need the underscore and that the box types were simplified. Unfortunately this patch did not stay in master for some reasons that I forgot. I believe I went too far with some other enums and needed up reverting everything because I thought it was too drastic. The boxtype changes did work fine though. Question: do you want me to reapply the boxtype underscore changes before Sunday? Or do you want to keep things as they are and just remove the mentions?

I'm now looking into this and I'll let you know what I found out...

[Albrecht Schlosser]

On 10/17/24 15:10 'Albrecht Schlosser' wrote:
> You'll notice that the upload happened when the generation date on the
> title page changes to 'Oct 17' or any later date (after clearing the
> browser cache, maybe).

Done: I uploaded the latest docs from Git commit
cb6ee39852d2a3ddeba1a68fab3086c487b998bc.

[Albrecht Schlosser]

On 10/17/24 17:08 'Albrecht Schlosser' via fltk.general wrote:
> On 10/17/24 15:18 'Matthias Melcher' via fltk.general wrote:
>> In one of the descriptions, you mention that the box types no longer
>> need the underscore and that the box types were simplified.
>> Unfortunately this patch did not stay in master for some reasons that
>> I forgot. I believe I went too far with some other enums and needed
>> up reverting everything because I thought it was too drastic. The
>> boxtype changes did work fine though.

I'm lost. I can't find a commit that reverts anything related in
FL/Enumerations.H and the original mention of Fl_Boxtype in CHANGES.txt
is really, really old (maybe in 2017 or older).

>> Question: do you want me to reapply the boxtype underscore changes
>> before Sunday? Or do you want to keep things as they are and just
>> remove the mentions?

If you can find the commit that reverted things related to the
Fl_Boxtype underscore I'd be interested to see it, and if it really
changed the behavior, then we (i.e. you) should please "reapply the
boxtype underscore changes before Sunday".

I believe that this is an essential feature of FLTK 1.4 and should be
kept. Usage of boxtypes with underscore in user code should be
considered deprecated (I believe it's documented with "don't use it" or
similar) and we should make sure that all boxtypes in user code work
without the underscore prefix. This way we can maybe remove the enums
with prefix at some time later - or at least mark them as deprecated
such that the compiler emits a warning in 1.5.0.

[Matthias Melcher]

Albrecht-S schrieb am Donnerstag, 17. Oktober 2024 um 17:08:43 UTC+2:

On 10/17/24 15:18 'Matthias Melcher' via fltk.general wrote:

I just updated the FLUID documentation on fltk.org . They are nice the way they are. I may want to add two or three undocumented features, but there is no rush to do that.

I just updated the FLUID documentation on fltk.org once again after my recent changes (commit cb6ee39852d2a3ddeba1a68fab3086c487b998bc). Some of my fixes apply to fluid (docs), hence I uploaded my latest docs.

Please check if anything is wrong with my version of the fluid docs: I saw some fluid windows popping up while creating the docs, and I suspect that the "autodoc" feature might create screenshots on the running system. You may want to check if my screenshots broke any of yours which were obviously created on macOS.

If this is the case we need to find out how I can create the distribution tarballs w/o having to use my Mac or whatever we need...

Your handbook output looks perfectly fine. I have created a Github action to generate the handbook on a Linux machine on Github (I should probably change that to a macOS system for nicer font rendering). https://github.com/fltk/fltk/actions/workflows/build_fluid_docs.yml . Click on "Run Workflow", and after three minutes or so, under "Artifacts" two zip archives will appear, one for the pdf and one for the html handbook. The "manual" version on a local machine is slightly different, but nothing really worrysome (different source code preview size, filled out shell preferences).

 

[Matthias Melcher]

Albrecht-S schrieb am Donnerstag, 17. Oktober 2024 um 18:47:22 UTC+2:

On 10/17/24 17:08 'Albrecht Schlosser' via fltk.general wrote:
> On 10/17/24 15:18 'Matthias Melcher' via fltk.general wrote:
>> In one of the descriptions, you mention that the box types no longer
>> need the underscore and that the box types were simplified.

I'm lost. I can't find a commit that reverts anything related in
FL/Enumerations.H and the original mention of Fl_Boxtype in CHANGES.txt
is really, really old (maybe in 2017 or older).

tl;dr: there is nothing to do before RC1. Disregard my mail. 

Ok, sorry, my bad.  This is referring to a very old fix. My mind was with a different fix from 2024 that removes the underscores entirely, because Bill's idea to optimize the linker output by only linking boxtype modules that are actually used, no longer makes sense and only complicates things. Since we support runtime schemes, *all* box types must always be linked anyway, plus modern linkers don't optimize by object file, but per function.

As the removal of "dynamic" box types has not been merged, I assume it is not too late for RC1, so I will hold off until 1.5. 

Labeltypes, _FL_SHADOW_LABEL, etc. use the same linker optimization, but here it actually works.

[Eric Sokolowsky]

I'm a longtime user of FLTK and I'm really excited to see 1.4 released.

I have been using FLTK for my application (running on Rocky 8, FLTK version 1.3.9) but with the imminent release I decided to try FLTK 1.4.0 for the first time. I also tried using gcc 13.2.1 to compile my application. I came up with some errors in the way my code was using menu items.

In the flags field of the Fl_Menu_Item class, I often use conditionals to change the behavior of the program menus (sometimes some menu items are inactive, for example). However, under gcc 13.2.1 this started to throw errors because of narrowing types (unsigned int to int). Here's an example:

FL_Menu_Item menu_[] = {

 ...

 {Ca&talog", 0, 0, playlist_catalog_menu_items, (show_all ? FL_MENU_INACTIVE : FL_SUBMENU_POINTER), FL_NORMAL_LABEL, 0, 14, 0 },

 ...

}

I had to cast the flags field back to int to get it to compile without errors.

Does it make sense to the FLTK developers to change the flags field to be an unsigned int to avoid this problem? A signed quantity in a bitfield parameter doesn't make a lot of sense to me. I know that the flags member of FL_Menu_Item hasn't changed between 1.3.9 and 1.4.0 so I suspect that the change in reporting of this as an error is because of the compiler upgrade.

I was able to make some type casts in my code and my application now compiles and runs with 1.4.0.

Eric

--

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/346ef7e4-9383-4c11-b2f2-d428c6f627a1n%40googlegroups.com.

[Greg Ercolano]

On 10/18/24 06:32, Eric Sokolowsky wrote:

In the flags field of the Fl_Menu_Item class, I often use conditionals to change the behavior of the program menus (sometimes some menu items are inactive, for example). However, under gcc 13.2.1 this started to throw errors because of narrowing types (unsigned int to int). Here's an example:

FL_Menu_Item menu_[] = {

 ...

 {Ca&talog", 0, 0, playlist_catalog_menu_items, (show_all ? FL_MENU_INACTIVE : FL_SUBMENU_POINTER), FL_NORMAL_LABEL, 0, 14, 0 },

 ...

}

I had to cast the flags field back to int to get it to compile without errors.

    Hmm, in this context it should have to do with the underlying type of an enum,
    and as far as I know, under normal circumstances that should reduce to an int.

    FL_MENU_INACTIVE and FL_SUBMENU_POINTER are defined as enums:

enum { // values for flags:
  FL_MENU_INACTIVE   = 1,          ///< Deactivate menu item (gray out)
  FL_MENU_TOGGLE     = 2,          ///< Item is a checkbox toggle (shows checkbox for on/off state)
  FL_MENU_VALUE      = 4,          ///< The on/off state for checkbox/radio buttons (if set, state is 'on')
  FL_MENU_RADIO      = 8,          ///< Item is a radio button (one checkbox of many can be on)
  FL_MENU_INVISIBLE  = 0x10,       ///< Item will not show up (shortcut will work)
  FL_SUBMENU_POINTER = 0x20,       ///< Indicates user_data() is a pointer to another menu array
  FL_SUBMENU         = 0x40,       ///< Item is a submenu to other items
  FL_MENU_DIVIDER    = 0x80,       ///< Creates divider line below this item. Also ends a group of radio buttons
  FL_MENU_HORIZONTAL = 0x100,      ///< ??? -- reserved, internal (do not use)
  FL_MENU_RESERVED   = 0xffffff00  ///< These bits are reserved for internal or future usage (do not use)
};

    ..and the 5th element in the Fl_Menu_Item struct is 'int flags;'.

    So it really "should" be an int.

    However, I think the issue here is the compiler sees FL_MENU_RESERVED set to 0xffffff00
    which might trigger it to expand the data type to an (unsigned int).

    I just did some tests with a struct and an enum, and that seems to be the cause.
    FL_MENU_RESERVED seems to be new in 1.4.x (not in 1.3.x), so that might be
    the reason this is cropping up.

    We could maybe lower that value for FL_MENU_RESERVED so it doesn't trigger this.
    In my experiments, if I change the enum to 0x7fffff00, then it goes back to being an int type. e.g.

struct Foo {
  int flag;
};

void bla() {
  int show_all = 1;
  enum {
    ENUM_A=1,
    ENUM_B,
    ENUM_C,
    ENUM_MAX = 0xffffff00    // changes enum to be unsigned int
    // ENUM_MAX = 0x7fffff00    // changes enum to be int
  };
  Foo f[] = {
    { show_all ? ENUM_A : ENUM_B },   // complains if ENUM_MAX is 0xffffff00, but not if 0x7fffff00 (or lower)
    0
  };
}

[Bill Spitzak]

The value could also just not be part of the enumeration. I’d also look into removing the value, or replacing it with the inverted “all” value.

[Albrecht Schlosser]

On 10/16/24 20:39 Greg Ercolano wrote:

On 10/16/24 10:30, 'Albrecht Schlosser' via fltk.general wrote:

On 10/16/24 17:46 Greg Ercolano wrote:

    Has the ABI checker been run yet to check for API issues?
    I figure results of that should be shown and resolved before an RC.

Short answer: no, I didn't use the ABI checker (yet) because FLTK 1.4 definitely breaks the ABI (that's what minor version changes in FLTK are intended and allowed to do). Hence, why bother? ...

Longer answer: I'm not sure if you really meant "to check for API issues" which is a totally different question but an interesting byproduct of the ABI checker.

    Yes, that's why I mentioned it -- it makes note of API breaking changes as well,
    and lists removals of any public function/method/structs/etc.

OK, I ran the ABI checker with some special settings, as mentioned elsewhere in this thread.

I found and fixed some minor issues. The remaining issues are still confusing because we added a lot of new methods and/or added new parameters with default values to existing functions/methods.

There are some remaining issues where - theoretically - a user program might have issues when recompiling, for instance when we removed some protected methods of classes that were intended to be used internally. Theoretically someone could have derived their own classes and used such protected methods.

Conclusion: AFAICT there are no API issues caused by unintended changes that would affect user programs. Therefore I believe that we don't have any severe API issues except those already documented.

[Daniel Harding]

On Friday, October 18, 2024 at 8:32:50 AM UTC-5 eso...@gmail.com wrote:

I suspect that the change in reporting of this as an error is because of the compiler upgrade.

I was able to make some type casts in my code and my application now compiles and runs with 1.4.0.

I noticed the same issue when I upgraded to FLTK 1.4 earlier this year, and I did not do a compiler upgrade so I don't believe that is related to the cause. I also just added the cast from unsigned to signed and carried on.

P.S. I'm very excited for and fully support the release of 1.4.0 RC1!

[Eric Sokolowsky]

Greg,

Your response seems to be correct to me. Either of the two fixes mentioned (changing the value of FL_MENU_RESERVED or eliminating it altogether) would fix the problem. If this is not changed in the FLTK source, I'll just continue to use type casting for that parameter, but I'd rather not have to do that.

Kudos to the FLTK developers! This minor point is all I had to change to get my program to go from 1.3.x to 1.4.

Eric

--
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/a3876039-6abb-4bd6-b7d4-4239908afc76%40seriss.com.

[Greg Ercolano]

On 10/18/24 20:26, Eric Sokolowsky wrote:

Greg,

Your response seems to be correct to me. Either of the two fixes mentioned (changing the value of FL_MENU_RESERVED or eliminating it altogether) would fix the problem. If this is not changed in the FLTK source, I'll just continue to use type casting for that parameter, but I'd rather not have to do that.

Kudos to the FLTK developers! This minor point is all I had to change to get my program to go from 1.3.x to 1.4.

    This is probably worth fixing, as I don't think we want the enum to
    change to being an unsigned int.

    Perhaps the right thing to do would be to simply cast 0xffffff00 as an int, e.g.

-  FL_MENU_RESERVED   = 0xffffff00
+  FL_MENU_RESERVED   = int(0xffffff00)

    This seems to also solve the problem.

[Matthias Melcher]

Wouldn't it make more sense to set the FL_MENU_RESERVED to 0x0000ffff, for example, reserving the bottom 16 bits for FLTK use and giving the top 15 (16) bits to the user? Why reserve *all* bits for core? And why are those bits that core already uses not part of the mask? Maybe there is something I don't get?

[Albrecht Schlosser]

On 10/19/24 13:18 'Matthias Melcher' via fltk.general wrote:

Wouldn't it make more sense to set the FL_MENU_RESERVED to 0x0000ffff, for example, reserving the bottom 16 bits for FLTK use and giving the top 15 (16) bits to the user? Why reserve *all* bits for core? And why are those bits that core already uses not part of the mask? Maybe there is something I don't get?

The discussion on GitHub Issue #332 pointed out that user manipulation of all and particularly of currently unused bits in Fl_Menu_Item::flags could be problematic. The discussion was about using currently undefined (supposedly free) bits in this struct member for future FLTK extensions and the result was that we decided to leave the code as-is and to document that the flags member should not be (mis)used by user code.

In commit 53b40f4138e70e44 I defined this bit mask for all previously undefined bits. However, since this was only for documentation, I decided now to remove this bit mask entirely and to clarify the (non-)usage of the flags member in the documentation, see commit 74d827f71fb4a27f. This should resolve the issue (having to use casts).

Note for future development: IMHO we should not touch the existing Fl_Menu code any more: it can't be fixed easily, and all efforts would be wasted time. As discussed before we should rather add a completely new menu code in 1.5.0 where we can use std::vector and other "modern" ;-) C++ stuff which would maintain the menu "arrays" automatically w/o needing such complicated stuff as in the current code that led to issue #332.

[Albrecht Schlosser]

On 10/19/24 05:26 Eric Sokolowsky wrote:

Greg,

Your response seems to be correct to me. Either of the two fixes mentioned (changing the value of FL_MENU_RESERVED or eliminating it altogether) would fix the problem. If this is not changed in the FLTK source, I'll just continue to use type casting for that parameter, but I'd rather not have to do that.

Thanks to you, Eric, for reporting this, and to Greg for investigating the background of these compiler warnings.

I decided to do the latter (eliminating FL_MENU_RESERVED altogether) because its only intention was to *document* that these bits are reserved.

In commit 74d827f71fb4a27f I removed this definition and added more textual documentation about the usage of the 'flags' member.

Eric, can you confirm that this fixes the issue for you? Thanks in advance.

Kudos to the FLTK developers! This minor point is all I had to change to get my program to go from 1.3.x to 1.4.

Welcome, and thank you very, very much for your positive feedback. Even this minor point should now be fixed.

[Albrecht Schlosser]

On 10/19/24 16:28 'Matthias Melcher' via fltk.general wrote:

Note for future development: IMHO we should not touch the existing Fl_Menu code any more: it can't be fixed easily, and all efforts would be wasted time. As discussed before we should rather add a completely new menu code in 1.5.0 where we can use std::vector and other "modern" ;-) C++ stuff which would maintain the menu "arrays" automatically w/o needing such complicated stuff as in the current code that led to issue #332.

Please not another data structure or array arrangement. We have a widget system that can build hierarchies, and that same system should be used for menus, just as it is used for windows.

But that's all for later... .

I agree, and I don't want to start a discussion here either. Note that my statement above didn't imply that we should not use Fl_Widget for menus if it's useful, but anyway, we should consider:

sizeof(Fl_Widget)    = 120
sizeof(Fl_Menu_Item) =  56

--> Fl_Widget is twice as big as Fl_Menu_Item.

Looking forward to discussing how to implement the new menu system after the release of 1.4.0. I'm more interested in the "look and feel" though than in the concrete implementation of menu hierarchies, particularly when looking at the now (IMHO) much better implementation of menus in - for instance - firefox etc. which also simplifies menu placement under Wayland.

But, as you wrote, that's all for later... . ;-)

[Eric Sokolowsky]

I tried using the updated FLTK with my application and I confirm that the menu item fix has solved the issue. Thank you!

Eric

--
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/f0ea0b78-8d73-4a52-aa95-586fd4ea4559%40aljus.de.

[Albrecht Schlosser]

On 10/21/24 17:23 Eric Sokolowsky wrote:
> I tried using the updated FLTK with my application and I confirm that
> the menu item fix has solved the issue.

Great, thanks for testing and for your quick feedback.