Will GTK be used in Openmoko?

[Shachar Shemesh]

Carsten Haitzler (The Rasterman) wrote:
> On Fri, 16 May 2008 10:43:31 +0300 Shachar Shemesh <shachar at shemesh.biz>
> babbled:
>
>
>   
> in my culture it
> it good natured fun.
And had it not been the first time I received a message for you, I might 
have. Since the rest of the mail was quite dismissive as well, it is 
very hard to figure out, based on one email, that it was automatic.
>   
>>
>> Like I said, adding display support to a toolkit, especially where the 
>> machine already has the required libraries, is a piece of cake.
>>     
>
> not really. please tell me how you determine if you display right to left or
> left to right where a paragraphi may be 50% roman and 50% arabic text?
The standard way (GTK, QT) is to use the first character of the 
paragraph, where translators are instructed to place an RLM/LRM at the 
beginning of the paragraph if that heuristics fails. There have been 
many battles with the GTK team about allowing an out of line override, 
so far to no avail. Windows usually insists that this be set out of 
bounds, but some undocumented experimentation suggests that placing two 
RLMs at the start of the paragraph will, actually, override it in some 
cases. For SMSs the heuristics is usually to treat it as right to left 
if there is any RTL character in the SMS.

The point I'm trying to make is not that it comes free. The point I'm 
trying to make is that once the infrastructure is there, I have the know 
how to do go the rest of the way. If the infrastructure is not there, 
however, I doubt I'll have the time to put it in.
>  which
> formatting method do you use?
I'm not sure I understand the question.
>  at what point do you change?
You don't. Each paragraph is rendered completely.
>  how do you do
> selections of text when you are selecting text dragging right to left then over
> some quoted roman text that is left to right?
It's complicated, but it does not come under my definition of "display". 
This is precisely the difference between adding display support and 
adding full i18n support, and precisely the reason I think going for a 
toolkit that doesn't have it is a problem. To me, you are just proving 
my point.
>  there's a lot of gotchas.
>   
But not with the display. The display is a simple "call fribidi and then 
show the text" (with shaping for Arabic). It's the other stuff, which 
are not display, that are difficult, and which will be greatly helped by 
a toolkit that has already addressed it.
>
> that is what i mentioned. input is another matter separate from display - they
> have entirely separate code paths and systems, so i know i tackle them
> separately.
>   
But does it make sense for them to have different toolkits? I don't know 
of any way to easily mix widgets from different toolkits in the same 
window (unless these are different processes doing separate message 
loops, but even then it's not easy). This means, to me, that we must 
think of the input stage even if it's far off. If a toolkit that is 
convenient now will give us grief later on, maybe it's not the right 
choice now.
>
>   
> there are 2 halves to it. the fact is as-is right now you will get only roman
> text input - on the gtk based om image as with anything else. you will need to
> ADD support for anything else
I don't mind adding support for things that are missing. HoweverAdding 
Hebrew letters to an already existing keyboard is one thing. 
Reimplementing a BiDi edit control is another.
>  - and then hope it works ok.
Except we know that with GTK it will be, more or less, ok, and with EFL 
it won't. We already know that.
> i still stand by the fact that the majority of people in the world - and by far
> and wide the majority of people who will buy or own an openmoko produced phone,
> will be right-to-left language users and the definite majority of those will
> even be using basic latin text.
Unless you are intending to use one toolkit for display and another for 
input, I find that statement strange. I am not sure how text input goes 
on Japanese phones, but I do know that, on Windows, an average IME 
weights over 30MB, most of which is the dictionary of words it uses to 
guess what you meant from the phonetic roman letters typed. Do you 
really want to reimplement that?
>  our stats show just that.
>   
Except that those stats disregarded input, and I do not see how you can 
disregard input.

Shachar