Recent

Author Topic: Can we use custom drawn LCL Widgetset to draw a form to an HTML5 Canvas?  (Read 445 times)

kveroneau

  • Jr. Member
  • **
  • Posts: 53
I must say FPC/Lazarus is turning into a mighty powerful language/tool, it is offering so much out of the box(or a small download away), I am still baffled at why ObjectPascal and Lazarus hasn't received more attention from mainstream developers.  Maybe it's more popular in Europe, while here in the west it is more seen as a legacy language from the past.  Anyways, back to pas2js!

I noticed that work is being done to potentially allow Lazarus forms to be brought to the web through a few different projects.  Last night I had an idea which might work as method to bring LCL Widgets to the web with as little friction as possible.  If I had better understanding on the LCL, and how pas2js actually transpiles, I might work on this myself.

The basic idea here is to use HTML5 Canvas technology to draw the LCL Widgets as we do in some other platforms using custom drawn.  If we could get custom drawn to draw it's widgets onto an HTML5 Canvas, and set the appropriate events onto the HTML5 Canvas, it could easily act as as form.  While this approach will not keep the general look-and-feel of a typical web form, using LCL Widgets on top of an HTML5 Canvas gives us access to a wider array of widgets which would otherwise not be possible in pure HTML forms.  Since the main idea of pas2js is to create Web Applications using pascal, and every consumer browser supports HTML5 Canvas', and we don't really need to support say Lynx, I don't see why using an HTML5 Canvas for rendering the LCL Widgetset a problem.

I have two potential solutions on how it could be rendered.  The most ideal way, and one which could be quicker is to have a Unit in pas2js which has procedures which work with LFM files directly.  The sole duty of this Unit is to parse an LFM file and render it to a HTML5 Canvas, and then attach the events within the LFM to their transpiled JavaScript code.  The other solution is much more aligned with how Lazarus currently compiles machine code, where the LFM is transpiled into JavaScript to render our HTML5 Canvas and connect the callback events.

In theory, this should allow some basic Lazarus programs which don't use IO or sockets, such as a text editor/view, a calculator, and other simple programs to be cross-compiled in pas2js with minimal code changes.  It would be nice if in the future pas2js could work with server-side code, or even generate a server-side Pascal application automatically based on the code.  There are also tools which allow regular socket connections through HTML5 WebSocket connections, but this wouldn't be ideal for say database programs, you would want some sort of server between the web application and the database for security reasons.

In the far future, I'd love to see GLES Lazarus programs be easily ported to WebGL, but one can only dream.

howardpc

  • Hero Member
  • *****
  • Posts: 2989
...The most ideal way, and one which could be quicker is to have a Unit in pas2js which has procedures which work with LFM files directly.  The sole duty of this Unit is to parse an LFM file and render it to a HTML5 Canvas, and then attach the events within the LFM to their transpiled JavaScript code.
You use the verb "render" in an unusual way. An LFM is not a picture file. It is a data file which identifies particular widgets (which are declared elsewhere) and specifies their initial properties and the names of the events to be attached to them (also declared elsewhere). None of the widgets specified in an LFM are anything to do with HTML of any version.

mattias

  • Administrator
  • Full Member
  • *
  • Posts: 133
    • http://www.lazarus.freepascal.org
First of all you have a right idea, that the HTML5 canvas is powerful enough to render components. TMS is doing that for many of their components. And TMS Webcore works in Lazarus too. Yes, you can use the Lazarus designer to create webapps.

About the LCL:
First the LCLBase needs to be ported to pas2js. For example it must support UTF-16. It also uses some generics, which I hope to get working in a few months in pas2js.

About LFM files: These files only contains property values. Lazarus provides ways to store the form data as Pascal statements. There are some todos left, but basically you can consider this issue as solved.

About "a Unit in pas2js which has procedures...to render it to a HTML5 Canvas, and then attach the events":  That's basically what a widgetset is doing. Keep in mind that many LCL components are custom drawn.


kveroneau

  • Jr. Member
  • **
  • Posts: 53
I am aware that an LFM file isn't a picture file as much as an SVG, LaTeX , and PostScript isn't a picture file, but has a strict definition of how to display it's content into a picture buffer, with LFM having additional definitions of how these elements should interact, and how they should be displayed/rendered.  I apologize for the confusion there.

I am glad to see that this has been through of, and look very forward to using this feature of being able to create my Lazarus Web Application entirely in a RAD environment.  I do not believe any RAD capable languages even support this entirely.  If Lazarus can pull this off and allow almost any LCL Widget to be drawn onto an HTML5 Canvas and also be fully interactive, it will place Lazarus in a very interesting position within the Web Development community.

At the current moment, FPC/Lazarus is my go-to language of choice for anything to do with cross-platform development just because of how seamless it works compared to competing technologies which require a lot of rewriting or using a huge runtime environment.  FPC/Lazarus has a huge advantage here, and now with native Android app development in the mix, this is basically an all-in-one solution for almost any problem.  Need a scripting language, FPC has InstantFPC, need to build an application that keeps the native widgetsets of both OS X, Windows, and Linux?  You got Lazarus.  Need to be-able to run a console application on both your Desktop Linux and on your Raspberry Pi?  FPC has you covered there too.  No other language toolkit can really offer such diversity with such minimal overhead.  Java requires the JVM to exist on your target, and doesn't tend to run well on embedded devices.  .NET requires the CLI runtime on the target, and Mono still has many limitations on non-Windows systems.  Sorry for praising FPC/Lazarus so much, but it has truly become a great piece of incredible software which is constantly innovating and evolving to modern computing needs.