[Lazarus] The future of desktop

[Santiago Amposta]

El 28/11/2013 15:01, Michael Van Canneyt escribió:
>
>
> On Thu, 28 Nov 2013, Santiago A. wrote:
>
>>
>> Perhaps Lazarus should start thinking about a widget "html+javascript"
>> and  prioritize it.
>
> I am laying the groundwork for this since some years. It is not an
> easy task if you want to do it correctly.
>
> Michael.

I have made a small test program, by hand, with no LCL and no RAD
utilities. It is boring and a lot of dirty work, but not difficult (If I
could do it, it can't be difficult, my programming skills are rusted
after years of programming sales reports). I have taken a look at QT
widget, and perhaps it shouldn't be that difficult integrating web with LCL.

Nevertheless I have found issues that have little to do with RAD, they
are related to the concept of remote GUI itself.

Let's suppose you have a checkbox that when cheked must enable some
controls. In a common desktop the event is sent to the application, and
application process the event and tells the GUI which controls must
enable. But if the application is remote, the roundtrip may take 30 ms,
add a cascade of events triggered and you get that you uncheking a
chekbox the application gets stalled for a moment or more (I read
somewhere that to get the "no time" perception it must react in less
than 100ms). I said 30ms but it could be 200ms depending on the
connection, and then the moment may become a second.

The solution to this problem is quite easy, and it is what many web-GUI
interfaces do: Move part of program to the client side, so they send big
javascripts to the client. No objection, I don't think it's a big deal
to send javascript libraries to the client, as long as it is transparent
for me as developer. What I intend to avoid, when I write an
application, is having to write half application in pascal and half
application using javascript. I want to write the whole application in
pascal and let the libraries use javascript or whatever they want.

Probably I'm demanding too much, there is no way a component can say "I
will convert this few lines of code into a javascript and send it to the
client"

Beside this, there are concerns with http protocol, it is document
oriented, not connection oriented. For example, unless you keep the
connection open, every event from GUI to application, even a single
byte,  must send a lot header information, let alone if you use cookies
that are sent with every connection. There are workarounds, comet, html5
websockets, perhaps with some drawbacks.

What is your approach to these questions?

-- 
Regards
Santiago A.
svaa at ciberpiula.net