On Wed, 2008-07-09 at 16:38 +0200, thomasg wrote: > Like said before, they are (at least for me) all but working well (not > even to mention the UI design with 2-color icons without ever knowing > what they might mean).
Some of the icons are all but intuitive but this is a question of the icons and not of the toolkit. > 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. 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. The current work separation between gsmd and phone-kit is a very clever one, but again not invented here but at o-hand. There have been plenty of alternatives been offered for the current gsmd but they were all blocked out. And many of those people simply left. > The userbase of Nokias Internet Tablet Series is huge, but it looks > for me as the developerbase isn't that big in relation, and that with > a GTK-stack. What makes you think this will be different with ETK? This means even less developers. > Even Nokia bought Trolltech, and I bet they'll drop GTK eventually And shortly afterwards Nokia bought Symbian. They are not going to drop any of the three. They just do everything to put up a front against Google's Android. That's what they fear. > They are paying the Trolltech folks now, and they are also paying EFL > developers. Yes, there is a cool application for connecting the N800 to your car electronics and see into the engine management. The point being is that there are way less ETK developers than GTK developers or qt developers > Again on the developers: they had nothing to work with. 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. > 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. It is one big pack that rather would be split in tiny packages. That makes development and debugging a lot easier. Moreover this will take another two years until it has some API stability. A huge API like this doesn't come overnight. 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. _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
