About window classes FLTK uses in its Windows platform and emoji input

[Manolo]

Issue #1360 reports that FLTK doesn't support correctly the input of emojis under Windows. Looking in more detail under Windows 11 shows this:

- typing Windows+dot opens an emoji palette

- test/input correctly inserts emojis selected from the palette

- test/editor inserts none of the selected emojis

- the cause of this difference is in an unexpected place: calling window->show(argc, argv)

sets the xclass() of windows of these programs to "input.exe" and "editor.exe",

respectively. Then these xclass names are used as 2nd argument of the window-creating system call under Windows, function CreateWindowExW(). The xclass name "editor.exe"

collides with the system name "Edit" that is predefined by Windows for Edit controls.

That causes emojis not to be inserted. Forcing program test/input to use the "editor.exe"

xclass name and program test/editor to use the "input.exe" xclass name reverses 

the bug: program test/input no longer inputs emojis whereas test/editor does input 

them.

My proposal is in attached 1360Windows.patch: prefix xclass names by "FLTK-"

and use the prefixed name in the CreateWindowExW() call to create windows.

This makes test/input and test/editor to input emojis correctly, after the emoji palette

gets displayed with Windows+dot.

What do fellow FLTK developers think about this proposal?

There remains an issue about measuring the width of emoji characters, but that's another story.

[imacarthur]

On Tuesday, 13 January 2026 at 13:19:30 UTC Manolo wrote:

 

The xclass name "editor.exe"

collides with the system name "Edit" that is predefined by Windows for Edit controls.

That causes emojis not to be inserted.

That is unexpected - do we know how many characters need to be "the same" for the collision to happen? (Or rather, what name is expected by default for an edit control, I suppose?)

Anyway, that's a tricky one - good work figuring that out!

 

My proposal is in attached 1360Windows.patch: prefix xclass names by "FLTK-"

and use the prefixed name in the CreateWindowExW() call to create windows.

What do fellow FLTK developers think about this proposal?

Sounds OK to me.

TBH I don't think I expected Windows to even care what we set in the window name, so this is a bit unknown territory.

With the patch as-is, we end up with "first_class_name" and the "xclass" name being different - is that something we'd care about? I can't see why it would matter, but...

 

There remains an issue about measuring the width of emoji characters, but that's another story.

Also tricky - does the inked text-extent return valid looking values I wonder? I assume the emoji glyphs will change size in strange and mysterious ways...

 

[Manolo]

Le mardi 13 janvier 2026 à 14:44:20 UTC+1, imacarthur a écrit :

On Tuesday, 13 January 2026 at 13:19:30 UTC Manolo wrote:

 

The xclass name "editor.exe"

collides with the system name "Edit" that is predefined by Windows for Edit controls.

That causes emojis not to be inserted.

That is unexpected - do we know how many characters need to be "the same" for the collision to happen? (Or rather, what name is expected by default for an edit control, I suppose?)

I've played a bit with that and concluded that any name begining with "edit" whatever its case

and whatever comes after collides with the system-reserved name.

 

[Albrecht Schlosser]

[combining my reply to Manolo and Ian]

On 1/13/26 14:19 Manolo wrote:

Issue #1360 reports that FLTK doesn't support correctly the input of emojis under Windows. Looking in more detail under Windows 11 shows this:

- typing Windows+dot opens an emoji palette

- test/input correctly inserts emojis selected from the palette

- test/editor inserts none of the selected emojis

- the cause of this difference is in an unexpected place: calling window->show(argc, argv)

sets the xclass() of windows of these programs to "input.exe" and "editor.exe",

respectively. Then these xclass names are used as 2nd argument of the window-creating system call under Windows, function CreateWindowExW(). The xclass name "editor.exe"

collides with the system name "Edit" that is predefined by Windows for Edit controls.

[...]

My proposal is in attached 1360Windows.patch: prefix xclass names by "FLTK-"

and use the prefixed name in the CreateWindowExW() call to create windows.

What do fellow FLTK developers think about this proposal?

+1 on prefixing the Window class with FLTK (if it doesn't begin with FLTK, as the proposed patch checks already)

Regarding the patch:

(1) The old code is pretty confusing at a first glance; it seems "correct" though. I suggest to use std::string to combine strings in 1.5 because it's easier to write and to read. Unless we wanted to backporat the patch to 1.4, where we might use the patch almost as given. So, if we used std::string we might want to rewrite the entire block that's concerned with setting the class names. But I'm open for "old char string" manipulation as well.

(2) As Ian wrote:
> With the patch as-is, we end up with "first_class_name" and the "xclass" name being different - is that something we'd care about?

I think we should. As I understand the code, `first_class_name` is just a static (!) storage of the first class name we set and is used as fallback when other windows are created. To fix this issue the final patch could be moved up some lines, i.e. before

if (!first_class_name) {

first_class_name = class_name;

}

such that this assignment is always *after* modifying `class_name`.

[Manolo]

Le mardi 13 janvier 2026 à 16:09:20 UTC+1, Albrecht-S a écrit :

[combining my reply to Manolo and Ian]

+1 on prefixing the Window class with FLTK (if it doesn't begin with FLTK, as the proposed patch checks already)

Regarding the patch:

(1) The old code is pretty confusing at a first glance; it seems "correct" though. I suggest to use std::string to combine strings in 1.5 because it's easier to write and to read. Unless we wanted to backporat the patch to 1.4, where we might use the patch almost as given. So, if we used std::string we might want to rewrite the entire block that's concerned with setting the class names. But I'm open for "old char string" manipulation as well.

I still prefer old string.

 

(2) As Ian wrote:
> With the patch as-is, we end up with "first_class_name" and the "xclass" name being different - is that something we'd care about?

I think we should. As I understand the code, `first_class_name` is just a static (!) storage of the first class name we set and is used as fallback when other windows are created. 

I disagree. Variables class_name (initially) and first_class_name both use FLTK-given names because both are initialized and compared to each other before the FLTK- prefix is added. 

Then class_name is prefixed (if necessary). It becomes a Windows-specific name and is used in 2 instances:

1) recoded to UTF-16 and used by Windows system calls

2) used by class_name_list.has_name() to check whether the (prefixed) name was already registered.

