Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-26 o 16:34, Tomas Hajny via fpc-pascal pisze: On 2020-12-26 15:45, gabor via fpc-pascal wrote: W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze: . . Very interesting. But in a future version of the FV (or other TUI framework) apart from migrating from objects to classes, using component streaming, collections, etc... it would be good if the unit "drivers" were more abstract and not strictly dependent on Video, Mouse and Keyboard units. Then it will be possible to create a driver that, for example, renders the screen buffer in a win32-gdi window, or even in html5 canvas or LCL. There's nothing preventing you to implement unit video in these environments, IMHO. Of course, but then we need to finish what Charlie started - unicode. And think about possibility of including multiple drivers in single executable. Michał. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
On 2020-12-26 15:45, gabor via fpc-pascal wrote: W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze: . . Very interesting. But in a future version of the FV (or other TUI framework) apart from migrating from objects to classes, using component streaming, collections, etc... it would be good if the unit "drivers" were more abstract and not strictly dependent on Video, Mouse and Keyboard units. Then it will be possible to create a driver that, for example, renders the screen buffer in a win32-gdi window, or even in html5 canvas or LCL. There's nothing preventing you to implement unit video in these environments, IMHO. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze: Anyway, any interest to develop Free Vision further is very welcome one, so we can move it from past tense to a future one. I still think text mode UI for console and terminals still has a place, but sadly the current FV implementation doesn't necessarily plays well on some Un*x terminals (it's highly dependent on the font, and many other factors), also a mono mode is sorely missing, which is a problem for both some modern and retro use cases. And yeah, on the high-end, Unicode would be needed. Speaking of Unicode, I have started working on adding Unicode support to the keyboard, video and mouse units (which are used internally by FV) in the unicodekvm branch. So, if anyone is interested in adding Unicode support to FV, take a look at this branch. Very interesting. But in a future version of the FV (or other TUI framework) apart from migrating from objects to classes, using component streaming, collections, etc... it would be good if the unit "drivers" were more abstract and not strictly dependent on Video, Mouse and Keyboard units. Then it will be possible to create a driver that, for example, renders the screen buffer in a win32-gdi window, or even in html5 canvas or LCL. Michał -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboVision is reborn as FOSS (again)
W dniu 2020-12-23 o 14:27, Graeme Geldenhuys via fpc-pascal pisze: On 22/12/2020 10:20 pm, gabor via fpc-pascal wrote: Sorry, I keep mistaking code point for character. I thought that the code point is a value in the range 0..10. I don't think I fully understand Unicode... Here in an example: https://en.wikipedia.org/wiki/Combining_character Two or more code points combined can form a "single character" when rendered on screen or paper. Sometimes you can replace those with a single "precomposed character" too. The Unicode standard includes many of them, but not all. https://en.wikipedia.org/wiki/Precomposed_character Hope that helps. Thanks, that is very helpful. But if I understand correctly, each such combination of code points can be properly represented by one code point (NFC normalization). Michał. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal