Forum > General
The future of Free Pascal
SymbolicFrank:
Well, Delphi is as good as dead. And, to be honest: good riddance. As the developments of the last ten years were nothing to write home about.
That does ask a question: without a Delphi lead, and Lazarus following and pushing specific Free Pascal changes, is there an overall goal where Free Pascal wants to go? Or is it over and done as well?
Like the ASML management said: at some point, all the competition was behind us, so we were the ones that had to come up with a good plan.
I can think of multiple expansions, although it is debatable if you would want to incorporate it in Free Pascal, or make a Lazarus library for it.
1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications. That would be the Apple way. Chance of success: low, without a strong and visible lead.
Why is this in this list, and on the first place? The main bottleneck is a unified compilation platform. No specific syntax, like with Objective Pascal or the JVM target. And coming from that, the incompatible event and widget models. And it would make the most difference in establishing Free Pascal / Lazarus as one of the main development platforms.
2. A slick, anti-aliased and zoomable OpenGL application GUI. Especially the text. That is easy to port, runs everywhere and looks much better than the current, pixelated ones. That would score major points with the customers of your applications. And it would be a requisite for the previous point.
3. Platform-agnostic, message-driven multitasking and multi-threading. Or, in other words: distributed processing.
Wow, tech alert! What is wrong with the current, event-driven one? Well, it doesn't scale beyond a single computer and CPU core. And the speed of that single thread/core barely increases over the hardware generations.
This happened more than ten years ago. Everyone expected, at that time, that by now every application would run across many computers and CPU's. But that didn't happen. Because everything is still single-thread based. There is very little development done in distributed processing. Mostly because there is this push going on for the last 15 years to web-based and mobile, which makes that futile. And so everything has stagnated over that period.
This is the best option to set Free Pascal / Lazarus solidly on the map from a technical perspective.
Well, I have more, but those are (IMO) the most important ones. And yes, I will help.
Graeme:
Free Pascal has for many many years come up with its own ideas and goals - it doesn't need Delphi to survive. Yes they tried to keep Delphi compatibility, but that is mostly to win ex-Delphi developers, or allow Delphi developers to target platforms Delphi never will.
As for your points (1) and (2) - take a look at fpGUI Toolkit. For years it already does what you describe, plus I've used it in many commercial application too. So its proven stable. As for an OpenGL backend - that can easily be written, but not by me. I don't like a GPU requirement for a desktop application. Saying that, 2 or 3 years ago somebody was working on an OpenGL backend for fpGUI. I never followed their progress, but if you search the fpgui.support newsgroup will should be able to find some URL or a contact email.
mse:
--- Quote from: SymbolicFrank on March 16, 2016, 11:10:19 pm ---1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications.
--- End quote ---
That already exists since more than 10 years (MSEide+MSEgui):
https://sourceforge.net/projects/mseide-msegui/
There is also fpGUI:
http://fpgui.sourceforge.net
--- Quote ---2. A slick, anti-aliased and zoomable OpenGL application GUI. Especially the text. That is easy to port, runs everywhere and looks much better than the current, pixelated ones.
--- End quote ---
MSEgui has an experimental OpenGL backend. Although I must say that OpenGL is a nightmare to serve as GUI-backend. There are so many different implementations, all with different limitations, extensions and bugs. Especially for text. ;-)
--- Quote ---3. Platform-agnostic, message-driven multitasking and multi-threading. Or, in other words: distributed processing.
--- End quote ---
I'll probably will implement such elements in MSElang:
https://gitlab.com/mseide-msegui/mselang/wikis/home
Currently I am developping MSElang with LLVM backend for the Free Pascal dialect used in MSEgui. The quality of the code which LLVM produces is impressive. The compiling speed not so much...
Personally I think use of parallel computing will be limited to special tasks because its complexity normally is not worth the effort. Most of the Applications are fast enough if they use well written libraries without the need of parallell computing.
--- Quote ---And yes, I will help.
--- End quote ---
You could implement a shader based OpenGL backend for MSEgui. The necessary functions:
--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- gdifuncty = (gdf_creategc,gdf_destroygc,gdf_changegc,gdf_createpixmap, gdf_pixmaptoimage,gdf_imagetopixmap, gdf_getcanvasclass,gdf_endpaint,gdf_flush,gdf_movewindowrect, gdf_drawlines,gdf_drawlinesegments,gdf_drawellipse,gdf_drawarc, gdf_fillrect, gdf_fillellipse,gdf_fillarc,gdf_fillpolygon, gdf_drawstring16, gdf_setcliporigin, gdf_createemptyregion,gdf_createrectregion,gdf_createrectsregion, gdf_destroyregion,gdf_copyregion,gdf_moveregion, gdf_regionisempty,gdf_regionclipbox, gdf_regsubrect,gdf_regsubregion, gdf_regaddrect,gdf_regaddregion,gdf_regintersectrect, gdf_regintersectregion, gdf_copyarea,gdf_getimage, gdf_fonthasglyph, gdf_getfont,gdf_getfonthighres,gdf_freefontdata, gdf_gettext16width,gdf_getchar16widths,gdf_getfontmetrics ); That would be a big help. The MSEide+MSEgui code is here:
https://gitlab.com/mseide-msegui/mseide-msegui
Zoran:
--- Quote from: SymbolicFrank on March 16, 2016, 11:10:19 pm ---
1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications. That would be the Apple way. Chance of success: low, without a strong and visible lead.
Why is this in this list, and on the first place? The main bottleneck is a unified compilation platform. No specific syntax, like with Objective Pascal or the JVM target. And coming from that, the incompatible event and widget models. And it would make the most difference in establishing Free Pascal / Lazarus as one of the main development platforms.
--- End quote ---
About 1 - yes, with FPC, currently, MSEIde/MSEgui and fpGUI are the way to go for unique look and feel across all platforms. They are well written and their maintainers go forward and are willing to give as much support as they can.
However, these are one-man projects. One man develops, one man decides where the project will go... Martin (MSE developer) even decided to create his own one-man developed new Pascal-like language... :)
I think that one-man projects can hardly get wide acceptance you are talking about.
So, as I see it, the farther development of Lazarus IDE is the only chance for wide acceptance.
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. But only as an option - the "native" way must stay.
--- Quote from: SymbolicFrank on March 16, 2016, 11:10:19 pm ---And yes, I will help.
--- End quote ---
There are two attempts to make this possible - fpGUI-LCL widgetset and CustomDrawn LCL widgetset. They are far from finished and currently not usable for serious development. The development of the fpGUI-LCL seems to be abandoned and the development of CustomDrawn also doesn't seem to move fast...
So, if you want to help, the way to go would be to take one of these two and commit to its development.
For the fpGUI-LCL widgetset, I think that if Graeme (fpGUI developer) doesn't get interested to seriously involve in this (and as I see he is not much interested) you will have hard time... and for CustomDrawn... I don't know...
marcov:
All points have some merits, but IMHO none of them is a core part.
1 and 2 are not Lazarus points, and the other toolkits do all kinds of owner drawn work, so that is their turf.
I'd like to see a OpenGL toolkit for embedded GUIs, and thought about it (because some of my work app GUI is opengl), but there are practical issues to consider.
The problem is while many will pay lipservice to the concept, there probably is internal division. Some dream of fancy animated driven GUI that I don't care about at all, and because we generally only deliver new developments on new hardware, I wouldn't mind setting a quite high minimal level for the GPU (like Haswell, or even Skylake). Sandy bridge has a defunct geometry shader, and Ivy Bridge's is slow.
As for 3, I don't see any reason for this to integrate with the GUI. It seems to me you have not exhausted the existing library options yet (like omnithread or Bero's), and expect to carry on doing Delphi like apps with just multimachine and threads thrown in.
That will never happen. Any significant expansion of the scope of a framework usually brings a new way of working, and more constraints.
For portable opengl font handling, you can borrow from my signed distance fonts demo
Navigation
[0] Message Index
[#] Next page