FV and UTF-8 - is it feasible

[alpine]

I intend to write a small maintenance application in a text mode Linux and since I don't have much experience with the Linux console I'd like to ask whether FV can handle UTF-8 properly.

It is a Debian like Linux and there is no X. It will be accessed remotely and despite a Web interface is an option, I would prefer to access it with a terminal emulator via ssh - I'm not a Web developer either.   

So, is the UTF-8 handled properly in FV?  The app needs to interact with a DB (sqlite3) thus it will need to handle international characters.

[marcov]

Afaik massive amounts of work on that subject was done in Trunk by Nikolaj, specially the deeper ends.

As new FV is relatively rare, I haven't heard practical experiences of people using that.

[alpine]

Afaik massive amounts of work on that subject was done in Trunk by Nikolaj, specially the deeper ends.

As new FV is relatively rare, I haven't heard practical experiences of people using that.

Thanks for the reply!

Reading the sub forum I found that a Unicode branch exists:
https://forum.lazarus.freepascal.org/index.php/topic,54894.msg408140.html#msg408140
But I cannot judge how complete is it because I'm not much into this Linux KVM stuff. Based on my experience with TV some >30 years ago: INT 16h, Video Memory, etc. - I suspect it is not quite trivial.

Anyway, I'll try to investigate a bit more on the topic.

[marcov]

The contents of that branch is what has been added to trunk.

KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.

[alpine]

The contents of that branch is what has been added to trunk.

KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.

Playing around with this for a day, I can see how much work Nikolay put into it. But it's only half baked and will need at least that much more to cover the size of the original library (e.g. Editors.pas not fixed, etc.).

Initially, on Ubuntu, the testuapp broke with RunError(234) on a first keystroke until I included cwstring into the uses clause.
IMHO the biggest complication is from the need to keep the video buffer portable, I'm not sure it's worth the effort that way or it is better to be revamped completely.

[PascalDragon]

The contents of that branch is what has been added to trunk.

KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.

Playing around with this for a day, I can see how much work Nikolay put into it. But it's only half baked and will need at least that much more to cover the size of the original library (e.g. Editors.pas not fixed, etc.).

Then please report such occurrences.

Initially, on Ubuntu, the testuapp broke with RunError(234) on a first keystroke until I included cwstring into the uses clause.

That is expected. Unicode handling requires a Unicode manager on non-Windows.

[alpine]

The contents of that branch is what has been added to trunk.

KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.

Playing around with this for a day, I can see how much work Nikolay put into it. But it's only half baked and will need at least that much more to cover the size of the original library (e.g. Editors.pas not fixed, etc.).

Then please report such occurrences.

I've got the impression that this is a work in progress.

Initially, on Ubuntu, the testuapp broke with RunError(234) on a first keystroke until I included cwstring into the uses clause.

That is expected. Unicode handling requires a Unicode manager on non-Windows.

Perhaps, It should be noted somewhere. At least, I noted it here in the forum.

I'm considering my scenario as quite specific - text UI program for non English speakers via remote terminal. Judging by the name, Nikolay is my fellow countryman and I don't know how many others like us have the need to use FV. Is there such a demand? How many of the potential users will require compatibility with the non-Unicode TV?

Because IMO revamping to full Unicode will be easier. Without the vast array of $IFDEFs.

[marcov]

Perhaps, It should be noted somewhere. At least, I noted it here in the forum.

I'm considering my scenario as quite specific - text UI program for non English speakers via remote terminal. Judging by the name, Nikolay is my fellow countryman and I don't know how many others like us have the need to use FV. Is there such a demand? How many of the potential users will require compatibility with the non-Unicode TV?

If you mean the cwstrings, that is not for compatibility with non unicode. That is because enabling unicode by default links to libraries that makes copying simple binaries from system to system more difficult. 
 

[alpine]

Perhaps, It should be noted somewhere. At least, I noted it here in the forum.

I'm considering my scenario as quite specific - text UI program for non English speakers via remote terminal. Judging by the name, Nikolay is my fellow countryman and I don't know how many others like us have the need to use FV. Is there such a demand? How many of the potential users will require compatibility with the non-Unicode TV?

If you mean the cwstrings, that is not for compatibility with non unicode. That is because enabling unicode by default links to libraries that makes copying simple binaries from system to system more difficult.

Since I'm trying the Unicode version of FV the cwstring was required to setup the widestring manager, particularly for the UpCase() call at menus.inc:750 which broke at the first place. That was a quick one.

My question for how many of the users will require compatibility with the non-Unicode TV was because keeping the FV that way (with $IFDEFs and WriteBuf/WriteLine) mixes UnicodeStrings with PShortString, i.e. imposes wacky deref macros (?!) and things like that. Revamping with classes instead of objects and managed strings instead of PShortString will simplify everything. But it will break the TV compatibility.

[marcov]

I fully agree (classes, strings, exceptions and e.g. resource based forms loading to replace the current cumbersome chained method calls).

But since that would be such massive break, it would make more sense to put it next to FV (e.g. with a certain prefix, name all functions FVNG.dialogs etc) rather than doing it in the FV codebase.

[PascalDragon]

The contents of that branch is what has been added to trunk.

KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.

Playing around with this for a day, I can see how much work Nikolay put into it. But it's only half baked and will need at least that much more to cover the size of the original library (e.g. Editors.pas not fixed, etc.).

Then please report such occurrences.

I've got the impression that this is a work in progress.

It's not. Buf even if it would be: report bugs nevertheless, because the developer might have overlooked something.

Initially, on Ubuntu, the testuapp broke with RunError(234) on a first keystroke until I included cwstring into the uses clause.

That is expected. Unicode handling requires a Unicode manager on non-Windows.

Perhaps, It should be noted somewhere. At least, I noted it here in the forum.

It's a general requirement that has nothing to do with FreeVision: you're dealing with Unicode on non-Windows? Then you need to include a Unicode manager, be it cwstrings or fpwidestrings or a third party one.