foxgui-users Mailing List for FOX GUI Toolkit

On the Mac using xQuartz there is a bug (well known:
https://github.com/XQuartz/XQuartz/issues/438) that when you
resize a window it does not get refreshed properly. 

 

I've added everything I could think of to force a refresh in my
c++ code that is called on resize but nothing works:

 

 

update();

repaint();

getApp()->refresh();

getApp()-flush();

 

 

 

any ideas?

 

 

Kind regards,

 

js

 

 

 

Just because I walked face first into this switching my project to vcpkg 
and I like things documented all together.

Kitware dropped support for Ubuntu 18

https://apt.kitware.com

so no official repo

One can download a .sh from here though

https://cmake.org/download/

it extracts, but I'm saving the disappointment of finding out it doesn't 
run until tomorrow.

Even Ubuntu 24.04 doesn't have a current enough CMake for vcpkg.

Please forgive if you guys already knew this


On 1/2/2026 9:45 PM, JVZ wrote:
> On Fri, 2 Jan 2026 12:12:06 -0600
> Roland Hughes via Foxgui-users<fox...@li...> wrote:
>
>> On 1/2/2026 11:05 AM, Sander Jansen wrote:
>>> I still don't get it. Assuming you have 3.27, why can't you set the
>>> minimum required version in FOX to 3.23?
>>>   
>>>> But, if you want to still support Ubuntu 18.04 (Some development
>>> locked there) your min needs to be 3.10
>>>
>>> I don't see the point. If you insist on running a 7 year old OS for
>>> stability reasons, why would you want the latest version of a library.
>>> Just download 1.6 or whatever was released 7 years ago. Also there
>>> seems to be some sort of double standard, YES on downloading the
>>> bleeding edge of FOX and NO on downloading the latest cmake.
>> Well, this goes back to my original chiming in and the fact I live in a
>> different world.
>>
>> *What is the oldest OS you are looking to support with this release?*
> There's no need for "bleeding edge" cmake to get its benefits; my VC++
> were also not "bleeding edge", for same reason: we don't have the assumption
> that everyone is at the bleeding edge, some stragglers will be behind, some
> will the in the middle and a few will be at the latest.
>
> FYI, I'm shooting for cmake 3.xx, where xx probably >16.
>
> The argument "just upgrade" works for us at home, but not for people that
> are beholden slow-moving s/w update approval process that I.T. departments
> may have.
>
>
>
>
>      					-- JVZ
>
>
>
-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

On Fri, 2 Jan 2026 12:12:06 -0600
Roland Hughes via Foxgui-users <fox...@li...> wrote:

>On 1/2/2026 11:05 AM, Sander Jansen wrote:
>> I still don't get it. Assuming you have 3.27, why can't you set the 
>> minimum required version in FOX to 3.23?
>>  
>> > But, if you want to still support Ubuntu 18.04 (Some development   
>> locked there) your min needs to be 3.10
>>
>> I don't see the point. If you insist on running a 7 year old OS for 
>> stability reasons, why would you want the latest version of a library. 
>> Just download 1.6 or whatever was released 7 years ago. Also there 
>> seems to be some sort of double standard, YES on downloading the 
>> bleeding edge of FOX and NO on downloading the latest cmake.  
>
>Well, this goes back to my original chiming in and the fact I live in a 
>different world.
>
>*What is the oldest OS you are looking to support with this release?*

There's no need for "bleeding edge" cmake to get its benefits; my VC++
were also not "bleeding edge", for same reason: we don't have the assumption 
that everyone is at the bleeding edge, some stragglers will be behind, some
will the in the middle and a few will be at the latest.

FYI, I'm shooting for cmake 3.xx, where xx probably >16. 

The argument "just upgrade" works for us at home, but not for people that
are beholden slow-moving s/w update approval process that I.T. departments
may have.




    					-- JVZ



-- 
+----------------------------------------------------------------------------+
| Copyright (C) 21:30 01/ 2/2026 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

On 1/2/2026 11:05 AM, Sander Jansen wrote:
> I still don't get it. Assuming you have 3.27, why can't you set the 
> minimum required version in FOX to 3.23?
>
> > But, if you want to still support Ubuntu 18.04 (Some development 
> locked there) your min needs to be 3.10
>
> I don't see the point. If you insist on running a 7 year old OS for 
> stability reasons, why would you want the latest version of a library. 
> Just download 1.6 or whatever was released 7 years ago. Also there 
> seems to be some sort of double standard, YES on downloading the 
> bleeding edge of FOX and NO on downloading the latest cmake.

Well, this goes back to my original chiming in and the fact I live in a 
different world.

*What is the oldest OS you are looking to support with this release?*

I didn't see an answer for that. The documentation on the official Web 
site lists a bunch of really ancient operating systems, but not which 
versions you need.

If you want to support Ubuntu 18.04 then the minimum CMake version needs 
to be what comes with those repos. If you have customers/users running 
older operating systems, you need to use their version.

The doc on the web site needs to segregate archaic OSes that only work 
with very old (possibly no longer available) versions of FOX from 
"minimum OS today's version needs." It's confusing to people.

*As to the 7 year old OS*

It's not so much stability as legal requirement. I live in the FDA 510K 
regulated world of medical devices. Every few years I get a phone call 
or email (usually both) from this Indian consulting firm named Harman to 
work on some kind of cardiac device. All work must be done on-site (I 
think the place is in Iowa, never went) because you must use the 
gingerly maintained development system. OS/2 compiling Qt3. As I said, I 
never took the contract because they also want it done for absolutely no 
money.

When I was working on this device <https://www.kneevoice.com> not long 
ago, we looked at Fox as one of the possible libraries. The end client 
had never created a medical device, they wanted sexy, so they used one 
of other libraries I evaluated. They also haven't gotten through the 
510K process last I heard. I tried to explain to them how wretched the 
Medtronic base unit for pacemaker control is, but they would have none 
of it. For board verification software, we needed serial and audio i/o 
with almost no GUI, so I went with NanoGUI because it was tiny and 
wouldn't get in the way of the other two.

When we build a medical device there are several detailed documents that 
must be created. One lists the file size, version, and location of every 
binary on the device. The other is a document third party testing must 
be able to re-create the development environment from. When they get 
done, the binary versions of everything must match before they begin 
testing.

Most places are now using Oracle Virtual Box VM that is configured to be 
disconnected from the source repos and Internet because someone 
installing their favorite IDE or whatever can pooch this. First time 
through there is no avoiding a full 510K process using multiple external 
testing firms approved by the FDA. It is time consuming and expensive. 
For something like a surgical robot it can consume 5-7 years. Once you 
get through it, you can't change anything in the Dev world.

/Source code doesn't count/

As long as it is a library you build from source and contain within your 
own code repository you can qualify for "minor enhancement" approval 
pass if you:

 1. Perform full static analysis of said code
 2. Have a formal code review for every module/change with formal diffs
    that you archive in your Design History File.
 3. Perform full in-house QA validation of the new device once it comes
    off your existing FDA approved manufacturing line.

For some lower risk devices you just send that documentation to the FDA 
and you get approved a short time later.

If the binaries of your Dev environment don't match what you originally 
filed . . . fugedaboutit

It's not just FDA stuff. I worked at a client site that develops 
control/operation systems for hog barns. They are also still on Ubuntu 
18.04 last I heard. There are some similar regulations for systems 
responsible for animal welfare.

We exist in worlds where you are locked in, for good reason, to a Dev 
environment so results are 100% reproducible.

When it comes to GUI libraries, there can be compelling bug fixes or new 
features that justify bringing in the new library when working on an 
enhancement or fix. You are stopped cold if the Dev environment has to 
change though. Must be a product generating oceans of revenue to justify 
going through a more involved 510K process.

Sorry for the length, but there is no short explanation.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

I still don't get it. Assuming you have 3.27, why can't you set the minimum
required version in FOX to 3.23?

> But, if you want to still support Ubuntu 18.04 (Some development locked
there) your min needs to be 3.10

I don't see the point. If you insist on running a 7 year old OS for
stability reasons, why would you want the latest version of a library. Just
download 1.6 or whatever was released 7 years ago. Also there seems to be
some sort of double standard, YES on downloading the bleeding edge of FOX
and NO on downloading the latest cmake.



On Fri, Jan 2, 2026 at 8:49 AM Roland Hughes <ro...@lo...>
wrote:

> Debug and --dependency-file
>
> https://cmake.org/cmake/help/latest/release/3.27.html
>
> But, if you want to still support Ubuntu 18.04 (Some development locked
> there) your min needs to be 3.10
> On 1/2/2026 8:43 AM, Sander Jansen wrote:
>
> I have 4.2.1 but that's unlikely relevant to the discussion, why would we
> need to set the minimum requirement to 3.27? Obviously, users can run newer
> versions if they want to use the debugging feature.
>
> Sander
>
> On Wed, Dec 31, 2025 at 3:32 AM Roland Hughes via Foxgui-users <
> fox...@li...> wrote:
>
>>
>> On 12/30/2025 1:19 PM, Sander Jansen wrote:
>>
>> The minimum cmake requirement probably can be dropped to 3.23.
>>
>> No. You want 3.27
>>
>> Working on someone else's code I just hit a need to debug CMake. You can
>> guess at it using --trace-source and --trace-expand.
>>
>> We didn't get cmake_language(TRACE ON|OFF) until CMake 4.2
>>
>> --
>> Roland Hughes, President
>> Logikal Solutions
>> (630)-205-1593  (cell)https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://johnsmith-book.com
>>
>> _______________________________________________
>> Foxgui-users mailing list
>> Fox...@li...
>> https://lists.sourceforge.net/lists/listinfo/foxgui-users
>>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593  (cell)https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://johnsmith-book.com
>
>

Debug and --dependency-file

https://cmake.org/cmake/help/latest/release/3.27.html

But, if you want to still support Ubuntu 18.04 (Some development locked 
there) your min needs to be 3.10

On 1/2/2026 8:43 AM, Sander Jansen wrote:
> I have 4.2.1 but that's unlikely relevant to the discussion, why would 
> we need to set the minimum requirement to 3.27? Obviously, users can 
> run newer versions if they want to use the debugging feature.
>
> Sander
>
> On Wed, Dec 31, 2025 at 3:32 AM Roland Hughes via Foxgui-users 
> <fox...@li...> wrote:
>
>
>     On 12/30/2025 1:19 PM, Sander Jansen wrote:
>>     The minimum cmake requirement probably can be dropped to 3.23.
>
>     No. You want 3.27
>
>     Working on someone else's code I just hit a need to debug CMake.
>     You can guess at it using --trace-source and --trace-expand.
>
>     We didn't get cmake_language(TRACE ON|OFF) until CMake 4.2
>
>     -- 
>     Roland Hughes, President
>     Logikal Solutions
>     (630)-205-1593  (cell)
>     https://theminimumyouneedtoknow.com
>     https://infiniteexposure.net
>     https://johnsmith-book.com
>
>     _______________________________________________
>     Foxgui-users mailing list
>     Fox...@li...
>     https://lists.sourceforge.net/lists/listinfo/foxgui-users
>
-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

I have 4.2.1 but that's unlikely relevant to the discussion, why would we
need to set the minimum requirement to 3.27? Obviously, users can run newer
versions if they want to use the debugging feature.

Sander

On Wed, Dec 31, 2025 at 3:32 AM Roland Hughes via Foxgui-users <
fox...@li...> wrote:

>
> On 12/30/2025 1:19 PM, Sander Jansen wrote:
>
> The minimum cmake requirement probably can be dropped to 3.23.
>
> No. You want 3.27
>
> Working on someone else's code I just hit a need to debug CMake. You can
> guess at it using --trace-source and --trace-expand.
>
> We didn't get cmake_language(TRACE ON|OFF) until CMake 4.2
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593  (cell)https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://johnsmith-book.com
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users
>

Just dropped 1.7.89, its main difference is Microsoft VS2019 project files,
updated from VS2015.  If you have newer versions, these should automatically
update to your newer version.  The case of the missing spaces in custom-
build step call to 'reswrap' have been fixed.

This is *really* the last update in 2025 ;-)


          -- JVZ


-- 
+----------------------------------------------------------------------------+
| Copyright (C) 10:00 12/31/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

On Wed, 31 Dec 2025 15:47:28 +0100
Pof <jd3...@gm...> wrote:

>Hi all,
>
>I am trying to build the last Fox1.7.88 (I was previously using 1.7.81) 
>using MSVC++2017 on Windows 11.
>I am having a MSB4198 error while building foxlib (see below) saying 
>that it is impossible to evaluate expression "FullPath".
>
>I haved checked the 
>[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] is 
>corretly set to: "LongPathsEnabled"=dword:00000001
>Am I doing something wrong?
>
>Regards,
>JD
>
>
>1>------ Début de la régénération globale : Projet : reswrap,   
>Configuration : Release x64 ------
>1>reswrap.cpp
>1>reswrap.vcxproj ->   
>D:\Dev\Fox\fox-1.7.88VC15\windows\x64\Release\reswrap.exe
>2>------ Début de la régénération globale : Projet : foxlib,   
>Configuration : Release x64 ------
>2>Reswrapping icons...
>2>C:\Program Files (x86)\Microsoft Visual   
>Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(240,30): 
>error MSB4198: Impossible d'évaluer l'expression "FullPath" sur 
>l'élément "arrownext.gif arrowprev.gif bigapp.gif bigcdrom.gif 
>bigcomputer.gif bigdesktop.gif bigdoc.gif bigfloppy.gif bigfloppy3.gif 
>bigfloppy5.gif bigfolder.gif bigfolderopen.gif bigharddisk.gif 
>bignetdrive.gif bignethood.gif bookadd.bmp bookclr.gif bookclr_gif.gif 
>bookdel.bmp bookdel_gif.gif bookmrk_gif.gif booknxt_gif.gif 
>bookprv_gif.gif bookset.gif bookset_gif.gif clearentry.gif cmymode.gif 
>dialmode.gif dirup_gif.gif dockbottom.gif dockflip.gif dockfree.gif 
>dockleft.gif dockright.gif docktop.gif entericon.gif erroricon.gif 
>eyedrop.gif fileaccept.gif filecancel.gif filecopy.gif filedelete.gif 
>filehidden.gif filelink.gif filemove.gif filerename.gif fileshown.gif 
>foldernew.gif gotohome.gif gotowork.gif hammer_gif.gif hsvmode.gif 
>infoicon.gif landscape.gif listmode.gif miniapp.gif minicdrom.gif 
>minicomputer.gif minidesktop.gif minidoc.gif minifloppy.gif 
>minifloppy3.gif minifloppy5.gif minifolder.gif minifolderopen.gif 
>miniharddisk.gif mininetdrive.gif mininethood.gif minizipdrive.gif 
>newfolder.bmp portrait.gif questionicon.gif redo_gif.gif rgbmode.gif 
>searchicon.gif showbigicons.gif showdetails.gif showsmallicons.gif 
>sorting.bmp undo_gif.gif warningicon.gif winclose.gif winmaximize.gif 
>winminimize.gif winrestore.gif". Impossible d'appliquer la métadonnée 
>d'élément "%(FullPath)" au chemin d'accès "arrownext.gif arrowprev.gif 
>bigapp.gif bigcdrom.gif bigcomputer.gif bigdesktop.gif bigdoc.gif 
>bigfloppy.gif bigfloppy3.gif bigfloppy5.gif bigfolder.gif 
>bigfolderopen.gif bigharddisk.gif bignetdrive.gif bignethood.gif 
>bookadd.bmp bookclr.gif bookclr_gif.gif bookdel.bmp bookdel_gif.gif 
>bookmrk_gif.gif booknxt_gif.gif bookprv_gif.gif bookset.gif 
>bookset_gif.gif clearentry.gif cmymode.gif dialmode.gif dirup_gif.gif 
>dockbottom.gif dockflip.gif dockfree.gif dockleft.gif dockright.gif 
>docktop.gif entericon.gif erroricon.gif eyedrop.gif fileaccept.gif 
>filecancel.gif filecopy.gif filedelete.gif filehidden.gif filelink.gif 
>filemove.gif filerename.gif fileshown.gif foldernew.gif gotohome.gif 
>gotowork.gif hammer_gif.gif hsvmode.gif infoicon.gif landscape.gif 
>listmode.gif miniapp.gif minicdrom.gif minicomputer.gif minidesktop.gif 
>minidoc.gif minifloppy.gif minifloppy3.gif minifloppy5.gif 
>minifolder.gif minifolderopen.gif miniharddisk.gif mininetdrive.gif 
>mininethood.gif minizipdrive.gif newfolder.bmp portrait.gif 
>questionicon.gif redo_gif.gif rgbmode.gif searchicon.gif 
>showbigicons.gif showdetails.gif showsmallicons.gif sorting.bmp 
>undo_gif.gif warningicon.gif winclose.gif winmaximize.gif 
>winminimize.gif winrestore.gif". Le chemin 
>D:\Dev\Fox\fox-1.7.88VC15\windows\foxlib\arrownext.gif arrowprev.gif 
>bigapp.gif bigcdrom.gif bigcomputer.gif bigdesktop.gif bigdoc.gif 
>bigfloppy.gif bigfloppy3.gif bigfloppy5.gif bigfolder.gif 
>bigfolderopen.gif bigharddisk.gif bignetdrive.gif bignethood.gif 
>bookadd.bmp bookclr.gif bookclr_gif.gif bookdel.bmp bookdel_gif.gif 
>bookmrk_gif.gif booknxt_gif.gif bookprv_gif.gif bookset.gif 
>bookset_gif.gif clearentry.gif cmymode.gif dialmode.gif dirup_gif.gif 
>dockbottom.gif dockflip.gif dockfree.gif dockleft.gif dockright.gif 
>docktop.gif entericon.gif erroricon.gif eyedrop.gif fileaccept.gif 
>filecancel.gif filecopy.gif filedelete.gif filehidden.gif filelink.gif 
>filemove.gif filerename.gif fileshown.gif foldernew.gif gotohome.gif 
>gotowork.gif hammer_gif.gif hsvmode.gif infoicon.gif landscape.gif 
>listmode.gif miniapp.gif minicdrom.gif minicomputer.gif minidesktop.gif 
>minidoc.gif minifloppy.gif minifloppy3.gif minifloppy5.gif 
>minifolder.gif minifolderopen.gif miniharddisk.gif mininetdrive.gif 
>mininethood.gif minizipdrive.gif newfolder.bmp portrait.gif 
>questionicon.gif redo_gif.gif rgbmode.gif searchicon.gif 
>showbigicons.gif showdetails.gif showsmallicons.gif sorting.bmp 
>undo_gif.gif warningicon.gif winclose.gif winmaximize.gif 
>winminimize.gif winrestore.gif dépasse la limite maximale de chemin du 
>système d'exploitation. Le nom du fichier qualifié complet doit contenir 
>moins de 260 caractères.
>2>Génération du projet "foxlib.vcxproj" terminée -- ÉCHEC.  
>========== Régénération globale : 1 a réussi, 1 a échoué, 0 a été ignoré 
>==========

In my original VS2015 build, reswrap was called *before* sources were compiled;
this is necessary as otherwise icons.h and icons.cpp don't yet exist; they're
created by "custom-build-step" which was supposedly pre-build step.

When upgrading to later VS, the ordering of custom-build step seems to have 
gotten out of whack.  Its not a huge deal, hit build a 2nd time it usually picks
up the icons.h/icons.cpp then; they were still created, albeit not before the
regular file compiles start.

My original was VS2015, I skipped VS2017 and went to VS2019.  Now I'm
messing with VS2022 and VS2026 [which is just out].

Not sure if there are special issues wirh VS2017, but VS2019 and VS2022
as well as the still bleeding edge VS2026 have worked fine for me.


One more thing: during the project files upgrade process, a space is getting
lost in the call to "reswrap".  The first image file is stuck to the icons.h
[first call], and to and icons.cpp [second call].  

I had to manually insert the ' ' between them.  

Right-click on "Properties", goto "Custom Build Step"/"General" then edit
the Command Line.  You may have to change both Debug and Release command
lines, inserting the missing space after icons.h and icons.cpp.
This needs to be done for foxlib, foxdll, and in those sub-projects that
use reswrapped icons.

Note that the original VS2015 project files were correct.  The error appears
during the upgrade of the project files to newer >VS2015 process, it seems.



      -- JVZ



-- 
+----------------------------------------------------------------------------+
| Copyright (C) 09:00 12/31/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

Hi all,

I am trying to build the last Fox1.7.88 (I was previously using 1.7.81) 
using MSVC++2017 on Windows 11.
I am having a MSB4198 error while building foxlib (see below) saying 
that it is impossible to evaluate expression "FullPath".

I haved checked the 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] is 
corretly set to: "LongPathsEnabled"=dword:00000001
Am I doing something wrong?

Regards,
JD


1>------ Début de la régénération globale : Projet : reswrap, 
Configuration : Release x64 ------
1>reswrap.cpp
1>reswrap.vcxproj -> 
D:\Dev\Fox\fox-1.7.88VC15\windows\x64\Release\reswrap.exe
2>------ Début de la régénération globale : Projet : foxlib, 
Configuration : Release x64 ------
2>Reswrapping icons...
2>C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(240,30): 
error MSB4198: Impossible d'évaluer l'expression "FullPath" sur 
l'élément "arrownext.gif arrowprev.gif bigapp.gif bigcdrom.gif 
bigcomputer.gif bigdesktop.gif bigdoc.gif bigfloppy.gif bigfloppy3.gif 
bigfloppy5.gif bigfolder.gif bigfolderopen.gif bigharddisk.gif 
bignetdrive.gif bignethood.gif bookadd.bmp bookclr.gif bookclr_gif.gif 
bookdel.bmp bookdel_gif.gif bookmrk_gif.gif booknxt_gif.gif 
bookprv_gif.gif bookset.gif bookset_gif.gif clearentry.gif cmymode.gif 
dialmode.gif dirup_gif.gif dockbottom.gif dockflip.gif dockfree.gif 
dockleft.gif dockright.gif docktop.gif entericon.gif erroricon.gif 
eyedrop.gif fileaccept.gif filecancel.gif filecopy.gif filedelete.gif 
filehidden.gif filelink.gif filemove.gif filerename.gif fileshown.gif 
foldernew.gif gotohome.gif gotowork.gif hammer_gif.gif hsvmode.gif 
infoicon.gif landscape.gif listmode.gif miniapp.gif minicdrom.gif 
minicomputer.gif minidesktop.gif minidoc.gif minifloppy.gif 
minifloppy3.gif minifloppy5.gif minifolder.gif minifolderopen.gif 
miniharddisk.gif mininetdrive.gif mininethood.gif minizipdrive.gif 
newfolder.bmp portrait.gif questionicon.gif redo_gif.gif rgbmode.gif 
searchicon.gif showbigicons.gif showdetails.gif showsmallicons.gif 
sorting.bmp undo_gif.gif warningicon.gif winclose.gif winmaximize.gif 
winminimize.gif winrestore.gif". Impossible d'appliquer la métadonnée 
d'élément "%(FullPath)" au chemin d'accès "arrownext.gif arrowprev.gif 
bigapp.gif bigcdrom.gif bigcomputer.gif bigdesktop.gif bigdoc.gif 
bigfloppy.gif bigfloppy3.gif bigfloppy5.gif bigfolder.gif 
bigfolderopen.gif bigharddisk.gif bignetdrive.gif bignethood.gif 
bookadd.bmp bookclr.gif bookclr_gif.gif bookdel.bmp bookdel_gif.gif 
bookmrk_gif.gif booknxt_gif.gif bookprv_gif.gif bookset.gif 
bookset_gif.gif clearentry.gif cmymode.gif dialmode.gif dirup_gif.gif 
dockbottom.gif dockflip.gif dockfree.gif dockleft.gif dockright.gif 
docktop.gif entericon.gif erroricon.gif eyedrop.gif fileaccept.gif 
filecancel.gif filecopy.gif filedelete.gif filehidden.gif filelink.gif 
filemove.gif filerename.gif fileshown.gif foldernew.gif gotohome.gif 
gotowork.gif hammer_gif.gif hsvmode.gif infoicon.gif landscape.gif 
listmode.gif miniapp.gif minicdrom.gif minicomputer.gif minidesktop.gif 
minidoc.gif minifloppy.gif minifloppy3.gif minifloppy5.gif 
minifolder.gif minifolderopen.gif miniharddisk.gif mininetdrive.gif 
mininethood.gif minizipdrive.gif newfolder.bmp portrait.gif 
questionicon.gif redo_gif.gif rgbmode.gif searchicon.gif 
showbigicons.gif showdetails.gif showsmallicons.gif sorting.bmp 
undo_gif.gif warningicon.gif winclose.gif winmaximize.gif 
winminimize.gif winrestore.gif". Le chemin 
D:\Dev\Fox\fox-1.7.88VC15\windows\foxlib\arrownext.gif arrowprev.gif 
bigapp.gif bigcdrom.gif bigcomputer.gif bigdesktop.gif bigdoc.gif 
bigfloppy.gif bigfloppy3.gif bigfloppy5.gif bigfolder.gif 
bigfolderopen.gif bigharddisk.gif bignetdrive.gif bignethood.gif 
bookadd.bmp bookclr.gif bookclr_gif.gif bookdel.bmp bookdel_gif.gif 
bookmrk_gif.gif booknxt_gif.gif bookprv_gif.gif bookset.gif 
bookset_gif.gif clearentry.gif cmymode.gif dialmode.gif dirup_gif.gif 
dockbottom.gif dockflip.gif dockfree.gif dockleft.gif dockright.gif 
docktop.gif entericon.gif erroricon.gif eyedrop.gif fileaccept.gif 
filecancel.gif filecopy.gif filedelete.gif filehidden.gif filelink.gif 
filemove.gif filerename.gif fileshown.gif foldernew.gif gotohome.gif 
gotowork.gif hammer_gif.gif hsvmode.gif infoicon.gif landscape.gif 
listmode.gif miniapp.gif minicdrom.gif minicomputer.gif minidesktop.gif 
minidoc.gif minifloppy.gif minifloppy3.gif minifloppy5.gif 
minifolder.gif minifolderopen.gif miniharddisk.gif mininetdrive.gif 
mininethood.gif minizipdrive.gif newfolder.bmp portrait.gif 
questionicon.gif redo_gif.gif rgbmode.gif searchicon.gif 
showbigicons.gif showdetails.gif showsmallicons.gif sorting.bmp 
undo_gif.gif warningicon.gif winclose.gif winmaximize.gif 
winminimize.gif winrestore.gif dépasse la limite maximale de chemin du 
système d'exploitation. Le nom du fichier qualifié complet doit contenir 
moins de 260 caractères.
2>Génération du projet "foxlib.vcxproj" terminée -- ÉCHEC.
========== Régénération globale : 1 a réussi, 1 a échoué, 0 a été ignoré 
==========

On 12/30/2025 1:19 PM, Sander Jansen wrote:
> The minimum cmake requirement probably can be dropped to 3.23.

No. You want 3.27

Working on someone else's code I just hit a need to debug CMake. You can 
guess at it using --trace-source and --trace-expand.

We didn't get cmake_language(TRACE ON|OFF) until CMake 4.2

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

So looks like both msys2 and vcpkg could work well here and we can
basically leave it up to the user to decide what works best for them. No
specific cases needed in the cmake project.

The FetchContent cmake feature could work as a backup in case we don't find
anything, as the more popular dependencies (zlib, jpeg. tiff, openjpeg) can
be easily integrated (they come with cmake already) and would perhaps also
work for cross-compiling things.

The minimum cmake requirement probably can be dropped to 3.23.



On Sat, Dec 27, 2025 at 11:38 AM JVZ <je...@fo...> wrote:

> On Sat, 27 Dec 2025 08:54:30 -0600
> Sander Jansen <s.j...@gm...> wrote:
>
> >I've updated my CMake project files for FOX to a minimum version of 4.0 as
> >the 3.xx releases are now considered legacy. Currently updated to 1.7.86.
> >
> >The new version is much better organized and also installs CMake config
> >files, which makes integration into other CMake projects a lot easier
> (just
> >import the FOX target). Out of tree builds are now properly supported. In
> >addition projects can also link directly to the build tree for testing
> >purposes without having to install FOX.
> >
> >This new version also enables PCH which basically halves the compile time
> >for FOX.
> >
> >I was able to cross compile FOX using MinGW quite easily and was even able
> >to run it under Wine without a hitch. I have not tested it under native
> >Windows yet, but I'm planning to see whether I can use CMake's
> FetchContent
> >to automatically fetch and compile basic dependencies like jpeg and zlib,
> >as Windows lacks package management like we do on Linux
> >
> >I did find an oddity in regards to the jpeg2000 support in FOX, as it
> >seemingly requires both HAVE_JP2_H and HAVE_J2K_H to be defined. The
> latter
> >appears to be used in the FXJP2{Icon/Image}, while the former is used in
> >the actual io.
> >
> >Another remaining issue is the few left over FXAPI decorators in the
> >glviewer app which breaks builds on Windows due to dlexport/ dlimport
> >mix-up. Those should be removed.
> >
> >The repo for CMake can be found here:
> >https://github.com/gogglesguy/fox/tree/cmake
> >
> >I'm in the progress of updating gogglesmm to use this as a submodule here:
> >https://github.com/gogglesmm/gogglesmm/tree/cmake4
> >
> >Cheers,
> >
> >Sander
>
> This sounds good.  Switching to cmake has been on the to-do list for a
> while
> and if your cmake configs look good it will become the official build
> system
> soon.
>
> For windows support w/o VC++, perhaps you can look into MSYS2?
>
> MSYS2 has [and you'll like this] the Arch package system; once you have a
> core MSYS2 installed, you can pacman -S <pkg> and pacman -Syu to update
> the
> whole enchilada.  Besides, MSYS2 also has a alternative C-runtime
> libraries.
>
> Both GCC and clang are available, even ARM target support is in there..
>
> For other projects, I've been using cmake for a bit, and VC++ CE 2019
> which I'm using has cmake-generator to flesh out VC++ project files;
> this is a huge part of my motivation to switch to CMAKE as updating
> the stupid proect files "by hand" is going to be a thing of the past.
>
>
>
>      -- JVZ
>
>
>
>
>
>
> --
>
> +----------------------------------------------------------------------------+
> | Copyright (C) 11:20 12/27/2025 Jeroen van der Zijp.   All Rights
> Reserved. |
>
> +----------------------------------------------------------------------------+
>

On Tue, 30 Dec 2025 12:11:03 +0100
Enno Rehling <enn...@gm...> wrote:

>On 12/29/2025 00:20, JVZ wrote:
>> On Sun, 28 Dec 2025 11:15:52 +0100
>> Enno Rehling <enn...@gm...> wrote:
>>   
>>> On 12/27/2025 20:19, Roland Hughes via Foxgui-users wrote:  
>>>> Honestly, I hate MSYS2. Actually I hate anything to do with "Linux
>>>> emulation" on Windows for building Windows apps.  
>>>
>>> I agreee whole-heartedly. Trying to pretend that Windows can be made to
>>> work like a UNIX is misguided.  
>> 
>> MSYS2 ucrt does NOT do that, if I understand it correctly.  
>
>Apologies, I was thinking of cygwin, which does.
>
>Someone mentioned vcpkg in this thread: While I'm usually in favor of 
>using whatever OS package manager to install dependencies (apt, rpm, 
>brew, or ports), in cases where there is none (Windows, either 32 or 64 
>bit), vcpkg does a good job. I've never used it outside of Windows, but 
>apparently that should also work (unless, like me, you prefer the native 
>package manager).
>
>>> Regarding the original post: A lot of distributions still ship with
>>> CMake 3, appartently. My Debian 13 comes with CMake 3.31.6, to name one.
>>> I have never needed to set cmake_minimum_required higher than 3.13 in
>>> the past, and hope this doesn't mean I need to change my projects?  
>> 
>> It looks like I'm on CMake 3.28.3; this is running Mint 22.2 "Zara" so
>> I'm pretty up-to-date.  
>
>My point seems made: It may be too early to go all-in on CMake 4, and 
>too big a step to take when introducing CMake to Fox all at once. What 
>would be the advantage of using CMake 4 over 3? Are there must-have 
>features that building Fox depends on?

I changed the top line in Sander's CMakeLists.txt to: 

	cmake_minimum_required(VERSION 3.28)

And it appeared to compile w/o a hitch.

At least on Linux there doesn't seem to be a compelling need for cmake4.

I am planning to come up with cmake config which requires some version
of cmake3 or up; it seems the most common out there at this point.

I should check what version is on current raspbian operating system
as well, as I'm planning to extend support for aarch64.



       -- JVZ



-- 
+----------------------------------------------------------------------------+
| Copyright (C) 09:50 12/30/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

On 12/30/2025 5:11 AM, Enno Rehling wrote:
>
> Someone mentioned vcpkg in this thread: While I'm usually in favor of 
> using whatever OS package manager to install dependencies (apt, rpm, 
> brew, or ports), in cases where there is none (Windows, either 32 or 
> 64 bit), vcpkg does a good job. I've never used it outside of Windows, 
> but apparently that should also work (unless, like me, you prefer the 
> native package manager).

That was me.

My first exposure to it has been with creating a Windows installer for 
LsCs, then LsScintilla, so I can have a Windows version of RedDiamond.

I am loathe to replace my existing shell scripts that use native tools 
to build Debian and RPM packages. I have been burned too many times by 
"tools" to generate packages and even ISO files. Can't remember the name 
of it, but there was a GUI tool that would let you spin up a custom ISO 
of Ubuntu: create user accounts, choose the packages, tweak the "live" 
desktop and the installer. Yeah it looked nice. It was certainly simple 
if all you wanted to do was either take stuff out or install stuff from 
the repos. Really sucked trying to add your own (&)(*&)(*.

The following year the package was no longer maintained.

I gave you that little rant because now CPack claims to have RPM, 
Debian, and Windows engines (among others).

https://cmake.org/cmake/help/latest/cpack_gen/rpm.html

https://cmake.org/cmake/help/v3.8/module/CPackRPM.html

Debian

https://cmake.org/cmake/help/latest/cpack_gen/deb.html

https://cmake.org/cmake/help/v3.7/module/CPackDeb.html

Windows

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Packaging%20With%20CPack.html


It's tempting to switch . . . but . . . I've been a victim of 
abandonware before.

https://www.logikalsolutions.com/wordpress/information-technology/thank-you-for-your-future-abandonware/


It's tempting to switch all of the projects to use vcpkg as well. Let 
vcpkg pull in jpeg, sqlite3, etc. packages at time of build and bundle 
what it built with the installation package. That's real tempting. Maybe 
others on this list never get burned by it, but I'm sick of the Agile 
development Linux distros use. *How many of you have had a perfectly 
working executable, the distro powers that be then push out whatever 
shat itself out the ass-end of the last sprint, and now stuff is broken?*

You did nothing wrong, but now your software won't work. Guess who gets 
the call?

I was creating AppImages of RedDiamond to get around this problem.

https://sourceforge.net/projects/reddiamond/files/AppImages/

No good deed goes unpunished. Ubuntu 24 moved to a new version of Fuse 
(which AppImage needs) so you have to instruct people how to install the 
old version of Fuse to make things run.

I was considering Flatpacks for the future . . . but vcpkg might be the 
best way to go.

I would like Jeroen to look at the vcpkg route and chime in. Just how 
much pain would it save you to ONE version of every dependency library 
like jpeg, etc? No longer having to hack around all of those issues

>
> My point seems made: It may be too early to go all-in on CMake 4, and 
> too big a step to take when introducing CMake to Fox all at once. What 
> would be the advantage of using CMake 4 over 3? Are there must-have 
> features that building Fox depends on?
>
> Enno. 

To me, just spouting out that ass sitting on my shoulders, you first 
have to decide

/What are you going to abandon?/

The move to CMake will man FOX no longer runs on many of those platforms 
listed on the documentation page. Not that many, if any, of those 
platforms are still around and I would seriously doubt they are keeping 
current with FOX, but, one has to make the decision.

I can offer a cautionary tale here.

When I posted a message on the CMake boards looking for an example 
project to build a Windows installation package for a library that had 
both run-time and development installations one person offered up their 
own package.

https://github.com/LegalizeAdulthood/iterated-dynamics

It did build just fine on Windows. I noticed they had some verbge in the 
script for Unix so I spun up one of my Ubuntu 18.04 development VMs. 
Died horribly. I did not know that they had broken their Unix/Linux 
support while working on a major update. Then someone else on the CMake 
message board chimed in.

cmake --workflow --preset default

I forget if it was workflow or preset, but, one of those did not exist 
in the version of CMake available for Ubuntu 18.04.

At this point I will rephrase the question.

/What is the oldest version of insert-Linux-distro-here you wish to run on?/

Use the version of CMake that is in their repos and it "should" build on 
all newer ones until CMake becomes mature enough to start deleting major 
features.


> -- 

Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

On 12/29/2025 00:20, JVZ wrote:
> On Sun, 28 Dec 2025 11:15:52 +0100
> Enno Rehling <enn...@gm...> wrote:
> 
>> On 12/27/2025 20:19, Roland Hughes via Foxgui-users wrote:
>>> Honestly, I hate MSYS2. Actually I hate anything to do with "Linux
>>> emulation" on Windows for building Windows apps.
>>
>> I agreee whole-heartedly. Trying to pretend that Windows can be made to
>> work like a UNIX is misguided.
> 
> MSYS2 ucrt does NOT do that, if I understand it correctly.

Apologies, I was thinking of cygwin, which does.

Someone mentioned vcpkg in this thread: While I'm usually in favor of 
using whatever OS package manager to install dependencies (apt, rpm, 
brew, or ports), in cases where there is none (Windows, either 32 or 64 
bit), vcpkg does a good job. I've never used it outside of Windows, but 
apparently that should also work (unless, like me, you prefer the native 
package manager).

>> Regarding the original post: A lot of distributions still ship with
>> CMake 3, appartently. My Debian 13 comes with CMake 3.31.6, to name one.
>> I have never needed to set cmake_minimum_required higher than 3.13 in
>> the past, and hope this doesn't mean I need to change my projects?
> 
> It looks like I'm on CMake 3.28.3; this is running Mint 22.2 "Zara" so
> I'm pretty up-to-date.

My point seems made: It may be too early to go all-in on CMake 4, and 
too big a step to take when introducing CMake to Fox all at once. What 
would be the advantage of using CMake 4 over 3? Are there must-have 
features that building Fox depends on?

Enno.

Oh come on, there's a whole day left! Surely you have time for one more 
major release!!! 😂

Happy New Year to All!

On 12/29/2025 9:00 PM, JVZ wrote:
>
>      The setTraceTopics() API is a little bit stricter on syntax.
>
>      FXPath::convert() more battle-tested; new APIs convertToWindows(), convertFromWindows() added.
>
>      FXPath::enquote(), FXPath::dequote() more solidly implemented, particularly Windows versions.
>
>      FXURL::fileToURL(), FXURL::fileFromURL() use above convertToWindows(), convertFromWindows() to encode files to urls on Windows.
>
>      FXPath dealings with non-fully qualified paths now improved.
>
>      Updated FXPath::parseArgs().
>
>      Updated internals of FXProcess building command lines for CreateProcess() on Windows.
>
>      Modeline paring in Adie takes place after other methods.
>
>      FXSettings key-value parser was improved: relaxed key- and section-names by allowing escapes for dangerous characters.
>
>      FXPath implementation improvements, particularly for Windows.
>
> ---------
>
>   This will be final release for 2025.  All the best for 2026!
>
>
>              -- JVZ
>
>
-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

    The setTraceTopics() API is a little bit stricter on syntax.

    FXPath::convert() more battle-tested; new APIs convertToWindows(), convertFromWindows() added.

    FXPath::enquote(), FXPath::dequote() more solidly implemented, particularly Windows versions.

    FXURL::fileToURL(), FXURL::fileFromURL() use above convertToWindows(), convertFromWindows() to encode files to urls on Windows.

    FXPath dealings with non-fully qualified paths now improved.

    Updated FXPath::parseArgs().

    Updated internals of FXProcess building command lines for CreateProcess() on Windows.

    Modeline paring in Adie takes place after other methods.

    FXSettings key-value parser was improved: relaxed key- and section-names by allowing escapes for dangerous characters.

    FXPath implementation improvements, particularly for Windows.

---------

 This will be final release for 2025.  All the best for 2026!


            -- JVZ


-- 
+----------------------------------------------------------------------------+
| Copyright (C) 20:50 12/29/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

On 12/28/2025 5:20 PM, JVZ wrote:

> MSYS2 ucrt does NOT do that, if I understand it correctly.

I've not personally worked with it. Having said that, I went here.

https://www.msys2.org/

and scrolled down to points 6, 7, 8.

Hopefully that image doesn't get shredded. It appears MSYS2 is really 
just an Arch package management environment for mingw-w64 emulation 
libraries and packages. It is true that one does not need to have mingw 
installed to run the resulting binary, it will "run" on any Windows 10 
or above computer but . . . it bundles in all of the emulation libraries 
it needs.

Now, it is possible, I do not know, but possible they also leverage some 
of Microsoft's WSL which would reduce the amount of emulation they need 
to bring along.

I gotta wonder just how well SIGNAL handling works. Not Qt signal/slot 
but Linux/Unix SIGNAL handling. Also gotta wonder just how well code 
that relies on DMSG to detect media changes, etc. will work.

Since I'm mostly embedded development these days I gotta wonder about 
the humble serial port. Even the new-to-me Dell I just bought came 
standard with both PS/2 and a Serial port because it was originally 
built for medical device/industrial equipment development. 9th or 10th 
gen i7 so not really that old.

I'm sure they can make it work at 1200 BAUD. They might even get it to 
work at 9600 BAUD. The "standard" high speed ones from NXP now run 
5Mbt/s. You can also get 5Mbt/s units for your desktop so one can test 
at full throttle during development. Any kind of emulation layer will 
overrun the buffers and cause data loss.

The irony in all of this is that Windows will eventually become "just a 
desktop" for Linux like Gnome, KDE, etc. in a few years and the 
"operating system" you install will just be a hypervisor/virtualbox 
host.

Just my 0.002 cents before pennies disappear.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

On Sun, 28 Dec 2025 11:15:52 +0100
Enno Rehling <enn...@gm...> wrote:

>On 12/27/2025 20:19, Roland Hughes via Foxgui-users wrote:
>> Honestly, I hate MSYS2. Actually I hate anything to do with "Linux 
>> emulation" on Windows for building Windows apps.  
>
>I agreee whole-heartedly. Trying to pretend that Windows can be made to 
>work like a UNIX is misguided.

MSYS2 ucrt does NOT do that, if I understand it correctly.

>Regarding the original post: A lot of distributions still ship with 
>CMake 3, appartently. My Debian 13 comes with CMake 3.31.6, to name one. 
>I have never needed to set cmake_minimum_required higher than 3.13 in 
>the past, and hope this doesn't mean I need to change my projects?

It looks like I'm on CMake 3.28.3; this is running Mint 22.2 "Zara" so
I'm pretty up-to-date.


   -- JVZ





-- 
+----------------------------------------------------------------------------+
| Copyright (C) 00:40 12/28/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

Just to be Debbie Downer here

Once Fox switches to CMake and has a minimum version, someone will need 
to update the the documentation page and delete a whole bunch of systems 
from there or do the ugly task of stating which versions ran on the dead 
platforms.

Hey, I write books

https://theminimumyouneedtoknow.com

https://infiniteexposure.net

https://lesedi.us

https://www.johnsmith-book.com

https://twentyoftwo.com

So I'm a bit of a stickler when it comes to keeping the documentation 
kinda-sorta-close to right.

Quazi-related

https://store.techspot.com

has sale. Windows 11 Pro $10  It installed and registered just fine for 
me. I did have to use Rufus on a Windows machine to put the ISO onto 
thumb drive. Linux just wouldn't work. On the plus side, Rufus let me 
turn off a whole bunch of annoying Windows things, like having to have a 
Microsoft account.

Office Professional 2021 $35  Yes I bought and installed.

Microsoft Visual Studio Professional 2022 $10  (I bought 2)

Honestly, if you dudes, dudettes, and infinite spaces between zero and 1 
are looking to spin up a Windows dev machine, you just can't do it cheaper.

I was stunned that all the stuff downloaded and activated. Told a client 
of mine about it and he bought some licenses for is company as well.

Seems like they even have Mac versions of stuff if you happen to have 
icky nasty Apple equipment. Sale was supposed to end at midnight, but it 
is almost 5am here and seems like prices are still good.

On 12/28/2025 4:15 AM, Enno Rehling wrote:
>
>
> On 12/27/2025 20:19, Roland Hughes via Foxgui-users wrote:
>> Honestly, I hate MSYS2. Actually I hate anything to do with "Linux 
>> emulation" on Windows for building Windows apps.
>
> I agreee whole-heartedly. Trying to pretend that Windows can be made 
> to work like a UNIX is misguided.
>
> Regarding the original post: A lot of distributions still ship with 
> CMake 3, appartently. My Debian 13 comes with CMake 3.31.6, to name 
> one. I have never needed to set cmake_minimum_required higher than 
> 3.13 in the past, and hope this doesn't mean I need to change my 
> projects?
>
> Enno.
>
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

On 12/27/2025 20:19, Roland Hughes via Foxgui-users wrote:
> Honestly, I hate MSYS2. Actually I hate anything to do with "Linux 
> emulation" on Windows for building Windows apps.

I agreee whole-heartedly. Trying to pretend that Windows can be made to 
work like a UNIX is misguided.

Regarding the original post: A lot of distributions still ship with 
CMake 3, appartently. My Debian 13 comes with CMake 3.31.6, to name one. 
I have never needed to set cmake_minimum_required higher than 3.13 in 
the past, and hope this doesn't mean I need to change my projects?

Enno.

Honestly, I hate MSYS2. Actually I hate anything to do with "Linux 
emulation" on Windows for building Windows apps.

Then again, not much supports Arch.

The Nsis64 (sp?) generator can generate Debian packages and lots of 
other things, but no RPM and no ARCH. There are something like a dozen 
generators CPack supports. I didn't look into the others.

I know, MSYS2 has fans.

 >

MSYS2 also has a alternative C-runtime libraries.

I have been sooooo fried by environments with "alternative" C/C++ 
runtime libraries."

Works on my machine and not anywhere else is what ends up happening.

Just my 0.002 cents before all the pennies are gone.


On 12/27/2025 11:38 AM, JVZ wrote:
> On Sat, 27 Dec 2025 08:54:30 -0600
> Sander Jansen <s.j...@gm...> wrote:
>
>> I've updated my CMake project files for FOX to a minimum version of 4.0 as
>> the 3.xx releases are now considered legacy. Currently updated to 1.7.86.
>>
>> The new version is much better organized and also installs CMake config
>> files, which makes integration into other CMake projects a lot easier (just
>> import the FOX target). Out of tree builds are now properly supported. In
>> addition projects can also link directly to the build tree for testing
>> purposes without having to install FOX.
>>
>> This new version also enables PCH which basically halves the compile time
>> for FOX.
>>
>> I was able to cross compile FOX using MinGW quite easily and was even able
>> to run it under Wine without a hitch. I have not tested it under native
>> Windows yet, but I'm planning to see whether I can use CMake's FetchContent
>> to automatically fetch and compile basic dependencies like jpeg and zlib,
>> as Windows lacks package management like we do on Linux
>>
>> I did find an oddity in regards to the jpeg2000 support in FOX, as it
>> seemingly requires both HAVE_JP2_H and HAVE_J2K_H to be defined. The latter
>> appears to be used in the FXJP2{Icon/Image}, while the former is used in
>> the actual io.
>>
>> Another remaining issue is the few left over FXAPI decorators in the
>> glviewer app which breaks builds on Windows due to dlexport/ dlimport
>> mix-up. Those should be removed.
>>
>> The repo for CMake can be found here:
>> https://github.com/gogglesguy/fox/tree/cmake
>>
>> I'm in the progress of updating gogglesmm to use this as a submodule here:
>> https://github.com/gogglesmm/gogglesmm/tree/cmake4
>>
>> Cheers,
>>
>> Sander
> This sounds good.  Switching to cmake has been on the to-do list for a while
> and if your cmake configs look good it will become the official build system
> soon.
>
> For windows support w/o VC++, perhaps you can look into MSYS2?
>
> MSYS2 has [and you'll like this] the Arch package system; once you have a
> core MSYS2 installed, you can pacman -S <pkg> and pacman -Syu to update the
> whole enchilada.  Besides, MSYS2 also has a alternative C-runtime libraries.
>
> Both GCC and clang are available, even ARM target support is in there..
>
> For other projects, I've been using cmake for a bit, and VC++ CE 2019
> which I'm using has cmake-generator to flesh out VC++ project files;
> this is a huge part of my motivation to switch to CMAKE as updating
> the stupid proect files "by hand" is going to be a thing of the past.
>
>
>
>       -- JVZ
>
>
>
>
>
>
-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

On Sat, 27 Dec 2025 08:54:30 -0600
Sander Jansen <s.j...@gm...> wrote:

>I've updated my CMake project files for FOX to a minimum version of 4.0 as
>the 3.xx releases are now considered legacy. Currently updated to 1.7.86.
>
>The new version is much better organized and also installs CMake config
>files, which makes integration into other CMake projects a lot easier (just
>import the FOX target). Out of tree builds are now properly supported. In
>addition projects can also link directly to the build tree for testing
>purposes without having to install FOX.
>
>This new version also enables PCH which basically halves the compile time
>for FOX.
>
>I was able to cross compile FOX using MinGW quite easily and was even able
>to run it under Wine without a hitch. I have not tested it under native
>Windows yet, but I'm planning to see whether I can use CMake's FetchContent
>to automatically fetch and compile basic dependencies like jpeg and zlib,
>as Windows lacks package management like we do on Linux
>
>I did find an oddity in regards to the jpeg2000 support in FOX, as it
>seemingly requires both HAVE_JP2_H and HAVE_J2K_H to be defined. The latter
>appears to be used in the FXJP2{Icon/Image}, while the former is used in
>the actual io.
>
>Another remaining issue is the few left over FXAPI decorators in the
>glviewer app which breaks builds on Windows due to dlexport/ dlimport
>mix-up. Those should be removed.
>
>The repo for CMake can be found here:
>https://github.com/gogglesguy/fox/tree/cmake
>
>I'm in the progress of updating gogglesmm to use this as a submodule here:
>https://github.com/gogglesmm/gogglesmm/tree/cmake4
>
>Cheers,
>
>Sander

This sounds good.  Switching to cmake has been on the to-do list for a while
and if your cmake configs look good it will become the official build system
soon.

For windows support w/o VC++, perhaps you can look into MSYS2? 

MSYS2 has [and you'll like this] the Arch package system; once you have a 
core MSYS2 installed, you can pacman -S <pkg> and pacman -Syu to update the 
whole enchilada.  Besides, MSYS2 also has a alternative C-runtime libraries.

Both GCC and clang are available, even ARM target support is in there..

For other projects, I've been using cmake for a bit, and VC++ CE 2019
which I'm using has cmake-generator to flesh out VC++ project files;
this is a huge part of my motivation to switch to CMAKE as updating
the stupid proect files "by hand" is going to be a thing of the past.



     -- JVZ






-- 
+----------------------------------------------------------------------------+
| Copyright (C) 11:20 12/27/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

Ah thanks. I'll take a look at vcpkg

Sander


On Sat, Dec 27, 2025 at 9:12 AM Roland Hughes via Foxgui-users <
fox...@li...> wrote:

> Doing some work with Visual Studio Community edition and command line
> building in the x64 developer command shell.
>
> You need to use vcpgk
>
> https://vcpkg.io/en/packages.html?query=jpeg
>
> Install it under the community edition and endure its high sensitivity
> to internet connections.
>
> https://github.com/RolandHughes/ls-cs/tree/ls-cs-0.2.1
>
> Look at windows-configuration-notes.txt and build-LsCs-Windows.bat in
> the above branch.
>
> I'm not "done" getting all the way through CPack packaging for Windows
> installer, need to control some file placements a bit better, but this
> is at least kinda-sorta-like Linux building.
>
> On 12/27/2025 8:54 AM, Sander Jansen wrote:
> > I've updated my CMake project files for FOX to a minimum version of
> > 4.0 as the 3.xx releases are now considered legacy. Currently updated
> > to 1.7.86.
> >
> > The new version is much better organized and also installs CMake
> > config files, which makes integration into other CMake projects a lot
> > easier (just import the FOX target). Out of tree builds are now
> > properly supported. In addition projects can also link directly to the
> > build tree for testing purposes without having to install FOX.
> >
> > This new version also enables PCH which basically halves the compile
> > time for FOX.
> >
> > I was able to cross compile FOX using MinGW quite easily and was even
> > able to run it under Wine without a hitch. I have not tested it under
> > native Windows yet, but I'm planning to see whether I can use CMake's
> > FetchContent to automatically fetch and compile basic dependencies
> > like jpeg and zlib, as Windows lacks package management like we do on
> > Linux
> >
> > I did find an oddity in regards to the jpeg2000 support in FOX, as it
> > seemingly requires both HAVE_JP2_H and HAVE_J2K_H to be defined. The
> > latter appears to be used in the FXJP2{Icon/Image}, while the former
> > is used in the actual io.
> >
> > Another remaining issue is the few left over FXAPI decorators in the
> > glviewer app which breaks builds on Windows due to dlexport/ dlimport
> > mix-up. Those should be removed.
> >
> > The repo for CMake can be found here:
> > https://github.com/gogglesguy/fox/tree/cmake
> >
> > I'm in the progress of updating gogglesmm to use this as a submodule
> here:
> > https://github.com/gogglesmm/gogglesmm/tree/cmake4
> >
> > Cheers,
> >
> > Sander
> >
> >
> > _______________________________________________
> > Foxgui-users mailing list
> > Fox...@li...
> > https://lists.sourceforge.net/lists/listinfo/foxgui-users
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593  (cell)
> https://theminimumyouneedtoknow.com
> https://infiniteexposure.net
> https://johnsmith-book.com
>
>
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users
>

Doing some work with Visual Studio Community edition and command line 
building in the x64 developer command shell.

You need to use vcpgk

https://vcpkg.io/en/packages.html?query=jpeg

Install it under the community edition and endure its high sensitivity 
to internet connections.

https://github.com/RolandHughes/ls-cs/tree/ls-cs-0.2.1

Look at windows-configuration-notes.txt and build-LsCs-Windows.bat in 
the above branch.

I'm not "done" getting all the way through CPack packaging for Windows 
installer, need to control some file placements a bit better, but this 
is at least kinda-sorta-like Linux building.

On 12/27/2025 8:54 AM, Sander Jansen wrote:
> I've updated my CMake project files for FOX to a minimum version of 
> 4.0 as the 3.xx releases are now considered legacy. Currently updated 
> to 1.7.86.
>
> The new version is much better organized and also installs CMake 
> config files, which makes integration into other CMake projects a lot 
> easier (just import the FOX target). Out of tree builds are now 
> properly supported. In addition projects can also link directly to the 
> build tree for testing purposes without having to install FOX.
>
> This new version also enables PCH which basically halves the compile 
> time for FOX.
>
> I was able to cross compile FOX using MinGW quite easily and was even 
> able to run it under Wine without a hitch. I have not tested it under 
> native Windows yet, but I'm planning to see whether I can use CMake's 
> FetchContent to automatically fetch and compile basic dependencies 
> like jpeg and zlib, as Windows lacks package management like we do on 
> Linux
>
> I did find an oddity in regards to the jpeg2000 support in FOX, as it 
> seemingly requires both HAVE_JP2_H and HAVE_J2K_H to be defined. The 
> latter appears to be used in the FXJP2{Icon/Image}, while the former 
> is used in the actual io.
>
> Another remaining issue is the few left over FXAPI decorators in the 
> glviewer app which breaks builds on Windows due to dlexport/ dlimport 
> mix-up. Those should be removed.
>
> The repo for CMake can be found here:
> https://github.com/gogglesguy/fox/tree/cmake
>
> I'm in the progress of updating gogglesmm to use this as a submodule here:
> https://github.com/gogglesmm/gogglesmm/tree/cmake4
>
> Cheers,
>
> Sander
>
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com