FreeBASIC GUI

[Berkeley]

FreeBASIC should have a unified, platform independent GUI system.

Some really crazy people may agree that

Code: Select all

MESSAGEBOX "Hello !"

might be better than

Code: Select all

#IF Defined(__FB_WIN32__)
#include "windows.bi"
MessageBox(0, "Hello !", "", 0)
#ElseIf Defined(__FB_LINUX__)
...

Something like this MESSAGEBOX would be a wrapper function for any OS resp. library. This means, that what MESSAGEBOX will do depends on what library you/the compiler includes. You may draw your messagebox even on your own, with LINE or even characters of a console. But in principle it will just work in the compiled binaries without any changes on Windows and Linux if (figurative) "windows.bi" or "linux.bi" are included. For example put/link its code in "wxwidget.bi" for wxWidget message boxes.

Draft:
MESSAGEBOX <String text>[, <String title>][, <ENUM flags>[, <String buttons>]], <ByRef ENUM returnvalue>
(assuming int beeing "returnvalue", not "flags" if parameter list is string(, string), int)

Flags for icons(sounds) and standard buttons => NONE, ALERT, QUESTION, INFO, STOP, ERROR; OK, OKCANCEL, YESNO, SAVE, RETRY... Further, you may label buttons on your own. Ideally, the message box is fully integrated in the platform's GUI and its look&feel. But it might also enhance the GUI by adding new standard options like "Save"/"Don't Save"/"Cancel". The strings are UTF-8 encoded, line break code is 13 (\r), support of soft-hypen and automatic linewrap.

The button string is e.g. "Left|Up|Down|Right", e.g."R_ight" defines (and might show) R as a hotkey. (no need to implement everything, just regard => remove underscores) Return value is 0 to 4, almost normally depending on the button's number. If the platform thinks, "Okay" should come after "Cancel", it will be, but the return values are always the same. You can specify a default value (hit Return) by setting the return value to the button number resp. its return value. In user-defined buttons you can further use " _" at the beginnig for Return(default button) as hotkey, "0_" for Escape. Such codes will be hidden. As default, also "1"-"4" are hotkeys for the buttons.

Standard return values:
0 - CANCEL, ABORT [CLOSED?]
1 - NO, RETRY, DONTSAVE [BUTTON1?]
2 - SAVEALL, IGNORE [BUTTON2?]
3 - OK, YES, SAVE [...]
User-defined buttons simply return 1-4 for the respective button. 0 is false, 3 is binary "11" and therefore most like true. 0 could also be returned on error / closing the dialog window.

flags (ENUM DIALOGFLAG):
32 ALERT, 64 STOP, 96 QUESTION, 128 INFO, 224 ERROR
0 "OK" (NONE / OKONLY)
1 OK Cancel (OKCANCEL)
2 Yes No (YESNO)
3 Yes No Cancel (YESNOCANCEL)
4 Save Don't_Save (SAVEDONTSAVE)
5 Save Don't_Save Cancel (SAVECANCEL)
7 "Cancel" (CANCELONLY)
8 Save Save_All (SAVEALL)
9 Save Save_All Cancel (SAVEALLCANCEL)
12 "Retry" (RETRYONLY)
13 Retry Abort (RETRYABORT)
14 Retry Abort Ignore (RETRYIGNORE)
The return values should be also part of the DIALOGFLAG type, therefore "OK" is named "OKONLY" for instance.

You might also have a waiting dialog and progress-bar dialog, but the message box and fileselect-dialog are elementary for a BASIC like FreeBASIC.

[Berkeley]

The second elementary GUI function is FILESELECT. A dialog to select a file for loading or saving / to browse the filesystem for files.

Syntax:
FILESELECT [<String title>,] <String path>[, <String file filter>] [,ENUM FILEATTRIB flags], <ByRef String selection>

"Title" is a (UTF8) string like "Save Document", you might use "%IDS_SAVEFILE%" or "%IDS_OPENFILE%" for a localised string. "Path" a FreeBASIC path, where "" means the current directory. You may also use wildcards here like "*.txt" and omit the file filter parameter. The file filter is a string list for file patterns to search, using the wildcards * and ?. "TXT,STR,INI" is enough to get the same result as with "*.TXT,*.STR,*.INI" - extensions are expected as file type filters. You may further use group IDs like "#TEXT" for all text files, "#BINARY" for binary files, "#BITMAP" for bitmap files e.g., "#ALL" is just the same as "*.*" or "*". Linux works case-insensitive, i.e. you'll get "INFO.TXT" as well as "info.txt", even "info.TxT", but all files together, if existing. Note, that folder names should be written correctly resp. keep them in lower case for Unix systems.

"Flags" are file flags, where only HIDDEN and SYSTEM will work ("HIDDEN+SYSTEM" resp. more correct "HIDDEN OR SYSTEM"). May be just aliases for "fbHidden"/"fbSystem".

The selection variable will contain the selected file and can contain a preselection for the dialog. If you put a comma at its end, the fileselection dialog will allow multiple selections resp. if you don't, it will supress multiple selections. If hit "OK", returns a string list of files with full FreeBASIC path resp. one file name with full FreeBASIC path. On error or "Cancel" returns "". The selection variable should be a dynamic string of course. Otherwise too long results will produce an error => empty return string.

The realisation doesn't matter again. If the destination platform doesn't have any fileselector title, you may add one manually or you simply have none. The dialog may show own descriptions like "text document" for "TXT" files. It might be part of the platform or manually created, even just textconsole-based. What you'll get depends on the ".bi" file you are including. The source code won't have to be changed in any way.

[jakobssystems]

Well, as somebody coming from Xojo I can tell you "crossplatform" GUI does not work. When talking about Default File or MsgBox Dialog, which one? On Windows you have multiple ones to choose from Win32, UWP, .NET and on Linux it strongly depends on your WM and Theme. Your App will be alien on all platforms and in the end of the day you will still need to deal with Compller Directives e.g. If fPlatform=Linux then..

I would rather like to see integrations into modern IDEs an UI Builders like VS Codium, Gnome Builder or Glade with GTK3/4 bindings and comprehensive tutorial.

[marcov]

Well, as somebody coming from Xojo I can tell you "crossplatform" GUI does not work. When talking about Default File or MsgBox Dialog, which one? On Windows you have multiple ones to choose from Win32, UWP, .NET and on Linux it strongly depends on your WM and Theme. Your App will be alien on all platforms and in the end of they you will still end up with Compller Directives e.g. If fPlatform=Linux then..

Yes, it won't be a blind recompile, but that doesn't make the result useless.

I would rather like to see integrations into modern IDEs an UI Builders like VS Codium, Gnome Builder or Glade with GTK3/4 bindings and comprehensive tutorial.

I always despised the GTK cruft. For many reasons, but general buggy-ness and bad long term stability (specially after GTK2)

[Berkeley]

Well, as somebody coming from Xojo I can tell you "crossplatform" GUI does not work.

There's no reason for that. Only, that an executable won't work forever. At least you have to compile it again for a new platform. The libraries must be updated/adapted, not the programs.

When talking about Default File or MsgBox Dialog, which one?

Whatever you like. That's the knack: we define ONE syntax working for all, the libraries are implementing this function to show those dialogs as defined. If you don't have an error symbol, it might be added for the destination platform or you use the alert symbol instead. And you may write your own message box dialog e.g. for a computer game, looking like a scroll of parchment.
- Still using the same syntax. MESSAGEBOX is just a wrapper for the real function, translating the parameters for the destination API.

You will still need to deal with Compiler Directives e.g. #IFDEF __FB_LINUX__ ...

But in the LIBRARY, NOT your application. You have only to demand the rules that will be applied on the destination platforms. Like "make a 640x480 canvas and draw a line". Such will work on any platform unless you exceed the possibilities of the destination platform. But you have to be smart. For instance, you must not demand the size of dialog elements, you have to describe the dialog like an HTML document. The sizes and arrangements should be calculated by smart algorithms. This way you won't have to draw your dialogs for each language again either.

Really tricky is to reconcile all "look & feels" of the destination platforms. For instance, that Alt+F4 kills an application in Windows, while Command+Q in MacOS. Especially the application menus are differently arranged: while Macs have the "Settings" under the "<CurrentApp>" menu, Windows hides them in "Extras". But it is all doable. Just don't create everything without thinking about. - And you can't avoid to do things "manually". Every GUI normally has primitive drawing functions you might have to use instead of the canned functions, to create the functionality demanded.

[jakobssystems]

This is why I love free software... everybody can do whatever he/she wants to

[paul doe]

FreeBASIC should have a unified, platform independent GUI system.

No. The compiler is already hard to port as it is; imagine if you had to deal with GUI nonsense. That's what libraries are for. QB64, FreeBasic is not.

[jakobssystems]

FreeBASIC should have a unified, platform independent GUI system.

That's what libraries are for.

GTK for instance

[Berkeley]

FreeBASIC should have a unified, platform independent GUI system.

No. The compiler is already hard to port as it is; imagine if you had to deal with GUI nonsense. That's what libraries are for. QB64, FreeBasic is not.

FreeBASIC is more than the compiler. And if you would have read the posting you'd understand that it's all about FreeBASIC libaries. I'd even don't want PRINT hardcoded in the compiler. PRINT should be replaceable by manually written functions, especially because the hardcoded version doesn't support UTF-8. A compiler/interpreter should only have instructions like "IF" hardcoded, data types and such - the BOOLEAN type for instance :-p

A GUI standard would be an abstraction layer to proprietary libraries, you'd become able to switch from GTK+ to wxWidgets simply by replacing #INCLUDE "gtk.bi" with #INCLUDE "wxwidget.bi". Something that happens ideally when you compile a BASIC program for Linux. Your PRINT is a very different machine code under Linux than under Windows...

[paul doe]

What you suggest (an abstraction layer for a GUI) is nothing new, and it was already implemented with varying levels of 'success'. If you try to do it, I think you'll quickly realize why it is usually futile.

[demosthenesk]

hey, have you tried window9 lib gui https://www.freebasic.net/forum/viewtopic.php?t=17058
it is for windows/linux

[Berkeley]

What you suggest (an abstraction layer for a GUI) is nothing new, and it was already implemented with varying levels of 'success'. If you try to do it, I think you'll quickly realize why it is usually futile.

Because everyone programs for Windows, and the only FreeBASIC examples are telling you to use MessageBox from windows.bi... Noone cares whether their program works on other platforms or new Windows versions. Programming should be circumstancial and incompatible.

[paul doe]

Because everyone programs for Windows, and the only FreeBASIC examples are telling you to use MessageBox from windows.bi...

There's a cross-platform library above your previous post. Have you tried it? It does exactly what you're suggesting (serve as an abstraction layer for a specific implementation). How is your suggestion any different/better?

[jakobssystems]

What you suggest (an abstraction layer for a GUI) is nothing new, and it was already implemented with varying levels of 'success'. If you try to do it, I think you'll quickly realize why it is usually futile.

Because everyone programs for Windows, and the only FreeBASIC examples are telling you to use MessageBox from windows.bi... Noone cares whether their program works on other platforms or new Windows versions. Programming should be circumstancial and incompatible.

I honor your wishes and objectives. But reality isn't like this (as I said, I am coming from Xojo)

I rather develop on Linux and crosscompile for Windows and Linux (and even do my testing with wine) and fine with GTK+ which looks wonderful and quite the same on both platforms. Take Python written PDFArranger as example (https://github.com/pdfarranger/pdfarranger).

Maybe Avalonia is something more suitable? By the way, somebody did a great job:
https://devclass.com/2024/11/12/visual- ... t-for-fun/

[Berkeley]

Because everyone programs for Windows, and the only FreeBASIC examples are telling you to use MessageBox from windows.bi...

There's a cross-platform library above your previous post. Have you tried it? It does exactly what you're suggesting (serve as an abstraction layer for a specific implementation). How is your suggestion any different/better?

There should be a standard messagebox and fileselector, you shouldn't have to include/install a library for. In a GUI enviroment, message/alertboxes are like PRINT on the C64/DOS.

My suggestion is indeed better because you can use the same MESSAGEBOX instruction as you've been used to and might get the GTK+ or whatever version when you include a GUI library. On the other hand you won't patronise one to use a specific GUI framework.