It's a little off-topic, but as the comment was asking about pascal and lazarus, I will put it here:

In a Spanish blog, a fresh graduated asked about what programming languages should learn. People post their opinions, and someone asked "What about delphi/object-pascal/freepascal/lazarus? Nobody has mentioned it and we use it a lot in Argentina"
http://empleo.barrapunto.com/comments.pl?sid=90556&cid=1350850

INHO, the reply was very interesting:

"I used to program a lot in Object pascal at the end of XX century, and maybe until 2003. But since then I have had very little chances of using Object Pascal. And only when I could choose the tool. Last time I used it was a day I decided to evaluate Lazarus.
Desktop applications are declining. On a hand we have a lot of new devices that usually use Java, Objective-C, and on the other hand we have Web applicationes. So desktop applications are in small niche, like its development tools.
Here is an example: A friend of mine works for a company that has been hired by a bank to rebuild the workstation software. Now client are running on XP and the software is written in .NET (and VB4!!!). The are moving to client software running in a local server written in PHP and workstations with a browser with a lot of javascript. The Operating system of clients and its hardware becomes irrelevant. IT is always changing, but the change that is coming is deeper than usual."

I still work a lot with native desktop, but recently I asked about the options to change the interface to web with ExPasJS etc. I'm afraid we are moving to that.

Native GUI is the best... but "native" has become a moving target. Now we have many devices, we use remote connections more that a few years ago, so we don't know what is in the client side. Even windows, the most extended desktop, changes its GUI from version to version, so many times you are forced to redesign the interface of your applications. It would be wonderful if we could have a standard GUI for every device/operating system. There have been several attempts (Freedesktop, Fresco) etc.
The one we have now is HTML+Javascript, it's ugly, it's slow, it's a lot of bad things, but it's a standard. Look what ever device you want and there is a browser. That's why there are many tools that make extensive use of javascript like Gnome Shell (even a full OS like FirefoxOS) .

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.

Santiago A. wrote

Perhaps Lazarus should start thinking about a widget "html+javascript" and prioritize it.

Even if I would agree you on the general direction, this would be dumb IMHO, since compatability of such thing would be low and the LCL structure only something to fight against. It is a common pattern that such transitional techniques never make it in the long run.

If you want a Pascal webframework, create a Pascal webframework, and independent (designer etc) plugins for Lazarus as needed.

As for Lazarus, lazarus relies on volunteers that can't be directed. If you want a change in direction, provide the manpower that does it, it is as simple as that.

I agree 100%. I have spent the last 4 years or so in development of such a system.

Aurawin includes virtual desktop platform that is open source. It's lacking a cloud development environment. Presently, all application development is done via the CMS system via the GUI console. The back-end is all FPC-Lazarus. I'm adding JavaScript and FPC Script support to the engine so the core objects don't need to be re-compiled and restarted.

Downloads App : https://aurawin.com/downloads/
AuVDM is the source to the Aurawin Virtual Desktop AuSCS is the server that the VDM needs to installed on.

This is the syntax editor I'm planning to use for the AuIDE App :

https://aurawin.com/core/vdm/editor/editarea_0_8_2/exemples/exemple_full.html I'm looking for syntax editors in HTML5. If you know any I would be happy for the info.

Anyways, let me know what you think. I'm still looking for market validation ;-)

Santiago A. wrote

Perhaps Lazarus should start thinking about a widget "html+javascript"

Some years ago I did some (limited) testing on that behalf, but gave up after some days, seeing that the necessary effort is not do hope that Michael v C is more successful.

At home I have a NAS by QNAP..
Since the latest update it features a really nice HTML GUI.

It nicely can do forms and many Lazarus-like GUI elements and -functions, and it can show status changes really fast (which is not easy with a HTTP-connected, browser-based GUI).

I do suppose, they use a "standard" "widget set" for this (EXTJS or something), but I never saw such a thing working this great.

No idea how they designed the GUI. It is so complex that I would be astonished if they did not use a GUI designer tool for this.

If Lazarus would be able to offer such a capability, driven by the standard GUI design tool (of course taking some limitations into account in that mode), this would be a major argument for doing embedded application with Lazarus. (This was why I did the research at that time.)

-Michael

These days it is very easy to make a very responsive web gui.

Michael.

2013/11/28 Michael Van Canneyt

The Lazarus team could think of something like this:

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

Currently, I and my business partner, we are using hybrid systems, i.e: some APIs maked with Brook and FCL (both FastCGI and embedded HTTP server), and being consumed by applications written in Delphi (desktop/Android) and Kendo UI (HTML5, CSS3 and jQuery). But, soon, we are thinking of abandoning our Delphi applications and definitely adopt Node.js. And from what we are seeing, our decision is not random, it has big company considering leaving Java, for example, to adopt Node.js:

https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal

But, in future, If it would be possible to render HTML5 + CSS3 + jQuery screens in a LCL form, even using a webkit of third party, we would realizing a old dream: have nice applications in HTML+JS, such JavaScript already have, with Node.js.

Below, some screen shot of our initial application, it is pure Brook ( http://brookframework.org), Bootstrap (http://getbootstrap.com), Kendo UI ( http://www.kendoui.com) and PostgreSQL (http://www.postgresql.org) and, in future, a desktop version written with Node:

https://www.dropbox.com/sh/saobeixb4p1uxvx/0EIPPqAj43

Sorry for my ugly english please. ;)

I think you've just answered yourself -> IT is always changing. There's no need for LCL to have web-support at all! Developers are actually selecting PHP (or other web-server) platform.
Even if LCL will start "web target" today, it will be 10 years later that LCL can be used without problems.

By the time, the down spiral of IT evolution will popularize desktop applications again! (this there HTML5 is going - lets upload all the script to the client and execute there :) ... and Lazarus will have to switch back to "native system controls" :) - in whatever forms they are.

Since everyone else is switching to "web frameworks", Lazarus should stick to OS nativity. In the end, it will remain the only option and it will boost its popularity :)

Is LCL the only "native controls" cross-platform framework left? Everyone else are now "custom drawn" (Qt and Gnome) or not cross , Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131128/552b06c1/attachment.html>

Both Borland and Netscape (later Sun) had visual HTML/Javascript builders, both got buried. Part of the problem was that both assumed that the backend would be their own database and transaction manager, and we all know how much corporates like to charge for that sort of thing once they've got their foot in the door.

If you're designing a headless system like a NAS, then the terminal type that you can rely on people having is pretty limited: an HTML browser or a VT-100 terminal (including telnet). A significant advantage of this approach is that with care it can be designed to do something sensible even if the client can't or won't run Javascript or Java, other alternatives such as a desktop app served by VNC fail dismally by comparison.

Once you're talking about an app that runs on the desktop or handheld system then the rules are completely different. Perhaps we can make a difference by constantly reminding people that it's still possible to write portable apps for that environment, and that there can be significant performance advantages doing so.

The sad thing about HTML that it is destroying itself. A web-framework consists of probably 4 tags:
<div> (everything is a div)
<a> (just for browser look)
<input type=hidden> (and yes, every other control is just a div, rather than an input)
<img> is to be replace by <canvas>
Forms are being used just as an ad-hoc data sending mechanism. No-one relies on browser implementation (due to the war), just write its own JS engine.

Let's wait for an alternative to the web as it is right now :) (some other scripting+code language than HTML+JS, that will satisfy glam-looking requirements better?)
...or build one using Lazarus.

thanks,
Dmitry

On Thu, Nov 28, 2013 at 11:40 AM, Mark Morgan Lloyd <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131128/65ecbb2b/attachment.html>

That's over-simplifying the landscape. There is so much tweaking that has to happen to make apps have a similar "look and feel" across all HTML devices. Spacial adaptations need to be considered as well.

HTML is not destroying itself. I still use raw text to write HTML5 apps. If you organize your app code into components it makes for easier comprehension and review down the road.

Andrew Brunner wrote

That's over-simplifying the landscape. There is so much tweaking that has to happen to make apps have a similar "look and feel" across all HTML devices. Spacial adaptations need to be considered as well.

Is it over-simplification? I agree or "simplification" but not "over" Here's QNAP (mentioned earlier) web-interface demo: http://www.qnap.com/en/?lang=en&sn=934
Just login and look to the code of the page ;)

I'm in gmail web interface and I'm looking at page source. ...well yes... <table>s are being used also :)

Any way, Lazarus is good and shiny!

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131128/4a89af32/attachment-0001.html>

* I agree on "simplification" but not "over"

On Thu, Nov 28, 2013 at 12:31 PM, Dmitry Boyarintsev <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131128/128bf2fe/attachment.html>

Dmitry Boyarintsev wrote

Here's QNAP (mentioned earlier) web-interface demo: http://www.qnap.com/en/?lang=en&sn=934 Just login and look to the code of the page ;)

Ooops, missed that one. I really wanna get the server for ARM compiled and advertise that to hobbyists. No social capabilities with QNAP though.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131128/99606719/attachment.html>

If you're designing a headless system like a NAS, then the terminal type that you can rely on people having is pretty limited: an HTML browser or a VT-100 terminal (including telnet).

ACK

As long as this model is based on a (more or less) portable widgetset, I see no real difference vs. an browser (HTML) widgetset. What may make things complicated are LCL assumptions about nested widgets and layout management, which may be unavailable or different in a browser and HTML documents.

DoDi

El 28/11/13 17:39, Dmitry Boyarintsev escribi?:

Even if LCL will start "web target" today, it will be 10 years later that LCL can be used without problems.

If that's is the schedule, nothing makes sense.

Since everyone else is switching to "web frameworks", Lazarus should stick to OS nativity. In the end, it will remain the only option and it will boost its popularity :)

Lazarus allows you to write applications with several common widgets. Now html+javascript has become very common (more than cocoa, for example), so it is a good idea to think of it.

Is LCL the only "native controls" cross-platform framework left? Everyone else are now "custom drawn" (Qt and Gnome) or not cross don't want to use Lazarus because it is the last defender of "Native

