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
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

I don't know. This is what is written in the readme of freeq.
JohnK
Posts: 279
Joined: Sep 01, 2005 5:20
Location: Earth, usually
Contact:

Re: RAD for Linux (in development)

Post by JohnK »

There are several gui-designers like Visual mingw studio and others, all similar like fbedit. They produce .rc and .res files. Then i started with FreeBasic. Here i found Firefly and FreeQIDE. It works with RapidQ, which is oop, could be of interest here:
Actually FreeQ is still being worked on - I was going to improve the FB target portion. Here is the source code
http://rapidq.phatcode.net/FreeQ/

FreeQ is Win32 or WINE only, but you can freely use the source code for your needs.

Details of the RapidQ compiler are not known but likely use the widget (VCL) library from the Delphi / C++ Builder 32 bit compiler.
RapidQ language is very similar to FreeBasic but FB is more powerful in many ways. I really like the GUI for RapidQ, which is kind of like your Linux RAD ideas here. Although RapidQ had a Linux distro that used GTK for Linux, that part has been abandoned long ago.

I need more 'energy' to make a RapidQ like GUI library for FB. Maybe someday
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

The designer with the many widgets i mentioned before is a separate program called "RapidFRM.exe" in the folder "FreeQ/tools". It can be started with rightclick/open with/wine windows atarter on Mint 18.2 (if Wine is installed). The produced forms can then be exported as FB-code.

Oops, now it is crashed when saving. But it should be possible to copy and paste the code in geany...

Anyway, it all relies on winapi, so it is not what munair is doing. :-)
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by marcov »

Well, Munair has stated his work is modelled after Delphi/Lazarus too VCL/LCL (which is a winapi wrapper originally, but had enough abstraction to make it somewhat portable)

Anyway, regardless of backend, the important bit is to find out if FB has ways to create an own independent wrapper of something that shields users from the widgetset. IOW can FB sufficiently abstract an interface? And if not, what is missing (and I bet on RTTI and variables containing class types).

In an earlier discussion events also came up. Delphi style events are near rock bottom (basically fields that hold references to <instance,method> tuples), methodpointers so to speak) but if you want more, like typed arguments or multicast, then some work there is also needed.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

marcov wrote:IOW can FB sufficiently abstract an interface?
IMHO it can. Thats what Munair plans to do. The usage of oop results in a kind of own language inside FB, like RapidQ did. It's hierarchy tree started with QObject. From there all other windows and widgets were derived. A RapidQ-program then looked like that:

Code: Select all

$TYPECHECK ON
$INCLUDE "RAPIDQ.INC"
'
Declare Sub Paint
'
Dim Bitmap As QBitmap
'
CREATE Form AS QForm
    WindowState = wsMaximized
    Create Canvas as QCanvas
        Align = alClient
        OnPaint = Paint
    End Create
END CREATE
'
SUB Paint
    Canvas.FillRect 0,0 ,Form.ClientWidth,Form.ClientHeight,&H999999
    Canvas.Draw (0, 0,Bitmap.bmp)    
END SUB    
'
Form.Show

ShowMessage ("Will Display The Picture")
'
Bitmap.BMP = "images/example.bmp"
Paint
'
Form.Visible = False
Form.ShowModal

But sadly it was not used by many. I believe his oop approach is not what the average FB-user wants. He wants simple procedural programming like it once was.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

lizard wrote:I believe his oop approach is not what the average FB-user wants. He wants simple procedural programming like it once was.
It is quite difficult if not near impossible to write complex software with procedural programming. FreeBASIC supports full OOP for a reason. Objects make things much more flexible, easier to patch and adjust. It is easier programming because there is clear structure and cohesion. A common problem with procedural programming is conflicting identifier names, which can only be tackled by using specific prefixes for things that belong together. And in general, with procedural programming most definitions and identifiers are exposed.

OOP doesn't impose a separate language within FB. Definitions and identifiers are the same as with procedural programming. The only difference is that a procedure is part of an object, so instead of

Code: Select all

ShowWindow(handle, 0, 0, 400, 200) ' user defined procedure 
one writes:

Code: Select all

dim w1 as TWindow = TWindow() 'constructor loads default properties
w1.Show() ' procedure is a specific window property
And when changing properties like:

Code: Select all

WindowTitle(handle, "Untitled")
one writes:

Code: Select all

w1.Title = "Untitled" ' Title is a property and immediately changes the title on assignment.
As you can see there are many advantages with OOP. It is non-trivial IMO.
Last edited by Munair on Dec 11, 2017 18:57, edited 1 time in total.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

But if you look at the examples in this forum, less than 5% use oop.
JohnK
Posts: 279
Joined: Sep 01, 2005 5:20
Location: Earth, usually
Contact:

Re: RAD for Linux (in development)

Post by JohnK »

After writing a gui-heavy program like FreeQ, you will really appreciate OOP.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by marcov »

lizard wrote:But if you look at the examples in this forum, less than 5% use oop.
Nearly none truly use event driven GUI programming either. So that is nothing to do with OOP :-)
lizard wrote:I believe his oop approach is not what the average FB-user wants. He wants simple procedural programming like it once
was.
Having an OOP lib somewhere doesn't hinder them in their efforts of creating procedural GUIs after their own choice.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

Just want to say, we can use the experiences from RapidQ and its designer-program. The widget system seems interesting there. Many are non-visual. Output can be both oop (RapidQ) and procedual (FB).

It would be even be possible to adapt the surface of RapidQ and change the underlying winapi to gtk. Then it could work on both Windows and Linux.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

lizard wrote:But if you look at the examples in this forum, less than 5% use oop.
That's because there is no RAD for FreeBasic like there is for FreePascal. However, a RAD for Linux is not necessarily meant to pursuade current FreeBasic users. First and foremost it is meant to attract a wider audience and make working with the FreeBasic compiler more interesting. There are also many Linux users who would like to see something similar to REALbasic (the free version with the old interface). The current alternative I know of - Gambas - is not going to do that because it is an interpreter and not very user friendly.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: RAD for Linux (in development)

Post by speedfixer »

lizard wrote:
But if you look at the examples in this forum, less than 5% use oop.

I think examples are intended to be simple, so not much OOP in them.
And, I think those that ARE using OOP are a little farther along in programming skill and you see them less often in the forums. I'm sure they are out there.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: RAD for Linux (in development)

Post by caseih »

OOP design lends itself fairly well to UI toolkit design, but you really don't need to use OOP in your own program to take advantage of UI toolkits. In fact the "is composed of" paradigm is far more useful for using GUIs than the "is a" paradigm. My GUIs contain widgets more often than I want to make a new widget by extending an existing widget.

Inheritance is traditionally used to implement polymorphism. That is to say that if a base class defines a particular method, you can easily call that method on any instance of a descendant class, even if you aren't even sure of the actual class. The method call goes to the base class part of an object and bubbles up to the actual class. But it turns out that there are other ways to achieve this idea without resorting to inheritance. At least in some languages. I watched a very interesting presentation on this. The presentation was entitled, "Inheritance is the base class of evil." Basically he makes the case that interface contracts are far more useful and clean than inheritance. This idea fits very well with a language like Python where you have duck typing. It's a bit more awkward in C++ where you have to use some template black magic. And I don't think FB would support this sort of paradigm at present. The core principle is that it shouldn't matter what the inheritance tree is. You should be able to call a method on any object that implements such a method. For example, if you have a collection of objects, you should be able to call "draw()" on each of them, regardless of their actual classes.

Anyway I found it interesting, especially as I'm working on a large Qt project in C++ that uses a lot of class inheritance, and I see how unwieldy inheritance can get.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: RAD for Linux (in development)

Post by lizard »

I don' think people come to FB to program in oop. If they want to do this they go to C++. Thats oop-paradise. But why are Gtk, linux-kernel and few other programmed in plain C, not C++? Because oop tends to make programs slower and unclearer. Each function call costs time and space. If you program something without any function call it will always be faster than the same with oop and a lot of methods. Many users of FB know this, because they are using assembler and have a deeper understanding of programming.

Often you read nowadays, speed doesn't matter anymore, because the hardware has become so fast. Naturally this is pure nonsens. Speed matters and always will.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: RAD for Linux (in development)

Post by Munair »

Classes and inheritance are very powerful tools and they are fast if one knows how to use those tools correctly. Where OOP becomes slow is when programmers become lazy or careless as a result of which multiple calls are made to objects without necessity. For example, when a Window is instantiated, often multiple calls are made to the same code, either by design flaw, or because programmers put the code in the wrong handler or call them multiple times without realizing it (by naively modifying properties).

Before I used REALbasic, I primarily programmed with QuickBASIC and VB. VB at the time was not truly OOP but I didn't care much about that since I was used to procedural programming since the days of QB. (I remember in the late 80s Borland came out with C++ 3.0 for DOS, which supported true OOP; it gave me headaches reading about objects and inheritance).

By 2006-2007 I started to look for advanced development tools for Linux. There pretty much weren't any, except REALbasic. So I gave it a try. I downloaded the user guide and reference guide and found it to be really easy to use, despite OOP, classes and inheritance. If there is one RAD in the last 15 years that made the concepts of OOP programming easy to understand and use, it was REALbasic. If you had an idea about some program, you could turn it into reality within a few days with a cross-platform, native looking program as a result. There is a very good read about it underlining my experience: http://loewald.com/blog/tag/realbasic/

In every way imaginable, the FreeBasic compiler has the power of the REALbasic compiler and more; it comes closest to QB and it produces fast, small programs.

The reason why Linux programmers stick to C is because it is the traditional language in the Unix world where programming always took place at the command prompt and with bare-bone text editors. Another reason is that the predominating UI toolkit is GTK, that is used natively in C. The downside is that it takes long(er) to develop powerful/complex software and that it requires deep knowledge of the complex GTK toolkit (or any other UI toolkit of choice). It is also more difficult to maintain programs. The recent Thunar bug with renaming files is a perfect example; they just didn't seem to be able to get it right, despite the different patches offered by the community. But because Linux is open-source, programmers do not care about that much; they're not getting payed for it and they're perfectly fine with a bit of coding in their spare time. There are no consquences if the program/update/patch isn't finished before some time. As a result we often see bug reports dating back several years still without solved-status.

Linux desktop OSs are superior in many ways, despite (or perhaps thanks to) being non-commercial. My recent bad experience with Windows 10 is just another confirmation. But software development in Linux traditionally has a slow pace and is not for the beginners or even intermediates. In the old days of DOS one could have fun with QuickBASIC because it was way easier than C or C++, even easier than Pascal. Writing complete programs then was possible, even for beginners. At the time I developed an IDE that supported syntax color highlighting with text UI controls that allowed me to write programs more quickly. I still miss that on Linux with a Basic-like programming language. FreeBasic allows to do the same, so the choice is simple. The beauty is that with RAD one can always choose between procedural programming (as in a traditional IDE), and full objected oriented programming, depending on need or preference.
Post Reply