On Wed, Mar 2, 2011 at 1:49 PM, Razvan Adrian Bogdan <[email protected]> wrote: > I was looking at this: "The ONLY problem this plugin has, > is that it doesn't support hardware acceleration so no OpenGL. For > OpenGL I need to resurrect "mw" plugins, I'll do it after sw plugin > will be production stable. "
Maybe they use the new Surface API, but that only appeared in Android 2.3. It offers a raw surface, no widgets. > I have high hopes for QT, it's the best integrated CrossPlatform toolkit, i > have seen GTK and it makes me feel that it was made by people that do not > appreciate aesthetics so the source code looks hard to read. > Qt had one problem with the GPL licensing, now it's also LGPL so the problem > is gone. I too like Qt and fpGUI, so maybe my mails were sounding like if I think it is a bad idea to invest in checking how they can work in Android, it's not the case. The thing is that I work with Android Programming so I know that custom drawn programs suffer from major integration issues in android which can be solved if you have a company with dozens of developers working full time on that and people testing all of the 50+ most important smartphones, tablets, etc, but a small team (or just 1 guy alone) will have a very hard time keeping up. Every new phone that comes in might bream custom drawn apps or their integration to the OS in general and so many things are configurable. And everything is tested against the standard Java widgets, not against custom drawn apps. But, despite these issues, Qt or fpGUI might be the only viable solutions for porting Lazarus to Android. My bindings which connect Pascal to the Android API (which I am calling Android4Pascal) are more viable for standalone programs then for the LCL. > The problems appear when trying to mimic the way native widgets work on > each platform such as pulsing buttons and things like that > but if browsers can do it, so can FPGui. Actually, many browsers use native widgets. Desktop browsers use native widgets more often then mobile browsers, for the reason that we already know: Lack of trust in the stability and durability of mobile APIs. Many mobile OSes have died over the years. > I was thinking how did Google do it, did they write the GUI core in C/C++ > and created wrappers so that Java may use them or did they write the GUI in > Java and now people have to find ways to make Java respond to native calls > through indirect wrappers and service applications. Ah, I see. I don't know, but I think that the widget drawing and handling code is in Java, otherwise they would have made the API public. -- Felipe Monteiro de Carvalho -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
