[Lazarus] Qt5 plans available

Marco van de Voort marcov at stack.nl
Wed May 11 10:18:21 CEST 2011


On Wed, May 11, 2011 at 09:18:57AM +0200, Michael Schnell wrote:
> > And if you want to capitalize on it, you need to be ready now, not only
> > start.
> >
> > Lazarus is not suitable for trying to follow fast moving trends. Iphone
> > was just yesterday, and even that is not really ready.
> >
> Yep.
> 
> OTOH, I feel that Android is the more promising concept.

Maybe, but only if some dominant vendor emerges that standarizes a certain
set of features across its line. This is now chaos.

> In fact I don't like it's strong Java binding.

I don't like that either, but usually such things will eventually be watered
down by reality. (and I don't think it will be any different for the
javascript bit)

(CIL vs JVM)

We have gone over the CIL rants before, so I'll not repeat it, except that I
think it is a very coloured view, and I do not agree.

> But other than then the iPhone OS+GUI, that seems quite different to the 
> PC Mac OS+GUI, Android to me seems to be about to win at multiple targets:
>   - mobile (smart Phone and "Pad":  anyway)
>   - Laptop
>   - Desktop (via the Laptop path)
>   - embedded (I already found the first embedded PCBs that come with 
> Android <enhanced by API extensions for embedded hardware interfaces)
>   - Servers (it's not harm if the usual Linux server gets a - seldom 
> used -  Android GUI just for compatibility)

This demonstrates the problem what is "win". Widest range of devices? Most
devices sold? Biggest turnover in the software market?

I think for the average developer it is the latter, and then corrected by
subtracting turnover of the very large companies. (e.g. we won't compete
with mp3 sales, and other very popular apps, we won't ever get that
business, so it is no sense). 

Note that is turnover for the devices I can reach in practice. Not the
devices that run some form of android, but android in the right version on
the right architecture with a device that has the required aux. hardware on
board (think GPS,Tilt sensor etc), and sold separately or by a carrier that
allows app install.

And of course the cost of development. How many versions of the app for
different devices/archs/versions must I make?  How many different periphal
hardware will I have to support (different GPSes etc). How much does it cost
to get them in the marketplace and promote them etc etc.

That is all more important than cil vs jvm, or even bytecode vs native.

But my personal opinion is that neither cil NOR jvm is a valid target for
Lazarus/FPC (regardless of the fact if you think bytecode is the way to go
or not).

I slightly turned last summer after some discussions on IRC and the lazarus
day in the sense that if a JVM backend wouldn't complicate the compiler too
much. (the JVM is standalone, and the rest of the compiler remains native),
and has its own separate libraries, that would be a possibility.

But still I think it would be better served with an independant project long
term.




More information about the Lazarus mailing list