controls" against the evil "web-controls". I want to use Lazarus because I want to use a powerful language like Pascal in the backend and a framework with a RAD that allows me write GUI interfaces quickly.

Santiago A.

Then go ahead. Lazarus does allow creation of backends. They just having to do with LCL.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131128/c710f775/attachment.html>

Michael Van Canneyt wrote

These days it is very easy to make a very responsive web gui.

"Responsiveness" (the program reacts to user input) is not the problem I meant to describe but the ability of the program to issue "state" messages spontaneously.

This is hampered by the missing symmetry of the http protocol: The client needs to poll for such "reverse" messages.

This can partly be improved by techniques like "comet" that leave a http protocol open in a somewhat "non-standard" way. But AFAIK, this does result in certain problems.

I don't know how the QNAP box works on that behalf. But in fact it looks like doing a great job.

-Michael

The old version of the QNAP box hat a standard HTML-interface (pure HTML widgets, thus simple CGI stuff).

With the new version they converted to a "remote GUI" in the browser (thus the functionality is within the box, while the remote GUI implementation is completely independent from the functionality).

I do suppose they did this for a reason :-) .

In fact the remote GUI implementation uses a huge java script library that the browser pulls when starting the work on that page.

-Michael

Given that the average user has a reaction time of 1 second, polling every second is really not an issue.

It makes no sense to poll every 1/100 of a second if the eyes (let alone the brain) of the user cannot follow.

And if you really, really, need speed: websockets are a standard part of browsers these days.

Michael.

Michael Van Canneyt wrote

Given that the average user has a reaction time of 1 second, polling every second is really not an issue.

OK. As you seem to have done a lot of research on that, I am looking forward to what you are going to come up with.

Thanks for your work,
-Michael

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 :-) :-)

-Michael

Santi wrote

I don't want to use Lazarus because it is the last defender of "Native controls" against the evil "web-controls". I want to use Lazarus because I want to use a powerful language like Pascal in the backend and a framework with a RAD that allows me write GUI interfaces quickly.

Yep.

Because it wants to provide RAD, the LCL GUI designer is one of the most easy to use GUI designers. I once failed on trying to find an "active" web page designer tool that comes anywhere close regarding user friendliness.

Thus for me a "Web GUI" LCL Widget type makes a huge lot of sense (even if the count and features of the widgets usable in this mode is restricted vs the "local" widgets.

In fact it should be possible to switch between "Web GUI" and "local GUI" just by setting the Widget type variable. Decent messages for stuff that does not work on the WebGUI appreciated.

Something similar once had been tried with "EXT Pascal", but AFAIK, the project died.

-Michael

Dmitry Boyarintsev wrote

Then go ahead. Lazarus does allow creation of backends. They just having to do with LCL.

The problem is not that it does not make sense. The problem is that it is a huge task.

-Michael

It appears that around 50% of our external network traffic is caused by a colleague who leaves a significant number of browser windows open each with Javascript which periodically polls for server-side updates.

Almost anything is better than getting tarred with that brush.

This can partly be improved by techniques like "comet" that leave a http protocol open in a somewhat "non-standard" way. But AFAIK, this does result in certain problems.

That goes back to some of the earliest Netscape versions, IIRC it was originally used to update images periodically. While attractive, this sort of thing can turn into a nightmare if the browser on an end user's system leaks memory until an entire page (i.e. not just part of the DOM describing the page) is forcibly reloaded- BTDT.

El 28/11/2013 15:01, Michael Van Canneyt escribi?:

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?

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 :)

Michael.

Do we still need to take into account that a browser is that limited ? Browser technology has advanced a lot during the passed few years.

As HTML5 is a strong recommendation for "active" web page programming I find it hard to believe that spontaneous server-initiated messages is not cared for in any decent way with modern servers and browsers.

-Michael

WebSockets is the standardized solution for this.

Regards,
Sven

Sven Barth wrote

WebSockets is the standardized solution for this.

WebSockets seems to be here to stay, thus having the Lazarus backend communicate with a HTML5 / Java Script GUI front end seems like a very promising way to do do a remote GUI that might be rather close to what is possible with locally the LCL.

-Michael

"Do we have to take into account that a browser might have bugs?"

Probably.

"Do we have to take into account that somebody might run a browser older than we like supporting?"

Partly: at the absolute minimum to give him a sensible error message, and ideally to provide some sort of usable UI even if it lacks the "bells and whistles".

El 29/11/2013 12:13, Michael Van Canneyt escribi?:

So, you don't plan to create a new widget in LCL for html+javascript, but an utility that process application source and generates a big javascript.

Santiago A. wrote

So, you don't plan to create a new widget in LCL for html+javascript, but an utility that process application source and generates a big javascript.

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.

After compiling the user program to HTML5 via Smart Mobile Studio we could theoretically have a remote GUI.

-Michael

Pulling all those assets into a browser means that they have optimized their vdm for speed not size. I know at present I need over 120MB of storage for assets. For embedded systems I wonder if that is a rather large requirement.

In fact the remote GUI implementation uses a huge java script library that the browser pulls when starting the work on that page.

In order to do that they must have a development branch that keeps assets separate. With Aurawin SCS I have 2 domains. I use directory templates and keywords to manage different "boot" modes for each domain that has the EXACT same file base. This way daily.aurawin.com under Chrome shows me exactly what I'm looking at. Without that, development is a MAJOR PITA.

I wanted to make 2 points here...
1.) This can be mitigated with existing HTTP protocol if you have control over the server. For instance, with Aurawin SCS if a request comes in with access to the "core" I set a flag in the sockets engine that says keep this socket stream infinitely open. This way HTTPS re-negotiation is a thing of the past, and requests are instant. 2.) Your web browser is key here. Chrome keeps socket sessions cached. So more often than not there already is a connection made. Meaning in the JS code, if you say XMLHTTPRequest(/server/core/command) it just creates a string and sends it to the server. That XMLHTTPRequest does not imply a new HTTP connection.

This can partly be improved by techniques like "comet" that leave a http protocol open in a somewhat "non-standard" way. But AFAIK, this does result in certain problems.

"Non-standard" is a subjective term. However, there is presently WebSockets that standardizes HTML5 event driven socket communication to exactly address this entire point.

I've made myself such web widget set, which have the same API as LCL. Thus its simple to recompile desktop application to gain web application

its huge (>1000 forms) program which is use by hundreds user day by day . I've mention about it a few times, i work with it from years, and I think that HTML5 + Pascal is the best tool to web application.

No time perception is under 300ms.
No one controls must wait to response from server to change its look, this do JS lying under each. But of course, each user action is transmitted to server and respond carry information of look other controls. In other words: each control take care only of itself, no business logic is include in JS, rest is done by server.

This is outlined, as I do: 95% in pascal and 5 in JS+CSS+HTML

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"

I dont send JS for controls, only some HTML like (real copy) <td colspan="2" xcol="19"><div id="dfaF5FB9B20" class=" fieldhint fieldliczba"><input id="faF5FB9B20" type="text" onchange="return chk('aF5C5E030','faF5FB9B20');" value=""></div></td>

rest is done by JS + CSS
by the way: CSS id great, allows for separation of look and behavior, its far better than LCL

This is not problem. Today network is fast, sending packet information under size of frame (<1400bytes) has no overhead.
Pooling : only 1 request for 15 s, its under 0.001% overhead.

Much difficult is architecture of HTTP server. I need modal windows, thus I use 3 levels of thread. If add logging, timers or background task then levels count. But its work the same as on desktop (only nicer)

Darek

Could You mention this problems?

Darek

RAD is only small addition. I use Delphi from several years and don't use RAD (design forms by mouse). And many professional developers drop RAD and made forms in code.

Thus for me a "Web GUI" LCL Widget type makes a huge lot of sense (even if the count and features of the widgets usable in this mode is restricted vs the "local" widgets.

Some times (and increasingly) they are much powerful: 3d look, textures, animated, structural hints etc.

In fact it should be possible to switch between "Web GUI" and "local GUI" just by setting the Widget type variable.

This is background

Decent messages for stuff that does not work on the WebGUI appreciated.

I think that 99.9% code may work on proper WebGUI
This is then same like switch form Intel to ARM or to x64. When library/compiler developers take care, rest can no/small worry about it.

Darek

As ExtPascal?

Marcos Douglas

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

No.

Extpascal does wat mseide does. Transport everything back to the server. That is completely the wrong approach. Not , 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.

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'.

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:

<!DOCTYPE html><html>
<head>
<title>Hello World!</title>
</head>
<body>
<h1>Hello World!</h1>
We are using node.js <script>document.write(process.version)</script>. </body></html>

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.

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?

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131130/f676f005/attachment.html>

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.

Exactly.

Michael.

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

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?

.

2013/11/30 Michael Van Canneyt

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('<html><div id="hello">hello</div></html>');
  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.

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.

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

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

Michael.

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/

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.

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

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.

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.

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

Marcos Douglas

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.

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 <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131201/6e0be59d/attachment.html>

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.

I'd say that the problem resides in the adaptation of the (given) VCL interface to multiple widgetsets. Some widgetsets fit better into this model than others do.

We could try something like Borland tried to achieve with CLX, and construct an subset of the LCL functionality that makes less assumptions about window/layout managers and built-in functionality of the basic controls. Unfortunately it's not sufficient to simply *not use* features not available in a certain (HTML...) widgetset, as long as the LCL controls use (and consequently rely on) such features internally. One solution could try to "outsource" specific features, i.e. move them into dedicated classes which can be overridden as suitable for every supported widgetset. This would allow to fully disregard properties or other programmatical requests internally (in the dumb base classes), without causing consequential errors. But it looks impossible to me, to separate all problematic functionality from the existing LCL. A complete refactoring would be required (too complicated), or a restart from point zero (who would be interested in doing that?).

DoDi

Martin Schreiber wrote

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. ;-)

This is why I dared to mention it right now :-) :-) .

-Michael

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

If course I do remember very well, how ifi works. For me, it is a really great idea to decently physically separate the "business logic" from the GUI without completely loosing the "RAD" features Delphi, Lazarus and mseGUI provide. At best you could develop the program with a local GUI and then set a switch to compile it as an ifi Server.

Regarding the OP's question:

I suppose regarding ifi "socket" includes "WebSockets". So the server site seems to be in place.

As the "ifi" byte stream is well defined, it should be possible to do the server and the client in different languages/environments. Thus as a client "Browser plugin" you could do a pascal program, which seemingly would be rather easy to do, but would need installing it at the client site, which in some environments (we did get burnt :( ) is impossible due to IT guide lines (aka incompetence).

Thus other ways could be considered:
- compiling the pascal code with Delphi Prism to a CIL plugin and use Silverlight / Moonlight to run it in the browser sandbox.
- re-implement the client site of the library in java script.

-Michael

Dariusz Mazur wrote

Could You mention this problems?

I did not do tests myself, but when researching I was told that some Web servers would kill the connection to the client and/or the fast-cgi and would not recover decently.

At that time I did not know about WebSockets. This now seems mere like the way to go. So I would not invest more effort in Comet.

-Michael

vfclists . wrote

The 'desktop' for Delphi developers where many FreePascal come from basically means Microsoft.

AFAIK, the mother of the Desktop is X11, which IIRC was invented by Xerox (for headless Unix boxes).

Using the siblings of same, we now have KDE and GNOME (and several more) in Linux.

So IMHO Microsoft was a copycat (as always) but very successful (as always).

-Michael

Michael Schnell wrote

AFAIK, the mother of the Desktop is X11, which IIRC was invented by Xerox (for headless Unix boxes).

X11 isn't the mother of desktop according to:
http://en.wikipedia.org/wiki/X_Window_System#Predecessors

"X originated at the Massachusetts Institute of Technology (MIT) in 1984."

"Several bitmap display systems preceded X. From Xerox came the Alto (1973) and the Star (1981). From Apollo Computer came Display Manager (1981). From Apple came theLisa (1983) and the Macintosh (1984). The Unix world had the Andrew Project (1982) and Rob Pike's Blit terminal (1982)."

Andrew Brunner wrote

If you use HTTPS as the transport mechanism, you can assume code is secure and just execute it.

Seemingly this is not good enough and that is why WebSockets seems to replace Comet.

-Michael

Andrew Brunner wrote

The more server off-loading the better.

This was the idea behind Silverlight.

But seemingly Silverlight is not actively supported any more, which IMHO makes the idea of C# / CIL / .net rather senseless (obsolete).

-Michael

Michael Van Canneyt wrote

Extpascal does wat mseide does. Transport everything back to the server. That is completely the wrong approach. Not really scalable solution would have to provide both:

- just compile the normal Lazarus / mseGUI based program and with a simple compiler switch
- allow for running selectable parts of the application at the user site.

This is what Microsoft intended by C# / CIL / .NET / Silverlight but seems to have dumped due to the overwhelming success of Java / Java Script in the mobile world.

In fact mseIFI seems to intend to provide the scalability by allowing for Pascal Script at the user site.

If your effort allows for compiling pascal to Java Script this might be even better at the client site, but IMHO this is not an argument against the "ifi" way of communicating between client and server, as IMHO it makes a lot of sense to allow for gradually migrate parts of the "business logic" code from server to client without much porting effort.

-Michael

+1

(so your idea would be a nice option to do javascript stuff even with no gui actions involved)

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

:-) :-) :-)

lost in translation:

simple compiler switch ... convert it (e.g.) in a cgi with a browser based remote GUI.

-Michael

The mother of the /desktop/, i.e. with printer and trash icons displayed, is the Xerox Star, but X is a completely distinct lower-level. If you want to compare Xerox's desktop ideas with anything then you should be going directly to KDE and Gnome, and leaving X out of it.

X came from MIT, which means that in principle at least it inherited from some of the very earliest multiuser work while Xerox was more oriented towards singleuser workstations (some of which were physically big, as I understand it their Artificial Intelligence Workstation was a full 19" rack).

Using the siblings of same, we now have KDE and GNOME (and several more) in Linux.

Careful there, I think you're at risk of mixing layers again. Qt and GTK are normally implemented on top of X11, although Qt also has a fairly wide selection of other substrates. GTK is also being forced in that direction since a number of players- particularly Ubuntu- are experimenting with graphical subsystems which provide roughly the same services as X11 but are designed from the ground up with a different emphasis (e.g. single-user with no provision for serialising the API over the LAN or a pipe).

So IMHO Microsoft was a copycat (as always) but very successful (as always).

But reminding people who are devoted to their products of that particular point is not always helpful :-)

Mark Morgan Lloyd wrote

I think you're at risk of mixing layers again.

Of course you are absolutely right and I do know this.

But I replied to Microsoft being the inventor of the desktop we are using. And Microsoft does not use a (publicly) defined X layer but that layer is an integral part of what is perceived as the thingy that holds the programs' GUIs (and might be called "Desktop").

-Michael

"Michael Schnell" wrote

But I replied to Microsoft being the inventor of the desktop we are

using.

Let's look at what you replied to:
On 11/30/2013 01:44 PM, vfclists . wrote:

The 'desktop' for Delphi developers where many FreePascal come from basically means Microsoft.

So where did vfclists write that Microsoft invented the desktop? He just said that for Delphi developers (what quite some FPC users are or have been) the desktop means Microsoft. At least until XE2 with OS X support appeared.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131202/1a1d8569/attachment.html>

The first MS desktop was GEM, borrowed from Digital Research borrowed from Apple, I used it also on my Atari ST. License issues forced MS to create something slightly different, named Windows. The major difference of Windows (vs. GEM) is the added messaging system, with message pipes and loops, which turned the GEM event polling model upside down. Next come menus, which were moved from the screen into forms. The rest is technically almost the same, with only a different look to convince judges in defense against Apple and DRI claims.

DoDi

Michael Schnell wrote

If your effort allows for compiling pascal to Java Script this might be even

do you mean "java" or "javascript" above? ;)

Actually, Microsoft has nothing to do with GEM, it was made by Digital Research. Also technically GEM is/was very different from Windows (GEM relies on interrupts and can run only a single program while Windows was multitasking from the start, GEM apps can be made by any DOS compiler that can issue interrupts and has the necessary header files, Windows apps require special compilers, etc). You can check FreeGEM for an up to date version (the source code of GEM was released a while ago and some people fixed bugs and added a few features).

Both Microsoft and Digital Research were sued by Apple when their systems were released. DR decided to modify their 'desktop' program to disallow overlapping windows and removed the trash can (previously it looked very similar to Mac Finder) while Microsoft decided to counter Apple's claim. In fact Windows 2 was even more like Mac (overlapping windows vs Windows 1's tiled windows, more Mac-like colors, etc) and AFAIK even when Windows 3 was released, they hadn't settled yet on the case.

Check http://toastytech.com/guis/guitimeline.html for a timeline, some history notes, screenshots, etc of various GUIs over time, from the first Alto to Windows 8.1 The site is slightly biased against Microsoft, but the historic comments are good. I've read about Microsoft's and Apple's history from a couple of books too (i like computer history) and i think whatever mentioned there is mostly right. I haven't checked everything in the site though and i believe it misses some aspects (f.e. Lisa introduced more than just pulldown menus - f.e. the whole concept of finder was something new at the time and Andy Hertzfeld's book on the development of Macintosh has images from other prototypes that show how much the Mac and Lisa teams actually came up with that today we take granted).

We need a desktop development history page on the wiki. It is not FPC or Lazarus related, but something that's interesting to read for a developer :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131202/8ca7596e/attachment-0001.html>

Actually, Microsoft has nothing to do with GEM, it was made by Digital Research.

Right, but it was the first desktop presented by Microsoft.

Also technically GEM is/was very different from Windows (GEM relies on interrupts and can run only a single program while Windows was multitasking from the start,

I'm not sure what GEM has to do with multitasking.

GEM apps can be made by any DOS compiler that can issue interrupts and has the necessary header files, Windows apps require special compilers, etc).

I don't see a need for an special Windows compiler. The only requirement is a linker that links the resources into the executable. This was a separate program for a long time, in addition to the compiler and linker.

DoDi

Michael v.C. said:
"That is exactly my plan: 1. Convert pascal to javascript...."

(or did you just stumble at the capitals and blanks ? )

-Michael

That history has gone full-circle, and the NEW DESKTOP APPS (for Windows 8 Metro) are predominantly full screen...

And the [GEM/DR/?] idea of menus on top of screen also makes a come back in Ubuntu... and IIRC Gnome3.

[...]

DoDi

-L.

That history has gone full-circle, and the NEW DESKTOP APPS (for Windows 8 Metro) are predominantly full screen...

And the metro look itself with the buttons as a plain flat rectangle are like they are from Windows 1.0 Very ugly IMHO.

"Lukasz Sokol" wrote

And the [GEM/DR/?] idea of menus on top of screen also makes a come back

in Ubuntu...

and IIRC Gnome3.

Considering Mac OS: were they ever away?

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131203/7a2375f3/attachment.html>

Hans-Peter Diettrich wrote

Right, but it was the first desktop presented by Microsoft.

No it wasn't. GEM was presented by Digital Research, Microsoft had nothing to do with it.

I'm not sure what GEM has to do with multitasking.

You said that they were technically similar, which isn't the case. Multitasking was an example of a major technical difference they had.

Windows (Win16) executables are a different format and while a linker *could* do it, a windows-aware compiler is still needed. The Win16 calling convention is (was) different to whatever DOS compilers used (usually compilers used their own). Windows was doing software-based virtual memory management and would unload parts of the program by unloading functions and patching the memory where the function was make a system call for loading them back (so running code that tried to call the function would continue to work). The compiler had to know about that do make proper prologs and epilogs. Also AFAIK callbacks required special handling too.

Some notes are given in
http://www.openwatcom.org/index.php/Exploring_Windows_3.x but that is mostly Win3.x specific. There some notes about Windows 1.0 and Windows 2.0 in Raymond Chen's "the old new thing" blog, but i can't find specifics right now.

Michael Schnell wrote

(or did you just stumble at the capitals and blanks ? )