I believe this coexistence of non-prefixed FLTK-given names and of prefixed Windows-specific names is correct.

[Albrecht Schlosser]

On 1/13/26 16:43 Manolo wrote:

Le mardi 13 janvier 2026 à 16:09:20 UTC+1, Albrecht-S a écrit :

[combining my reply to Manolo and Ian]

+1 on prefixing the Window class with FLTK (if it doesn't begin with FLTK, as the proposed patch checks already)

Regarding the patch:

(1) The old code is pretty confusing at a first glance; it seems "correct" though. I suggest to use std::string to combine strings in 1.5 because it's easier to write and to read. Unless we wanted to backporat the patch to 1.4, where we might use the patch almost as given. So, if we used std::string we might want to rewrite the entire block that's concerned with setting the class names. But I'm open for "old char string" manipulation as well.

I still prefer old string.

OK, this is a matter of taste. I'm not objecting.

 

(2) As Ian wrote:
> With the patch as-is, we end up with "first_class_name" and the "xclass" name being different - is that something we'd care about?

I think we should. As I understand the code, `first_class_name` is just a static (!) storage of the first class name we set and is used as fallback when other windows are created. 

I disagree. Variables class_name (initially) and first_class_name both use FLTK-given names because both are initialized and compared to each other before the FLTK- prefix is added. 

Then class_name is prefixed (if necessary). It becomes a Windows-specific name and is used in 2 instances:

1) recoded to UTF-16 and used by Windows system calls

2) used by class_name_list.has_name() to check whether the (prefixed) name was already registered.

I believe this coexistence of non-prefixed FLTK-given names and of prefixed Windows-specific names is correct.

I don't think it's "correct" for what the comment says and what the original intention of this static variable was. Although I don't think that it makes any difference in the final outcome, but this is not what the author wanted, and it's some small overhead that can be avoided.

Maybe you missed that the variable `first_class_name` is a static variable that is initializes with nullptr (`0L`). Let's have a deeper look at the code:

static NameList class_name_list;

static const char *first_class_name = 0L

const char *class_name = w->xclass();

if (!class_name)

class_name = first_class_name; // reuse first class name used [1]

if (!class_name)

class_name = "FLTK"; // default to create a "FLTK" WNDCLASS

if (!first_class_name) {

first_class_name = class_name; [2]

}

// [3] Manolo's patch (prefixing `class_name` follows here

[1] Since static first_class_name is initialized with nullptr (0L) this statement is used only for the second and all further calls of function makeWindow and only if xclass() returns nullptr.

[2] Again, since first_class_name is static this assignment is executed only for the very first window.

So far, so good. After that your patch [3] is executed and `class_name` is prefixed with "FLTK-". That's OK, but first_class_name is now unprefixed, whereas class_name is prefixed (and the latter is subsequently used for Windows functions).

Now, lets look at making the second and all further windows (assuming the same parameters etc., xclass() not set). Then the statement marked [1] would assign the unprefixed classname and your patch would again "prefix" class_name with "FLTK-". The result would be the same, but doing this all over again for every new window that's opened with the same parameters (xclass etc.) would be useless.

See the comment at [1] that says "reuse first class name used". So why not store the pointer to the "class name used" directly in first_class_name?

I apologize if this sounds like nitpicking, but we should do what the original code intended and prevent unnecessarily "prefixing" the string all over again (for each but the first window where it must be done).

[Albrecht Schlosser]

On 1/13/26 18:51 'Albrecht Schlosser' via fltk.coredev wrote:

(2) As Ian wrote:
> With the patch as-is, we end up with "first_class_name" and the "xclass" name being different - is that something we'd care about?

I think we should.

Here's another point, unfortunately I misinterpreted Ian's statement. Everything I wrote about the technical aspects of these two variables stands as I wrote it. However:

I think Ian's statement is correct, and all the prefixing we talked about would happen in two cases:

(1) if xclass() is not set (nullptr), and
(2) if xclass() is non-null.

I think it would be better not to prefix `class_name` if the user set xclass() because this would overwrite what the user expects, for whatever reason.

I wonder where the xclass() in test/editor comes from in the first place. I changed the printf statement in the patch slightly and I see:

$ wine bin/test/hello.exe 
makeWindow: class_name=FLTK-hello.exe, first_class_name=hello.exe, w->xclass=hello.exe

Well, I don't see any assignment of xclass() or default_xclass() inside the /test/ folder except that of `clock.cxx`:

test/clock.cxx:52:  window.xclass("Fl_Clock");
test/clock.cxx:53:  window2.xclass("Fl_Clock");

Consequently the output of bin/test/clock.exe is:

$ wine bin/test/clock.exe 
makeWindow: class_name=FLTK-Fl_Clock, first_class_name=Fl_Clock, w->xclass=Fl_Clock
makeWindow: class_name=FLTK-Fl_Clock, first_class_name=Fl_Clock, w->xclass=Fl_Clock

According to our documentation of xclass():
```

Sets the xclass for this window.

A string used to tell the system what type of window this is. Mostly this identifies the picture to draw in the icon. This only works if called before calling show().

...

Under Microsoft Windows, this string is used as the name of the WNDCLASS structure, though it is not clear if this can have any visible effect.

If the default xclass has not yet been set, this also sets the default xclass for all windows created subsequently.

```

Therefore I wouldn't want to overwrite this string if xclass() was set by the user before show()ing a window. However, the question remains: where does this string "editor.exe" or "input.exe" come from in the first place? This should not be there!

Looking at the code: the default "window class" if xclass() is not set (as it should IMHO be in all our demo programs except clock.exe) would be "FLTK" which would prevent this conflict without prefixing the string at all.

Maybe we're looking at the wrong place, although Manolo's findings that "editor.exe" conflicts with some Windows default values is "interesting".

<rant>
BTW, this looks like "typical Windows behavior" that setting the "window class" to a string like "editor.exe" can have such effects as described by Manolo.
</rant>

This needs further investigation. Please don't commit the suggested patch yet, before we know all the details.

[Albrecht Schlosser]

On 1/13/26 19:38 'Albrecht Schlosser' wrote:

Therefore I wouldn't want to overwrite this string if xclass() was set by the user before show()ing a window. However, the question remains: where does this string "editor.exe" or "input.exe" come from in the first place? This should not be there!

Well, I found the culprit. It's set in commandline argument parsing:

diff --git a/src/Fl_arg.cxx b/src/Fl_arg.cxx
index 46e9f7073..c78d02564 100644
--- a/src/Fl_arg.cxx
+++ b/src/Fl_arg.cxx
@@ -315,8 +315,10 @@ void Fl_Window::show(int argc, char **argv) {
   }
 
   // set the class, which is used by X version of get_system_colors:
+#ifndef _WIN32
   if (name) {xclass(name); name = 0;}
   else if (!xclass() || !strcmp(xclass(),"FLTK")) xclass(fl_filename_name(argv[0]));
+#endif
 
   if (title) {label(title); title = 0;}
   else if (!label()) label(xclass());

I disabled as a "quick fix" / workaround the offending statements (see diff above), and I get:

$ wine bin/test/editor.exe 
makeWindow: class_name=FLTK, first_class_name=FLTK, w->xclass=FLTK

... as I would expect, and ISTR that window class (xclass) "FLTK" was set in earlier versions. At least, IIRC, under Windows.

That's something we really need to investigate before we change anything.

[Albrecht Schlosser]

On 1/13/26 19:50 'Albrecht Schlosser' via fltk.coredev wrote:

On 1/13/26 19:38 'Albrecht Schlosser' wrote:

Therefore I wouldn't want to overwrite this string if xclass() was set by the user before show()ing a window. However, the question remains: where does this string "editor.exe" or "input.exe" come from in the first place? This should not be there!

Well, I found the culprit. It's set in commandline argument parsing: [...]

I disabled as a "quick fix" / workaround the offending statements (see diff above), and I get:

$ wine bin/test/editor.exe 
makeWindow: class_name=FLTK, first_class_name=FLTK, w->xclass=FLTK

... as I would expect, and ISTR that window class (xclass) "FLTK" was set in earlier versions. At least, IIRC, under Windows.

That's something we really need to investigate before we change anything.

Result of "investigation": the code in question exists since the initial FLTK revision (1998), but - as the context above says - this is only used if the window is opened by using show(argc, argv) or Fl::args() is called explicitly.

As another test, if I remove the arguments "argc, argv" from test/hello.cxx (after restoring the original Fl::args() function), I get

$ wine bin/test/hello.exe 
makeWindow: class_name=FLTK, first_class_name=FLTK, w->xclass=FLTK

as expected.

OK, we still need to find out what the intended and expected behavior is. Maybe we shouldn't set the xclass() in the argument parser to the executable (argv[0]) under Windows, or whatever. I don't know.

[Manolo]

I have no information about why FLTK uses the program name for an app window's xclass

when command line arguments are processed. Could it be related to recognition by the OS

that a collection of windows belongs to the same process? It may be meaningful for X11

and not for Windows.

In my app, I use Fl_Window::xclass(const char *) to identify the various kinds of toplevel windows

it uses, allowing a  running program to recognize to what kind an Fl_Window belongs

without dynamic_cast.

Therefore, a program born under Linux that gives xclass names to its windows may unexpectedly 

collide with a system-reserved class name when ported to Windows.

For this reason, I believe it's desirable to prefix the user-given xclass name of a window, specifically

under Windows, to avoid collision with system-reserved types.

Here is the list of window class names reserved by Windows:

https://learn.microsoft.com/en-us/windows/win32/winmsg/about-window-classes#system-classes

For example, replace at the end of test/input.cxx
  window->show(argc, argv);
by

  window->xclass ("EDITxxy");
  window->show();
and use the unpatched FLTK library. The resulting Windows program no longer enters emojis

in its text boxes because the user-chosen "EDITxxy" window class name collides with

Windows system-defined "Edit" window class name. Use "EDTxxy" as xclass name

and the resulting app works OK.

[imacarthur]

I don't really know how (or why) Windows uses the "lpszClassName" that is given to WNDCLASSEX when we create a window but it seems to me that:

- We need it NOT to begin with "EDIT..." or any of the other "reserved names" that MS use (so changing it as Manolo suggests seems like a good idea)

- We need to do this in such a way that if the user later reads back the "xclass" for the window, they will see the same string that they set when they created the window (assuming they did set an xclass at all, or course...)

So I think we have to be careful to change the value sent to WNDCLASSEX in a suitable way, whilst also keeping the string read back by xclass() the same as was set by the user.

Beyond that, I have no useful ideas!

[Manolo]

I have committed at 81c965f new code that fixes use of the emoji palette under Windows.

Both text input widgets now fully support using this palette to enter emojis.

This commit also prefixes under Windows, user- and application-given window xclass names 

with "FLTK-" to avoid collision with window class names reserved by Windows. A change was 

necessary for the other fix to fully work. But I'm aware the exact fix to xclass names under

Windows is still under debate here.

[Albrecht Schlosser]

On 1/14/26 09:07 Manolo wrote:

I have no information about why FLTK uses the program name for an app window's xclass

when command line arguments are processed. Could it be related to recognition by the OS

that a collection of windows belongs to the same process?

There's a lot of info in the MS docs (e.g. the link you posted recently, in this case about their WNDCLASS) but in the end I don't know what exactly Windows does with this item. One point seems to be that the WNDCLASS and the Windows message processing function are closely bound together by the WNDCLASS.

It may be meaningful for X11 and not for Windows.

To be precise: I agree that setting the default class under Windows when arguments are parsed (either way) doesn't seem useful, nor does it seem to be appropriate.

Under X11 this is (AFAICT) also used to process Xresources, and there it makes perfectly sense to use the executable name (argv[0]).

In my app, I use Fl_Window::xclass(const char *) to identify the various kinds of toplevel windows

it uses, allowing a  running program to recognize to what kind an Fl_Window belongs

without dynamic_cast.

Therefore, a program born under Linux that gives xclass names to its windows may unexpectedly 

collide with a system-reserved class name when ported to Windows.

For this reason, I believe it's desirable to prefix the user-given xclass name of a window, specifically

under Windows, to avoid collision with system-reserved types.

If that would be the case, then the user (programmer) would have the responsibility to change their xclass() assignments. That's not something FLTK should do "under the hood".

Here is the list of window class names reserved by Windows:

https://learn.microsoft.com/en-us/windows/win32/winmsg/about-window-classes#system-classes

In this document (or a related one) they say that it's allowed to override a system WNDCLASS for process local or process global usage. Therefore such side effects as described by you (in your previous post and below) are -- IMHO -- clearly a bug in Windows. Which doesn't help us much though.

For example, replace at the end of test/input.cxx
  window->show(argc, argv);
by

  window->xclass ("EDITxxy");
  window->show();
and use the unpatched FLTK library. The resulting Windows program no longer enters emojis

in its text boxes because the user-chosen "EDITxxy" window class name collides with

Windows system-defined "Edit" window class name. Use "EDTxxy" as xclass name

and the resulting app works OK.

I "understand" all this, and there seems to be  *is* yet another bug in Windows: why does it match only the four characters "Edit" (case-insensitively) when we specify "EDITxxy" or as in the original example "editor.exe" ? I don't know all the Windows documentation but this is obviously really a bug.

Back to the question whether we can or should prefix the class name (i.e. WNDCLASS) with "FLTK-" or anything else:

(1) If the user sets the xclass (WNDCLASS) explicitly by calling either Fl_Window::xclass() or Fl_Window::default_xclass() then I'm strictly against overriding their given class name internally. We document that xclass() sets the MS-specific WNDCLASS and therefore we MUST NOT change the class name. Maybe the user *wants* to set the class name to "Edit" or "Editor" for some reason, and if we changed that we'd cause a regression.

(2) If Fl_Window::xclass() (the window's potential WNDCLASS) is not set at window creation time (i.e. show(with-or-w/o-args)) we set it to "FLTK" anyway which is good because we should set a WNDCLASS (I'm not aware what happens if this struct member is 0 or nullptr).

(3) Setting the WNDCLASS to the commandline argument (e.g. "editor.exe") under Windows is not intuitive and unexpected, and having the full filename with the type ".exe" doesn't sound right as well. We should probably not do this in the commandline parser under Windows at all. Not setting it in the commandline parser under Windows would solve all (real) problems.

Note also that setting the xclass() to argv[0] existed already in the initial commit of FLTK (as I found out), i.e. *before* the port to Windows was done at all! This makes it even more likely that this is a bug in our Windows port.

(4) If a user program sets an invalid or "conflicting" class name (see (1)) then it's up to the programmer to fix this, it's not our task to do this.

My proposal is to remove the setting of xclass at commandline parsing time under Windows, and that should be all we need to do. This should be done in 1.5 and higher (not backported to 1.4) and clearly documented. That's it.

[Manolo]

Le mercredi 14 janvier 2026 à 17:06:18 UTC+1, Albrecht-S a écrit :

……

My proposal is to remove the setting of xclass at commandline parsing time under Windows, and that should be all we need to do. This should be done in 1.5 and higher (not backported to 1.4) and clearly documented. That's it.

I agree. Do you (Albrecht) volunteer to implement that? It requires to establish a new platform-dependent code path

about window classes because what is done under Linux/Unix (use the executable name) would differ

from what is done under Windows (use "FLTK" is class name is empty). Under macOS, I would believe the overriden

function should not change the user-given class name.

My practice of using Fl_Window::xclass(const char *) to avoid dynamic_cast becomes a bit risky because collisions with

reserved names under Windows must be avoided. But this can be explained in the documentation.

I'm not sure to agree about not backporting to 1.4: no change prevents to backport emoji support under Windows.

[Albrecht Schlosser]

On 1/14/26 17:54 Manolo wrote:

Le mercredi 14 janvier 2026 à 17:06:18 UTC+1, Albrecht-S a écrit :

……
My proposal is to remove the setting of xclass at commandline parsing time under Windows, and that should be all we need to do. This should be done in 1.5 and higher (not backported to 1.4) and clearly documented. That's it.

I agree. Do you (Albrecht) volunteer to implement that?

Yes, I can do this. But note that this would also imply to remove your "prefixing" patch, at least as long as it is not optional.

While I was writing this I got an idea: instead of applying the prefix "FLTK-" as you suggested we can add yet another variable (string) for the optional prefix which users can set by calling (for instance) Fl_Window::xclass_prefix(const char *prefix). 
As long as this prefix is `nullptr` (the default) we don't apply a prefix to the class name, but users are free to set such a prefix that will be prepended to all xclass names set by the program. This could even be done in FLTK 1.4 if we wanted. But I don't think that this is necessary at all. Whatever we do should be done in 1.5, and 1.4 should be left alone...

It requires to establish a new platform-dependent code path

about window classes because what is done under Linux/Unix (use the executable name) would differ

from what is done under Windows (use "FLTK" if class name is empty). Under macOS, I would believe the overriden

function should not change the user-given class name.

Currently I have no idea (off the top of my head) what Fl_Window::xclass() would be used for on macOS, but this should not be hard to find out. If you could give a hint that would be appreciated, but I'll try myself tomorrow.

My practice of using Fl_Window::xclass(const char *) to avoid dynamic_cast becomes a bit risky because collisions with

reserved names under Windows must be avoided. But this can be explained in the documentation.

Yes, that's exactly my point. And I would add that the documentation should be updated in both 1.4 and 1.5 to tell the user that they should take care about such "reserved" class names on Windows. Even if we left the code that sets the xclass when parsing the commandline in place, users could always set other WNDCLASS  names by calling xclass() explicitly once they know what's wrong with a particular "xclass".

I'm not sure to agree about not backporting to 1.4: no change prevents to backport emoji support under Windows.

It's fine to fix bugs in branch-1.4 but we all agree(d) that we don't want to add new features and for sure we don't want to introduce behavioral changes we can't fully evaluate -- because (a) we don't know Windows in all details, and (b) we don't know what users did with their own software. As I wrote before, what if a user program depends on setting the WNDCLASS to "editor" or anything else? How can we replace that name with "FLTK-editor" w/o knowing why they do that? IMNSHO: no way!

If we change this, release 1.4.5, and hope that this update will make it into Linux distros, then we must be strictly backwards compatible: (a) with the ABI, but (b) also with such behavioral changes. Particularly if the user has no way to reverse that change. Imagine what an existing program on Debian would do if the shared FLTK library was replaced and the existing program would suddenly do something different. The same would of course be applicable to Windows DLL's.

Real bug fixes are another story. They are not allowed to change the ABI but a bug fix is a bug fix (like preventing to dereferene a nullptr). Such a behavioral change is intended and OK, that's the entire reason to make "patch releases".

With FLTK 1.5 it's different. The development branch is by definition beta software. If we change something, then we hope to get feedback, and if that change was considered negative, we can revert it before the release.

That's why I say that it is OK to change this in 1.5 but not to backport it to 1.4.

[Albrecht Schlosser]

On 1/14/26 16:29 Manolo wrote:
> I have committed at 81c965f new code that fixes use of the emoji
> palette under Windows.
> Both text input widgets now fully support using this palette to enter
> emojis.

Thanks, the surrogate pair stuff looks good, at least at a first glance
at the code. Well done!

> This commit also prefixes under Windows, user- and application-given
> window xclass names
> with "FLTK-" to avoid collision with window class names reserved by
> Windows. A change was
> necessary for the other fix to fully work. But I'm aware the exact fix
> to xclass names under
> Windows is still under debate here.

