[haiku-commits] Re: haiku: hrev45990 - docs/user/interface
- From: John Scipione <jscipione@xxxxxxxxx>
- To: "haiku-commits@xxxxxxxxxxxxx" <haiku-commits@xxxxxxxxxxxxx>
- Date: Mon, 26 Aug 2013 14:56:18 -0400
On Mon, Aug 26, 2013 at 9:33 AM, Stephan Aßmus <superstippi@xxxxxx> wrote:
> By the way, I am pretty sure that setting a different encoding is not
> supported by the Haiku app_server. All strings are always interpreted as
> UTF-8 encoded.
Can somebody verify this?
From what I could tell from looking at app_server the encoding of a
font can be set to something other than UTF-8, I am not sure if it is
actually used or not.
> Additionally, I think it sucks that the Be API even offered this in BFont. I
> find it much cleaner to define /the/ encoding used throughout the entire
> API, with some converter classes that make conversions from/to any other
> encoding easy. As it is, supporting this would make app_server a tiny bit
> slower for no good reason, and you if you need to deal with encodings in any
> other context than displaying some text, you need another separate
> implementation for the conversion. What's available in BFont wouldn't be the
> tiniest bit useful.
Don't kill the messenger! The encoding support in BFont seems pretty
lame to me too.
From the perspective of a documentation writer I'm trying to explain
how the system works and to a lesser extent how it is suppose to work
when there's a difference. I can't speak to the design of BFont, but,
If we would like to deviate from how BeOS R5 worked here, it should be
written into the documentation loudly and clearly.
From the perspective of a developer I just want to know what
assumptions I'm allowed to make. If I can assume UTF-8, that's great,
if not, I need to know that.
After reading the BeBook and the code examples it looks like I can
assume UTF-8 most of the time but also need to be prepared to deal
with the encoding being a single-byte high ASCII encoding sometimes.
Practically that means that I can rely on 7-bit ASCII characters in
KeyDown() all the time and UTF-8 for multibyte characters (i.e
numBytes > 1), but, If it's single byte and not ASCII I need to check
the specific encoding used.
It could be worse, at least we don't have to deal with other Unicode
encodings like UTF-16 or UTF-32 in Interface Kit classes which aren't
compatible with good ol' 7-bit ASCII.
I'd like to expand on the documentation for BView::KeyDown() and
BView::DrawString() to make this all clear.
Other related posts:
