Re: [Lazarus] The future of desktop

[Dmitry Boyarintsev]

On Fri, Nov 29, 2013 at 4:52 AM, Michael Schnell  wrote:

> On 11/28/2013 05:39 PM, Dmitry Boyarintsev wrote:
>
>> Even if LCL will start "web target" today, it will be 10 years later that
>> LCL can be used without problems.
>>
> You don't seem to know what Michel v C and friends can do :-) :-)

Yes, I do. I also do know how LCL works internally.
As you can see below in MVC's reply, he actually confirms my point.

LCL is not going to be network based, for one simple reason - it
technically cannot - too much is bound to low lever WinAPI-like functions.

And of course, a web-framework can be created based on Lazarus. But using
Lazarus as IDE only (or at least - package manager).
So to be more accurate a web-framework will be Free Pascal based.

thanks,
Dmitry


On Sat, Nov 30, 2013 at 8:28 AM, Michael Van Canneyt  wrote:
>
> You are missing the point, I think.
>
> The idea is not to create a new widgetset.
>
> The idea is just to be able to program in pascal, output Javascript.
>
> Using some kind of 'external' declarations would enable you to use Adobe
> Air,
> ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see
> fit.
>
> I am not making any assumptions on that.
>
> But, and this is what I miss in all other attempts mentioned here: I want
> to be able to program the browser WITHOUT necessarily having an application
> server running on a webserver.
>
> It must be possible to ship a HTML file and a Javascript file for a
> working application. That's it.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, Marcos Douglas wrote:


Is the pascal scripting engine ready for production use?



Not at all.

Michael.


This project will be open source?


It will be, obviously.


If yes, why don't you release the code right now? Other people can
contribute too.


Because I want to have a decent subset of Pascal translated before I publish it, 
so there is something to build on.


Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Marcos Douglas]

On Sat, Nov 30, 2013 at 11:30 AM, Michael Van Canneyt
 wrote:
>
>
> On Sat, 30 Nov 2013, Andrew Brunner wrote:
>
>> On 11/30/2013 06:38 AM, Michael Van Canneyt wrote:
>>>
>>> No.
>>>
>>> Extpascal does wat mseide does. Transport everything back to the server.
>>> That is completely the wrong approach. Not scalable at all. Slow, not
>>> guaranteed to have a return etc. In short: wrong.
>>>
>>> I want to program the browser itself. In Pascal.
>>>
>>
>> Do you mean an embedded component that displays web pages?  Or do you mean
>> a scripting project that takes lfm and pas units and build the app "on the
>> fly"?
>
>
> Not on the fly. See it more as a Pascal-to-Javascript compiler.
>
> You really should have a look at the Morfik AppsBuilder or Smart Mobile
> studio products.
>
> I just want to be able to do what they do, but in Lazarus.
>
>
>> Is the pascal scripting engine ready for production use?
>
>
> Not at all.
>
> Michael.

This project will be open source?
If yes, why don't you release the code right now? Other people can
contribute too.


Marcos Douglas

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, Felipe Monteiro de Carvalho wrote:


On Fri, Nov 29, 2013 at 12:13 PM, Michael Van Canneyt
 wrote:

That is exactly my plan:

1. Convert pascal to javascript.
2. Use the custom widget design capabilities of Lazarus to design the form.

Just like Morfik does/did, and recently Smart Mobile studio.


But a very large piece here is at stage zero of development: the
pascal 2 javascript compiler.

Or does it already exist and I am not aware of it?


Well. 2 pieces exist publicly: the fcl-js and fcl-passrc.

The transformer for the AST is started, but is not published.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Felipe Monteiro de Carvalho]

On Fri, Nov 29, 2013 at 12:13 PM, Michael Van Canneyt
 wrote:
> That is exactly my plan:
>
> 1. Convert pascal to javascript.
> 2. Use the custom widget design capabilities of Lazarus to design the form.
>
> Just like Morfik does/did, and recently Smart Mobile studio.

But a very large piece here is at stage zero of development: the
pascal 2 javascript compiler.

Or does it already exist and I am not aware of it?

-- 
Felipe Monteiro de Carvalho

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, Martin Schreiber wrote:


On Saturday 30 November 2013 13:38:58 Michael Van Canneyt wrote:

On Fri, 29 Nov 2013, Marcos Douglas wrote:

Extpascal does wat mseide does. Transport everything back to the server.