yes, exactly and thus why i asked for clarification since they changed the meaning considerably ;)

At least it was the first desktop I saw in our company on an IBM-PC. It came very close to my Atari desktop, but turned out to be crippled to allow only for 4 windows, and more crap. I may be misleaded in so far, as it might be presented by DRI even on an PC? [I only saw it running on one of our desktops]

As the acronym GEM says, it's a Graphical Environment Manager, which e.g. on my Atari ST was installed on top of TOS. Multitasking is a feature of the underlying OS, not of GEM.

Okay, that's the same for every platform, not Windows specific. Every platform has its own ABI and object file format, which must be supported by every compiler for that platform. See also the --target etc. switches of FPC.

Windows 3.0 turned out to be the first released and usable desktop version for our portable PCs (from GRiD). At that time we also used a (beta) version of the Borland C development system on Win3.0, which became our new development environment after GW-Basic. I also assisted in the development of an Atari version of BC, and there I wrote a window library that allowed (to some degree) to run Windows code on GEM. From that experiment I remember some of the fundamental differences between GEM and Windows.

DoDi

Well spotted :) I never had one...

-L.

back in Ubuntu...

Me neither, but it's one of the things I know about Mac OS (X).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20131204/cfc92512/attachment.html>

El 04/12/2013 11:50, Sven Barth escribi?:

I think that all this thread about the history of GUI and who copied whom is going a little too far, and too much off topic ;-)

No I beg to differ: even if word :Lazarus: just because isn't mentioned in every other post here, doesn't mean that it is too off topic yet.

Oh there, I mentioned Lazarus. Again. :)

-- Saludos Santiago A.

-L.

+1

I'd suggest migrating to the -other topic.

Everything I say here is my opinion only and related to MSWindows only because I do not have another OS to work with. I think Lazarus could grow quite a bit and maybe find some deep pockets, if it would address the problems of RightToLeft language support. There are a few billion people that must deal with the RightToLeft world. But with Lazarus's RightToLeft limitations, programmers take one look and move on to something with better support. At the moment, on MSWindows, you can not produce a true RightToLeft application with Lazarus.

If there was a significant interested, I'am sure somebody using RightToLeft would have addressed these problems.

But with Lazarus's RightToLeft limitations, programmers take one look and move on to something with better support. At the moment, on MSWindows, you can not produce a true RightToLeft application with Lazarus.

There's very little interest because it simply can't do the job. If you're looking to buy a new car, you don't stop at a motorcycle shop. If Lazarus could overcome just a few of the major obstacles I think there would be RightToLeft people that would make the effort to create a great RightToLeft tool.

As it stands right now, if you mirror any TWinControl (like the Forms) to make it RightToLeft it corrupts the canvas and makes it unusable. At that point, you close Lazarus, and delete it from your system and continue looking for a development tool that can do what you need. Bottom line, very little interest.

Delphi doesn't have this problem. You can make true RightToLeft applications that work very well with very little effort. But Delphi is expensive and in many respects it is inferior to Lazarus.

If the guys who started lazarus, would have thought the same, there would be no an OSS tool misses a certain feature, then there is simply not enough interest, else somebody who needs it, would implement it. Period.

I think the problem is more of an issue of newcomers confidence that they can dive into the codebase and start tackling stuff, or at least they can find someone to guide them if they want to. Systems programming is not an easy area to get involved with and there are many developers who have never had to get anywhere close to that kind of programming. It all looks rather daunting for those who may not be so proficient at Pascal or experienced in low level programming

The guys that started Lazarus had a base to start from. They didn't start from scratch. They already had the basic code to do a lot of things and it worked. But it only worked for LeftToRight.

If Lazarus could address even a few of the major issues, I think it would become the dominant programming tool of the Middle East. I thing that's significant.

Avishai wrote

The guys that started Lazarus had a base to start from. They didn't start from scratch. They already had the basic code to do a lot of things and it worked. But it only worked for LeftToRight.

They *did* start from scratch, because there was *no* code to achieve what Lazarus has done: implement a clone of the VCL in a platform independant way.

If Lazarus could address even a few of the major issues, I think it would become the dominant programming tool of the Middle East. I thing that's significant.

I know it sounds harsh, but: patches are accepted. In Open Source one mostly investigates in problems that oneself is interested in. Afterall most developers are working on such projects in their free time. So if you want something implemented then either implement it yourself or find someone else to implement it for you (e.g. by putting up a bounty or by finding some kind soul that would implement it).

Regards,
Sven

@vfclists. I agree with what you said. I have the knowledge about the requirements of RightToLeft applications, but I don't have the programming skills to make it happen. My suspicion is that the great majority of Lazarus/FPC users are not proficient enough to dig down into the low level code and figure out how to fix problems. I know for fact that I am not. That doesn't keep me from trying though. I've been looking for that TWinControl Canvas bug for 2 years and I'm no closer today than the day I started.

But Mirroring technology is the simplest and most straightforward approach to RightToLeft on the MSWindows platform. For the most part it already works, but only if you disable Themes. That's a price most programmer feel they can't pay.

Really? I thought it started fro Megido.

Is it just me or am I only receiving half of the discussion? O.o

Regards,
Sven

Avishai wrote

Really? I thought it started fro Megido.

And? Then the same would apply to Megido.

No. Significant are the contributors.

I've said what I had to say. I tried to point to a potential new avenue to increase the Lazarus/FPC community and possible contributors, both code and financial. If the suggestion isn't welcome then so be it.

Hi Avishai,

Your contributions are welcome. There is a bounties page. I suggest you post something here:
http://wiki.lazarus.freepascal.org/Bounties

You must first create a Wiki account before you can edit the page.

Sven Barth wrote

I know it sounds harsh, but: patches are accepted. In Open Source one mostly investigates in problems that oneself is interested in.

this reminds me of one of the mantras of (F)OSS...

There is no crying in (F)OSS.

meaning that if something doesn't work, fix it or find someone to fix it ;)

Afterall most developers are working on such projects in their free time. So if you want something implemented then either implement it yourself or find someone else to implement it for you (e.g. by putting up a bounty or by finding some kind soul that would implement it).

that's is how it is done and has been for many years :)

+1

If the guys who started lazarus, would have thought the same, there would be no an OSS tool misses a certain feature, then there is simply not enough interest, else somebody who needs it, would implement it. Period.

Look into Delphi forums, where references to Lazarus typically end up in user comments like: tried to ..., didn't work, dropped it as unusable.

Most of my personal contacts react in the same way :-(

DoDi

On 04.12.2013 21:31, Avishai wrote: I know it sounds harsh, but: patches are accepted.

Sorry, my experience is different. All attempts to make the drag&drop *really* Delphi compatible were rejected, only a few minor patches were accepted after more than a year of work on this topic.

I suspect the same problem with RTL writing, affecting things like component auto sizing and arrangement (anchor docking...). I tried to understand the implementation of these parts, in order to allow for different layout managers, and got stuck in any number of affected standard methods, with no idea how to make these use different layout methods.

Give me a LCL version with all that removed, and I'm sure that the RTL problems can be fixed in reasonable time.

DoDi

because I do not have another OS to work with. I think Lazarus could grow quite a bit and maybe find some deep pockets, if it would address the problems of RightToLeft language support. There are a few billion people that must deal with the RightToLeft world. But with Lazarus's

Avishai, why not enlist some Lazarus developers and create a kickstarter project to add RTL support? Then seek pledges from people in the middle east?

In fact, this would be a good way, I think, to acquire funds to create the new Lazarus widgetsets for web and mobile development!

I believe that Lazarus could become the premier desktop and mobile development environment given the right funding and attention.

Or at the very least by setting out in a clear fashion what you consider the problems to be, describing how they can be fixed in a cross-platform manner, and why they're sufficiently compelling as to require immediate work to the possible detriment of the remainder of the project.

That might have been my experience a few years ago, particularly when somebody was trying to use an "uncommon" platform like CE. But these days the majority of Delphi users appear to be looking first for an alternative to Object Pascal and second for an alternative to Embarcadero, and Lazarus is not seriously considered because the underlying language is believed to be obsolete.

What we, as a community, have not managed to do is dispel the stigma inflicted by early Pascal implementations which were too constrained to be useful for "real" work, and to overcome faulty logic that says that since ISO Pascal failed to standardise things like file I/O that implementations quite simply could not access files. As a result I still have to deal with rants about 1970s projects which failed because Pascal wasn't up to the job, from people who freely admit that they've not tracked developments since that era.

So to summarise: it's not a deficiency of Lazarus or the development process that makes promotion an uphill struggle. Rather, it's the long-standing inability of the Pascal community to promote the language, to the extent that these days even its members believe the misinformation spread about it.

Maybe we need a bit more information on the Lazarus home page about it.

There is a "Why use it?" link that goes here:
http://lazarus.freepascal.org/index.php?page=whyuse but it mainly talks about Lazarus with a only short mention about Free Pascal.

Perhaps this should link to a wiki article with more information about the modern features of Free Pascal and answer common objections.

That's not going to work. Would you visit a site devoted to Arabic calligraphy when what you were looking for was a word processor for the novel you'd just thought of?

What we need is a way of raising awareness of the strengths of the language by showcasing its use. But if FPC and Lazarus themselves aren't effective demonstration projects then I don't know what would be better.

One question to be considered is how the C community has managed to move from the acknowledged deficiencies of the K&R era to the strengths of ANSI C and (later) C++, without having its members rebel as things like type checking and a large standard library were introduced into the language.

Please the the new thread, I started on this topic

Seems like we're not the only ones discussing
the future of desktop apps:

http://hardware.slashdot.org/story/13/12/04/0346251/the-desktop-is-dead-long-live-the-desktop

Rumours of my death are greatly exaggerated. People always treat articles which are placed to boost the shares of technology companies with actual trends. So long as large screens are needed to perform tasks desktops will exist.

The worst that can happen is that tablets and smartphones will require docking stations to play the role of desktops when big screens and keyboards are required to perform a task. They will still require desks won't they? Printers, scanners, external drives need a desk or shelf somewhere in order to be useful.