nanogui: Fonts and keyboard support
Subject:
Fonts and keyboard support
From:
"Vidar Hokstad" ####@####.####
Date:
4 Jan 2000 14:22:10 -0000
Message-Id: <20000104142055.31296.qmail@mail.relight.com>
I'm currently working on a text area widget for NanoWidgets (we'll have to put
a new release together fairly soon... There's several new widgets, and lots of
bugfixes), and the font and keyboard handling issue popped up again.
I'd like to know the status of any ongoing work on keyboard events and font
handling before I start hacking on something myself.
There's quite a few things to consider:
- Support for international characters.
It would be good to support unicode internally. I would suggest
support for using UTF-8 text rendering. The advantage of using
UTF-8 is that the 128 ASCII letters stay the same, while any characters
with MSB set are part of multibyte sequences mapping to UCS-4 (32 bit
unicode characters). It is easy and compact to encode, and for any fonts
that only support ASCII, characters with MSB set can just be ignored.
- Support for font formats.
For very small devices, compiled in fonts like it is currently would
probably be enough. However for larger devices, support for many fonts
and maybe even scalable fonts, may be requirement. I suggest making it
easy to replace the font rendering at compile time. (We're considering
adding support for Freetype, but realize that Freetype is *way* to big
to just add to Nano-X without an option to turn it off).
- Support for querying for fonts.
We need a mechanism to obtain a list of fonts, their ID, and their most
important attributes (at the very least size - including a value to signal
"any" for freetype etc. -, and slant). Internally this could be handled
by whatever font renderer is compiled in, for instance a Freetype wrapper,
or a simple function that copies a compiled in structure when using compiled
in fonts.
- Keyboard events:
0.87 broke my escape code handling, and anyway I've always needed a small
patch to disable the ESC = quit thingie... I'd like to know if the keyboard
handling is now stable, or if things will change again. Again, I'd love
adding unicode support, but I'm thinking that for the keyboard this might
belong on the client side, since some applications may want raw keyboard
events anyway. Any comments?
I'm also thinking about looking into my archives and digging out the
preliminary support for an on screen keyboard I wrote last summer...
Basically a function to insert fake keyboard events into the event stream.
(should also be useful for automated testing...)
Any comments welcomed...
Regards,
Vidar Hokstad
VP of R&D,
Screen Media AS
