foxgui-users

Re: [Foxgui-users] [EXTERNAL] Re: Grab observation

[<je...@fo...>]

On 2025-09-04 12:07, Dav...@am... wrote:
> Thanks, Jeroen.  While that’s good to know, on the other hand, on
> Windows, Enter/Leave events will *not* be generated with [un]grab.
> 
> This kind of asymmetry makes it more difficult to implement
> cross-platform controls.  In my perfect world, FOX would handle this
> for me – either FXApp would suppress spurious enter/leave events due
> to [un]grab, or synthesize such events on Windows.  After all, I’m
> writing a control for FOX, not for Xlib or Microsoft.
> 
> But beggars can’t be choosers, so “almost” cross-platform
> control behavior is better than nothing ;)

Yes, problem is we have been relying on X11 [GDI] "state machine"
for keyboard and mouse events.

Its probably better to have internal state-machine and drive it
from external events, and synthesize events which are not provided
by underlying platform.

Needless to say, this is a major undertaking and would probably have
to wait for the FXReactor / FXDispatcher event handling revamp.

     -- JVZ

Re: [Foxgui-users] font dialog error

[<je...@fo...>]

On 2025-09-04 11:00, John Selverian wrote:
> v1.7.50
> 
> It is a custom widget derived form the standard font dialog.

So, some background about the problem:

1) On Linux, we use Xft [XLFD still works, but looks really ugly].  
Fonts
    in Xft can be measured a character at a time, so we can avoid 
overflowing.

    Measuring character at a time was necessary because 
XftTextExtentsUtf8() was
    using a 16-bit short, which overflows too quickly.

2) Due to fixes in FXTextField, we no longer draw invisible text, just 
visible
    text.  Buffer limits or client-server transfer limits less likely to 
be a
    problem.  Of course this should also be faster.

3) On Windows, I've split text measurement and drawing into two 
branches; the fixed-
    buffer version, which lives on the stack, is used for short strings.

    In the rare case we have a large string, we allocate variable size 
buffer and
    use it for the utf8->utf16 conversion, then free it immediately.

    Alloc/free overhead can  be a lot, so we prefer to do it only when 
needed.


Either way, for drawing purposes, strings are transferred between your 
FOX program
and the drawing system [X11 or GDI] and if you have a large string, 
trouble MAY
still ensue.  FOX widgets which may have very long strings [FXText and 
FXTextField]
are now safe against this, since drawing has been limited to the part of 
the text
that's visible, which by definition is much less than the whole screen.
Most other widgets won't have very long strings and should be OK.

I recommend custom widgets that deal with really long strings should be 
looked at
and potentially updated to draw only the visible fragments; this would 
avoid
these problems, and at the same time, significantly speed up drawing.


              -- JVZ

Re: [Foxgui-users] Grab observation

[<je...@fo...>]

On 2025-09-02 15:13, Dav...@am... wrote:
> Hi Jeroen,
> 
> I have an observation wrt the grab function.  When a control calls
> this on Linux (e.g., in response to a left click), LeaveNotify and
> EnterNotify events will be generated when XGrabPointer [1] is called,
> which means that onLeave and onEnter will be called on the control,
> even though the control was already "entered".  This is different
> behavior than on Windows, where no leave/enter sequence will occur.
> 
> In my case, this exposed a bug in my code, so it was a happy
> coincidence.  But I wonder if it would be better to somehow suppress
> these events on Linux or to synthesize them on Windows, so that the
> same call sequence would occur on both platforms from the perspective
> of the control?  This would help to avoid platform-specific bugs when
> writing a new FOX control.

David,

When in response to [un]grab, the FXEvent "code" field will be set to
CROSSINGGRAB or CROSSINGUNGRAB.  Otherwise, this will be set to
CROSSINGNORMAL.

When needed, you can look at this field.

   -- JVZ

Re: [Foxgui-users] font dialog error

[John S. <joh...@ja...>]

v1.7.50

It is a custom widget derived form the standard font dialog.

I'll look into what you said.




-----Original Message-----
From: je...@fo... <je...@fo...> 
Sent: Thursday, September 4, 2025 11:28 AM
To: joh...@ja...
Cc: fox...@li...
Subject: Re: [Foxgui-users] font dialog error

On 2025-08-29 16:34, John Selverian wrote:
> On Ubuntu when I enumerate the system fonts and go through them
I get 
> the following error in the cmd window:
> 
> 
> 
> 
> 
> X Error: code 16 major 140 minor 20: BadLength (poly request
too large 
> or internal Xlib length error).

Do you know what version of FOX this was?  Stuff with long
strings was recently fixed and on the linux side, there should be
no buffer length issues at this time.

The fix is two-fold:

1) FXTextField fix which now limits draw calls to visible area.
This should
    be well below buffer limits.

2) FXFont::getTextWidth() change which now measures utf8
character at a time.
    [basically implements exact commands that
XftTextExtentsUtf8() was calling
    under the hood.

3) On Windows, limitations may still exist.  We've removed buffer
limitations
    in FXDCWindow::drawText() and FXDCWindow::drawImageText() on
windows.

Note: drawing APIs are less likely to hit the limits, but
measuring APIs like getTextWidth() are; optimal drawing should
limit itself to visible parts only, and we're now doing a bit
more work to avoid drawing in clipped areas; chiefly, this was
FXTextField as FXText already does this.

If you have custom widgets, perhaps they may have been drawing
clipped parts of text.  A typical screen, e.g. 4k, would only be
able to show a few hundreds of characters, even at really small
font sizes.

   -- JVZ

Re: [Foxgui-users] font dialog error

[<je...@fo...>]

On 2025-09-04 11:00, John Selverian wrote:
> v1.7.50
> 
> It is a custom widget derived form the standard font dialog.

That version is definitely from before the changes.  So please
try with latest snapshot...


     -- JVZ

Re: [Foxgui-users] font dialog error

[<je...@fo...>]

On 2025-08-29 16:34, John Selverian wrote:
> On Ubuntu when I enumerate the system fonts and go through them I
> get the following error in the cmd window:
> 
> 
> 
> 
> 
> X Error: code 16 major 140 minor 20: BadLength (poly request too
> large or internal Xlib length error).

Do you know what version of FOX this was?  Stuff with long strings
was recently fixed and on the linux side, there should be no buffer
length issues at this time.

The fix is two-fold:

1) FXTextField fix which now limits draw calls to visible area.  This 
should
    be well below buffer limits.

2) FXFont::getTextWidth() change which now measures utf8 character at a 
time.
    [basically implements exact commands that XftTextExtentsUtf8() was 
calling
    under the hood.

3) On Windows, limitations may still exist.  We've removed buffer 
limitations
    in FXDCWindow::drawText() and FXDCWindow::drawImageText() on windows.

Note: drawing APIs are less likely to hit the limits, but measuring APIs
like getTextWidth() are; optimal drawing should limit itself to visible
parts only, and we're now doing a bit more work to avoid drawing in
clipped areas; chiefly, this was FXTextField as FXText already does
this.

If you have custom widgets, perhaps they may have been drawing clipped
parts of text.  A typical screen, e.g. 4k, would only be able to show
a few hundreds of characters, even at really small font sizes.

   -- JVZ

[Foxgui-users] font dialog error

[John S. <joh...@ja...>]

On Ubuntu when I enumerate the system fonts and go through them I
get the following error in the cmd window:

 

 

X Error: code 16 major 140 minor 20: BadLength (poly request too
large or internal Xlib length error).

 

 

I've included a screenshot so you can see the setup.

 

 

 

 

Kind regards,

 

js

Re: [Foxgui-users] Building latest snapshop

[<je...@fo...>]

On 2025-08-29 08:11, Cesar wrote:
> Hello,
> 
> I'm having trouble building fox-toolkit and the samples. I was
> successful in building with msys2 mingw64 but whenever i run the
> samples it opens an extra command prompt, even with -mwindows ldflag.
> However with the -mwindows ldflag i can close the command prompy
> without the app closing (calculator for example) so i decided to try
> and build with visual studio instead to see if it does that. But it
> fails to compile because in foxlib the icons.cpp and icons.h keeps
> getting overwritten with an incomplete version. I removed it from the
> "Extensions to Delete on Clean" but it still happens. Please help.
> 
> Thank you,

VStudio2015 works for me; pulling into later versions of VStudio
should work w/o problems, as far as my experience goes.

There's a custom build step to generate icons.h and icons.cpp via
reswrap.  Dependencies are set to ensure reswrap is compiled first
thing, but you might want to make sure that this actually happens.

I have noticed on occasion that custom build step fails; it seems
to be that you have an icons.h or icons.cpp from a previous build;
so clean the project first, and make sure the old icons.h/icons.cpp
are gone.

   -- JVZ

Re: [Foxgui-users] Fox 1.7.86 and png issues

[Pasquale <pjr...@pr...>]

On Thu, Jul 24, 2025 at 1:24 PM, <[je...@fo...](mailto:On Thu, Jul 24, 2025 at 1:24 PM,  <<a href=)> wrote:

> On 2025-07-24 12:18, Roland Hughes via Foxgui-users wrote:
>> stupid question,
>>
>> did you try installing libpng-dev
>>
>> package name might be a wee bit different if you aren't on a
>> Debian/Ubuntu based distro.
>
> libpng-dev is no longer required.
>
> PNG support now is built in; only libz still needed.

Okay, so good to know that png isn’t needed. I relooked at my code and compared it to other code which is similar and apparently I had code in a source/header file that was called before the fox includes. Moving the fox header above the other header worked.

I hadn’t changed anything in my code other than updating the fox version, so I didn’t think it was with my code, but I guess prior to updating fox, I must have changed something.

Thanks everyone for the help!

> -- JVZ
>
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

Re: [Foxgui-users] Fox 1.7.86 and png issues

[<je...@fo...>]

On 2025-07-24 12:18, Roland Hughes via Foxgui-users wrote:
> stupid question,
> 
> did you try installing libpng-dev
> 
> package name might be a wee bit different if you aren't on a
> Debian/Ubuntu based distro.

libpng-dev is no longer required.

PNG support now is built in; only libz still needed.


    -- JVZ

Re: [Foxgui-users] Fox 1.7.86 and png issues

[<je...@fo...>]

On 2025-07-24 11:44, Pasquale via Foxgui-users wrote:
> I switched from v1.7.84 to v1.7.86 to get mousewheel scroll support,
> but when I compile a program, i am getting png issues.
> 
> I noticed in v1.7.86 there is no --disable-png configure option, but
> there is one with v1.7.84, so I was wondering if png support wasn't
> included and how to fix that? I'm don't really know how to modify the
> autoconfig/make system files.
> 
> Thanks,
> Pasquale
> 

Hi,

Before, PNG support could be disabled, in order to avoid linking to PNG
library, which may be big (or, worse, unavailable!).

Now, PNG support is built into FOX so there's no need to disable it 
anymore,
and the implementation is quite small [one single file].  PNG now being
the most common format for non-lossy image compression, we felt it was 
good
to have it supported regardless of libpng availability. [We did add 
another
non-lossy image format, QOIF.  This one is really simple and compression
is pretty good, but not quite as good as PNG].

This new version should work well, but there may be a few improvements 
in the
near future, as the PNG standard has *JUST* been updated [of course this 
had
to happen right after I wrapped up my PNG reader ;-( ].

I have not had time to delve through new PNG docs to see what has 
changed.

Some plans I had before the new PNG standard got dropped on us:

1) Speed up CRC calculation using Intel carry-less multiply [GF(2) 
multiply].
    I've got this *mostly* figured out, but I'm still looking at how this
    should be packaged.  Not sure what we can do about ARM cpus, we might
    need old method as fallback.

2) Some speedups reading and writing the file through FXStream.  Perhaps
    this could be improved a bit.

3) The LZ decoder/encoder could probably also be replaced; right now, 
PNG
    support is still contingent on having libz compression library 
around.
    [Does anyone know if zstd compressed data is compatible with libz; I
    have not been able to find any statement about it...].



    -- JVZ

Re: [Foxgui-users] Fox 1.7.86 and png issues

[Roland H. <ro...@lo...>]

stupid question,

did you try installing libpng-dev

package name might be a wee bit different if you aren't on a 
Debian/Ubuntu based distro.

Probably should tell everyone what platform you are on.

On 7/24/25 11:44 AM, Pasquale via Foxgui-users wrote:
> I switched from v1.7.84 to v1.7.86 to get mousewheel scroll support, but when I compile a program, i am getting png issues.
>
> I noticed in v1.7.86 there is no --disable-png configure option, but there is one with v1.7.84, so I was wondering if png support wasn't included and how to fix that? I'm don't really know how to modify the autoconfig/make system files.
>
> Thanks,
> Pasquale
>
>
> _______________________________________________
> 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] Fox 1.7.86 and png issues

[Pasquale <pjr...@pr...>]

I switched from v1.7.84 to v1.7.86 to get mousewheel scroll support, but when I compile a program, i am getting png issues.

I noticed in v1.7.86 there is no --disable-png configure option, but there is one with v1.7.84, so I was wondering if png support wasn't included and how to fix that? I'm don't really know how to modify the autoconfig/make system files.

Thanks,
Pasquale

Re: [Foxgui-users] unicode character has 5 digits

[Roland H. <ro...@lo...>]

On 7/8/2025 7:57 AM, je...@fo... wrote:
> Thanks for this wonderful background.  32-bit wide characters would
> indeed incur enormous bloat, but thankfully, it seems UTF8 encoding
> is brilliantly leaving most european langauges very close to 1-byte
> per characters; even people in Korea, Japan, and China, UTF8 is never
> bigger than 32-bit wide characters, but all punctuation, numbers, etc.
> is mercifully as short as 1 byte.
>
> Now RAM and DISK space is cheaper than ever, but the biggest problem
> was always software.  UTF8 also makes software *mostly* able to deal
> with wide characters w/o undue pain and suffering. 

Since I work mostly with embedded systems I've been working on a fork of 
CopperSpice (which is a fork of Qt 4.8 sans QML). One of the many things 
on my never ending TODO list is replace all of the QString classes with 
BdString classes based on UTF8-CPP.

https://github.com/nemtrif/utfcpp?tab=readme-ov-file

I just need to make certain the Boost 1.0 license is compatible.

https://github.com/nemtrif/utfcpp/blob/master/LICENSE

If you are going to pop the hood on strings, you probably want to look 
at that library. I don't remember if Fox is UTF-16 under the hood or 
pure UTF-8.

Yes, UTF-8 has won. Both wide strings and UTF-16 have proven failures. 
Microsoft and a lot of legacy products are trapped with UTF-16.

Too bad embedded systems customers don't like the old Motif look and 
feel Fox has.

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

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 07:40, John Selverian wrote:
> I try this:
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = unescape("\U0001E05F");
> 
> and
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = \U0001E05F";
> 
> IN both cases I get this warning on compiling in VS2022:
> 
> “warning C4566: character represented by universal-character-name
> '\U0001E05F' cannot be represented in the current code page (1252)”
> 
> and it displays as ‘??’ in all fonts I try.

Found something else: in some compilers, the escape sequence
only applies to one character, so a 16-bit wide character would
not be able to use \Uxxxxxxxx, only \uxxxx\uxxxx, i.e. a surrogate
pair.  It appears this limitation may go away in future compilers.

FYI, c++ recognized unicode escape sequences require 8 hex digits
for \U and four for \u.



    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 07:40, John Selverian wrote:
> I try this:
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = unescape("\U0001E05F");
> 
> and
> 
> const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL
> = \U0001E05F";
> 
> IN both cases I get this warning on compiling in VS2022:
> 
> “warning C4566: character represented by universal-character-name
> '\U0001E05F' cannot be represented in the current code page (1252)”
> 
> and it displays as ‘??’ in all fonts I try.

Please note, on Windows, wide characters are not as wide (only 16-bit).
Thus, surrogate pairs would be needed to compile into 16-bit wide
character strings; wchar_t on windows is 16-bit.

This is partially why FXString can handle both 32-bit wide character
strings as well as 16-bit wide character strings.

So the same code:

     const wchar_t some_string[]=L"blablabla";

is therefore different sizes in Windows vs Linux.

Its OK, FXString can be initialized from both of these, converting them 
to
utf8 immediately.

Needless to say, if you let the compiler unescape escaped characters in
the string, then look at how your compiler does that.  
FXString::unescape()
can also perform unescaping, but then you [at least for now] need to use
surrogate pairs.


    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 03:53, Roland Hughes via Foxgui-users wrote:
> Please define "Does not work."
> 
> Do you get a compilation error?
> 
> Just not see the character?
> 
> What OS are you on?
> 
> I haven't coded with Fox in years, but . . . when it comes to Unicode,
> the first thing you have to do is ensure the font you are using
> actually has the character represented. Most fonts only have a tiny
> subset.
> 
> Here is an ancient discussion about finding which fonts have what
> character
> 
> https://graphicdesign.stackexchange.com/questions/63283/how-to-find-browse-fonts-that-include-certain-rare-characters-unicode-internat
> 
> 
> a 4 year old discussion
> 
> https://www.reddit.com/r/Unicode/comments/l3a3t8/what_font_renders_all_unicode_characters/
> 
> 
> A bit of barefoot in the snow for you
> 
> We should have forced all countries to use American English just so
> software developers would have an easier life. Internationalization is
> where it all went to Hell. Those who are long in the tooth (or now
> toothless) will remember wide characters.
> 
> https://www.geeksforgeeks.org/cpp/wide-char-and-library-functions-in-c/
> 
> 
> This was it!!!  Instead of 256 ASCII values we could now have 65536.
> That would rule the world! Please read point 2 at the top of that.
> wchar_t could be 2 or 4 bytes DEPENDING ON COMPILER USED. Data
> exchange was basically impossible.
> 
> Microsoft, in its infinite wisdom, cough cough hack hack, basically
> got trapped here. They are still trapped here today. Under the hood
> they went with the first cut of UTF-16 to avoid having to do multiple
> value characters like UTF-8 forced. In theory it was faster. Keep in
> mind Windows 3.10 was running no 286 computers so 16-bit at the time.
> 
> https://www.betaarchive.com/forum/viewtopic.php?t=38718
> 
> Still we could not get the population to engage in global nuclear
> warfare and force it to use the one true language, American English,
> where we could make do with good ole ASCII and those wonderful code
> pages. Especially since IBM still thwarts the universe today with
> EBCDIC
> 
> https://en.wikipedia.org/wiki/Code_page
> 
> Guess what?
> 
> Instead of subjugating all others via global warfare, they chose to
> promote peace and love, forming a committee churning out an ever
> larger elephant when the world wanted a mouse. Like all committees, it
> lacked any real industry knowledge. All they ever had was an x86 so
> that must be all that exists.
> 
> Read up on surrogates
> 
> https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)
> 
> Pay attention to the BE (Big Endian) and LE (Little Endian) columns.
> IBM and AMDAL (sp?) are Big Endian. Despite Unisys switching to Intel
> processors they are still ones complement.
> 
> Now, we had a fine fine pickle brine.
> 
> The x86 and ARM world needed to support itty bitty embedded systems
> having 512MB or less of RAM (think universal remote control for your
> TV)
> 
> __AND__
> 
> we now had to be able to indicate the width of a constant.
> 
> The one true world where everything fit into a single 16-bit box was
> gone!
> 
> There is oceans of documentation and legacy code examples out there
> where \u is always used for unicode.
> 
> So now, C programmers, who've never touched a shift key in their life,
> had to use \U
> 
> Just wait for the hack they come up with when the benevolent committee
> lacking industry knowledge bloats UTF past 32.
> 
> UTF-64 is already taken.
> 
> https://utf64.moreplease.com/

Thanks for this wonderful background.  32-bit wide characters would
indeed incur enormous bloat, but thankfully, it seems UTF8 encoding
is brilliantly leaving most european langauges very close to 1-byte
per characters; even people in Korea, Japan, and China, UTF8 is never
bigger than 32-bit wide characters, but all punctuation, numbers, etc.
is mercifully as short as 1 byte.

Now RAM and DISK space is cheaper than ever, but the biggest problem
was always software.  UTF8 also makes software *mostly* able to deal
with wide characters w/o undue pain and suffering.

UTF8 is very clever: you can start a character walk from any point in
a string, as the begin of a character is always recognizable as such;
thus, you can also walk backwards through UTF8 very easily.

Various other encodings of 32-bit wide characters are not nearly as
clever.  So UTF8 is winning and all those who gambled on 16-bit
characters are having the worst of both worlds now: not as compact
as UTF8, while still having variable-sized characters.

So, UTF8 is the way to go.  For those who don't interpret the
characters, just store them, you'll never need to know anything other
than 8-bit safe strings of bytes.  In a few cases, you need to traverse
a character, not a byte at a time, you can look for the magic 
lead-character:

    (ch&0xC0)!=0x80

this takes only two clock cycles!



    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-08 03:41, Enno Rehling wrote:
> I believe the \u escape sequence is strictly defined for 16-bit
> unicode characters only. try using \U:
> 
> 	char *emoji = "\U0001F92A";
> 
> Enno.

Be aware that FXString::unescape(), at this time, does not interpret 
\UXXXXXXXX,
only \uXXXX.  But it does know about surrogate pairs, so it will convert 
a pair
of escaped surrogate pairs into the proper UTF8 representation.

unescape keeps prior unescaped character, so if it processes a follower 
of a
surrogate pair, and the prior was a leader of a surrogate pair, then the
converted utf8 will be the unpacked wide character.

Maybe I should add the \UXXXXXXXX very wide character decode capability 
as well,
since it makes sense to add it now...


    -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[John S. <joh...@ja...>]

I try this:

 

const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL = unescape("\U0001E05F");

 

and 

 

const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL = \U0001E05F";

 

 

IN both cases I get this warning on compiling in VS2022:

 

“warning C4566: character represented by universal-character-name '\U0001E05F' cannot be represented in the current code page (1252)”

 

and it displays as ‘??’ in all fonts I try.

 

 

 

 

 

 

From: Roland Hughes via Foxgui-users <fox...@li...> 
Sent: Tuesday, July 8, 2025 4:53 AM
To: fox...@li...
Subject: Re: [Foxgui-users] unicode character has 5 digits

 

Please define "Does not work."

Do you get a compilation error?

Just not see the character?

What OS are you on?

I haven't coded with Fox in years, but . . . when it comes to Unicode, the first thing you have to do is ensure the font you are using actually has the character represented. Most fonts only have a tiny subset.

Here is an ancient discussion about finding which fonts have what character

https://graphicdesign.stackexchange.com/questions/63283/how-to-find-browse-fonts-that-include-certain-rare-characters-unicode-internat

a 4 year old discussion

https://www.reddit.com/r/Unicode/comments/l3a3t8/what_font_renders_all_unicode_characters/

 

A bit of barefoot in the snow for you

We should have forced all countries to use American English just so software developers would have an easier life. Internationalization is where it all went to Hell. Those who are long in the tooth (or now toothless) will remember wide characters.

https://www.geeksforgeeks.org/cpp/wide-char-and-library-functions-in-c/

This was it!!!  Instead of 256 ASCII values we could now have 65536. That would rule the world! Please read point 2 at the top of that.  wchar_t could be 2 or 4 bytes DEPENDING ON COMPILER USED. Data exchange was basically impossible.

Microsoft, in its infinite wisdom, cough cough hack hack, basically got trapped here. They are still trapped here today. Under the hood they went with the first cut of UTF-16 to avoid having to do multiple value characters like UTF-8 forced. In theory it was faster. Keep in mind Windows 3.10 was running no 286 computers so 16-bit at the time.

https://www.betaarchive.com/forum/viewtopic.php?t=38718

Still we could not get the population to engage in global nuclear warfare and force it to use the one true language, American English, where we could make do with good ole ASCII and those wonderful code pages. Especially since IBM still thwarts the universe today with EBCDIC

https://en.wikipedia.org/wiki/Code_page

Guess what?

Instead of subjugating all others via global warfare, they chose to promote peace and love, forming a committee churning out an ever larger elephant when the world wanted a mouse. Like all committees, it lacked any real industry knowledge. All they ever had was an x86 so that must be all that exists.

Read up on surrogates

https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)

Pay attention to the BE (Big Endian) and LE (Little Endian) columns. IBM and AMDAL (sp?) are Big Endian. Despite Unisys switching to Intel processors they are still ones complement.

Now, we had a fine fine pickle brine.

The x86 and ARM world needed to support itty bitty embedded systems having 512MB or less of RAM (think universal remote control for your TV)  

__AND__ 

we now had to be able to indicate the width of a constant.

The one true world where everything fit into a single 16-bit box was gone!

There is oceans of documentation and legacy code examples out there where \u is always used for unicode.

So now, C programmers, who've never touched a shift key in their life, had to use \U

Just wait for the hack they come up with when the benevolent committee lacking industry knowledge bloats UTF past 32.

UTF-64 is already taken.

https://utf64.moreplease.com/

On 7/7/2025 8:27 PM, John Selverian wrote:



I’ve used Unicode successfully in the past. For instance for a subscripted ‘t’ I used:

 

UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c <file://u209c> ");

 

 

I want to now use a subscripted ‘y’ and found this:

 

IE05F

CYRILLIC SUBSCRIPT SMALL LETTER U

<sub> 0443 y

 

 

But this code: 

 

unescape(\\u1E05F <file://u1E05F> )

 

Does not work. How do I encode a Unicode character with a 5 digit code?

 

 

Kind regards,

 

js






_______________________________________________
Foxgui-users mailing list
Fox...@li... <mailto: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

Re: [Foxgui-users] unicode character has 5 digits

[<je...@fo...>]

On 2025-07-07 20:27, John Selverian wrote:
> I've used Unicode successfully in the past. For instance for a
> subscripted 't' I used:
> 
> UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");
> 
> I want to now use a subscripted 'y' and found this:
> 
> IE05F
> 
> CYRILLIC SUBSCRIPT SMALL LETTER U
> 
> <sub> 0443 y
> 
> But this code:
> 
> unescape(\\u1E05F [1])
> 
> Does not work. How do I encode a Unicode character with a 5 digit
> code?

Unescape needs to take in a so-called surrogate pair.  A surrogate
pair is two 16-bit wide characters encoding for a 32-bit wide character.

For historic reasons, unicode started out as 16-bit wide characters, but
as these things go, the number of code-points eventually outgrew the 
16-bit
space, and surrogate pairs were needed to encode characters > 16-bit.



32-bit (UCS32) character -> 16-bit (UCS16):

   CH = (U >> 10) + 0xD800
   CL = (U & 0x03FF) + 0xDC00

16-bit UCS16 -> 32-bit UCS32:

   U = (0x10000-(0xD800<<10)-0xDC00) + (CH<<10) + CL

The magic term in the above is to compensate for the fact that two 
constants
were added for CL and CH to package the 32-bit character into the at the 
time
not yet assigned code space of the 16-bit Unicode system.


   -- JVZ

Re: [Foxgui-users] unicode character has 5 digits

[Roland H. <ro...@lo...>]

Please define "Does not work."

Do you get a compilation error?

Just not see the character?

What OS are you on?

I haven't coded with Fox in years, but . . . when it comes to Unicode, 
the first thing you have to do is ensure the font you are using actually 
has the character represented. Most fonts only have a tiny subset.

Here is an ancient discussion about finding which fonts have what character

https://graphicdesign.stackexchange.com/questions/63283/how-to-find-browse-fonts-that-include-certain-rare-characters-unicode-internat

a 4 year old discussion

https://www.reddit.com/r/Unicode/comments/l3a3t8/what_font_renders_all_unicode_characters/


A bit of barefoot in the snow for you

We should have forced all countries to use American English just so 
software developers would have an easier life. Internationalization is 
where it all went to Hell. Those who are long in the tooth (or now 
toothless) will remember wide characters.

https://www.geeksforgeeks.org/cpp/wide-char-and-library-functions-in-c/

This was it!!!  Instead of 256 ASCII values we could now have 65536. 
That would rule the world! Please read point 2 at the top of that.  
wchar_t could be 2 or 4 bytes DEPENDING ON COMPILER USED. Data exchange 
was basically impossible.

Microsoft, in its infinite wisdom, cough cough hack hack, basically got 
trapped here. They are still trapped here today. Under the hood they 
went with the first cut of UTF-16 to avoid having to do multiple value 
characters like UTF-8 forced. In theory it was faster. Keep in mind 
Windows 3.10 was running no 286 computers so 16-bit at the time.

https://www.betaarchive.com/forum/viewtopic.php?t=38718

Still we could not get the population to engage in global nuclear 
warfare and force it to use the one true language, American English, 
where we could make do with good ole ASCII and those wonderful code 
pages. Especially since IBM still thwarts the universe today with EBCDIC

https://en.wikipedia.org/wiki/Code_page

Guess what?

Instead of subjugating all others via global warfare, they chose to 
promote peace and love, forming a committee churning out an ever larger 
elephant when the world wanted a mouse. Like all committees, it lacked 
any real industry knowledge. All they ever had was an x86 so that must 
be all that exists.

Read up on surrogates

https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)

Pay attention to the BE (Big Endian) and LE (Little Endian) columns. IBM 
and AMDAL (sp?) are Big Endian. Despite Unisys switching to Intel 
processors they are still ones complement.

Now, we had a fine fine pickle brine.

The x86 and ARM world needed to support itty bitty embedded systems 
having 512MB or less of RAM (think universal remote control for your TV)

__AND__

we now had to be able to indicate the width of a constant.

The one true world where everything fit into a single 16-bit box was gone!

There is oceans of documentation and legacy code examples out there 
where \u is always used for unicode.

So now, C programmers, who've never touched a shift key in their life, 
had to use \U

Just wait for the hack they come up with when the benevolent committee 
lacking industry knowledge bloats UTF past 32.

UTF-64 is already taken.

https://utf64.moreplease.com/

On 7/7/2025 8:27 PM, John Selverian wrote:
>
> I’ve used Unicode successfully in the past. For instance for a 
> subscripted ‘t’ I used:
>
> UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");
>
> I want to now use a subscripted ‘y’ and found this:
>
> IE05F
>
> CYRILLIC SUBSCRIPT SMALL LETTER U
>
> <sub> 0443 y
>
> But this code:
>
> unescape(\\u1E05F <file://u1E05F>)
>
> Does not work. How do I encode a Unicode character with a 5 digit code?
>
> Kind regards,
>
> js
>
>
>
> _______________________________________________
> 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

Re: [Foxgui-users] unicode character has 5 digits

[Enno R. <enn...@gm...>]

I believe the \u escape sequence is strictly defined for 16-bit unicode 
characters only. try using \U:

	char *emoji = "\U0001F92A";

Enno.

On 7/8/2025 03:27, John Selverian wrote:
> I’ve used Unicode successfully in the past. For instance for a 
> subscripted ‘t’ I used:
> 
> UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");
> 
> I want to now use a subscripted ‘y’ and found this:
> 
> IE05F
> 
> CYRILLIC SUBSCRIPT SMALL LETTER U
> 
> <sub> 0443 y
> 
> But this code:
> 
> unescape(\\u1E05F <file://u1E05F>)
> 
> Does not work. How do I encode a Unicode character with a 5 digit code?
> 
> Kind regards,
> 
> js
> 
> 
> 
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Foxgui-users] unicode character has 5 digits

[John S. <joh...@ja...>]

I've used Unicode successfully in the past. For instance for a
subscripted 't' I used:

 

UNICODE_SUBSCRIPT_t_SYMBOL = unescape("\\u209c");

 

 

I want to now use a subscripted 'y' and found this:

 

IE05F

CYRILLIC SUBSCRIPT SMALL LETTER U

<sub> 0443 y

 

 

But this code: 

 

unescape(\\u1E05F <file://u1E05F> )

 

Does not work. How do I encode a Unicode character with a 5 digit
code?

 

 

Kind regards,

 

js

Re: [Foxgui-users] features wishes for FOX (1.7.87 or newer) on Linux

[JVZ <je...@fo...>]

On Tue, 01 Jul 2025 12:42:08 +0200
Basile Starynkevitch <ba...@st...> wrote:

>Hello all
>
>On my Debian/Trixie/x86-64 desktop I did configure FOX 1.7.87 (ie the 
>fox-snapshot.tar.gz2 fetched today near Jul  1 12:00 PM CEST 2025, whose md5sum
>is e250a287d6902ef21b39513a8da3f833) with
>
>     './configure'  '--with-x' '--enable-release' \
>     'CFLAGS=-Dmoncflagsici -O2 -g2' \
>     'CXXFLAGS=-Dmoncxxflagsla -O2 -g2' 'CXX=/usr/local/bin/g++-15'
>
>The G++-15 compiler has been compiled by myself.
>

I suggest:

    export CXX="c++ -Dmoncxxflagsla"

because configure blasts over CXXFLAGS

>The -Dmoncflagsici and -Dmoncxxflagsla preprocessor flags are totally useless,
>but I am adding them to ensure that they are passed. 
>
>Surprisingly make output don't show them.
>
>
>My suggestions (or wishes) are:
>
>1) have the FOX build infrastructure generate some _fox-configure_.h file
>containing all the -DHAVE_* preprocessor flags. This ensure that the compilation
>commands remain short and human readable.
>
>2) provide some API (or generated preprocessor string) containing the
>configuration options. As far as I know GNU autoconf knows how to do that.
>
>3) provide some API to query the (many) optional features (wayland support,
>opengl support, X11 support) and the build time.

That would be useful; we have it in the "About" panel of the FOX projects
like Adie and Pathfinder, but no reason we wouldn't have a published compiled
in string or version number of some kind in the library.

One thing we should check is if shared library and header files "belong to-
gether", i.e. if you're linking to the same library as what you're compiling
to.  It can get confusing if you're working both on applications and on the
library itself.


>4) I have no idea if FOX can be compiled and linked with link-time-optimization
>options. If that is the case please document so.

So, we don't.  I've tried -O3 and obviously, this is faster.  But I feel its
overkill for most code, and highly bloated binary is often generated, where
compiler goes all-out on things which won't matter in terms of user-experience.

Don't forget, we're more influenced by the quality of e.g. device driver
libraries and hardware graphics cards than by our own methods of generating 
the drawing commands.

There's new macros for performance counting [in FOX but also useful for
user generated source code].  It exercises CPU tick counter to measure
time spent in a scope, its great for micro-benchmarking things.

You can also look at google perf [not to be confused with gperf] which makes 
nice call graphs letting you know where the time goes.  This is not 100% useful 
since your typical GUI sits there waiting for a user to do something, but if you
have a few large activities to measure it can be handy.

The design of the public-facing header files in FOX is such that most of
the time, user programs don't need to know the gory platform details [except
that they *are* on Windows vs Linux, for example.  Other special #define's
are set by your compiler automatically, e.g. architecture, o.s. types, etc.

>Regards from near Paris in France (it is terribly hot here).

Hot here too, but that's expected for the Heart of Dixie; I (barely) survived
a heat-stroke last saterday...


   -- JVZ




-- 
+----------------------------------------------------------------------------+
| Copyright (C) 18:50 07/ 1/2025 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

[Foxgui-users] features wishes for FOX (1.7.87 or newer) on Linux

[Basile S. <ba...@st...>]

Hello all

On my Debian/Trixie/x86-64 desktop I did configure FOX 1.7.87 (ie the 
fox-snapshot.tar.gz2 fetched today near Jul  1 12:00 PM CEST 2025, whose md5sum
is e250a287d6902ef21b39513a8da3f833) with

     './configure'  '--with-x' '--enable-release' \
     'CFLAGS=-Dmoncflagsici -O2 -g2' \
     'CXXFLAGS=-Dmoncxxflagsla -O2 -g2' 'CXX=/usr/local/bin/g++-15'

The G++-15 compiler has been compiled by myself.

The -Dmoncflagsici and -Dmoncxxflagsla preprocessor flags are totally useless,
but I am adding them to ensure that they are passed. 

Surprisingly make output don't show them.


My suggestions (or wishes) are:

1) have the FOX build infrastructure generate some _fox-configure_.h file
containing all the -DHAVE_* preprocessor flags. This ensure that the compilation
commands remain short and human readable.

2) provide some API (or generated preprocessor string) containing the
configuration options. As far as I know GNU autoconf knows how to do that.

3) provide some API to query the (many) optional features (wayland support,
opengl support, X11 support) and the build time.

4) I have no idea if FOX can be compiled and linked with link-time-optimization
options. If that is the case please document so.

Thanks for reading.

Regards from near Paris in France (it is terribly hot here).
-- 
Basile STARYNKEVITCH                            <ba...@st...>
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys