UI: replace "x" with multiplication sign when displaying calculations #106388

Damien Picard · 2023-03-31T15:48:51+02:00

Damien Picard commented

2023-03-31 15:48:51 +02:00

The multiplication sign looks like an "x" but should be used in its
stead to display calculations and dimensions such as "1920x1080". It
is supported in many fonts including DejaVu Sans, the font currently
used for the UI.

The modification was done only for strings which are displayed in the
user interface, so this excludes prints.

Before	After

The multiplication sign looks like an "x" but should be used in its stead to display calculations and dimensions such as "1920x1080". It is supported in many fonts including DejaVu Sans, the font currently used for the UI. The modification was done only for strings which are displayed in the user interface, so this excludes prints. ----- | Before | After | |-------------------------------------------------------------|-------------------------------------------------------------| | ![image](/attachments/f258b8a9-8724-4fb3-85f3-e0aa2a3fda6c) | ![image](/attachments/95368a53-1961-4f90-abaa-e1b1951bc1c6) | | ![image](/attachments/4473e18a-7466-45fa-867b-86fde59b4d97) | ![image](/attachments/75534328-3d05-43e5-8982-4c1787ac8d1a) | | ![image](/attachments/b49eb7a2-ab16-4aec-a0cd-d3a4b466dbb8) | ![image](/attachments/31895cc4-0375-4dfc-b5ff-c40028072e03) |

image.png

9.7 KiB

image.png

12 KiB

image.png

9.7 KiB

image.png

6.9 KiB

image.png

7.0 KiB

image.png

12 KiB

👍 2

Damien Picard added the

Module

User Interface

label 2023-03-31 15:48:51 +02:00

Harley Acheson commented

2023-04-01 21:59:06 +02:00

That's a pretty cool idea. Note that this symbol is safe to use even if you select a different UI font. This is because we are using a stack of multiple fonts so if their selected font does not contain "×" it will still be found in the "Noto Sans Math" font in the fallback stack. You can see all the fonts in the datafiles/fonts folder.

I'm a little leery of the use of the "Universal Characters Name" \u00D7 though as I'm unsure of the support in all platform compilers. I'd hate to find that some dumb compiler adds 0x00 0xD7 and not the actual utf8 bytes of 0xC3 0x97.

Simplest would be to just use the literal '×' there. We've had direct uses of characters not in the lower ascii range for quite a few years without issues. A good example is in rna_wm.c you will find ←, ↓, →, ↑.

That's a pretty cool idea. Note that this symbol is safe to use even if you select a different UI font. This is because we are using a stack of multiple fonts so if their selected font does not contain "×" it will still be found in the "Noto Sans Math" font in the fallback stack. You can see all the fonts in the datafiles/fonts folder. I'm a little leery of the use of the "Universal Characters Name" `\u00D7` though as I'm unsure of the support in all platform compilers. I'd hate to find that some dumb compiler adds 0x00 0xD7 and not the actual utf8 bytes of 0xC3 0x97. Simplest would be to just use the literal '×' there. We've had direct uses of characters not in the lower ascii range for quite a few years without issues. A good example is in rna_wm.c you will find ←, ↓, →, ↑.

Damien Picard commented

2023-04-01 23:23:37 +02:00

stack of multiple fonts so if their selected font does not contain "×" it will still be found in the "Noto Sans Math" font in the fallback stack. You can see all the fonts in the datafiles/fonts folder.

Thanks, I hadn’t thought of that. Your font stack system is really very cool :)

Simplest would be to just use the literal '×' there. We've had direct uses of characters not in the lower ascii range for quite a few years without issues. A good example is in rna_wm.c you will find ←, ↓, →, ↑.

Oh, interesting, I thought on the contrary that non-ascii characters would be less compatible. Probably because I saw these \u codes recently in Python working on another PR (!106240).

Can you run a build just to make sure?

> stack of multiple fonts so if their selected font does not contain "×" it will still be found in the "Noto Sans Math" font in the fallback stack. You can see all the fonts in the datafiles/fonts folder. Thanks, I hadn’t thought of that. Your font stack system is really very cool :) > Simplest would be to just use the literal '×' there. We've had direct uses of characters not in the lower ascii range for quite a few years without issues. A good example is in rna_wm.c you will find ←, ↓, →, ↑. Oh, interesting, I thought on the contrary that non-ascii characters would be less compatible. Probably because I saw these \u codes recently in Python working on another PR (!106240). Can you run a build just to make sure?

Harley Acheson commented

2023-04-01 23:50:25 +02:00

Oh, interesting, I thought on the contrary that non-ascii characters

Yes, I remain a bit surprised that those arrows in rna_wm.c have never been a problem, but it could be that things are just getting better over time.

Where we use an ellipsis character it looks like this:

    /* Ellipsis. Some compilers complain with real literal string. */
    const char sep[] = {0xe2, 0x80, 0xA6, 0x0};

Looking now I actually used Universal Characters Names in blf_thumbs.c for the font samples. Although slightly different usage in that they were in 32-bit strings like U"\ud55c\uad6d\uc5b4". There is a utf8 specifier like u8"This is utf8" but no idea how supported that is. In your case you just have a char array and \u00D7 and hoping it turns into 0xC3 0x97 and not 0x00 0xD7. Probably always works fine and I am just being too cautious. But it would look nicer with '×' in there.

Can you run a build just to make sure?

Are you not able to, or not sure how? Try adding a new comment to this thread that contains nothing but the following single line:

@blender-bot build

> Oh, interesting, I thought on the contrary that non-ascii characters Yes, I remain a bit surprised that those arrows in rna_wm.c have never been a problem, but it could be that things are just getting better over time. Where we use an ellipsis character it looks like this: ``` /* Ellipsis. Some compilers complain with real literal string. */ const char sep[] = {0xe2, 0x80, 0xA6, 0x0}; ``` Looking now I actually used Universal Characters Names in blf_thumbs.c for the font samples. Although slightly different usage in that they were in 32-bit strings like `U"\ud55c\uad6d\uc5b4"`. There is a utf8 specifier like `u8"This is utf8"` but no idea how supported that is. In your case you just have a char array and `\u00D7` and hoping it turns into 0xC3 0x97 and not 0x00 0xD7. Probably always works fine and I am just being too cautious. But it would look nicer with '×' in there. > Can you run a build just to make sure? Are you not able to, or not sure how? Try adding a new comment to this thread that contains nothing but the following single line: ``` @blender-bot build ```

Damien Picard commented

2023-04-02 00:00:37 +02:00

Are you not able to, or not sure how? Try adding a new comment to this thread that contains nothing but the following single line:
@blender-bot build

I was pretty sure I didn’t have the proper rights to do it, but now that you mention it I’ll have to test it next time I need it—because your comment just triggered a build!

> Are you not able to, or not sure how? Try adding a new comment to this thread that contains nothing but the following single line: > > ``` > @blender-bot build > ``` I was pretty sure I didn’t have the proper rights to do it, but now that you mention it I’ll have to test it next time I need it—because your comment just triggered a build!

Damien Picard force-pushed dp_replace_x_in_dimensions from a2ca4fe873 to 37aaa0c815

2023-04-20 20:18:38 +02:00

Compare

Damien Picard commented

2023-04-20 20:19:33 +02:00

@blender-bot build

Blender Bot commented

2023-04-20 20:19:36 +02:00

Only blender organization members with write access can start builds. See documentation for details.

Only blender organization members with write access can start builds. See [documentation](https://projects.blender.org/infrastructure/blender-bot/src/branch/main/README.md) for details.

Damien Picard commented

2023-04-20 20:26:59 +02:00

Hello Harley, sorry about the delay.

I found a few other occurrences of strings using "x" as a multiplication sign, so I replaced them as well. I hope I got all of them, this time!

I also used a literal "×" as you suggested, and there wasn’t any problem when building on Linux, could you trigger the bot again to make sure it’s all right, since the bot denied me?
If there is any issue, it’s in a separate commit I can still remove, otherwise it can be squashed.

Hello Harley, sorry about the delay. I found a few other occurrences of strings using "x" as a multiplication sign, so I replaced them as well. I hope I got all of them, this time! I also used a literal "×" as you suggested, and there wasn’t any problem when building on Linux, could you trigger the bot again to make sure it’s all right, since the bot denied me? If there is any issue, it’s in a separate commit I can still remove, otherwise it can be squashed.

Damien Picard commented

2023-04-20 20:35:53 +02:00

Screenshots:

Screenshots: ![image](/attachments/6d7dff8d-9e3d-4fdb-ba05-e60d109cf4f0) ![image](/attachments/b88dea99-519d-4dd9-b26d-e24a2cee8d70) ![image](/attachments/427b577f-5732-4130-ae50-bbe15965af01) ![image](/attachments/6bf6a890-f28b-42b0-8357-b0c41015246e) ![image](/attachments/d27e0ec2-8dc6-4df6-b99b-55ff8fa588c6) ![image](/attachments/09dfbad7-30df-4f64-8ee5-4dd7d627d326)

image.png

20 KiB

image.png

43 KiB

image.png

21 KiB

image.png

11 KiB

image.png

20 KiB

image.png

20 KiB

Evan Wilson commented

2023-04-20 21:20:15 +02:00

Gitea makes a bunch of noise with this change.

Does anyone know if those only show up in pull requests, or do they appear in the code repository as well?

Gitea makes a bunch of noise with this change. Does anyone know if those only show up in pull requests, or do they appear in the code repository as well? ![44E2AC58-D09E-4346-8685-665607B881FD.png](/attachments/a8d96259-27db-4d74-9bda-c045bc31db00)

44E2AC58-D09E-4346-8685-665607B881FD.png

411 KiB

Damien Picard commented

2023-04-20 21:30:10 +02:00

or do they appear in the code repository as well?

They do, here in my fork.

> or do they appear in the code repository as well? [They do](https://projects.blender.org/pioverfour/blender/src/commit/37aaa0c815303e512282dfe94a15ece06e586e7e/source/blender/makesrna/intern/rna_nodetree.c#L114), here in my fork.

Harley Acheson commented

2023-04-20 23:49:24 +02:00

I should say that this encoding issue recently came up with Campbell on this: #106581 and he didn't want even want Unicode literals in comments. I ended up using the same "Universal Characters Names" that was your first idea. Sorry if I led you astray.

Damien Picard force-pushed dp_replace_x_in_dimensions from 37aaa0c815 to 4ec573c4f5

2023-04-21 00:16:15 +02:00

Compare

Damien Picard commented

2023-04-21 00:20:04 +02:00

No problem, I reset to the previous version.

Damien Picard changed title from ~~UI: replace "x" by multiplication sign when displaying calculations~~ to UI: replace "x" with multiplication sign when displaying calculations

2023-05-08 11:42:48 +02:00

Damien Picard force-pushed dp_replace_x_in_dimensions from 4ec573c4f5 to 188cf47424

2023-05-10 12:19:21 +02:00

Compare

Damien Picard requested review from Harley Acheson 2023-05-18 18:57:08 +02:00

Damien Picard force-pushed dp_replace_x_in_dimensions from 188cf47424 to 0d0d54a44d

2023-06-13 21:10:51 +02:00

Compare

Harley Acheson referenced this pull request

2023-06-20 17:33:23 +02:00

Refactor: UTF-8 Character Defines #109163

Harley Acheson commented

2023-06-20 22:03:11 +02:00

Hey @pioverfour, sorry for the delay.

I had a look around at all our other uses of Unicode characters and found it to be a bit of a messy hodgepodge. We use literals, universal characters and byte escape sequences. And it also looks like most of that mess is my fault. So I made the following - #109163 - which adds defines for them in a single format. I am hoping you can take a look at it. Maybe they should be elsewhere, be in a different format, or have a different naming scheme, etc.

Hey @pioverfour, sorry for the delay. I had a look around at all our other uses of Unicode characters and found it to be a bit of a messy hodgepodge. We use literals, universal characters and byte escape sequences. And it also looks like most of that mess is my fault. So I made the following - #109163 - which adds defines for them in a single format. I am hoping you can take a look at it. Maybe they should be elsewhere, be in a different format, or have a different naming scheme, etc.

Damien Picard commented

2023-06-20 23:11:45 +02:00

Hey @pioverfour, sorry for the delay.

Hey, no worry, this isn’t the most urgent feature!

I made the following - #109163

I replied in the PR, but basically I believe unifying Unicode characters is a good idea, but this solution breaks translations. I don’t have a strong opinion on which alternative is best, I guess I’d probably go with universal characters as in this PR.

> Hey @pioverfour, sorry for the delay. Hey, no worry, this isn’t the most urgent feature! > I made the following - #109163 I replied in the PR, but basically I believe unifying Unicode characters is a good idea, but this solution breaks translations. I don’t have a strong opinion on which alternative is best, I guess I’d probably go with universal characters as in this PR.

Damien Picard force-pushed dp_replace_x_in_dimensions from 0d0d54a44d to f06ff2fb45

2023-06-27 13:56:48 +02:00

Compare

Damien Picard commented

2023-06-27 14:03:22 +02:00

@Harley I changed the PR to use your new BLI_STR_UTF8_ macros, except for strings parsed using regex (one TIP_() and one BKE_reportf()).

@Harley I changed the PR to use your new `BLI_STR_UTF8_` macros, except for strings parsed using regex (one `TIP_()` and one `BKE_reportf()`).

Harley Acheson commented

2023-06-27 21:00:35 +02:00

@pioverfour - Noice!

Harley Acheson approved these changes 2023-06-27 21:01:02 +02:00

Harley Acheson merged commit 9b4749e7c7 into main