Skip to content

Conversation

@ONykyf
Copy link
Contributor

@ONykyf ONykyf commented Jun 13, 2025

To make FvwmForm input fields UTF-8 aware, input.size field is duplicated as input.width, the first one containing size in bytes and the latter width in multibyte chars. To allow walking along a string with chars of different lengths (1 to 4 bytes), e.g., for pasting or moving a cursor by arrow keys or by a mouse click, a helper function find_nth_UTF8_char() is introduced.

Fixes #1211

ONykyf added 2 commits June 13, 2025 09:38
To make FvwmForm input fields UTF-8 aware, input.size field is
duplicated as input.width, the first one containing size in bytes
and the latter width in multibyte chars. To allow walking along
a string with chars of different lengths (1 to 4 bytes), e.g.,
for pasting or moving a cursor by arrow keys or by a mouse click,
a helper function find_nth_UTF8_char() is introduced.
@ONykyf ONykyf force-pushed the on/fvwmform-utf8 branch from 1ec6cde to ea426a0 Compare June 13, 2025 09:33
@ONykyf
Copy link
Contributor Author

ONykyf commented Jun 15, 2025

@ThomasAdam @somiaj No more places affected by "multibyteness" found. Testing shows no problems. Please review.

@ThomasAdam
Copy link
Member

@ONykyf -- Thanks for this. It looks OK, although I'm not going to get time to properly look at it until later on the week.

Other than my very small nits I've identified, I think we can probably improve on the logic in a few areas, but I'll wait until I've had change to go over those properly.

…ocate mouse click faster, and translate labels with Gettext
@ThomasAdam
Copy link
Member

@ONykyf

This PR is getting there, still with comments from me which need addressing.

I'm still not completely happy with the state of things overall though, but it's a convoluted mess and this is probably going to have to be good enough, but I suspect I'll merge this once you've finished addressing things, and then tidy it up afterward.

@ONykyf
Copy link
Contributor Author

ONykyf commented Jun 21, 2025

Hope now the logic of the helper function is more straightforward and manageable enough by whoever will do this in the future.

@ONykyf ONykyf requested a review from ThomasAdam June 21, 2025 17:01
@ONykyf ONykyf requested a review from ThomasAdam June 21, 2025 18:04
@ONykyf
Copy link
Contributor Author

ONykyf commented Jun 21, 2025

Removed.

Copy link
Member

@ThomasAdam ThomasAdam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be squashed into a previous commit as it's not introducing anything new.

@ONykyf ONykyf force-pushed the on/fvwmform-utf8 branch from 3dd4dca to c18fd01 Compare June 21, 2025 18:42
@ONykyf ONykyf requested a review from ThomasAdam June 21, 2025 18:44
@ONykyf
Copy link
Contributor Author

ONykyf commented Jun 28, 2025

@ThomasAdam Unsafe strndup() replaced with fxstrndup() analogous to fxstrdup() but truncated if necessary.

In fact getpwuid.c also contains strndup() alongside fxstrdup(). Maybe replace it there as well?

@ThomasAdam
Copy link
Member

@ThomasAdam Unsafe strndup() replaced with fxstrndup() analogous to fxstrdup() but truncated if necessary.

No thanks. I don't think we need this.

In fact getpwuid.c also contains strndup() alongside fxstrdup(). Maybe replace it there as well?

getpwuid.c is a compat file found elsewhere, it's not changing to fit in with any wrapper functions.

The point of the fx*() wrappers is mostly for portability; fxmalloc() is perhaps the only exception to this.

You may as well just remove this latest commit, and make the following adjustment:

item->input.init_value = fxmalloc(var_l + 1);
strlcpy(...);

I also think we need to look at item->input_init_value vs item->input.value.

@ONykyf ONykyf force-pushed the on/fvwmform-utf8 branch from 7611217 to 53d8c40 Compare June 28, 2025 11:22
@ONykyf
Copy link
Contributor Author

ONykyf commented Jun 28, 2025

@ThomasAdam Unsafe strndup() replaced with fxstrndup() analogous to fxstrdup() but truncated if necessary.
You may as well just remove this latest commit, and make the following adjustment:

item->input.init_value = fxmalloc(var_l + 1);
strlcpy(...);

Done

I also think we need to look at item->input_init_value vs item->input.value.

item->input_init_value is used to restore item->input.value on form restarts.

@ONykyf
Copy link
Contributor Author

ONykyf commented Jul 24, 2025

@ThomasAdam Are there any more adjustments to be made?

@ThomasAdam ThomasAdam added type:enhancement Augmenting an existing feature relates:module Issue is in module code labels Jul 24, 2025
@ThomasAdam ThomasAdam added this to FVWM3 Jul 24, 2025
@github-project-automation github-project-automation bot moved this to PRs in FVWM3 Jul 24, 2025
@ThomasAdam ThomasAdam added this to the 1.1.4 milestone Jul 24, 2025
@ThomasAdam ThomasAdam merged commit 7200d17 into fvwmorg:main Jul 24, 2025
8 checks passed
@github-project-automation github-project-automation bot moved this from PRs to Done in FVWM3 Jul 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

relates:module Issue is in module code type:enhancement Augmenting an existing feature

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

FvwmForm input field fails to process multibyte chars

2 participants