[Lazarus] Android and QT ?

Felipe Monteiro de Carvalho felipemonteiro.carvalho at gmail.com
Wed Mar 2 14:27:56 CET 2011


On Wed, Mar 2, 2011 at 1:49 PM, Razvan Adrian Bogdan
<lightningflash at gmail.com> 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




More information about the Lazarus mailing list