bring back the regular checkmarks

[Ckath]

its great and all this is still maintained, but I dont enjoy things becoming less readable. you could argue here "use a better font" but htop is used in a lot of minimal installs that might be lacking all and any fancy glyphs, which is why the old method of checkmarks is used in nearly every cli program

[Arkanosis]

I have to agree there. As much as I like using dedicated glyphs in most places, I have a hard time telling whether a box is checked or not since 3.0.

BTW, thanks for taking over maintainership!

[Ckath]

to add on to this as I just noticed, in TTY the symbol is exactly the same for checked and unchecked with these new glyphs

[Arkanosis]

to add on to this as I just noticed, in TTY the symbol is exactly the same for checked and unchecked with these new glyphs

Oh, you're right. Not sure how I could take a screenshot of a TTY, but I get an identical small blue square for both checked and unchecked boxes. That's probably because I use the sun12x22 console font, but that's not something I can change without breaking a lot of other stuff. Unicode characters in the TTY might actually require upgrading to Linux 5.7+ (fine for Arch, but not for Debian / CentOS) or switching from the kernel VT to something like kmscon.

[bertwesarg]

Very unfortunate to hear, that this is not appealing on all terminals, fonts, or sizes. Though I'm not sure that removing the feature completely is the way to go. We may can add an option to disable the use of UTF-8, even though the terminal supports it. But this would also effect the UTF-8 characters for the tree view.

[Ckath]

Very unfortunate to hear, that this is not appealing on all terminals, fonts, or sizes. Though I'm not sure that removing the feature completely is the way to go. We may can add an option to disable the use of UTF-8, even though the terminal supports it. But this would also effect the UTF-8 characters for the tree view.

I dont think anyone ever complained about the utf8 tree chars, as they are regular box drawing chars that exist in most if not all fonts used. I considered adding a way to have the settings structure in CRT.c where its set, and allow user overwrites for what they want utf8 or ascii. even if that was added, it doesnt seem ideal(wont live update) and also not worth the effort as everyone was completely okay with the ascii/utf8 situation as it was (characters for trees but not checkboxes).

thus simply making it act like it has done for years seemed the easiest solution.

[Arkanosis]

Yeah, UTF-8 is fine for the tree view, and is fine for most characters as well (let's say I have some fôöbâr.sh running; it's displayed properly in htop even within a TTY). Having to disable UTF-8 altogether would be a regression. So far, the only problem I've seen is with the checkboxes.

[Ckath]

should add that the whole "utf8" detection seems like a bit of nonsense to begin with as box drawing chars used for tree are within the ascii table as well

[sugar700]

I believe using Unicode ballot boxes and check marks was a mistake. If you check wcwidth(L'☑') it will provide 1 as answer (at least that's what happens on my operating system). This means that a check mark will take 1 character of space in a terminal.

Now, consider that this character is rendered as a square. In many fonts, the height of a character is twice as big as its width. However, because ballot box is a square its size is going to be affected by its width, resulting in a tiny character.

On systems where wcwidth(L'☑') is 2 (maybe macOS? surely it didn't look too bad for whoever submitted this patch) I think this rendering is fine, but when wcwidth(L'☑') is 1 it's going to be pretty bad.

[chrisduerr]

I'd like to point out that box drawing characters aren't even UTF-8 necessarily. There's a dedicated character set for box drawing characters that the terminal can switch to for those (character set 0). So you can easily use those without UTF-8 support, just by using ascii.

[bertwesarg]

Let me give you a little more context, why I choose to switch to the UTF-8 check boxes:

I added the toplogy view to the affinity panel ('a'). This shows the hardware topology in a tree to easily select the sup-trees for the affinity mask. Thus there is a tree and for each tree entry a check box. I looked at the process tree, which also allows to collapse process children. But I was rather disappointed about the use of + for the state of a collapsed tree node:

Here is the opened state, i.e., show process children, which uses the BOX DRAWINGS LIGHT HORIZONTAL as the -

├─ x
│  └─ y
└─ z

Here is the closed state, which uses the ASCII +:

├+ x
└─ z

As you can (hopefully) see, the horizontal line of the + does not align with the box drawing character.

I therefor searched for a better solution in the Unicode charset, but did not found a better one. But I found the checkbox code points and also code points for ⊟ and ⊞. I considered these superior to the ASCII check boxes. Because the affinity panel is very prone to have an excessive panel width, if the hardware topology gets too complex. The unicode codepoints could save here valuable screen estate, in contrast to the ASCII [x] and [+]/[-]version.

The ASCII version has a nonlabel width of of 4 (check box) + (3 * hierarchy depth) (tree drawing) + 4 (tree open/closed). While the Unicode version has only a non-label width of 2 + (3 * hierarchy depth) + 2. Thus the width is 4 characters more narrow.

I have now found, that Unicode 13 has a new code point for a horizontal line with a stroke which should provide an aligned +. Thus reverting to process tree variant for closed/opened sub-trees, should be possible and thus would not require the extra ⊟ and ⊞. Resulting in a non-label width of 4 (ASCII check box) + (3 * hierarchy depth) (tree drawing). Thus is the same as with the current Unicode implementation.

I will therefor create a merge request, which reverts to ASCII only check boxes and to the same tree as the process tree for open/closed. And will also add an option to use the new U+1FBAF code point, instead of the +. Though I'm not sure, if it is possible to add an configure check for this.

[Ckath]

As you can (hopefully) see, the horizontal line of the + does not align with the box drawing character.

so then dont use the + when you want it to lign up with box drawing chars, theres stuff like ACS_PLUS or any of the other box drawing things that couldve been used here.

valuable screen estate

its not so much a matter of screen realestate as it is readability, its a mess to have these unicode things inside a 99% ascii ui, it'll never line up or look right. for example, this is how great these 'superior' symbols are going to look for me:

I will therefor create a merge request, which reverts to ASCII only check boxes and to the same tree as the process tree for open/closed. And will also add an option to use the new U+1FBAF code point, instead of the +. Though I'm not sure, if it is possible to add an configure check for this.

step in the right direction though I would highly prefer it just all being ascii and all and any unicode being the optional enable. as the code is currently I only see settings taking effect after a restart with how CRT.c is structured. instead of setting it there once, just checking a setting value wherever it is used might work out.

[AlexandraAalto]

My terminal entirely lacks the checkbox characters, replacing them with identical placeholders thus making the option screen unusable.