BASIC Studio for Linux (Cancelled)

User contributed sources that have become inactive, deprecated, or generally unusable. But ... we don't really want to throw them away either.
Post Reply
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux

Post by marcov »

St_W wrote:
Munair wrote:In any case, from a practical point of view, current GUI development is for GTK. In time, Qt might be added.
Using Qt from FreeBasic will be quite troublesome as it offers only a C++ API, afaik. You would need some wrapper library or some hacks to access the Qt methods from FreeBasic. GTK in contrast offers a C API which can be used from FreeBasic directly.
This has been discussed before. (IIRC see "Big Bundle" discussion). It hinges on how close you use the widget set. If you want to offer all of QT to the user, this is very complex. However a subset like Lazarus uses requires a fairly small, and fairly stable subset.
Munair wrote: I was already wondering about that. So the idea might be dropped altogether. The C API from GTK and Linux in general makes FreeBasic a great language for the platform.
I don't think it is really RAD philosophy to expose users that just want a GUI to GTK internals and glib object models.

Anyway, as long as it is for Linux only, it matters less, but from what I learned from 20 years on the Lazarus maillist is that QT is more stable, both usage and apiwise (small GTK version updates often break things, seems that anything that is not directly stress by the current desktop iteration is ill defined and buggy) And QT is a lot more usable on OS X and Windows than GTK.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: RAD for Linux

Post by caseih »

Can LCL from Lazarus be ported to or used from FB?

Lately I've been doing some GUI development with QtQuick, which is a new declarative UI system introduced by the Qt Project, and that seems like it would be quite easy to wrap in a C wrapper and use from FB, since only a very small number of classes need to wrapped and accessed. QtQuick is definitely a departure from the classic UI toolkit, and I'm still not sure how I feel about it!
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: RAD for Linux

Post by St_W »

marcov wrote:If you want to offer all of QT to the user, this is very complex. However a subset like Lazarus uses requires a fairly small, and fairly stable subset.
How does Lazarus access the Qt APIs - is there already some sort of C wrapper for that? If so, it could be probably used for FB as well.
//edit: seems caseih had similar thoughts at the same time :-)
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux

Post by Munair »

I believe writing a new RAD with and for FreeBasic will give it most flexibility not having to rely on predefined stuff. It would be 100% generic to FreeBasic.
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: RAD for Linux

Post by St_W »

Munair wrote:I believe writing a new RAD with and for FreeBasic will give it most flexibility not having to rely on predefined stuff. It would be 100% generic to FreeBasic.
I agree, but that's also a lot of work.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux

Post by Munair »

St_W wrote:
Munair wrote:I believe writing a new RAD with and for FreeBasic will give it most flexibility not having to rely on predefined stuff. It would be 100% generic to FreeBasic.
I agree, but that's also a lot of work.
Indeed, but I enjoy very much what I'm currently working on. See also this thread: viewtopic.php?f=3&t=26113#p239458
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux

Post by marcov »

caseih wrote:Can LCL from Lazarus be ported to or used from FB?
Not really (even C++ needs extensions for that), but design principles carries, and if you get to some base level of analog architecture you might be able to borrow large amounts of code.

My point is not so much reusing the LCL, but getting rid of having 8 different FB initiatives for GUI, for various widgetsets.

So more the principles of LCL, specially having an own, native GUI abstraction that talks to the widgetset , rather than letting the gore of the external widgetsets(and its external object model) spill into the user''s newly written GUI code. AND, more importantly for the user to have to start over when one GUI projects wanes, and the next one rises.

This makes users wary of investing in GUI. The downside is that the initial effort is more work, before sharing generic code starts to pay off.
Lately I've been doing some GUI development with QtQuick, which is a new declarative UI system introduced by the Qt Project, and that seems like it would be quite easy to wrap in a C wrapper and use from FB, since only a very small number of classes need to wrapped and accessed. QtQuick is definitely a departure from the classic UI toolkit, and I'm still not sure how I feel about it!
Personally I don't like many of those new web like toolkits. It is hard to make effective use of your screen (not terribly densely packed, bad for overview and minimizing interactions to accomplish tasks), and the beginner friendliness doesn't really pay itself back with the limited number of users.
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: RAD for Linux

Post by St_W »

marcov wrote:My point is not so much reusing the LCL, but getting rid of having 8 different FB initiatives for GUI, for various widgetsets.
Regarding universal standards ... https://xkcd.com/927/ ;-)
Such a GUI (abstraction) framework would have to be developed by several people with a common goal. Previous GUI initiatives were usually one-man projects and thus didn't last very long.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux

Post by Munair »

marcov wrote:My point is not so much reusing the LCL, but getting rid of having 8 different FB initiatives for GUI, for various widgetsets.

So more the principles of LCL, specially having an own, native GUI abstraction that talks to the widgetset , rather than letting the gore of the external widgetsets(and its external object model) spill into the user''s newly written GUI code. AND, more importantly for the user to have to start over when one GUI projects wanes, and the next one rises.

This makes users wary of investing in GUI. The downside is that the initial effort is more work, before sharing generic code starts to pay off.
I agree with that up to a certain extent. Indeed, when I look at the current projects providing some kind of IDE or even a GUI for FreeBasic, the majority seems targeted at Windows (probably easier to do) and there's more than one of them. But none of them come close to what Lazarus offers.

Indeed, a native GUI abstraction is preferred, encapsulating the underlying widget set(s). The hard part currently for me is to wrap the widgets inside a hierarchy of FreeBasic objects effectively and efficiently. It takes some discipline and thorough thinking not to distract from that and take short-cuts to get the job done more quickly because undoubtedly you will have to pay for that sooner or later.

On the other hand, LCL with its cross-platform capabilities inevitably generates larger executables. It is probably one of the reasons why serious programmers prefer C or even C++ or similar solutions that create faster and smaller binary files. This is one of the reasons why my target is currently Linux and GTK as widget set. Qt and WxWidgets have become huge and I will also not settle for a subset.

Some 7 to 10 years ago I noticed that RealBasic gained quite some popularity with Linux users despite it being proprietary. Finally there was a solution allowing for really rapid application development, not having to rely on C, GTK routines and Glade (don't even mentioned that XML machinery). But here we saw a downside too: not so small exe files due to its cross-platform capabilities.

Throughout the years I have developed software using different RAD tools, like VisualBasic (before .NET)), Delphi, Lazarus and RealBasic. From all these I found the RealBasic interface most appealing because of its simplicity, cleanliness and logic. It allowed for a very short learning curve and very structured programming. One could drag components to the form and define event handlers with unmatched ease. It didn't start complaining about unfound units or libraries when using specific identifiers, which makes things overly complicated and unnecessarily disrupts a programmers workflow.

So here we have the basis for what I believe is a very efficient and elegant software development solution. I was so fond of that RAD environment that I am more than eager to work on a similar open-source solution for FreeBasic. It's a challenge for sure, but not impossible. And despite FreeBasic's lack of full class support (although the current OOP capabilities come close) I regard the FreeBasic compiler superior to the RealBasic compiler in many ways.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux

Post by Munair »

St_W wrote:
marcov wrote:My point is not so much reusing the LCL, but getting rid of having 8 different FB initiatives for GUI, for various widgetsets.
Regarding universal standards ... https://xkcd.com/927/ ;-)
Such a GUI (abstraction) framework would have to be developed by several people with a common goal. Previous GUI initiatives were usually one-man projects and thus didn't last very long.
Agreed. But the problem with a team of developers is often disagreement. We saw that in the early days before Lazarus became a new initiative. Quality control is another issue. It requires disciple and patience to add code consistently. The common goal may be another problem as one may prefer specific features or a different interface design. It usually takes one person to start off a project that will then be joined by others winthin several months or a few years if the project appears promising. The creation of the free pascal compiler is a good example.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux

Post by marcov »

Munair wrote: I agree with that up to a certain extent. Indeed, when I look at the current projects providing some kind of IDE or even a GUI for FreeBasic, the majority seems targeted at Windows (probably easier to do) and there's more than one of them. But none of them come close to what Lazarus offers.
That's another reason to go abstract. Like it or not, to get the majority on board long term.
Indeed, a native GUI abstraction is preferred, encapsulating the underlying widget set(s). The hard part currently for me is to wrap the widgets inside a hierarchy of FreeBasic objects effectively and efficiently. It takes some discipline and thorough thinking not to distract from that and take short-cuts to get the job done more quickly because undoubtedly you will have to pay for that sooner or later.
Yes, that is a two way street. It was for Lazarus too, and they had workarounds till FPC was mature enough. And still, the next Free Pascal version will hopefully finally have a "packages" system like Delphi that allows to register designtime components without recompilation/linking of the whole IDE.
On the other hand, LCL with its cross-platform capabilities inevitably generates larger executables. It is probably one of the reasons why serious programmers prefer C or even C++ or similar solutions that create faster and smaller binary files. This is one of the reasons why my target is currently Linux and GTK as widget set. Qt and WxWidgets have become huge and I will also not settle for a subset.
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?

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

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

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, several maintainers and complete rewrites further, while Lazarus is an household name.
Some 7 to 10 years ago I noticed that RealBasic gained quite some popularity with Linux users despite it being proprietary. Finally there was a solution allowing for really rapid application development, not having to rely on C, GTK routines and Glade (don't even mentioned that XML machinery). But here we saw a downside too: not so small exe files due to its cross-platform capabilities.
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.
Throughout the years I have developed software using different RAD tools, like VisualBasic (before .NET)), Delphi, Lazarus and RealBasic. From all these I found the RealBasic interface most appealing because of its simplicity, cleanliness and logic. It allowed for a very short learning curve and very structured programming. One could drag components to the form and define event handlers with unmatched ease. It didn't start complaining about unfound units or libraries when using specific identifiers, which makes things overly complicated and unnecessarily disrupts a programmers workflow.
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.

C# (and .NET in general) always had the problem that what was recommended was not equal to the current best practice (trying to push people to winforms when they were on VB6, then push to WPF when they were on Winforms, then created an APP platform that didn't host .NET initially etc etc). Java always had the "at arms (or two) length" problem. Nothing was ever native, or could be enhanced to be more native. It was always alien and difficult.
So here we have the basis for what I believe is a very efficient and elegant software development solution. I was so fond of that RAD environment that I am more than eager to work on a similar open-source solution for FreeBasic. It's a challenge for sure, but not impossible. And despite FreeBasic's lack of full class support (although the current OOP capabilities come close) I regard the FreeBasic compiler superior to the RealBasic compiler in many ways.
I don't really see what your approach is different from the other widgetset specific attempts. Or how it is RAD.
Last edited by marcov on Oct 23, 2018 21:45, edited 1 time in total.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux

Post by Munair »

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...
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux

Post by marcov »

(I'll keep it short, I can make a long reply gain about the views on Linux and binary sizes since I don't agree with most of what you are saying(including strange noting as considering QT and GTK runtimes part of OS and .NET not, when both are addons installed via the OS package system), but let's stick to the core points)
Munair wrote:
These days it actually takes a bit of effort to break the system. ;)
Not really. Take the oldest LTS and the newest distro, and voila, trouble enough. And keep in mind that GTK fragmentation is imminent again with GTK4 having been branched off recently.
Munair wrote:
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?
No. But a week would not be the timescale I think I could change something fundamental with FB. The title of the thread is "Rad for Linux", not "new widgets for GTK header".
Munair wrote:
Specific GTK bindings for FB are outdated or not even existent.
I thought TJF's were somewhat decent and GTK3 already. My guess only an year or two old? Of course there will be stuff to enhance/correct.
Munair wrote:
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.
Ok.
We'll see how it ends. Still it is more adding a GTK widget to the headers + demo than a true RAD. 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 easy 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...
I'm montoring that thread. It is a bit fpgtk in feel, but at least having a proper OO hierarchy to talk to with events etc would be a good start.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux

Post by Munair »

marcov wrote:including strange noting as considering QT and GTK runtimes part of OS and .NET not, when both are addons installed via the OS package system
GTK and Qt are not addons on the same note as .NET. And they are usually not installed via the package manager (although they can be), but added while the distro is being built depending on the choice of desktop environment. On Windows this would be the integrated API. But .NET, Visual C++ or other runtimes come in addition to the API depending on installed software requirements (they can be many).
marcov wrote:Take the oldest LTS and the newest distro, and voila, trouble enough.
No reason to mix distro's. We have virtual machines these days to try out different OSs.
marcov wrote:No. But a week would not be the timescale I think I could change something fundamental with FB. The title of the thread is "Rad for Linux", not "new widgets for GTK header".
In the first post it says: "I am thinking about developing a RAD against GTK specifically for Linux similar to RealStudio..."
marcov wrote:I thought TJF's were somewhat decent and GTK3 already. My guess only an year or two old? Of course there will be stuff to enhance/correct.
They don't include specific widgets like GtkSourceView. Those bindings need to be added.
marcov wrote:It is a bit fpgtk in feel
Funny statement given the fact that the code snippet could come from any development tool's source, RAD or otherwise supporting GTK.
marcov wrote:but at least having a proper OO hierarchy to talk to with events etc would be a good start.
Currently that's main priority and I'm happy to see FB has become mature enough to allow for these kind of OO constructs.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: RAD for Linux

Post by caseih »

Munair wrote:No reason to mix distro's. We have virtual machines these days to try out different OSs.
Also flatpak or snap packages are another solution to the linux distro library version mismatch problem.
In the first post it says: "I am thinking about developing a RAD against GTK specifically for Linux similar to RealStudio..."
Yes on Linux GTK+ is a good choice, especially given it's existing C Api which can be worked with easily from FB.

However I have got to the point where it is no longer my go-to choice for toolkit, unfortunately. The main reason is that right now the projects I'm working on will probably end up being used primarily on Windows (and maybe mac), and possibly android in the future. GTK+'s non-Linux future is always in question. Just today I read on the list that the OS X Quartz backend has no maintainer, so it's not getting bug fixes. The windows backend has a couple of people working on it, but nothing like the Linux backend, which has the full force of Gnome developers behind it.
Post Reply