marcov wrote:
First, one really should think about why binary size in the single MBs really matters. Does it really matter if the binary is 2,3,4 MB if you put it on a 128GB SSD or a 4TB harddisk or transfer it over a modern pipe?
I know it doesn't really matter, and to the world of Windows it certainly doesn't (read Microsoft bloat). But the spirit in the Linux world is quite different. In many ways it is still connected to the days of DOS and also to the efficiency and superiority of UNIX systems. Windows has never come close in this respect. If a Linux nert sees a 3 or 4 MB exe it will wonder what the heck is all in there -- unless it is a full-featured app that can account for the large size. I understand from a Laz dev point of view, it is ok if it just works (compiles cross-platform). To give you an example, PureBasic compiled one of my programs against GTK to a few hundred KB, while Laz took 3-4MB (as did RealBasic). That's a difference many programmers take seriously, or won't even accept, especially with the packing of distros in mind.
marcov wrote:If the next FPC and Lazarus generate very small (16-bit) windows 3.1 GUI binaries, will you run them? (not a theoretical question btw) If no, size is not everything :-)
I don't agree. It isn't a native interface (see next comment) and compiling for it would therefore be totally out of place, regardless of size, not to mention it being 16bit.
marcov wrote:Even then, a Lazarus solution on Windows is smaller than a GTK or QT installation. Anyway, in the future you can shared link the LCL and install that over package managers. See above :-)
A GTK or Qt installation (in Linux) is very much part of the operating system and all software benefits from it (like the Windows API). You can choose what software to install (100% Gtk or Qt or a mix of both). Compare that to the many .NET libraries, different versions stacked on top of each other to meet all the installed software requirements. It easily takes many 100s if not Gigs of diskspace. Regarding the LCL, it would be pretty much on its own and only support the software compiled against it, although the idea is actually not bad.
marcov wrote:All your arguments were made in 2000 by fpgtk, the precursor of what is now fpgui. And look where they are now. Still one person project, a whole rewrite further, while Lazarus is an household name.
The person behind fpgui (I checked the project once more recently) took the wrong turn when choosing its GUI. Since the days of the first Macintosh programs need to integrate nicely into the OS desktop interface. One shouldn't even begin to try to set oneself apart. Yet this is exactly what fpgui did. Its webpage reads:
"toolkit that doesn't rely on any huge third party graphics libraries like GTK+ or Qt. It talks directly to the underlying graphics system (GDI, X11 etc)." This is doomed to fail. I can imagine that it was a challenge to develop and to distinguish itself. But from today's OS's point of view, totally uinteresting. Perhaps it would have been interesting in the days of DOS as a competitor to Windows.
marcov wrote:I have an even earlier Linux trauma. About 17 years ago Kylix came out. Deployment is important, but the problem is not size, but dependencies and versioning, combined with the fact that Linux sales are always below par, which makes the Linux port very expensive/sale.
Here we touch on a topic that has created quite some tension: social attitude vs commercial gain. Yet, the world of computers, smartphones etc have greatly benefit from Linux and still does. We wouldn't be where we are today without the Linux kernel, despite its open-source philosophy. Looking at how large companies profit well also thanks to Linux, were all the contributors payed in accordance to their attributions? Definitely not! But I agree that in the early days dependencies caused a lot of problems on Linux based OSs. My first experience was in 1998 when OpenSUSE 6.4 was widely distributed and sold as a Windows replacement. The installation was a HELL having to choose which packages to install and ensuring that all dependencies were met. But those days are over. Especially Debian contributed greatly with Synaptic. These days it actually takes a bit of effort to break the system. ;)
marcov wrote:I did Delphi,Lazarus, C# (.NET 2.x) . VS C++ (rougly 2005..2017) and Java, and tested RB and VB6 in their time.
IMHO RB closed more doors than it opened. If you had a major problem, that was it, no solutions.
RB was developed from CrossBasic in 1996. It took a long time before the compiler became more mature; it was not until 2007 that structures (UDTs) were supported, and even then nesting of structures crashed the system. I seriously started to use RB in 2009 and have been with version RB2011r4 up until the present. I joined the forum and learned a lot from some very knowledgable people. Most problems were solved, except for a few that were Linux dependent and had no priority with the makers. I developed good programs with ease. Unfortunately, in my opinion, RB continued to suffer from an inefficient compiler, even though they had great class and interface support and a pretty good debugger too. But the main thing is: I still very much like the concept of its UI. It's nothing like the FB IDE attempts. Of course, it's always open for debate. Some programmers prefer to code everything by hand, even if a single button click would be faster. It's always a matter of taste
marcov wrote:I don't really see what your approach is different from the other widgetset specific attempts. Or how it is RAD.
Would you be able to setup a RAD system from scratch within a week? Specific GTK bindings for FB are outdated or not even existent. In fact many FB things are outdated, which is a sad thing. C headers require translation, wrappers need to be written. The screenshots I provided thus far show the most fundamental step: the code editor. While translating the essential GtkSourceView bindings, I also made sure the widget is integrated in an OOP manner, wrapped within a FB language object. See this thread (
viewtopic.php?f=3&t=26113&p=239477#p239458). In the process, things need to be figured out according to FBC's capabilities, which I'm not yet 100% familiar with. But FB actually allows me to do OOP things I wouldn't think were possible. Establishing an object hierarchy takes time and patience. Once there, other widgets are easier to integrate. So what you have currently seen is not all that will be visible for the programmer, except for the code editor. So be patient...