[opensuse-factory] Yast (and some console programs) not correctly displaying

newer
[opensuse-factory] libtirpc-devel:...

older
[opensuse-factory] Re: Tumbleweed...

Rainer Hantsch

18 Jan 2019 18 Jan '19

07:17

From my point of view this can only come from a poor usage of ncurses, if it would nbe ncurses itself, my programs would also have troubles (but they don't). Perhaps there is another layer of software on top of ncurses and that one is not correctly written? Or are this tools not using ncurses and doing everything "manually"? -> This is a many years persisting issue and shows that even Leap (many years after UTF8 introduction) is not tested well in this

Hello. I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and it also is a question of principle that an OS and all its programs have to correctly (and not mostly) support them. Linux is offering a huge number of different encodings and should be aware of correctly supporting all of them, as it did before UTF8. If not, it is a question of careless coding or implementation. I use still ISO-8859-1 on all of my servers and workstations because of several reasons (and I do not want to change something in this point). Most of my self-written programs are based on ncurses, using the fuill set of features (also windows and window layers). All of the, are working perfectly and are displaying correctly, so I am pretty sure that ncurses and all related libs _are_ correct. So what? I see that many programs (i.e. YaSt in textmode, but also several other tools) are not correctly displaying, they show sometimes 2-Byte characters and distort hereby the output. This happens more on real text screens (i.e. Ctrl-Alt-F1 console) and is slightly better in a graphical "konsole" of KDE, but it happens. point and/or fixed. I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Oliver Kurz

18 Jan 18 Jan

07:21

On 18/01/2019 08.17, Rainer Hantsch wrote:

...

Hello.

I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and it also is a question of principle that an OS and all its programs have to correctly (and not mostly) support them. Linux is offering a huge number of different encodings and should be aware of correctly supporting all of them, as it did before UTF8. If not, it is a question of careless coding or implementation.

I use still ISO-8859-1 on all of my servers and workstations because of several reasons (and I do not want to change something in this point). Most of my self-written programs are based on ncurses, using the fuill set of features (also windows and window layers). All of the, are working perfectly and are displaying correctly, so I am pretty sure that ncurses and all related libs _are_ correct.

So what? I see that many programs (i.e. YaSt in textmode, but also several other tools) are not correctly displaying, they show sometimes 2-Byte characters and distort hereby the output. This happens more on real text screens (i.e. Ctrl-Alt-F1 console) and is slightly better in a graphical "konsole" of KDE, but it happens. From my point of view this can only come from a poor usage of ncurses, if it would nbe ncurses itself, my programs would also have troubles (but they don't). Perhaps there is another layer of software on top of ncurses and that one is not correctly written? Or are this tools not using ncurses and doing everything "manually"? -> This is a many years persisting issue and shows that even Leap (many years after UTF8 introduction) is not tested well in this point and/or fixed.

I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work.

What could be a reason is that the YaST programs use https://github.com/libyui e.g. https://github.com/libyui/libyui-ncurses and not ncurses directly. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Rainer Hantsch

07:39

Hello Oliver. Thank you for this very quick answer. Am Freitag, 18. Jan 2019, 08:21:43 schrieb Oliver Kurz:

...

On 18/01/2019 08.17, Rainer Hantsch wrote:

...
I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work.

What could be a reason is that the YaST programs use https://github.com/libyui e.g. https://github.com/libyui/libyui-ncurses and not ncurses directly.

I already thought that such thing with some kind of overlaying software might be the reason. So the problem can now be... a.) A fault in this overlaying toolbox b.) An incorrect use of this toolbox. As I am no developer and it exceeds my knowledge to reverse-engineer YaST and/or libyui (I program only in FreePascal), I can only tell that something is not working properly. Those people developing libyui and YaST can check their software much quicker and reliably than I ever could. I am pretty sure that several tools in openSUSE will use libyui-ncurses, otherwise it would not have been mentioned on github: "... Libyui is a widget abstraction library providing Qt, GTK and ncurses frontends. Originally it was developed for YaST but it can be used in any independent project. ..." It appears to me that this libyui-ncurses is much more likely the reason in this case. This would explain why other programs also have sometimes displaying issues. But it also might be the case that in some lines of code this libgui-ncurses is not correctly used (i.e. a somewhere forgotten string-conversion between different codesets). This should be fixed anyways. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

08:19

On Friday 2019-01-18 08:39, Rainer Hantsch wrote:

...

...
On 18/01/2019 08.17, Rainer Hantsch wrote:

...
I do not want to start a discussion here about advantages/disadvantages of one or the other encoding (ISO-8859-1, UTF8, ...) and/or why I should use UTF8. I have good reasons why I don't want to do that and stay with ISO-8859-1, and

I watch this phenomen since UTF8 came out. Because I do remote administration often in text mode (ssh or in a few cases even by modem dial in), a properly working handling of encodings has to work. [...]

[yast] This should be fixed

So should your local encoding. But we already know *that's* not going to happen.. Mexican standoff. For as long as we "should" do something, I'll point out a thing you "should" be doing. ------- To interested people wanting to debug: * start putty native on openSUSE (this is set to UTF-8), ssh to localhost, run "hte" — mc and yast are fine —, observe. * start putty.exe on openSUSE through wine (this defaults to ISO IIRC), ssh to localhost, run hte or yast — mc is fine —, observe. * hte on xterm directly is fine.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org