T-Mobile with ASU on GTA01?

arne anka openmoko at ginguppin.de
Wed Jul 9 18:09:24 CEST 2008


>> The FSO-stack is what's needed to get that API and to get the
>> developers.
>
> The FSO-stack is another case of reinventing the wheel. It sounds nice
> on the paper but in reality this is a horror. There are PIM APIs like
> eds and whatever in the KDE world or qtopia is used. It took years for
> them to grow mature and nobody needs yet another API.

how far are they toolkit independent? ie do these apis work with  
gtk/etk/whatever or are they deeply integrated with kde/qtopia?


> The thing is that Michael Lauer massively dislikes C and needs
> everything reinvented in Python. C has its place in the embedded world
> as much as Python has. But again we cut a huge slice out of the
> developer base.

well, you need somebody willing to put some effort into things -- and it  
helps, if you love it.


> This is simply not true. It was just a lack of documentation. And I
> can't help it, but this has been deliberately blocked in order to pave
> the way for this ASU/FSO. Even developers from o-hand who developed for
> Openmoko in their freetime finally left the boat being completely
> disgusted by the fact of constantly running against walls.

i wouldn't know about that -- but as much as i would like you to ask for  
proof: i think it only will force this thread down the slope into a flame  
war which will solve nothing.

>>  FSO with it's dbus-api will make this much easier
>
> IMHO this is just pure nonsense. I know that it has been repeated over
> and over again by Michael Lauer because it is his baby.


i think those argumenta ad personam aren't going anywhere.
i don't know about past wars and fights and honestly -- i am not  
interested at all.
so let's just skip the "i don't like X because X likes Y" part and come to  
something useful:

- what makes you think fso will not solve anything (besides the already  
mentioned problem of maturity)
- what toolkit agnostic apis are available

> Last not least: if you want to use your code in the future on a moblin
> device you are just doomed/trapped in an API that nobody else uses.

well, what api do you see coming to be used on future moblin devices? as  
far as i can see both of the approaches (limo and google) are basically  
closed, exposing a careful selected window to the devices.





More information about the community mailing list