The future of Free Pascal

[Graeme]

However, these are one-man projects. One man develops, one man decides where the project will go...

Huh? I'm pretty open with fpGUI. Yes I obviously did most of the work, but I also accept many contributions... some were even massive contributions to the core of the framework itself.

A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me. 

Code: [Select]

[fpgui (maint)]$ git shortlog -s -n
  2801  Graeme Geldenhuys
   867  graemeg
    85  Jean-Marc Levecque
    36  sekelsenmat
    32  drewski207
    26  Felipe Menteiro de Carvalho
    21  David Laurence Emerson
    19  Andrew Haines
    13  Jean-Marc
     5  Dibo
     4  Jean-Marc.Levecque
     4  Michael van Canneyt
     3  Andrew
     3  David Emerson
     2  Philippe Lévi
     1  Jean Pierre Anghel
     1  Micheal Fyffe
     1  Paul Breneman
     1  Rodrigo Aliotti
     1  Stéphane Aulery
     1  Charlie Root
     1  Fred van Stappen
     1  hinst
     1  jean-marc
     1  jp anghel
     1  ArtSvetlakov
     1  Clemens Capitain


Lazarus LCL library with "native" OS widgetsets is a good way, but LCL still needs a good fpc-drawn library, independent from C-libraries gui backends, which can be used as widgetset and look and feel same everywhere.

That's exactly what the LCL-fpGUI widgetset is. I don't actively develop it, simply because I think LCL is rubbish. Very inconsistent, slow, bloated and too Windows-like [on other platforms]. LCL-fpGUI also reduces the functionality, flexibility and power of fpGUI widgets. Saying that, I do contribute patches every now and again to make sure it still works with the latest stable fpGUI. I've also implemented all the basic widgets (excluding TLabel).

[Graeme]

And STILL they push out new versions faster than us :-)

Simply because that makes the people - spending thousands on Delphi licenses per year - feel like they are getting something for their money. A good business tactic. It sucks for the developers though. Nobody upgrades their projects to new Delphi versions that quick.

[marcov]

And STILL they push out new versions faster than us :-)

Simply because that makes the people - spending thousands on Delphi licenses per year - feel like they are getting something for their money. A good business tactic. It sucks for the developers though. Nobody upgrades their projects to new Delphi versions that quick.

Euh, the "people" and "developers" in your reply are the same?

The new mandatory subscription sucks indeed though, I hope it doesn't last. I bought Seattle in October though (mainly because 64-bit debugger is fast & more stable), so I'm good for a while :-)

[skalogryz]

A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me. 

What happens to the project, if you would be gone tomorrow? 

What the "future of fpGUI" would be?

On topic: I see no correlation between "free pascal" as a language, another UI library and state of Delphi. Imho, all three are quite independent entities:
* FPC goes on its own, picking up delphi features here and there
* Delphi goes on its own
* UI libraries live on their own. Usually not using the latest language features.

[Zoran]

However, these are one-man projects. One man develops, one man decides where the project will go...

Huh? I'm pretty open with fpGUI. Yes I obviously did most of the work, but I also accept many contributions... some were even massive contributions to the core of the framework itself.

A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me. 

Code: [Select]

[fpgui (maint)]$ git shortlog -s -n
  2801  Graeme Geldenhuys
   867  graemeg
    85  Jean-Marc Levecque
    36  sekelsenmat
    32  drewski207
    26  Felipe Menteiro de Carvalho
    21  David Laurence Emerson
    19  Andrew Haines
    13  Jean-Marc
     5  Dibo
     4  Jean-Marc.Levecque
     4  Michael van Canneyt
     3  Andrew
     3  David Emerson
     2  Philippe Lévi
     1  Jean Pierre Anghel
     1  Micheal Fyffe
     1  Paul Breneman
     1  Rodrigo Aliotti
     1  Stéphane Aulery
     1  Charlie Root
     1  Fred van Stappen
     1  hinst
     1  jean-marc
     1  jp anghel
     1  ArtSvetlakov
     1  Clemens Capitain


Graeme, sorry. Yes, you are open to contributions. I just think that fpGUI (currently at least, this might change in future) have much smaller community than Lazarus, and you just have to do most of the work yourself. I still think that it has to be taken into account that it is currently mostly one-man project.
Okay, you might get more fpGui developers in the future and I hope you will.

Lazarus LCL library with "native" OS widgetsets is a good way, but LCL still needs a good fpc-drawn library, independent from C-libraries gui backends, which can be used as widgetset and look and feel same everywhere.

That's exactly what the LCL-fpGUI widgetset is. I don't actively develop it, simply because I think LCL is rubbish. Very inconsistent, slow, bloated and too Windows-like [on other platforms]. LCL-fpGUI also reduces the functionality, flexibility and power of fpGUI widgets. Saying that, I do contribute patches every now and again to make sure it still works with the latest stable fpGUI. I've also implemented all the basic widgets (excluding TLabel).

Yes, I know that is what LCL-fpGUI widgetset is, but it is not fully working (like win32/64, GTK2, Qt, Carbon). Since you think LCL is rubish, I doubt LCL-fpGUI will ever get into fully working state unless someone else makes serious effort to implement it. And I'm sure he will get full support from you, despite what you think of LCL.

It is normal that LCL-fpGUI cannot reach the full functionality of fpGUI itself, but having it as fully working LCL backend will be just enough for the need I am talking about - a Lazarus user will be able to easily switch between OS-native and Pascal-native GUI library.

[mica]

just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention

[taazz]

just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention

If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.

[JD]

just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention

If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.

I think so too. There was a certain discussion about that when Orca was first introduced.

JD

[SymbolicFrank]

Ok, a minimal OpenGL GUI to start, for devices that don't have an LCL, but do have a GPU, sounds low-entry. Very doable.

But, we could go much farther in that. Because of native controls requiring both a language interface for the events (hard problem in many cases), and support of the widget sets (lots of work). And the platform independent interfaces being pixel-based.

OpenGL is a standard. Yes, the implementation can be lacking, but with the shader model, we don't really need much more than surfaces (triangles and rectangles), textures and shaders. Most everything else is irrelevant.

Ok, a fast geometry shader would help immensely, for things like drawing controls and (especially) fonts. Or calculating the initial signed distance font texture. But those are all things that can be calculated up front.


As we are all programmers and not artists, making things slick looking is hard work. Nice to have and to look at, but that can be done at the end, to make it better.

If we start with the minimal requirements to make it work, it is very doable.


But, yest, that will be most of the work. I could do a distributed computing library in a few weeks time by myself, comparatively.

[JD]

just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention

If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.

Some links

https://jonlennartaasenden.wordpress.com/2015/05/04/pilotlogic-and-codetyphon-in-clear-violation-of-copyright-law/

http://forum.lazarus.freepascal.org/index.php?topic=24006.0

http://www.progtown.com/topic1898592-codetyphon-arguing.html

JD

[Graeme]

What happens to the project, if you would be gone tomorrow? What the "future of fpGUI" would be?

The same thing as what happened in the past... It continues with anybody interested. It's open source, the code is right there - available in the open.

I didn't start the fpGUI project, I found it [abandoned] in a FPC repository. Yes I might have completely rewritten in from scratch, and developed it for much longer than the original developer, but I enjoy the project so continue the effort. A huge bonus is that I now write all my personal and company software with it, simply because it is so easy to use, very consistent across platforms, and overcomes many LCL deficiencies.

The point being, somebody else created it [fpGUI], lost interest a while later, somebody else [me and others] picked it up again and carried it forward. The world is full of such open source examples.

I see no correlation between "free pascal" as a language, another UI library and state of Delphi. Imho, all three are quite independent entities:

Indeed. I fully agree.

[Graeme]

I just think that fpGUI (currently at least, this might change in future) have much smaller community than Lazarus,

Also take into account that Lazarus [at the time] offered something extra that didn't exist in fpGUI. An IDE, Delphi compatibly, close ties to the Free Pascal project etc. Those were the promised features that drew the crowd towards the Lazarus project. That's what built its momentum.

I made many choices with fpGUI Toolkit. I didn't want to implement an IDE - I wanted it to be IDE agnostic (you should only require FPC). I didn't bother with Delphi compatibility because I saw better solutions, I wanted custom drawn because its more flexible and portable. Not everybody agrees with these choices, but it sure worked for me, and fpGUI is better now because of it.

The world is full of examples of inferior products finally winning the competition: Betamax vs VHS, OS/2 vs Windows, Netscape vs IE, Firewire vs USB, SCSI vs IDE etc. I'm not bothered about fpGUI's popularity vs Lazarus. fpGUI works for me, and that's what I care about [plus it was a great learning experience that I still enjoy].

Yes, I know that is what LCL-fpGUI widgetset is, but it is not fully working (like win32/64, GTK2, Qt, Carbon). Since you think LCL is rubbish, I doubt LCL-fpGUI will ever get into fully working state unless someone else makes serious effort to implement it.

Just so you know, I did not start the LCL-fpGUI widgetset. I believe it was Andrew Haines. The biggest lacking widget currently holding back LCL-fpGUI is the TLabel widget. It is that widget which also causes application crashes at runtime when used. TLabel is a classic example of LCL's over engineering and Windows-ism. A seemingly simple widget, yet in LCL it is quite complex to implement. I simply don't have the time [or motivation] to study LCL in depth to figure it out. Implementing the other LCL widgets [I have contributed a few] was actually pretty simple.

And I'm sure he will get full support from you, despite what you think of LCL.

Of course. If anybody wants to work on LCL-fpGUI and needs technical information about fpGUI, I will gladly help out where I can.

It is normal that LCL-fpGUI cannot reach the full functionality of fpGUI itself, but having it as fully working LCL backend will be just enough for the need I am talking about.

I've always believed that a fully implemented LCL-fpGUI widgetset will be hugely beneficial to the Lazarus project. I know I would instantly recompile the Lazarus IDE to use fpGUI instead of GTK2 or Qt.

[skalogryz]

I didn't start the fpGUI project, I found it [abandoned] in a FPC repository.

Huh. Learn something new every day!
I always considered you the author of the library.

[marcov]

I didn't start the fpGUI project, I found it [abandoned] in a FPC repository.

Huh. Learn something new every day!
I always considered you the author of the library.

No, that was Sebastian Guenther. And fpgui was a rewrite of earlier OO gtk wrapper fpgtk to also have non GTK windows support. He also had a stab at writing an own delphi like lib "KCL" and ide "Kassandra", but that took too long, and fpgtk and fpgui were written because he needed GUIs for his business quickly.

The last time I spoke him, he said he was amazed how far Lazarus has come and said he was using it.

Sebastian also did quite some work on the early Delphi related libraries (sysutils, classes, fcl-base), working together a lot with Michael. They also collaborated on fcl-passrc/fpdoc I think, but I'm not entirely sure there, it might be all Michael.

[serbod]

Age of text consoles. Pascal was plain (without objects and interfaces), with inline assembler. Comfort way to deal with low level hardware/OS.

Age of text/graphics CGA, MS-DOS. TurboPascal/ObjectPascal is objective-based. TurboVision library. Comfort way to deal with interactive forms.

Age of graphics GUI desktops, MS-Windows. Delphi, VCL. Comfort way to develop GUI applications with database connectivity.

Age of networks. Client-server applications. Delphi up to 7 with wide set of components for GUI, networking and database. Comfort way to build almost any system for business.

Age of multimedia. DirectX, DirectShow. Almost not implemented in Delphi.

Age of web (HTTP). Web pages become interactive - Flash, Java, JavaScript. Almost not implemented in Delphi.

Age of portable devices. Small screens with big and simple controls. Not implemented in Delphi.

Age of clouds. Backend for web, distributed computing, hot-swap virtual containers. Not implemented in Delphi.



What can we do? Complete multimedia and web support. There is many libraries and components, but they not included in Lasarus.

Designed in IDE must be works on any local and remote device or browser without extra attention from programmer. Portable devices and web pages need some fundamental modifications in LCL/VCL - virtual controls connected to remote datasource, grids of controls. "Widgets - Data Object - Storage" model.

See TTreeView and TListView - you care only about items contents and order, not for they coordinates, rows, columns and fonts sizes and styles. Sizes can be changed by user or automatically on whole list/tree resize. And virtual list not contain any data, it just show data from some source. You don't need to synchronize data in visual list and inside code. Same in "Data Controls", but they works only with tables, not with single objects.

Distributive cloud computing in virtual containers is very promising, but still too young and evolving. May be PascalScript with simple variables/functions export/serialisation/marshalling will help.