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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
