Will GTK be used in Openmoko?

[Carsten Haitzler (The Rasterman)]

On Fri, 16 May 2008 11:37:51 +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.

every mail client adds that to the top of emails - automatically. mail clients
provide often a way to configure it. i happened to set mine to something
amusing. if you see it in every mil it's got to be obvious its automated - not
like everyone is manually doing it.

> >> 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.

ok. so even here we dont have a consensus and a solution. it's pretty hacky.

> It's complicated, but it does not come under my definition of "display". 

it does for me as the non-display portion is only a co-ordinate (the selection
start point - and end point) the rest is merely display (drawing) of a
selection (as well as logical mapping of that selection to the source text).

> 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.

adn that toolkit will have not addressed other things like powerful layering
and custom ui mixing, fast rendering, etc. etc. so you lose some things and
gain others. priorities. what matters most is what always needs weighing up -
like it or not, roman text is the majority of the userbase already.

> > 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.

you don't need to. you are still free to write or install apps with any toolkit
you want.

> > 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.

adding letters does not go solve your input methods - not for japanese, chinese
(traditional or simplified) or korean though. you can in fact keep your qwerty
kbd and just run the input method handler and bingo. it will work - as long as
the toolkit/apps talk to the input method handler (IME).

> > 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?

in the x world IME is handled by the input method - not the toolkit. the
toolkit talks to the IME and just dumbly displays completions or a composed
word. hell XIM even has a mode where the IME does the composition display itself
- toolkit simply gets told the final word. this is why i split it up. the
input-side of things is just a matter of being able to talk to the IME. the IME
is something like:

kinput2, scim, uim etc.

they work irrespective of toolkit - as long as you talk the protocol. almost
everything can talk XIM and they all support XIM bridges too. it's not elegant,
but does work. i have used XIM for japanese a lot - and uim and scim.

> >  our stats show just that.
> >   
> Except that those stats disregarded input, and I do not see how you can 
> disregard input.

no - stats were sales of gta01's. who actually bought one. where they live. i
am not going to go through them all but the vast vast vast majority are
westerners speaking reading, writing a latin-based language or a pure latin one
(not even with accents).


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>