Personally I would use FB more if it had a powerful and simple GUI.
1) I really appreciate lots of developers coming up with their own GUI, BUT this is more confusing as they may be incomplete or specific to one OS. At some point FB may compile on Android and MacOS...
2) I agree adding more keywords to FB is not needed. HOWEVER, making a powerful GUI (even using libs) may require changes to the compiler.
3) More important than the lib ('subsystem') is a standard "BASIC language" implementation of the GUI. I discuss this at the bottom.
For instance, a lot of "Basic" code on the web is implemented in either Visual Basic (VB5/6) and Visual Basic.NET. Personally I find .NET is overboard on Inheritance Objects and becomes very unreadable. On the other hand I find RapidQ makes coding easier than VB5/6. Therefore, I propose a GUI standard leans towards VB or RapidQ for the sake of easy project importing and readability but this is a group discussion.
Let's look at some VB code:
Code: Select all
Begin VB.Form Form1
Caption = "Equation Solver Demo"
ClientHeight = 8385
ClientLeft = 60
ClientTop = 345
ClientWidth = 6315
Begin VB.TextBox txtDisplay
BeginProperty Font
Name = "Courier New"
Size = 8.25
EndProperty
Top = 120
Width = 6015
Height = 4215
Left = 120
MultiLine = -1 'True
ScrollBars = 2 'Vertical
End
Begin VB.Frame Frame2
Caption = "Equations"
Height = 3735
Left = 120
Top = 4440
Width = 6015
Begin VB.CommandButton cmdSolveEchelon
Caption = "Solve Echelon"
Height = 375
Left = 3000
Top = 3240
Width = 1335
End
End
End
Now the same with RapidQ:
Code: Select all
CREATE Form1 AS QFORM
Caption = "Equation Solver Demo"
ClientHeight = 838
ClientLeft = 60
ClientTop = 34
ClientWidth = 631
OnClose = CleanUp
CREATE TextBox AS QRICHEDIT
Font.Name = "Courier New"
Font.Size = 8.25
Top = 12
Width = 601
Height = 421
Left = 12
MultiLine = True
ScrollBars = ssVertical
OnKeyDown = TextBox_KeyDown
End CREATE
CREATE Frame AS QPANEL
Caption = "Equations"
Height = 373
Left = 12
Top = 444
Width = 601
CREATE cmdSolve AS QBUTTON
Caption = "Solve"
Height = 37
Left = 300
Top = 324
Width = 133
OnClick = SolveIt
End CREATE
End CREATE
End CREATE
cmdSolve.OnClick = SolveOtherProblem.
I have no idea how to implement this format in a MACRO. Each Widget becomes a child of the preceding BEGIN (or CREATE) by automatically setting it's Parent. Furthermore, the Fonts are automatically a PROPERTY in widgets that use text! The callbacks in FB will need the address pointer to a sub/function. Also the PROPERTY SET / GET need to be addressed. RapidQ makes this very simple.
Now, I HIGHLY recommend using an existing GUI lib ('subsystem') rather than writing a new one -- they are extremely complicated and hard work to make your own if you want something powerful and professional:
I am leaning towards IUP
benefits - C interface is easier to implement (rather than C++), uses native API if possible (even GTK) and is open source, and compiles Static libs! Many OS supported
Downside - another abstraction layer and can be slow (I honestly don't see how this could be serious).
Next would be FLTK
benefits - DJ Peters put a LOT of effort into the C wrapper for the C++interface, smallish DLLs /so to distribute, open source
Downside - non-native API, C-wrapper needs maintaining, cannot compile as static libs, fewer OS support? I question how long it will be maintained
Next would be WxWidgets or GTK
Downside - C-wrapper needs maintaining, cannot compile as static libs, large and complicated DLLs /so to distribute, I question how long it will be maintained for C-Wrapper. Some say GTK is simple, but personally I find it very frustrating to read.
Now waiting your input. Happy new year.