My opinion on this part didn't change. I don't want to "break
contracts", i.e. introduce regressions on user code that sets
Fl_Window::xclass() by any means. But see my reply to your next message
for more details.

[Bill Spitzak]

I think it is ok to leave this as "FLTK" on both Windows and X11 unless the program actually calls xclass() (which probably nobody does).

The intention was to alter what defaults are read from the defaults database depending on the program, but I don't think this ever worked and nobody uses it now.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkcoredev/2ce54183-a4b3-4be9-9d10-7853092203ba%40aljus.de.

[imacarthur]

On Thursday, 15 January 2026 at 03:22:07 UTC Bill wrote:

I think it is ok to leave this as "FLTK" on both Windows and X11 unless the program actually calls xclass() (which probably nobody does).

The intention was to alter what defaults are read from the defaults database depending on the program, but I don't think this ever worked and nobody uses it now.

Some or other WM I was using (can't remember which one, likely some flavour of Ubuntu... and I'm on a Win machine right now so can't check) *was* reading the value set in xclass and using that to label the window icon it created.

I noticed this because a load of little test utilities I'd thrown together, in a bit of a rush, all came up with icons labelled FLTK and I couldn't tell which was which.

The FLTK test examples mostly came up with "sensible" labels like "editor" and "input", presumably because their code was setting the exe name as the xclass value.

I don't know if that WM behaviour is "widespread" but if it is, then keeping the *nix builds setting xclass "magically" from show(argc, argv) might be the safe fallback?

At least if the user has not explicitly set xclass anyway.

That said, I don't think the Win32 builds need to do that - it seems to be some sort of historical oversight, and as Manolo points out it has "unexpected side effects"...

So, on the basis of not really knowing what I'm talking about, it seems as if _maybe_:

- Leaving the *nix version of show() setting xclass to the exe name, if it is not already set by the user, seems like a good thing (or at least harmless)

- NOT having the Win32 version of show() set the xclass (i.e. just set it to FLTK unless the user sets it), also seem like the right thing.

If we do that, then we do not have to prepend the xclass value set on Win32 since to will not collide with any MS magic names unless the user does that on purpose. (So then it's their own fault!)

Is that kinda where we have got to with all this? It does look a bit like a bug to me, so maybe should be back-ported into 1.4.x?

On the other aspect of this work - Manolo's fix to handle surrogate pairs under WinXX - that seems like a Good Thing and we should have that anyway. Is that 1.5 only though, or is it back-ported to 1.4.x too?

On an irrelevant tangent - how did Manolo even spot this? 

I'm so old that the only way I'd have tried to put emoji into a widget would be by accidentally hitting some wrong key sequence - It's not something it would ever occur to me to actually do on purpose!

[Manolo]

Le jeudi 15 janvier 2026 à 10:30:38 UTC+1, imacarthur a écrit :

On an irrelevant tangent - how did Manolo even spot this? 

I'm so old that the only way I'd have tried to put emoji into a widget would be by accidentally hitting some wrong key sequence - It's not something it would ever occur to me to actually do on purpose!

This started with issue #1360 asking for cross-platform emoji input support.
After fixing it for macOS, I considered Windows. 

I saw that test/input would enter emojis (although it would display them with wrong widths)

whereas test/editor would not. I started to search for what created this difference.
I progressively "undressed" test/editor.cxx making it simpler and simpler

and when I replaced window->show(argc, argv); by window->show(); emojis suddenly

could be input in the Fl_Text_Editor widget. I rapidly found the cause was in Fl::args() setting 

the window class name to "editor.exe" that conflicts with the "Edit" class name reserved by the OS.

[Manolo]

I believe we now all agree that, under Windows, Fl_Window::show(int, char**) should not set the window's class name

to the executable program name. It should leave untouched whatever value has been set before by the app,

and set it to "FLTK" if none has been set yet to avoid a void window class name.

This would remove the group of changes to Fl_win32.cxx in commit 81c965f that is in function Fl_WinAPI_Window_Driver::makeWindow().

This will make the other group of changes in the same commit related to emoji input to work also

for a program that happens to be named starting with "edit", such as program test/editor.

I also believe that FLTK 1.3 failing to input emojis under Windows in an FLTK widget in some cases

or displaying them with wrong widths is a bug that merits its fix to be backported from FLTK 1.5 to 1.4.

I notice that Ian also supports this.

Finally, I also believe leaving FLTK 1.3 in a state where the emoji fix would not work for any program

whose name starts with "edit" is another bug (responsibility is partly shared with Microsoft)

that deserves to backport its fix from 1.5. I don't see how this backport would conflict with ABI compatibility

across 1.3.x because any user- or application- set xclass() value would not be altered by the fix,

and because the naming of window classes to the application name is not a documented feature of 1.3.

[Manolo]

Le mercredi 14 janvier 2026 à 22:45:28 UTC+1, Albrecht-S a écrit :

While I was writing this I got an idea: instead of applying the prefix "FLTK-" as you suggested we can add yet another variable (string) for the optional prefix which users can set by calling (for instance) Fl_Window::xclass_prefix(const char *prefix). 
As long as this prefix is `nullptr` (the default) we don't apply a prefix to the class name, but users are free to set such a prefix that will be prepended to all xclass names set by the program. This could even be done in FLTK 1.4 if we wanted. But I don't think that this is necessary at all. Whatever we do should be done in 1.5, and 1.4 should be left alone..

I don't support this proposal.  It's purpose it too minuscule.

 

[Manolo]

Le jeudi 15 janvier 2026 à 14:25:00 UTC+1, Manolo a écrit :

I also believe that FLTK 1.3 failing to input emojis under Windows in an FLTK widget in some cases

or displaying them with wrong widths is a bug that merits its fix to be backported from FLTK 1.5 to 1.4.

I notice that Ian also supports this.

Finally, I also believe leaving FLTK 1.3 in a state where the emoji fix would not work for any program

whose name starts with "edit" is another bug (responsibility is partly shared with Microsoft)

that deserves to backport its fix from 1.5. I don't see how this backport would conflict with ABI compatibility

across 1.3.x because any user- or application- set xclass() value would not be altered by the fix,

and because the naming of window classes to the application name is not a documented feature of 1.3.

I got confused with FLTK version numbers in these paragraphs. 

Each instance of 1.3 is wrong and should be replaced by 1.4.

 

 

[Albrecht Schlosser]

On 1/15/26 04:21 Bill Spitzak wrote:
> I think it is ok to leave this as "FLTK" on both Windows and X11
> unless the program actually calls xclass() (which probably nobody does).

Thanks, Bill, that's an interesting idea, your input is always
appreciated, particularly concerning FLTK history.

However, I believe that this could break existing programs that use the
old default xclass set by using argv[0]. I'm currently investigating the
existing code ...

> The intention was to alter what defaults are read from the defaults
> database depending on the program, but I don't think this ever worked
> and nobody uses it now.

Unfortunately we can't know who uses it. Maybe users have found out how
to set it up and arranged their Xresources such that it worked for them.
Changing this would have an impact on such users that I would like to avoid.

OTOH I hope that we can remove this default setting from the Windows and
macOS (and maybe also Wayland?) platforms, where it was accidentally
"sneaked" into the implementation, as it obviously did no harm in the
implementation of the Windows and macOS ports (and the X11 specific code
was not disabled for these platforms).

It's only since we're using Unicode (UTF-8) and think about how to
insert emojis that this made a difference on the Windows platform.

[Albrecht Schlosser]

On 1/15/26 10:30 imacarthur wrote:

On Thursday, 15 January 2026 at 03:22:07 UTC Bill wrote:

I think it is ok to leave this as "FLTK" on both Windows and X11 unless the program actually calls xclass() (which probably nobody does).

The intention was to alter what defaults are read from the defaults database depending on the program, but I don't think this ever worked and nobody uses it now.

Some or other WM I was using (can't remember which one, likely some flavour of Ubuntu... and I'm on a Win machine right now so can't check) *was* reading the value set in xclass and using that to label the window icon it created.

Actually this is even documented behavior of Fl_Window::xclass():

"A string used to tell the system what type of window this is. Mostly this identifies the picture to draw in the icon."

https://www.fltk.org/doc-1.4/classFl__Window.html#a913bb4f81e4627e5b4a860ef78bca1ff

And there's more in the docs of Fl_Window::default_xclass():

"The default xclass is used for all windows that don't have their own xclass set before show() is called. ... If you don't call this, the default xclass for all windows will be "FLTK". "
https://www.fltk.org/doc-1.4/classFl__Window.html#aa5e0b61428d6a4e497b13a5bdde85328

The last sentence of the second citation is clearly violated by the current code (which uses `argv[0]` instead) - but only if Fl::args() is called or Fl_Window::show(argc, argv) is called (the latter with parameters argc and argv).

I noticed this because a load of little test utilities I'd thrown together, in a bit of a rush, all came up with icons labelled FLTK and I couldn't tell which was which.

The FLTK test examples mostly came up with "sensible" labels like "editor" and "input", presumably because their code was setting the exe name as the xclass value.

I'd guess that the most likely difference was that your applications called Fl_Window::show() w/o (argc, argv). Could this have been the case? I think it's today still what you see when calling it w/o these arguments.

I don't know if that WM behaviour is "widespread" but if it is, then keeping the *nix builds setting xclass "magically" from show(argc, argv) might be the safe fallback?

At least if the user has not explicitly set xclass anyway.

Yeah, that's why I hesitate to change this, at least for FLTK 1.4 which is in maintenance mode and should not produce such "surprises" if someone uses this.

That said, I don't think the Win32 builds need to do that - it seems to be some sort of historical oversight, and as Manolo points out it has "unexpected side effects"...

I agree.

So, on the basis of not really knowing what I'm talking about, it seems as if _maybe_:

- Leaving the *nix version of show() setting xclass to the exe name, if it is not already set by the user, seems like a good thing (or at least harmless)

- NOT having the Win32 version of show() set the xclass (i.e. just set it to FLTK unless the user sets it), also seem like the right thing.

+1 for both, although I'm still investigating details.

The "*nix version" version, as you say, could maybe apply only to X11 and not to Wayland, or maybe both. I don't know yet.

If we do that, then we do not have to prepend the xclass value set on Win32 since to will not collide with any MS magic names unless the user does that on purpose. (So then it's their own fault!)

Yep! ;-)

Is that kinda where we have got to with all this? It does look a bit like a bug to me, so maybe should be back-ported into 1.4.x?

I'm +/- 0 on this after all these discussions. Removing the (default) xclass setting under Windows (and macOS) *might* be acceptable, I'm still investigating...

On the other aspect of this work - Manolo's fix to handle surrogate pairs under WinXX - that seems like a Good Thing and we should have that anyway. Is that 1.5 only though, or is it back-ported to 1.4.x too?

This part should definitely be considered for backporting to 1.4 as it fixes a bug without causing any harm..

[Albrecht Schlosser]

[Note: unintended references to 1.3 changed to 1.4 in citations below]

On 1/15/26 14:25 Manolo wrote:

I believe we now all agree that, under Windows, Fl_Window::show(int, char**) should not set the window's class name

to the executable program name. It should leave untouched whatever value has been set before by the app,

and set it to "FLTK" if none has been set yet to avoid a void window class name.

This would remove the group of changes to Fl_win32.cxx in commit 81c965f that is in function Fl_WinAPI_Window_Driver::makeWindow().

Yes.

This will make the other group of changes in the same commit related to emoji input to work also

for a program that happens to be named starting with "edit", such as program test/editor.

Yes.

I also believe that FLTK 1.4 failing to input emojis under Windows in an FLTK widget in some cases

or displaying them with wrong widths is a bug that merits its fix to be backported from FLTK 1.5 to 1.4.

I notice that Ian also supports this.

And so do I. This concerns (only) the fix to Windows surrogate editing.

Finally, I also believe leaving FLTK 1.4 in a state where the emoji fix would not work for any program

whose name starts with "edit" is another bug (responsibility is partly shared with Microsoft)

that deserves to backport its fix from 1.5. I don't see how this backport would conflict with ABI compatibility

across 1.4.x because any user- or application- set xclass() value would not be altered by the fix,

and because the naming of window classes to the application name is not a documented feature of 1.4.

I agree as well, as long as you don't mean that we should still prefix the WNDCLASS name with anything. This part must be removed from the current code base.

Clarification: if we don't set the default xclass to the program name anymore, then this bug is fixed. There's no need to prepend anything to xclass names set by a user because the default xclass under Windows will be "FLTK" as documented, and - as Ian wrote - if users set the xclass then we don't change it, and if this conflicts with any "magic Windows WNDCLASS names", then it's the users fault.

If this wasn't clear yet: I agree to backport the removal of setting the default xclass to the program name (argv[0]) at startup to 1.4 and the surrogate pair editing in the Windows input functions. I don't agree with prefixing the WNDCLASS name in any way.

I'll check some more issues and commit the necessary code changes (1.4 and 1.5) if nobody objects during the next 36 hours.

[Albrecht Schlosser]

On 1/15/26 14:30 Manolo wrote:

Le mercredi 14 janvier 2026 à 22:45:28 UTC+1, Albrecht-S a écrit :

While I was writing this I got an idea: instead of applying the prefix "FLTK-" as you suggested we can add yet another variable (string) for the optional prefix which users can set by calling (for instance) Fl_Window::xclass_prefix(const char *prefix). [...]

I don't support this proposal.  It's purpose it too minuscule.

I withdraw this proposal because it's unnecessary anyway if we don't prefix the WNDCLASS because we don't set the default xclass() from argv[0].

[Albrecht Schlosser]

On 1/15/26 19:46 'Albrecht Schlosser' wrote:
> If this wasn't clear yet: I agree to backport the removal of setting
> the default xclass to the program name (argv[0]) at startup to 1.4 and
> the surrogate pair editing in the Windows input functions. I don't
> agree with prefixing the WNDCLASS name in any way.
>
> I'll check some more issues and commit the necessary code changes (1.4
> and 1.5) if nobody objects during the next 36 hours.

FTR: I'm almost done and I believe that I got a working solution. I'll
make some more tests tomorrow, and then I'll hopefully be able to commit
something that works on both FLTK 1.4 and 1.5 ...

[Greg Ercolano]

Regarding xclass, perhaps stating the obvious, and not reading all the text in this long thread:

    Just adding I have a hazy memory that setting the xclass affected the display of app icons in certain contexts to work properly, IIRC esp. under either windows or Linux, be it in the dock or the corner of the window title bar while the app is running, or or desktop/folder browser icons to browse the executable before running it.

    This may have something to do with why it's set during show(argc,argv) to help the app display those icons properly at runtime, not sure.

    I've found with old SVN commits, if the commit msg and related STR aren't enough, you could sometimes get more context about a confusing code change by looking at old newsgroup posts made around the same date as the change (e.g. same day or going back a week or so, while an issue gets hashed out) We don't have newsgroup messages going back before 2003 due to a server crash around that time, so changes made in e.g. 1998 won't have this, but commits made 2003 on forward might give some extra info.

[Bill Spitzak]

I think you are right, this controlled the icon displayed by some X11 window managers. So it might make sense to leave it working for X11. Change Windows to set it to "FLTK" unless the program actually sets xclass().

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fltkcoredev/d42052f3-47b4-47dc-bdaa-44bff127995a%40seriss.com.