That is not quite right. MSEifi does not transport everything back to the
server. It transports only what is defined in the client form- and
datamodule-resources as "interesting for server". Most of the actions (for
example show dropdown lists, scroll and sort datasets) is done client side
without server interaction.
Programming the whole application in Javascript and running in browser surely
is an option, but why use Free Pascal for that purpose?


Easy:
Because of all the advantages that Pascal has over the mess that Javascript is.

The inventors of Javascript should be publicly flogged on the town square.
You can choose any town you like. The bigger, the better ;)

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Paul Breneman]

On 11/30/2013 02:08 AM, Martin Schreiber wrote:

On Friday 29 November 2013 13:55:10 Michael Schnell wrote:


MSEgui has a (supposedly not yet finished) extension called "ifi". Same
is supposed to provide a remote GUI via a Byte-pipe. Both the server and
the "user" end is a pascal program.


MSEifi-remote is still experimental because nobody made real applications up
to now. Local inprocess MSEifi is used in production to separate user
interface and business logic in MSEgui applications since years. IIRC I even
made a MSEifi-remote demo-binary especially for you so that you could show
the principle to your co-workers some years ago. ;-)

How MSEifi-remote works:

- Client is an application independent Free Pascal program with MSEgui/MSEifi-
library. The client could be realized as browser plug-in (not done up to
now).
- Server is a Free Pascal program with the necessary MSEifi connection
components. The server needs no GUI library elements.
- The client joins the server by a byte stream connection, currently
implemented are pipes and sockets.
- The server sends *.mfm data (the MSEgui equivalent of Lazarus form files) to
the client. The form data can contain Pascal Script snippets if necessary.
- The client instantiates the forms/datamodules exactly the same as a normal
MSEgui application would do -> look, feel and performance of the components
are the same.
- Client and server use MSEifi data- and event-components which are linked by
the MSEifi-remote protocol.

Example:

A user button click triggers firing of an event in a taction component by the
tbutton.action property, the event is transported over the wire, triggers
tnoguiaction.onexecute in the server, the server sends a modal form to the
client, the client shows the modal form, the user enters data which will be
sent to the data components in the server, the user closes the modal entry
form, the modalresult will be sent to the server.

So for development of server, client or standalone applications the same
MSEide+MSEgui RAD-approach can be used. While developping and debugging it is
possible to run client and server in the same process with
a "shortcut-connection".

Martin


A *long* time ago I was involved a little with Genotechs in Phoenix and 
they had a (Delphi) program called AstroMark that sounds similar:

http://www.eweek.com/c/a/Enterprise-Networking/Do-You-Deploy-Thin-or-Thick-Web-Applications/


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, Andrew Brunner wrote:



On 11/30/2013 07:28 AM, Michael Van Canneyt wrote:


But, and this is what I miss in all other attempts mentioned here: I want 
to be able to program the browser WITHOUT necessarily having an application 
server running on a webserver.


It must be possible to ship a HTML file and a Javascript file for a working 
application. That's it.


Don't forget browsers also have database storage now.  So some abstraction 
could be done there as well.


True. But that is just a matter of writing a wrapper class.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Martin Schreiber]

On Saturday 30 November 2013 13:38:58 Michael Van Canneyt wrote:
> On Fri, 29 Nov 2013, Marcos Douglas wrote:
>
> Extpascal does wat mseide does. Transport everything back to the server.

That is not quite right. MSEifi does not transport everything back to the 
server. It transports only what is defined in the client form- and 
datamodule-resources as "interesting for server". Most of the actions (for 
example show dropdown lists, scroll and sort datasets) is done client side 
without server interaction.
Programming the whole application in Javascript and running in browser surely 
is an option, but why use Free Pascal for that purpose?

Martin

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, silvioprog wrote:


2013/11/30 Michael Van Canneyt 
  On Sat, 30 Nov 2013, silvioprog wrote:

2013/11/30 Michael Van Canneyt 
      [...]
      I want to program the browser itself. In Pascal.


Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate 
it into Lazarus? That would leave the
responsibility for compatibility
with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support 
for cross-platform etc. for the webkit.


  You are missing the point, I think.

  The idea is not to create a new widgetset.

  The idea is just to be able to program in pascal, output Javascript.

  Using some kind of 'external' declarations would enable you to use Adobe 
Air,
  ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see 
fit.

  I am not making any assumptions on that.

  But, and this is what I miss in all other attempts mentioned here: I want 
to be able to program the browser WITHOUT
  necessarily having an application server running on a webserver.

  It must be possible to ship a HTML file and a Javascript file for a 
