Part 3 Action "the GUI library"

For other topics related to the FreeBASIC project or its community.
JohnK
Posts: 279
Joined: Sep 01, 2005 5:20
Location: Earth, usually
Contact:

Part 3 Action "the GUI library"

Postby JohnK » Dec 31, 2017 23:00

While Part 3 is taken up by sound library i am starting a thread on action on a much more global GUI standard for freebasic:
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


As you can see RapidQ is more compact and you can set the events ('callbacks') in line with the GUI creation -- but you don't have to. You can also DIM multiple objects and then assign them to any other widget by setting a 'Parent' Note that all widgets can have their own events callbacks or even one huge SUB to handle all requests -- it's up to you. You can dynamically change the events callback by doing this:
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.
Dinosaur
Posts: 1310
Joined: Jul 24, 2005 1:13
Location: Searcy AR USA
Contact:

Re: Part 3 Action "the GUI library"

Postby Dinosaur » Dec 31, 2017 23:29

Hi All

I am not proposing cgui should be in the list, BUT look at the simplicity of the code to create a window
and place a button which calls another window or routine.
Note that the #Alphabet loads a picture called Alphabet onto the button.
@Button1 is the routine called from that button press.

Code: Select all

Sub Main_window2 Cdecl (Byval userdata As Any Ptr)
    IF Tabs.Win2 < 1 Then   'if we havent already drawn this window
            ScreenColor
            Get_BigFont
            Tabs.Win2 = MkDialogue( Cgui_Adaptive, "-TOOLS-",CGUI_W_NOMOVE)
               Button.Alphabet = AddButton( CGUI_DownLeft OR CGUI_EqualWidth, "#Alphabet", @Button1, NULL)
               ToolTipText(Button.Alphabet,"Set Names for Inputs / Outputs.")
               MkGroove()       
            Button.Closing   = AddButton(CGUI_DOWNLEFT OR CGUI_EqualWidth, "#Close", @Close_Window, @Tabs.Win2 )
            SetWindowPosition(220,38)
            DisplayWin()
         Else
            SetFocusOn(Tabs.Win2)
    EndIf
End Sub


Regards
angros47
Posts: 1539
Joined: Jun 21, 2005 19:04

Re: Part 3 Action "the GUI library"

Postby angros47 » Jan 01, 2018 0:02

The RAPIDQ interface is simple, and it could be easily implemented using the current OOP features, with no need to modify the compiler.

The problem is another one: which GUI should be used? Windows has its own GUI, so under Windows there would be no issue, but under Linux there are several possible libraries: GTK, FLTK, Qt... which one should be used? Many of them have a version for Windows, too, but using the same library on Windows would introduce a dependency on external DLL that could have been avoided by using only Windows native functions.

So, the best solution would be to write a default library, that on windows wraps the default GUI, and on Linux offers interface for both GTK and Qt, always using the same syntax (that could be similar to RapidQ). Or this library could even create its own minimal interface (as it's done by the default library in HotBasic: no specific GUI library is required, under Linux, just X11).

So, a custom GUI library for FreeBasic would require more work, but in theory, it would be the best solution, since there would not be the need to decide if the most suitable GUI library is GTK, QT, FLTK or anything else.

This solution poses only one problem, described here: https://xkcd.com/927/
marcov
Posts: 2806
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Part 3 Action "the GUI library"

Postby marcov » Jan 01, 2018 2:14

JohnK wrote:Now waiting your input. Happy new year.


Some things to think of in your syntax:

  1. Some objects might only want reference another component. (e.g. a db aware widget to its db connection). Not all references can be handled by nesting
  2. If you don't specify a property what happens then?
  3. Syntax for creation initial is nice, but you still need to do some form of streamed loading/saving
  4. template forms, aka visual form inheritance ( a base form, e.g. with a statusbar and a menu, from which to inherit certain other forms)
  5. denseness of the syntax is not THAT important since most work is/should be done using generators or, better, two way form designers.

Is the VB code actual code or some streamed format ?
marcov
Posts: 2806
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Part 3 Action "the GUI library"

Postby marcov » Jan 01, 2018 2:23

angros47 wrote:So, the best solution would be to write a default library, that on windows wraps the default GUI, and on Linux offers interface for both GTK and Qt, always using the same syntax (that could be similar to RapidQ).


Correct, that would be best.

angros47 wrote:Or this library could even create its own minimal interface (as it's done by the default library in HotBasic: no specific GUI library is required, under Linux, just X11).


That is also correct, the trouble is that forces you to owner drawn, and the widgets look crappy and out-of-touch. And if you manage to get them somewhat looking ok (e.g. own theming engine), some major distribution changes the theme and you can start over.

Still, you could implement such minimal X11 interface also in the first case. (Like Lazarus with supports multiple widgetsets Win32 (GDI), GTK,QT but also a partially done owner drawn that paints its own widgets on a canvas, with then again opengl,X11, opengl, GDI etc drivers).

Handpainted widgets will never look or feel native (for long), but it is a nice level 0 fallback, and useful for some things that don't have to look native like POS terminals

So, a custom GUI library for FreeBasic would require more work, but in theory, it would be the best solution, since there would not be the need to decide if the most suitable GUI library is GTK, QT, FLTK or anything else.


I would vote win32(gdi), since usually the downloads are 70% windows and in business even more. Maybe the second would be one of the ones you name, and I'd pick QT. It has downsides too (Mock, C++ interface), but is more stable and looks nice, and is a default at least on some of the distributions.

GTK is close to a major version transition btw.

This solution poses only one problem, described here: https://xkcd.com/927/

[/quote]

I think it is good to have an ideal to strive for. One could keep the custom GUI library thin, and then start to expand.
JohnK
Posts: 279
Joined: Sep 01, 2005 5:20
Location: Earth, usually
Contact:

Re: Part 3 Action "the GUI library"

Postby JohnK » Jan 01, 2018 6:31

the VB code actual code or some streamed format?


Actual code that you would get from a download archive. I find it very handy to be able edit widgets by text in addition to visual designers. I am very interested in seeing how this thread grows
dixiony
Posts: 29
Joined: Jun 22, 2017 15:21
Location: Volgograd, Russia

Re: Part 3 Action "the GUI library"

Postby dixiony » Jan 01, 2018 7:26

You do not need any bindings to QT, GTK+, FLTK, .NET, etc. There is a Windows API and that's enough. You do not need to make a monster from a FB with any libraries that the executable file will need. You need a very good IDE, nothing else is needed.
Munair
Posts: 836
Joined: Oct 19, 2017 15:00
Location: 't Zand, NL
Contact:

Re: Part 3 Action "the GUI library"

Postby Munair » Jan 01, 2018 7:47

dixiony wrote:You do not need any bindings to QT, GTK+, FLTK, .NET, etc. There is a Windows API and that's enough. You do not need to make a monster from a FB with any libraries that the executable file will need. You need a very good IDE, nothing else is needed.

That would limit FreeBASIC to the Windows plarform.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: Part 3 Action "the GUI library"

Postby lizard » Jan 01, 2018 9:10

dixiony wrote:There is a Windows API and that's enough.


Completly disagree. FreeBasic itself is platformindepent and it should stay that way. I am not only thinking of myself and Linux that i am using at the moment. I was a dos/windows freak most of my life. But now it's over for several reasons. I may even become a Mac user in future or take another system.

Windows covers only a small part of the computer world, but FreeBasic should work on each computer existing since most will be compatible to the three big OSes Windows, Linux and Mac.
jj2007
Posts: 1263
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Part 3 Action "the GUI library"

Postby jj2007 » Jan 01, 2018 9:38

dixiony wrote:You do not need any bindings to QT, GTK+, FLTK, .NET, etc. There is a Windows API and that's enough. You do not need to make a monster from a FB with any libraries that the executable file will need. You need a very good IDE, nothing else is needed.
That is an extreme position, of course. FB has chosen to be platform independent, though. The problem seems not so much the Windows API, but rather the absence of something comparable in the Linux World.

Look at what QT needs to produce the equivalent of a Windows "Hello World" GUI application. A standalone exe (i.e. no extra dlls installed on the user's machine) arrives at 8 MB or so - ridiculous. The reputation of FB would be seriously damaged if users were confronted with either exes of that size, or the need to download huge dlls.

I have no experience with Linux, so I hope an expert is around who can explain if it is possible to create a simple GUI application with system libraries only. What about X11, can that be used as the equivalent to the Windows API?

lizard wrote:Windows covers only a small part of the computer world
Which part of the computer world is relevant for FB? Does it make sense to promote FB on smartphones, for example? I have no answer yet, just asking.
Last edited by jj2007 on Jan 01, 2018 9:44, edited 1 time in total.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: Part 3 Action "the GUI library"

Postby lizard » Jan 01, 2018 9:42

JohnK wrote: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.


For the GUI i would vote to not take it into the core of FB at the moment. There are several reasons:

1. GUIs are quickly changing like the OSes they are designed for. Every few months there are new versions.

2. It would be way to much work to maintain all that over decades.

3. Old Versions quickly become outdated or simply don't work anymore.

4. It bloats FB to much and many will not even use this GUI but another.

5. Additional libs must be loaded to the core. This should be avoided to beware the clarity.
jj2007
Posts: 1263
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Part 3 Action "the GUI library"

Postby jj2007 » Jan 01, 2018 9:53

lizard wrote:1. Guis are quickly changing like the OSes they are designed for. Every few mothns there are new versions.

This little GUI app builds and runs with an identical source code of 75 lines on the current OS and on the version that was current over 16 years ago. The executable has 51,200 bytes (yes, bytes, not kBytes).
Image
Munair
Posts: 836
Joined: Oct 19, 2017 15:00
Location: 't Zand, NL
Contact:

Re: Part 3 Action "the GUI library"

Postby Munair » Jan 01, 2018 9:55

jj2007 wrote:
dixiony wrote:I have no experience with Linux, so I hope an expert is around who can explain if it is possible to create a simple GUI application with system libraries only. What about X11, can that be used as the equivalent to the Windows API?
X11 can be used, but the interface doesn't look appealing at all because it would bypass the installed desktop environment and associated theming engine. Simply put, it wouldn't look native. For Linux, the GTK and Qt desktop are still the best options if you want to give your application a native look and feel. Also, GTK or Qt wouldn't bloat your software. They are very much comparable to the Windows API to which you would make calls to show windows. Installing GTK or Qt on Windows would be like installing additional API's. you wouldn't compile them into your application. What make executables big is when RAD systems support cross-platform multiple widget sets, like Lazarus or REALbasic (Xojo) do. Those systems easily generate a 3 to 5 MB executable for a simple "hello world" application. The advantage you get in return is that your code will compile cross-platform without modifications.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: Part 3 Action "the GUI library"

Postby lizard » Jan 01, 2018 10:12

jj2007 wrote:I have no experience with Linux, so I hope an expert is around who can explain if it is possible to create a simple GUI application with system libraries only. What about X11, can that be used as the equivalent to the Windows API?


A serious user on Linux will end up at Gtk or Qt sooner or later. But it is not the easiest solution. For smaller projects there maybe other GUIs more handy. Thats why one never comes to a final decision about GUIs on Linux. X11 itself is designed only as windowmanager. so one can't create programs with this alone, AFAIK.


lizard wrote:Windows covers only a small part of the computer world
Which part of the computer world is relevant for FB? Does it make sense to promote FB on smartphones, for example? I have no answer yet, just asking.


I think FB should work on each existing computer. If it is useful on Smartphones i don't know. Main Target would still be normal Windows, Linux or Mac Pcs.
Last edited by lizard on Jan 01, 2018 10:14, edited 1 time in total.
jj2007
Posts: 1263
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Part 3 Action "the GUI library"

Postby jj2007 » Jan 01, 2018 10:14

Munair wrote:Also, GTK or Qt wouldn't bloat your software. They are very much comparable to the Windows API to which you would make calls to show windows. Installing GTK or Qt on Windows would be like installing additional API's. you wouldn't compile them into your application.

Can you post a QT application that runs on Windows without me (dumb user) having to install additional software (dlls etc)? I mean, a real standalone executable? I am curious. What I have been told so far is that this is not possible.

As a developer, you don't care how bloated FB becomes with "additional API's".
As a software seller, your clients will tell you what is acceptable.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest