[Lazarus] Qt5 plans available

[Lee Jenkins]

On 5/11/2011 6:44 AM, Michael Schnell wrote:
> On 05/11/2011 10:18 AM, Marco van de Voort wrote:
>> 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).
> Agreed ! Lazarus/FPC is all about native code. It would be close to impossible
> to compile a decent Lazarus project to JVM or CIL.
>
> That is why in my first post in this thread I mentioned "ifi": a Widget Type
> that separates the business code from the widget generation and introduces a
> stream interface between these parts. Thus a set of standard "widget generator"s
> could be provided together with the LCL to do a remote GUI based on the
> streaming interface . And this baby can be done in Java (e.g. for Android), in
> Java Script (e.g. for server applications with Browser based remote GUI) in FPC
> Code (for a remote GUI using a standard GUI-program attached to the "server" or
> "service" via TCP/IP, serial interface or some Windows message based transport,
> enabling WIN Server 2008 services) or perhaps in Delphi Prism (for enabling
> Silverlight/Moonlight stuff).
>
> But I fear this is too much work to do for a small group of developers.
>

I started a project like this about a year ago, but never finished due to client 
changing direction when Apple announced not including flash support which was 
the first basic UI framework that it worked with.

http://leebo.dreamhosters.com/pasria/

Basically it did the what you are describing I believe.  The server basically 
instructed the (flash) GUI client to render textboxes, lists, grids, etc and 
bound the client events to the server so that a ComboBox in flex would signal 
it's selection to the server.  A small framework on the client side was proxied 
for the server application and rendered the GUI as instructed and reported 
"interesting" events to the server.

Though this project was geared to more "remote" clients such as over the web or 
intranet, the speed/responsiveness was surprisingly good though I frequently 
would envision roadblocks whereas you cannot always get the fine grained control 
that you need of a gui from the server side.

Some events are easy and straight forward like a click event.  Other events that 
you might need to capture and react to from the client, would be textbox change 
events.  My thinking at the time though, for these kinds of events was that it 
was fast enough for google's "search as you type" Ajax implementation over the 
web so probably fast enough for local network and intranet as the prospective 
project was to be.

If I were to pick this project up again, I would probably go with Appcellerator 
or PhoneGap for the GUI front end.

Also, speaking of Appcelerator and PhoneGap, wouldn't it be nice to see a FPC 
version of the same?  Basically, a fpc application that exposed webkit's WebView 
as PhoneGap does for the GUI (Appcelerator hooks native widgets by default I 
believe), but using object pascal to program it!  Of course, that would require 
some kind of objectpascal to javascript translator unless the WebKit WebView 
exposes underlying DOM and events through an API...

All fun stuff to speculate on, but then again, I do make a good armchair 
quarterback :-)


--
Warm Regards,

Lee