working application. That's it.


But that is exactly what the node-webkit does, however, using a webkit ready, 
and without a HTTP server. But node-webkit uses JS, so the
idea would be to use Pascal. E.g., in a pseudo code, would be:


Node-webkit still requires an external binary to be shipped somewhere, like Adobe Air. 
It emulates a browser.


That is not what I am trying to accomplish.

Using my approach, you will be able to use node-webkit, if you want to. All I 
will do in the first place
is convert pascal to Javascript. What you decide to do with that (how to interact with the browser or 
node-webkit, or whatever) is up to you. Once I have the Javascript part running, I will see how to 
integrate this with Lazarus so it can be used to design your web applications. Whether this will be 
with an existing webkit (and which one) or not is entirely up for discussion, and not relevant at this point.


Michael.--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, Andrew Brunner wrote:


On 11/30/2013 06:38 AM, Michael Van Canneyt wrote:

No.

Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all. Slow, not 
guaranteed to have a return etc. In short: wrong.


I want to program the browser itself. In Pascal.



Do you mean an embedded component that displays web pages?  Or do you mean a 
scripting project that takes lfm and pas units and build the app "on the 
fly"?


Not on the fly. See it more as a Pascal-to-Javascript compiler.

You really should have a look at the Morfik AppsBuilder or Smart Mobile studio 
products.

I just want to be able to do what they do, but in Lazarus.


Is the pascal scripting engine ready for production use?


Not at all.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, Andrew Brunner wrote:


On 11/30/2013 02:08 AM, Martin Schreiber wrote:

How MSEifi-remote works: -


That's not how it *should* be done.  Any logic code that can be executed 
should be executed by way of the client.  If you use HTTPS as the transport 
mechanism, you can assume code is secure and just execute it.


The more server off-loading the better.  Data submission is important and 
validation should be done on the client side with some framework safety 
checks before posting transactional data to the backend-database.


I don't think Lazarus should follow this particular mantra.


Exactly.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[vfclists .]

On 30 November 2013 13:28, Andrew Brunner  wrote:

>
> On 11/30/2013 07:04 AM, silvioprog wrote:
>
>  2013/11/30 Michael Van Canneyt 
>
>> [...]
>> I want to program the browser itself. In Pascal.
>>
>
>  Hello Michael,
>
>  Why not use an existing webkit (like Qt or Chrome) and incorporate it
> into Lazarus? That would leave the responsibility for compatibility with
> HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for
> cross-platform etc. for the webkit.
>
>  Please see this nice project:
>
>  https://github.com/rogerwang/node-webkit
>
>
>
> What would it take - in the form of a bounty - to get a community wide
> project to get Lazarus a *real* HTML5 browser for OSX and Linux?  I assume
> windows is already just an Active-X component.
>
> Any ideas? I can't stress this enough that it's like living in the
> technical dark-ages without access to developing front-ends without rich
> text and more often for me  now, web apps.
>
>
>
I think I mentioned what your real problem was in the my previous response.

Most of  we want can be found in
http://www.elevatesoft.com/products?category=ewb&type=web. The developer
speaks of Linux version being in the works which could be because the
backend probably depends on Delphi. Delphi as usual continues to be Lazarus
and FreePascal's worse enemy.

My  own feeling is that getting the Lazarus form builder to generate Pascal
code rather than, or as well as the .lfm files  is the first step. Then
Javascript next, QML or whatever. The Delphi legacy is still hanging over
Lazarus. Phil Hess did something that could translate a subset of the
components in.lfm files into Javascript some years ago and that may be a
start.

-- 
Frank Church

===
http://devblog.brahmancreations.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [ANN] FPSpreadsheet date support - success story

[Reinier Olislagers]

On 27/11/2013 09:43, Reinier Olislagers wrote:
> I've looked into adding date/time support for BIFF8/XLS and seem to have
> it working.
> As long as I'm busy with fpspreadsheet, I'm incorporating some other
> fixes I had going and added an FPCUnit test suite to check against
> regressions.
> 

Uploaded patch+new files to
http://bugs.freepascal.org/view.php?id=25388

Changes with previous version
- updated/added tests, added command-line test
- don't raise an exception with overlong strings as it messes with
writing xls. Instead truncate to a safe value. Still better than
silently corrupting the file.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [ANN] FPSpreadsheet date support - success story

[silvioprog]

2013/11/30 Reinier Olislagers 

> On 27/11/2013 09:43, Reinier Olislagers wrote:
> > I've looked into adding date/time support for BIFF8/XLS and seem to have
> > it working.
> > As long as I'm busy with fpspreadsheet, I'm incorporating some other
> > fixes I had going and added an FPCUnit test suite to check against
> > regressions.
> >
>
> Uploaded patch+new files to
> http://bugs.freepascal.org/view.php?id=25388
>
> Changes with previous version
> - updated/added tests, added command-line test
> - don't raise an exception with overlong strings as it messes with
> writing xls. Instead truncate to a safe value. Still better than
> silently corrupting the file.
>

Very nice buddy! :)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Andrew Brunner]

On 11/30/2013 06:38 AM, Michael Van Canneyt wrote:

No.

Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all. Slow, not 
guaranteed to have a return etc. In short: wrong.


I want to program the browser itself. In Pascal.



Do you mean an embedded component that displays web pages?  Or do you 
mean a scripting project that takes lfm and pas units and build the app 
"on the fly"?


Is the pascal scripting engine ready for production use?


--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, 
music, and more.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Martin Schreiber]

On Saturday 30 November 2013 14:24:03 Andrew Brunner wrote:
> On 11/30/2013 02:08 AM, Martin Schreiber wrote:
> > How MSEifi-remote works: -
>
> That's not how it *should* be done.  Any logic code that can be executed
> should be executed by way of the client.  If you use HTTPS as the
> transport mechanism, you can assume code is secure and just execute it.
>
There is not so much program logic which must be coded. Most is done by the 
MSEgui components, the GUI anyway, then there is the whole palette of DB, 
data entry and data visualisation components.
If one likes one can use client side Pascal Script for the rest of the 
business logic if one thinks that it is save enough. The server merely has to 
send the form resources, scripts and data.

Although I must say that I still more like "real" applications. ;-)

Martin

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[silvioprog]

2013/11/30 Michael Van Canneyt 
>
> On Sat, 30 Nov 2013, silvioprog wrote:
>
>  2013/11/30 Michael Van Canneyt 
>>   [...]
>>   I want to program the browser itself. In Pascal.
>>
>>
>> Hello Michael,
>>
>> Why not use an existing webkit (like Qt or Chrome) and incorporate it
>> into Lazarus? That would leave the responsibility for compatibility
>> with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for
>> cross-platform etc. for the webkit.
>>
>
> You are missing the point, I think.
>
> The idea is not to create a new widgetset.
>
> The idea is just to be able to program in pascal, output Javascript.
>
> Using some kind of 'external' declarations would enable you to use Adobe
> Air,
> ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see
> fit.
>
> I am not making any assumptions on that.
>
> But, and this is what I miss in all other attempts mentioned here: I want
> to be able to program the browser WITHOUT necessarily having an application
> server running on a webserver.
>
> It must be possible to ship a HTML file and a Javascript file for a
> working application. That's it.


But that is exactly what the node-webkit does, however, using a webkit
ready, and without a HTTP server. But node-webkit uses JS, so the idea
would be to use Pascal. E.g., in a pseudo code, would be:

procedure TForm1.FormCreate(Sender: TObject);
begin
  webBrowser.load('hello');
  webBrowser.elementById('hello').on('onclick', @Button1Click);
  webBrowser.element('window').on('message', @Msg);
end;

procedure TForm1.Msg(wb: TWebBrowser);
begin
  ShowMessage(webBrowser.elementById('hello').value.asString);
end;


> Michael.




-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Andrew Brunner]

On 11/30/2013 07:28 AM, Michael Van Canneyt wrote:


But, and this is what I miss in all other attempts mentioned here: I 
want to be able to program the browser WITHOUT necessarily having an 
application server running on a webserver.


It must be possible to ship a HTML file and a Javascript file for a 
working application. That's it.


Don't forget browsers also have database storage now.  So some 
abstraction could be done there as well.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Andrew Brunner]

On 11/30/2013 07:04 AM, silvioprog wrote:
2013/11/30 Michael Van Canneyt >


[...]
I want to program the browser itself. In Pascal.


Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate it 
into Lazarus? That would leave the responsibility for compatibility 
with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for 
cross-platform etc. for the webkit.


Please see this nice project:

https://github.com/rogerwang/node-webkit



What would it take - in the form of a bounty - to get a community wide 
project to get Lazarus a *real* HTML5 browser for OSX and Linux?  I 
assume windows is already just an Active-X component.


Any ideas? I can't stress this enough that it's like living in the 
technical dark-ages without access to developing front-ends without rich 
text and more often for me  now, web apps.



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Sat, 30 Nov 2013, silvioprog wrote:


2013/11/30 Michael Van Canneyt 
  [...]
  I want to program the browser itself. In Pascal.


Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate it into 
Lazarus? That would leave the responsibility for compatibility
with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for 
cross-platform etc. for the webkit.


You are missing the point, I think.

The idea is not to create a new widgetset.

The idea is just to be able to program in pascal, output Javascript.

Using some kind of 'external' declarations would enable you to use Adobe Air,
ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see fit.

I am not making any assumptions on that.

But, and this is what I miss in all other attempts mentioned here: 
I want to be able to program the browser WITHOUT necessarily having an application server running on a webserver.


It must be possible to ship a HTML file and a Javascript file for a working 
application. That's it.

Michael.--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Andrew Brunner]

On 11/30/2013 02:08 AM, Martin Schreiber wrote:

How MSEifi-remote works: -


That's not how it *should* be done.  Any logic code that can be executed 
should be executed by way of the client.  If you use HTTPS as the 
transport mechanism, you can assume code is secure and just execute it.


The more server off-loading the better.  Data submission is important 
and validation should be done on the client side with some framework 
safety checks before posting transactional data to the backend-database.


I don't think Lazarus should follow this particular mantra.


--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, 
music, and more.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[silvioprog]

2013/11/30 Michael Van Canneyt 

> [...]
> I want to program the browser itself. In Pascal.
>

Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate it into
Lazarus? That would leave the responsibility for compatibility with HTML5,
CSS3, mp3 encode, webGL, file manipulation, , support for cross-platform
etc. for the webkit.

Please see this nice project:

https://github.com/rogerwang/node-webkit

It uses a embedded Qt webkit version, and is very easy to use. E.g.:
---
Quick Start

Create index.html:


  
Hello World!
  
  
Hello World!
We are using node.js document.write(process.version).
  

Create package.json:

{
  "name": "nw-demo",
  "main": "index.html"}

Compress index.html and package.json into a zip archive called app.nw:

$ zip app.nw index.html package.json

This should create a structure like this:

app.nw
|-- package.json
`-- index.html

Download the prebuilt binary for your platform and use it to open the app.nw
 file:

$ ./nw app.nw

Note: on Windows, you can drag the app.nw to nw.exe to open it.
---

It tested it in my Windows and worked like a charm:

https://www.dropbox.com/s/hx489n2oxruvf45/nwk.png

Adopting a webkit, we would gain a long time, because it already has all
hard implementation that a browser needs to work.

[...]
> Michael.


-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[vfclists .]

On 30 November 2013 08:08, Martin Schreiber  wrote:

> On Friday 29 November 2013 13:55:10 Michael Schnell wrote:
> >
> > MSEgui has a (supposedly not yet finished) extension called "ifi". Same
> > is supposed to provide a remote GUI via a Byte-pipe. Both the server and
> > the "user" end is a pascal program.
> >
> MSEifi-remote is still experimental because nobody made real applications
> up
> to now. Local inprocess MSEifi is used in production to separate user
> interface and business logic in MSEgui applications since years. IIRC I
> even
> made a MSEifi-remote demo-binary especially for you so that you could show
> the principle to your co-workers some years ago. ;-)
>
> How MSEifi-remote works:
>
> Martin
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>



The real issue here is not the future of the desktop, it is basically
Microsoft and Hardware manufacturers 'punking out' business developers
through FUD. The simple fact is that all the industry majors are
'frenemies' of developers, they pretend to be your friends and screw you
over afterwards. Saying that the desktop has no future is simply a side
effect of  the policies Microsoft adopted as a consequence  of trying to
turn itself into Apple.

The 'desktop' for Delphi developers where many FreePascal  come from
basically means Microsoft. It is a consequence of Microsoft trying to force
all sales through their App Stores like Apple does, which is insane as LOB
applications are not consumer applications that are sold through App Stores.

For example Delphi developers feel they are being screwed over by
Embarcadero, if they feel bad they should ask Microsoft developers how they
feel about Microsoft's policies concerning Silverlight, WPF, Windows 8 and
all those issues.

For business developers the main advantage of the Web is that it cuts down
support costs and eliminates deployment issues. The downside is that
HTML5/Javascript combination is not good enough, leaving Flash and
Silverlight. Then Apple refuses to support Flash, Adobe withdraws Flash
(but leaving Microsoft and Google to develop it their versions, ignoring
Mozilla who are doing Shumway) and Microsoft cancels further Silverlight
development. These were the tools that were supposed to enable desktop
software developers to transition to the web, so you see the desktop is not
the issue, the agenda of the industry majors is.

Mozilla has XUL which enabled cross platform development and they started
messing with it. Google has Pepper and they say are ceasing development
from 2014.

Linux would or should work, but when hardware device makers don't want to
release drivers it results in  substandard drivers compared with those
available for Windows and Apple machines.

This doesn't mean that the desktop doesn't have a future it only means that
developers have to think strategically and work out carefully what their
options are.


To summarize the situation:

1. Microsoft seems confused and has apparently lost direction in the sense
of how it supports its traditional developers, or how to support their
transitioning to the tablet and smartphone era.

2. Linux is not getting enough support from hardware manufacturers.

3. Microsoft, Google and Mozilla are disabling their browser plugin
systems, and where they are present requiring apps that use them to be
whitelisted, as successful cross platform applications, especially if they
can be purely browser based would cut them out of the commission loop and
minimize the benefits of their platforms uniqueness. Their basic agenda is
you can do anything you want on our platforms so long as we gain access to
your Javascript, minified, Google Closured, asmjs-ed, whatever and are able
to take out commission.

4. Moral of the story - stick to Linux, port it to your smartphones and
tablets, develop your own Web browser and develop your own plugin system
for it. You just can't depend on 'frenemies'.


-- 
Frank Church

===
http://devblog.brahmancreations.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Michael Van Canneyt]

On Fri, 29 Nov 2013, Marcos Douglas wrote:


On Fri, Nov 29, 2013 at 9:13 AM, Michael Van Canneyt
 wrote:



On Fri, 29 Nov 2013, Santiago Amposta wrote:



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"



That is exactly my plan:

1. Convert pascal to javascript.
2. Use the custom widget design capabilities of Lazarus to design the form.

Just like Morfik does/did, and recently Smart Mobile studio.

But only in Lazarus :)


As ExtPascal?


No.

Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all. 
Slow, not guaranteed to have a return etc. In short: wrong.


I want to program the browser itself. In Pascal.

It has been done before (Morfik), it is being done as we speak (Smart Mobile studio), 
only not by Lazarus/FPC. All the big blocks are in place, my next step is the translation 
of Object Pascal to Javascript. There are obviously some inherent limitations due to 
the browser environment (pointers and such) but this is not a real problem.


Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

[Martin Schreiber]

On Friday 29 November 2013 13:55:10 Michael Schnell wrote:
>
> MSEgui has a (supposedly not yet finished) extension called "ifi". Same
> is supposed to provide a remote GUI via a Byte-pipe. Both the server and
> the "user" end is a pascal program.
>
MSEifi-remote is still experimental because nobody made real applications up 
to now. Local inprocess MSEifi is used in production to separate user 
interface and business logic in MSEgui applications since years. IIRC I even 
made a MSEifi-remote demo-binary especially for you so that you could show 
the principle to your co-workers some years ago. ;-)

How MSEifi-remote works:

- Client is an application independent Free Pascal program with MSEgui/MSEifi- 
library. The client could be realized as browser plug-in (not done up to 
now).
- Server is a Free Pascal program with the necessary MSEifi connection 
components. The server needs no GUI library elements.
- The client joins the server by a byte stream connection, currently 
implemented are pipes and sockets.
- The server sends *.mfm data (the MSEgui equivalent of Lazarus form files) to 
the client. The form data can contain Pascal Script snippets if necessary.
- The client instantiates the forms/datamodules exactly the same as a normal 
MSEgui application would do -> look, feel and performance of the components 
are the same.
- Client and server use MSEifi data- and event-components which are linked by 
the MSEifi-remote protocol.

Example:

A user button click triggers firing of an event in a taction component by the 
tbutton.action property, the event is transported over the wire, triggers 
tnoguiaction.onexecute in the server, the server sends a modal form to the 
client, the client shows the modal form, the user enters data which will be 
sent to the data components in the server, the user closes the modal entry 
form, the modalresult will be sent to the server.

So for development of server, client or standalone applications the same 
MSEide+MSEgui RAD-approach can be used. While developping and debugging it is 
possible to run client and server in the same process with 
a "shortcut-connection".

Martin

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus