Hi:

From a message from Gabor, it would be interesting to learn what's the

distribution of Lazarus users:

These are my data:

OS target:
Windows: 55%
Linux: 45%

Widget Target:
Win32 45%
Gtk2: 45%
fpGUI: 10%

Easter Egg data ;-)
Country: Spain

Windows: 20%
Linux: 75%
OSX: 5%

Qt 100%

Easter Egg data ;-) Country: Spain

Country: Croatia

zeljko

OS target:
FreeBSD: 90%
Linux: 10%
Windows: 0%
MacOS: 0%

Widget Target:
Win32: 0%
GTK2: 5%
fpGUI: 95% (pure fpGUI as LCL-fpGUI is still in Alpha state)

Country:
England

Regards,
Graeme

Santiago A. wrote

These are my data:

Nearly all is Windows, increasingly 64-bit. Some older and server oriented programs on Linux. Some of those I also use on my FreeBSD shell accounts.

*nix GUI is nearly zero, so widgetset is win32 except for during Lazarus/FPC conferences.

My web server logs show the following Lazarus downloads and installs by for the past 30 days:

2894 : /download/?platform=windows
1929 : /download/?platform=linux
1572 : /download/?platform=raspberry
691 : /download/?platform=macintosh
1279 : /installed/?platform=windows
1107 : /installed/?platform=linux
658 : /installed/?platform=raspberry
380 : /installed/?minimal&os=linux&dist=unknown
227 : /installed/?platform=macintosh
29 : /installed/?minimal&os=linux&dist=ubuntu

Source:

http://cache.getlazarus.org/images/lazarus-downloads-201607.png -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160718/89a21a91/attachment.html>

OS Target:
Windows: 30%
Linux: 70% (CGI/Brook - command line utilities).

Widget Target:
Win32: 100%*

*: The only desktop target right now, but most of our targets are command line and WEB.

Country: Argentina.

80% Windows (mostly Win32 apps, few console tools) 15% Linux (console services and tools)
3% Mac (console tools)
2% FreeBSD (console services and tools)

Plan is to increase the share in Linux and Mac by porting some GUI apps.

Denis

Our customers (desktop count only):
85% Ubuntu
15% Windows

2016-07-18 17:15 GMT-03:00 Denis Kozlov :

Can I use a LCL component in a fpGUI app?

Regards,
Ara
 

Aradeonas wrote

Can I use a LCL component in a fpGUI app?

No, they are separate toolkits - just like you can't mix GTK and Qt widgets in the same application.

Saying that, I have found it is quite easy and relatively quick to port LCL or VCL components to fpGUI. I've done that quite a few times already. Just curious, what component did you want to use?

Regards,
Graeme

OS target:
Linux: 99.9%
Windows: 0.1%
MacOS: 0%
FreeBSD: 0%

Widget Target:
Qt 99.8%
GTK2: 0.1% (just one app because of a Qt bug I never bothered to fix/report) Win32: 0.1%

Country:
devel: Italy
deploy: pretty much all the rest of the world (industrial equipments)

OS target:
Linux: 50%
Windows: 50%

Widget Target:
Win32: 50%
GTK2: 50%

Application:
both GUI and CLI on win ad linux. MacOSX not yet evaluated, it will probably be the next target. GTK2 (and eventually win32) could be replaced with Qt.
Customer: big companies and universities.

Il 19/07/2016 01:47, Giuliano Colla ha scritto:

Saying that, I have found it is quite easy and relatively quick to port LCL or VCL components to fpGUI. I've done that quite a few times already. Just curious, what component did you want to use?

Virtual tree view.

Regards,
Ara

Aradeonas wrote

> Just curious, what component did you want to use? Virtual tree view.

Are you using Virtual Treeview as a treeview or a grid? It seems some components (VT, ListView etc) don't really know what they want to be. ;-)

Many of fpGUI's standard components are much faster than LCL or VCL equivalents, so you don't need 3rd party component suites. eg: fpGUI's standard TreeView and StringGrid are really fast. For example the last time I testing fpGUI's StringGrid it could create 8 million columns and rows and populate each cell with unique text in 5 seconds. Scrolling was instant with no delays. LCL's TStringGrid got stuck at 100% CPU load for over 3 hours before I killed the process.

Regards,
Graeme

Are you using Virtual Treeview as a treeview or a grid? It seems some components (VT, ListView etc) don't really know what they want to be. ;-)

Both, As VTV is the best grid-ish component I fount in Lazarus world. Kgrid is good but slow.

You are right about LCL speed, it's grids are for simple use and I never used them in a real project but in the other hand VTV is the fastest I found and has many abilities (not built in unfortunately ) as editors and ... .
I didnt see a grid for this usage in fpGUI demos at least in my last check. Can it be a good grid because I miss DevExpress's cxGrid very much and I dont expect its abilities but I need VTV , Ara

Umm... using a TreeView component as a Grid. Somewhere the design went horrible wrong. :-p

For the rest of your questions, I'll reply in the fpGUI newsgroup (fpgui.support). It is not appropriate to continue this hijacked thread here.

http://fpgui.sourceforge.net/support.shtml

Regards,
Graeme

Ok, I should install XanaNews for that (after these years a forum will help new users knowing fpGUI) and I will ask for that but as I said VTV is the best option and its a good grid, its name is only a trick.

Regards,
Ara

I don't think so. MSEgui also supports a combination of treeview and grid by placing a TTreeItemEdit in a TWidgetGrid. TWidgetGrid accepts any data edit widget as column widget (TStringEdit, TIntegerEdit, TRealEdit, TDataButton, TSlider, TDropdownListedit...) which builds a column with the according data type. In case of TTreeItemEdit the datatype is an instance pointer of TTreeListItem. Very handy.

Martin

Graeme Geldenhuys wrote

Umm... using a TreeView component as a Grid. Somewhere the design went horrible wrong. :-p

I don't think so.
VTV (which I also find extremely flexible and fast) is a grid where one (arbitrary) column can contain a tree which simply means that the visible parts in this column are indented according to the level of the tree structure but still it is just an ordinary column with data
(getting wider with each level of tree depth).
The other columns just present meta-data to the entry. That's how I would expect any tree representation to look like:

If you don't use a tree like column it just falls back to an ordinary grid.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160719/83ea4675/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: ipiojjcefahccfoc.png
Type: image/png
Size: 16959 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160719/83ea4675/attachment-0001.png>

Graeme Geldenhuys wrote

Many of fpGUI's standard components are much faster than LCL or VCL equivalents,...

I am astonished to hear that, because up to now I thought that fpGUI ("drawing" a lot of the more complex stuff in Pascal code) would necessarily be slower than a library that links to a complex external graphical framework, that is OS and graphics driver aware and hence should be able to make use of the underlying system in a more optimized way.

As you might know I plan to enhance the "NoGui" Widget Type to allow for a standard main thread event queue, including standard usage of TTimer, TThread.Synchronize, TThread.Queue and friends. This already does work, but is not published as the project currently is stalled due to the usual "lack of available time" problem.

In a second step, I intend to do the basics for a "remote GUI" on top of that. Options here are "ifi" (invented by Martin, and already working in MSE: a dedicated program that shows the GUI of a remote program connected via a bidirectional byte stream), or a JavaScript based remote HTML GUI to allow for a "smart Web" application. As a base for this, I think, stealing the code of either of "FPGUI" or "CustomDrawn" might make sense.

Do you think FpGUI is more appropriate ?

Thanks,
-Michael

Michael Schnell wrote

I am astonished to hear that, because up to now I thought that fpGUI ("drawing" a lot of the more complex stuff in Pascal code) would

Other toolkits ultimately do drawing to a canvas too - just like fpGUI. There is no reason why I couldn't optimise fpGUI drawing - as is supposedly done in other toolkits. :)

There are plenty of examples where LCL or VCL standard components are very slow. Here is another link to a Mantis report where it was revealed that using TListView caused a 4-5 second delay in the user interface. Switching out the TListView (which maps to native controls) for a TStringGrid (which is custom drawn I believe) made the screen updates near instant.

http://mantis.freepascal.org/view.php?id=30317

In a second step, I intend to do the basics for a "remote GUI" on top of that. Options here are "ifi" (invented by Martin, and already working in

I never really understood the need for that - but then I don't know MSEgui very well. What I mean is, X11 already natively supports running applications remotely. Also with the popularity of Remote Desktop, VNC, TeamViewer (which is absolutely brilliant and even does session recordings in unbelievable small file sizes), I think all based are already covered pretty well.

Regards,
Graeme

Martin Schreiber wrote

I don't think so. MSEgui also supports a combination of treeview and grid ...

A friend of mine uses Python and just did some tests with a new (or updated to the current Python version) GUI toolkit.

Here a kind of "Grid" is done in a hierarchical way and seems to be the main building blocks of the GUI. E.g. a grid in a grid's field is the standard way of designing, and Buttons etc usually seem to be placed in grid fields.

Supposedly this is similar to how HTML pages can be designed.

Maybe FireMonkey (I don't ave a Delphi XE) works in a similar way, and yet maybe implementing of FireMonkey makes sense for Lazarus...

-Michael

Michael Schnell wrote

E.g. a grid in a grid's field is the standard way of designing, and Buttons etc usually seem to be placed in grid fields.

That sound like a “grid layout manager” implementation - similar to the 100’s of Java layout managers out in the wild.

A Visual Guide to Layout Managers:
https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html

Layout Manager Showdown:

http://web.archive.org/web/20081228153757/http://wiki.java.net/bin/view/Javadesktop/LayoutManagerShowdown?TWIKISID=3e5882397bd2ed89e1212654998feda6

Regards,
Graeme

All these options use an external complex graphics library in the remote "embedded" target.

The device is a thingy that nowadays in "new speak" is called and "Internet of Things" node. Hence a potentially very small and needing to be very cheap and extremely energy efficiently running device. So it does not feature any hardware allowing for displaying a GUI, and the OS and library infrastructure does not support any GUI work. Microsoft recently hopped on that bus by providing "Windows IoT" for free that in fact is Windows 10 with all GUI stuff stripped off. (A Colleague of mine was able to run Windows Services (that don't have a GUI) written in Delphi on Win IoT running on an Intel CPU based "embedded" board.)

So, my original (some 5 years old) motivation for the said enhancement to the LCL was running Lazarus- (or having been Delphi-) projects on such a board (usually called "embedded" at that time, the infrastructure of which does not provide any support for a GUI), after developing them on a PC in the "normal" RAD way (i.e. porting them from existing projects). Here having a Widget Type "remote GUI" would be extremely helpful for testing/examining and occasionally configuring the device.

-Michael

Graeme Geldenhuys wrote

TeamViewer (which is absolutely brilliant and even does session recordings in unbelievable small file sizes), I think all based are already covered pretty well.

Can you run this on an ARM-Linux device without GUI support (I could test it on a QNAP NAS) to occasionally remote control a permanently running Lazarus program from a Linux or Windows PC ?

-Michael

Why would you not do this with a HTML interface ?

The browsers are so powerful these days that your solution is hopelessly outdated even before you started.

The added benefit is that no installation is needed. And you can control your device from anywhere: PC, tablet, smartphone. If you write your own GUI (client/server or not), you will need a 'client' for each of these devices

In my line of work, a starting a new PC/Mac-based program is simply no longer an option. It's web-based or you're doomed.

Michael.

It's not that astonishing. A external library adds another layer. In addition, a library is usually a bloated, that's the price to pay for having a lot of things off-shelf.

That is exactly what I was about to say. And as you rightly pointed out, an HTML interface can work on every type of device out there - PC, mobile phone etc.

Regards,
Graeme

Michael Van Canneyt wrote

Why would you not do this with a HTML interface ?

This would need to be completely new designed from scratch with "non visual" methods, while the LCL (aka Delphi VCL) interfacing software is already in place with the (to be) ported projects. In fact I was not intending to do the (re-) design of the actual projects, but I only tried to create an infrastructure to enable the team of programmers who did the Delphi projects to have them port their code to be "embedded" in the said way.

The browsers are so powerful these days that your solution is hopelessly outdated even before you started.

OK. Completely re-implementing the software in Java, Python, PHP or whatever world be a "modern" way, but dumping millions of lines of code did not seem attractive.
Right mow they live with doing nothing about the software (i.e. staying with Delphi) and buying much too expensive Windows enabled hardware for the "IoT nodes", so that a GUI is supported and can be remoted by standard tools .

-Michael

Time ago I post in this forum a message "the future of desktop", and I agree, web is not the best GUI, (in fact, I hate it) but it's ubiquitous. The problem is that when I write an application in freepascal, I'd rather not to have to write half application in html-css-javascript and mess with communication protocol.

Santiago A. wrote

It's not that astonishing. A external library adds another layer. In addition, a library is usually a bloated, that's the price to pay for having a lot of things off-shelf.

... such as "themes".

I see.
Thanks,
-Michael

Graeme Geldenhuys wrote

That is exactly what I was about to say. And as you rightly pointed out, an HTML interface can work on every type of device out there - PC, mobile phone etc.

AFAIK there is no LCL "widget type" that supports this. IOW, no Lazarus-built-in GUI Builder, hence no RAD-Design for the software creator.

The QNAP device I have at home has a Java-Script-toolkit enabled remote HTML/HTTP GUI that looks very similar to a GUI created by LCL. It is really nice and fast.

Allowing for same simply by switching the LCL Widget-Type from the local standard to "remote HTML" would be the perfect (maybe unreachable) solution for poring a "normal" LCL application to be a "smart internet" application.

-Michael

Graeme Geldenhuys wrote

> "ifi" (invented by Martin, I never really understood the need for that

In fact the most basic idea of "ifi" is the same as doing a HTML GUI for a "rich internet" application: a (propriety format) byte stream connects the "busyness" software and the GUI.

With ifi, the GUI part is done in fpc with means of a semi-standard (here: mse) GUI library, that connects to a standard (here Windows or Linux Widget set) library.

With "rich internet", the GUI part is done in Java Script, that connects to a standard (here Browser JAVA-Script API) library.

-Michael

Santiago A. wrote

web is not the best GUI, (in fact, I hate it) but it's ubiquitous.

+1

Web interfaces tend to be slow too, but I have recently seen some pretty amazing "web applications".

Regards,
Graeme

Michael Schnell wrote

AFAIK there is no LCL "widget type" that supports this. IOW, no Lazarus-built-in GUI Builder, hence no RAD-Design for the software creator.

Get writing then! ;-) I'm sure many would appreciated such a contribution.

Regards,
Graeme

Michael Schnell wrote

Allowing for same simply by switching the LCL Widget-Type from the local standard to "remote HTML" would be the perfect (maybe unreachable)

I forgot to mention. Recently I saw just such a solution for Delphi's VCL. No idea how they did it, but I was very impressed with that.

I can't remember the name of that add-on though. Michael van Canneyt might remember what I'm talking about.

Regards,
Graeme

The problem is no aesthetic but of design and productivity.

HTML was designed to display documents and close connection, thus it has no concept of session, the session ends when you display the page and close connection. Cookies came to keep some data from session to session. Later came websockets etc. All are dirty patches to convert the initial design as displayer into a GUI. You started with bicycle, you added an engine, later four wheels, later a chassis, and now you have a car.

Xwindows is too low level, no widget.... VNC is no really a remote GUI (the server admits just one connection), Microsoft remote desktop is a good solution, but it's tied to windows. The monster ERP SAP has it's own GUI <https://es.wikipedia.org/wiki/SAP_GUI>, that is the way.

The world needs really bad a standard remote GUI protocol that can run on any graphic/OS. There have been some tries: XUL, Fresco <https://en.wikipedia.org/wiki/Fresco_%28windowing_system%29>, and others I've never heard about.

Regards, Graeme

Santiago A. wrote

The world needs really bad a standard remote GUI protocol that can run on any graphic/OS.

Personally I loved the idea of Java Applets. You had the full power of the Java language and a full feature GUI to work with. Just a pity Sun/Oracle went through a period of not keeping up with Java bugs. Luckily that is all behind us now, but unfortunately Java Applets paid the price.

Regards,
Graeme

Unigui or raudus. The latter even works with Lazarus.

http://www.unigui.com/
http://www.raudus.com/

The problem with this approach is that they are stateful on the server.

Michael.

We're working on a solution for this.

Michael.

Michael Van Canneyt wrote

http://www.unigui.com/

Thanks Michael. That’s the one I was referring to.

Regards,
Graeme

Santiago A. wrote

HTML was designed to display documents and close connection,.... All are dirty patches to convert the initial design as displayer into a GUI.

You are right, but the culprit is not HTML, but HTTP.

If we could have the browser use a simple bidirectional socket connection instead, this would not be a problem.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160720/5461620e/attachment.html>

Open sourcing Windows "Remote Desktop" ?!?!?

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160720/4e646e09/attachment.html>

Michael Van Canneyt wrote

We're working on a solution for this.

Any description / preview ?

If this is going to be reality out of the box, I maybe stop thinking about it myself :-) .

-Michael

Graeme Geldenhuys wrote

I forgot to mention. Recently I saw just such a solution for Delphi's VCL. No idea how they did it, but I was very impressed with that. I can't remember the name of that add-on though. Michael van Canneyt might remember what I'm talking about.

Years ago there was ExtPascal. but that had been abandoned long ago.

-Michael

Graeme Geldenhuys wrote

On 2016-07-20 13:10, Michael Van Canneyt wrote: > http://www.unigui.com/

A whole tot of *new *"TUnim..." visual components.

Hence supposedly a simple porting of an existing (local GUI) project is not supported.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160720/5492fd5f/attachment.html>

I suspect you'll have to keep thinking, because I doubt our solution will help you:

As far as I understand, you want to keep your current code as-is, but that will not be possible.

What we will offer you is to design/code in Lazarus/Delphi, transpile to Javascript and then run the code in the browser.

There will be a widgetset for the browser, but it will not do everything the LCL/VCL does.

Michael.

Michael Van Canneyt wrote

The problem with this approach is that they are stateful on the server.

It should allow for the application "pushing" (via some kind of polling) state information onto the Java Scripted GUI in a fast and protocol-efficient way as well with a built-in webserver as when placed "behind" a server like Apache.

-Michael

You keep coming back to this 'simple porting of an existing GUI'.

This leads me to believe that you have run deeply in the RAD trap:

Business code and GUI code tightly intertwined, making it impossible to quickly create a new front-end.

If so, my advice to you is: don't wait for the impossible, but start detangling your code.
Then a HTML/unigui/whatever front end will be less painful.

Michael.

2016. 07. 20. 15:42 keltezéssel, Michael Schnell írta:

Open sourcing Windows "Remote Desktop" ?!?!?

The protocol documentation is available freely (search for [MS-RDP*]):

https://msdn.microsoft.com/en-us/library/jj712081.aspx

But:

https://blogs.technet.microsoft.com/enterprisemobility/2013/12/11/remote-desktop-protocol-licensing-available-for-rdp-8

Gabor

I feel that this is a great way to go !

Maybe it is possible to build on this to go even further one day, combining it with what ifi might offer (i.e. transpiling the GUI site of ifi to run it in a browser) :-)

-Michael

Michael Schnell wrote

Open sourcing Windows "Remote Desktop" ?!?!?

It already exists for Linux and FreeBSD, called "rdesktop". Obviously it's not the official Microsoft version, but a reverse engineered open source client and server.

Regards,
Graeme

Michael Van Canneyt wrote

This leads me to believe that you have run deeply in the RAD trap:

You are perfectly right. Only that it is not "me" but I just want(ed) to support my colleagues who built a huge set of projects that way. I suppose you understand that I got kind of angry about exactly this when I got involved in the proceedings some years ago.

In the meantime they were forced to un-RAD part of their code due to new Windows versions not any more allowing a pseudo-GUI for services.

-Michael

Michael Van Canneyt wrote

What we will offer you is to design/code in Lazarus/Delphi, transpile to Javascript and then run the code in the browser.

I want to help if it is possible ....

There will be a widgetset for the browser, but it will not do everything the LCL/VCL does.

I was thinking that maybe it could be possible to use Gecko embedded or Chromium Embedded Framework to debug and/or design from lazarus . In fact the last 2 - 3 days I was doing some research in that direction ....

regards,

That does sound promising ....

-Michael

Michael Van Canneyt wrote

What we will offer you is to design/code in Lazarus/Delphi, transpile to Javascript and then run the code in the browser.

This reminds me the Morfik approach ...

regards,

What's wrong with stateful approach?.

Stateless aren't the silver bullet of every problem.

REST etc are good solutions when you work with few states and operations. And many times what you do is let data with a few operations and delegate GUI's complex states in the client side with javascript etc.

For me that's not the way to go either. Moving complexity from server to client works when you are offering services, but not when you have to program client side as well.

It is not scalable.

Michael.

Gabor Boros wrote

https://blogs.technet.microsoft.com/enterprisemobility/2013/12/11/remote-desktop-protocol-licensing-available-for-rdp-8

If someone would do a remote desktop running on the free Win IoT we would for free have a rather normal Windows running any normal Windows application.

M$ can't allow this.

-Michael

Exactly what I am aiming for.

IMHO, Morfik was/is the only architectural solution to pascal web apps 'done right'.

Sadly, somewhere in time they made a wrong turn. Maybe money ran out, no idea.

Michael.

Santiago A. wrote

For me that's not the way to go either. Moving complexity from server to client works when you are offering services, but not when you have to program client side as well.

Facing exactly this task, Microsoft once invented C# and Silverlight.

Here the same code (written in C#) can run as well on the server as on the Client (i.e. in the browser). It's up to the user where he places each single function.

To me this sounded like a great idea and I felt that the basic design was very well thought out and promising.

But obviously the public interest shifting from PCs to mobile devices made Java the winner over C# and finally Microsoft dropped Silverlight.

-Michael

I couldn't agree more, as we're still using Morfik 3 at work ;) We have some web apps, that are too heavy to be done from scratch again ...

regards,

I've heard (and used) client in Linux, but I'had never heard about Server. There are third part that offer terminal server, but only for windows. Any link?

Michael Schnell wrote

and finally Microsoft dropped Silverlight.

Oh wow, I didn't know that. Shows you how much I read anything Microsoft related these days. ;-)

Now if only Netflix can get their act together and drop Silverlight too, and rather switch to HTML5 Video. Then finally I'll be able to watch Netflix on my FreeBSD system. And other systems like Haiku, Linux etc will be able to enjoy Netflix too.

Regards,
Graeme

You can watch netflix with HTML5.
Install Google Chrome on a recent Ubuntu Linux, and it should work out of the box.

Michael.

Michael Van Canneyt wrote

Install Google Chrome on a recent Ubuntu Linux, and it should work out of the box.

Google Chrome is not available for FreeBSD and Haiku. Also Chrome comes with proprietary closed-source add-ons which is what Netflix uses for the DRM. No idea if Google will ever support FreeBSD.

Chromium is available everywhere, but without those proprietary add-ons it is useless for Netflix viewing. Surely HTML5 video must allow for something else that doesn't require proprietary add-ons? At the moment I just fire up my Win7 VM if I really need to watch on my desktop computer
- which is seldom really (alternatively I've got my Macbook Pro).

Regards,
Graeme

Santiago A. wrote

Any link?

I unfortunately don't have a link, but I'm sure a Google search should help you. I used the server portion about 5 years ago under Linux, so I know it exists.

Regards,
Graeme

Hi all
Thinking to HTML and the browsers that turned respectively into a "GUI language" and a "sort of virtual machine where to run" code, I often think about what role could have the pascal.

This is the world of interpreted languages, while pascal, currently compiled, has many advantages.

I think then to Lazarus and how it was made and the role it might have in a world with different OS. After all, browsers and VMs are not written in interpreted languages.

I try to explain, forgive my english, please :)

I could put an application server (written like the Lazarus IDE) called for example "LazApplicazionBrowser", on the same floor of a browser or a VM: compiled for each OS. Then put the packages of Lazarus on the same floor of a browser plugin.

This "LazApplicazionBrowser" with any module may install modules from either source (require the presence of fpc) or compiled (in this case the modules in repository should already be compiled for all the necessary OS). "LazApplicazionBrowser" then could make the "rebuild", ready for use, natively compiled on target OS.

Obviously we're not forced to exclude an interpreted pascal, but I think pascal applications with this system may have a greater spread on all the various OS.

I'd like to hear your comments.
Thank you
Marcello Basso

Scalable up to what? The GUI of a router. The users connected to an ERP. They needn't to support 10.000 connections a minute,

With stateful approach and you can make a more responsive and usable GUI

Michael Schnell wrote

In a second step, I intend to do the basics for a "remote GUI" on top of that. Options here are "ifi" (invented by Martin

Any documentation about "ifi"?

I haven't found anything inf MSEIde & MSEGui site

I have seen such applications break down at less than 100 users. It all depends on the application and what it does.

With stateful approach and you can make a more responsive and usable GUI

Having seen what can be done with ExtJS or other toolkits such as AngularJS, React and whatnot, I disagree completely, but I will not try to convince you...

Michael.

A brief explanation is here:
http://article.gmane.org/gmane.comp.ide.lazarus.general/73418 An example application here:
https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/mseifi/ifipipedemo and a video here:
http://mseide-msegui.sourceforge.net/pics/mseifiremote.mpeg

For questions about MSEide+MSEgui please use the mailinglist: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Martin

2016. 07. 20. 16:38 keltezéssel, Santiago A. írta:

I've heard (and used) client in Linux, but I'had never heard about Server. There are third part that offer terminal server, but only for windows. Any link?

xrdp?

https://github.com/neutrinolabs/xrdp

Gabor

OS Target:

Linux: 50%
Amiga: 30%
MorphOS: 20%

Widget Target:
GTK2: 50%;
MUI: 50%

Hello,

It sounds like the Ada Web Server project (http://libre.adacore.com/tools/aws/). You've an open source web server you can compile on any Gnat Ada supported platform and customize to your own needs. I don't know if they have plugins.

Regards
Norbert

yes, something like that.
but oriented to run binaries (already or just) compiled by pascal

Regards
Marcello

Martin Schreiber wrote

A brief explanation is here:...

Of course you know that I am a fan :-) .

Regarding this discussion being focused on a browser GUI:

Do you think there is a chance to do the GUI site of ifi in Java Script (using one of the several Java Script GUI libraries that already have been mentioned in this thread) and with this provide as well the (supposedly more versatile) control-executable solution as the (sometimes necessary) Browser based solution ?

Should we discuss this in an mse forum ?

-Michael

Michael Schnell wrote

On 07/20/2016 06:49 PM, Martin Schreiber wrote: > > A brief explanation is here:.. > "The client could be realized as browser plug-in (not done up to now).

I have no idea how a Browser-plugin can be create with fpc.

Moreover when running in a browser and the program to be remote controlled is "behind" a web server, how to do the communication (as I understand that ifi needs a bidirectional byte stream).

-Michael

For illustration see screenshot here:
http://mseide-msegui.sourceforge.net/pics/twidgetgrid.png

'Run' is a TDataButton, 'Enabled/Caption' a TTreeItemEdit, 'Filepath' a TFilenameEdit which shows a filedialog by clicking the ellipse-button, 'Comment' a TDialogStringEdit which shows a multiline edit dialog by clicking its ellipse-button and 'ED' a TDataButton in a right aligned column.

Martin

Maybe but not by me. MSEgui is too much sophisticated for JavaScript. ;-) Why not use the available JavaScript web environments directly?

Should we discuss this in an mse forum ?

Most likely.

Martin

It must be tunnelled by one way or another.

Martin

Martin Schreiber wrote

On Thursday 21 July 2016 10:41:41 Michael Schnell wrote: Maybe but not by me.

Of course not :-)

MSEgui is too much sophisticated for JavaScript. ;-) Why not use the available JavaScript web environments directly?

To be able to simply switch a project between local (mse-) GUI, remote (ifi) GUI and browser based (Java/ifi) GUI mode.

This would be a major argument to switch to mseGUI from many development tools.

as soon as any longer reply is necessary.

-Michael

From a message from Gabor, it would be interesting to learn what's the distribution of Lazarus users:

This is my current daily working stats (doesn't necessarily mean what I can make for):

OS target:
Linux: 100%

Widget Target:
Qt: 25%
NoGUI: 75% // webservices, webservices everywhere...

Country: Indonesia

leledumbo wrote

> From a message from Gabor, it would be interesting to learn what's the > distribution of Lazarus users:

Linux, no GUI (services): 80%
Linux, GUI (GTK): 5%

Windows, no GUI (services): 5%
Windows, gui: 10%

Country: Belgium.

Michael.

pretty much hobbyist
Same applications (Linux at home)

OS target:
Windows: 50%
Linux: 50%

Widget Target:
Win64 50%
Gtk2: 50%

Country: Italy

2016-07-13 18:12 GMT+02:00 Santiago A. :

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160722/bf9101d4/attachment-0001.html>