Part 3 Action "the GUI library"

[angros47]

This is what happens when people try desperately to port their Linux software to Windows, without having the faintest idea how Windows works. And they need over one GIGABYTE of "tools" to make a hello world proggie build and run. No thanks. Therefore, seriously: Use a very simple, BASIC syntax, and let the Linux crowd decide themselves which "toolbox" they want to use to implement MessageBox(0, "A text", "A title", MB_YESNOCANCEL).

Then, please, make a tool that is Windows only, and stop intervening in this discussion that is about a cross-platform GUI library.

[jj2007]

I don't know from where you get the idea that the many Linux distros are the cause of bloated frameworks.

No, it's the other way round: There are "GUI frameworks" because there is no common usable GUI API that works with the many distros that share the family name "Linux". These "frameworks" perform what the bloated but built-in GUI API does on Windows - fine for me. But don't ask that Windows users accept to put another bloated API on top of one that works already perfectly. Get your stuff done, in Linux.

[Munair]

I don't know from where you get the idea that the many Linux distros are the cause of bloated frameworks.

No, it's the other way round: There are "GUI frameworks" because there is no common usable GUI API that works with the many distros that share the family name "Linux". These "frameworks" perform what the bloated but built-in GUI API does on Windows - fine for me. But don't ask that Windows users accept to put another bloated API on top of one that works already perfectly. Get your stuff done, in Linux.

You are mistaken. Qt was one of the earliest attempts (1990) to bridge the gap between OSs at the time (Windows, MAC and Unix). When the Linux kernel was developed (1991) and the first Linux distros were born (1993), developers started to look for a suitable GUI library to build a desktop. Fortunately, by 1995 Qt had picked up on Linux/X11 allowing the development of the KDE desktop (1996). So Linux did not reinvent anything. It used a GUI library that was already available to Windows, MAC and Unix. So don't blame Linux. Blame Microsoft and Apple instead, and perhaps IBM for developing incompatible operating systems. If they had chosen to use UNIX, the world of OSs would be much simpler today. But things are complicated because of commerical interests and proprietary software, not because of the open-source Linux philosophy.

[marcov]

But I do really mean that you have shown no sign of understanding Windows or understanding its security situation.

That's because you don't read. Among other things I referred to raw sockets, which you ignored, and dll injection, which you seem to trivialize as only a local threat.

Which it is. of course most exploits are combinations of external and local exploits (first to gain access, then to elevate privileges), but nothing in that entire traject is windows specific.

And it could happen on Linux too if users downloaded binaries from the web all the time.

Install a good firewall with component management or even better, a separate manager, and you will see what processes can do and how vulnerable Windows is. I'm not sure about Windows 10 as I have not tested it thoroughly; my initial experience with not excepting the legal product key (error code 0xc0020036) was already enough for me.

In general, what I monitor on Windows with regards to processes (among other things):

- protection of physical memory
- process termination/modification
- global hooks
- rootkit/driver/service installation
- registry DLL injection
- raw sockets (preferrably disabled)

I also run without antivirus, and only occasionally walk through processes etc. Not failsafe, but I simply eliminated most threat vectors. I don't run cracked software or other dodgy software. I had one virus and two worms (code red and nimda) in twenty years, and both worms were during new installs, not normal (patched)situations. Since then I ran service packs always local first before connecting to the web.

For the average user, it wouldn't be workable to monitor these things.

With Linux I never have any of these problems. Yes Linux has LD_PRELOAD, but the difference is that on Linux only the execution environment per user is affected and the user already has the same privileges so it doesn't make any difference. Moreover, installing software from known repositories will never put the system in danger.

If you favour that view, you can configure windows 10 now to only install from the store.

Additionally, open-source software is transparent and one knows what it does.

Not really. I actually had compromised Linux servers in the past, and nearly always this was a result of atypical installation of software packages, where some packages (re)set fs permissions wrongly. Some packages require quite sensitive manual configuration. Some combinations requires dragging in from different version or backports repositories that increase risk.

The package systems have grown, and is quite stretched and problems are too easily dismissed. On many Linux distros you can boot an older, known vulnerable kernel by accidentally touching the arrow keys. (old kernels are only removed from bootmgr based on time, or user action, never on security status)

I stand by what I said before: Linux is superior in many ways. In my opinion a stable KDE desktop gives the user a much better computer experience than Windows; there are loads of options, free tools and apps, it's very user-friendly, very customizable, no need for antivirus, or firewall configuration, no yearly subscriptions. I could go on and on...

And I think you are being unfair. If Linux was used with the same disregard and under the same attack as Windows, it would have the nearly the same problems.

Anyway enough about this. Let's refocus on the other part. For the *nix side of things, why GTK, Why QT?

Qt and FreeBASIC isn't an easy option.

QT has the API hurdle but is has much less bugs, which will be easier when the initial bits are done. Also the API and other details are more windows like (e.g. things like how rects are calculated, iirc gtk adds bevels to the area of the control, keeping the client area equal to the configured control size, while QT, Win subtracts it from the control size (and thus reduces the effective clientarea)

The bloat discussion I would focus on a simple statement of what is good enough? It thrives because never exact good enough bounderies are stated, and people can always whine about toolkit xxx is 10 bytes shorter if you use upx and options XYZ and post edit the linker file and whatever.

IMHO just set 3-5MB for small potato (single form) apps, 7-15 MB for a serious apps are ok ranges to exist IMHO. Less is better, but other requirements(including time to market) take priority before size.

[badidea]

Wouldn't it be weird to focus FreeBASIC on a non-free OS?

QT can't be that slow, even my (Jolla) phone runs it pretty ok. Still I don't think QT is a good match for FreeBASIC. Even if there is some enthusiasm now to create a wrapper (maybe for only a part of the Qt-framework), the enthusiasm is probably gone when QT releases a newer version. And there are possibly licensing issues. I know QT has been discussed before on the forum, but searching for 'qt' is not easy. It did encounter some remarks of D.J.Peters on GUI's https://freebasic.net/forum/viewtopic.p ... 94#p196294 while searching.

The GUI discussion seems to date back to the beginning of FreeBASIC: Bad situation for portable GUI's?

I did play with FLTK example. But ideal would be a designer integrated in an IDE for FreeBASIC. Where you can quickly link between event and code, e.g. "onClick" and position items visually.

[Josep Roca]

But ideal would be a designer integrated in an IDE for FreeBASIC. Where you can quickly link between event and code, e.g. "onClick" and position items visually.

This is what Paul Squires is doing for Windows.

[deltarho[1859]]

One day somebody may start a project to write a #####Basic-ish, non-OO, small, multi-platform GUI library for FB, but it may take time..

Dragging on a bit, isn't it?

In the meantime, Windows members are churning out shed loads of GUI code. Oh wait, maybe not. That will change with a 'multi-platform GUI library for FB'. Oh wait, maybe not.

"Just then they came in sight of thirty or forty windmills that rise from that plain." Was Miguel de Cervantes prophesying Linux distributions? Maybe not. <smle>

[marcov]

Wouldn't it be weird to focus FreeBASIC on a non-free OS?

No, I don't think so. If that would be weird, you could only generate GPL apps with FreeBasic, and that is explicitely not so.

Even if there is some enthusiasm now to create a wrapper (maybe for only a part of the Qt-framework), the enthusiasm is probably gone when QT releases a newer version.

Same goes for GTK, which is actually right before a major transition right now. And GTK is known buggy and in a state of flux. References for that should be easy to find.

My remarks on api simularity might be harder to verify, I got that from Lazarus devels.

And there are possibly licensing issues. I know QT has been discussed before on the forum, but searching for 'qt' is not easy. It did encounter some remarks of D.J.Peters on GUI's https://freebasic.net/forum/viewtopic.p ... 94#p196294 while searching.

There are no license issues anymore since +/- 2010 when QT also went LGPL on Windows. So careful with searching on that, if you find old mails, it might misrepresent the situation. Moreover even the license before wouldn't have mattered, since the licensing issue was QT on Windows and using GTK/QT on Windows afaik is currently not planned by Munair's initiative

Anyway, it was meant as an incentive to look further than just getting started quickly. It is quite a major decision.

[marcov]

I still think QT -windows hybrid is easier than a GTK - Windows hybrid

That fits with your earlier remark here:

So going X11 only mostly means owner drawn, which means making your own widgetset library and linking that in always. It has uses, and doesn't have to be bloated (I think the fpgui guy has gui apps that do something in the 0.5MB range)

So future FB GUI executables will say "hello world" from 500kB onwards, is that your idea? You realise that this is a factor 500 bigger than what a native Windows GUI app really needs?

(Even if so, who cares? I refer to my earlier opinion on the subject:

The bloat discussion I would focus on a simple statement of what is good enough? It thrives because never exact good enough bounderies are stated, and people can always whine about toolkit xxx is 10 bytes shorter if you use upx and options XYZ and post edit the linker file and whatever.

IMHO just set 3-5MB for small potato (single form) apps, 7-15 MB for a serious apps are ok ranges to exist IMHO. Less is better, but other requirements(including time to market) take priority before size.

Still I'll try to answer your question)

Which is why I said that the X11 raw route is a speciality and recommended not to go that (X11 only) way default. Simply because on *nix fb line needs to be distributed. The base widgets are in GTK and QT that are typically shared linked and generally don't have to be distributed on Linux.

I actually favor QT not based on any size argument though, simply because it gives the nicest, long term stable GUIs. Better large good quality applications than small crap.

Note that any abstraction over widgetsets (even if only QT and Win32) in a RAD matter will in the end probably get you in that range anyway. Maybe not for a hello world, but if you use a normal form with a handful of widgets and the framework abstracts pretty good it probably will, that is the price of portability.

If you don't want that, keep on making widgetset specific most minimal guis so that they keep fitting on your 720kb floppies. Might I suggest upgrading to a HDD? :-)

[Munair]

A GTK transition shouldn't be an argument. XFCE is in active development and still partly GTK2. We can safely assume that GTK3 will be around for years to come. Not sure how "buggy" GTK is. GNOME is quite popular and so are other GTK based desktops. KDE/Qt seems to be behind in popularity.

[marcov]

A GTK transition shouldn't be an argument. XFCE is in active development and still partly GTK2. We can safely assume that GTK3 will be around for years to come. Not sure how "buggy" GTK is.

Quite. Things that Gnome and direct associated projects don't directly stress are typically buggy. But to provide a consistent GUI over (win32+X), you need to also use less commonly used calls, something that XFCE doesn't has to.

And add to that that GTK conventions are often different from (QT,Windows), like the already mentioned example how to count a bevel. Not a bug, but still costs a lot of time, and will have to do and debug such issues for every new widget.

Afaik stock GTK/gnome apps more often autosizing forms that are more tolerant to small render differences, often with a automatic scroll option if it doesn't fit. (browser model). Such free flowing model and autosizing hides small issues/variations in rendering. But relying on that means you have to enforce that also on other targets or the avg app won't be portable. These are the little philosophy differences that I'm talking about. XFCE has no problem there since they follow GTK philosophy.

QT is more windows like in that regard.

Another issue, not mentioned in this thread yet, is that QT is better on Mac (though ideally you'd want Carbon or Cocoa there, but that is a hornet's nest that you want to avoid for now).

As said upgrading major versions is often more involved with GTK (though QT also seems to go more in the direction of a browser/css model with qt/switch or what it is called. Mobile influence, it is a big market), so that might be a bit outdated, but it did apply for GTK1->GTK2 (complete rewrite) and GTK2->GTK3 (somewhat smaller, but still involved, so much that lazarus is still GTK2 default )

For XFCE, GTK is probably more central to their mission statement than for us.

GNOME is quite popular and so are other GTK based desktops. KDE/Qt seems to be behind in popularity.

True. And Android is 5 times popular than iOS. So iOS must be worse in quality? Think not. Check what developers on a somewhat fixed/finite timeschedule choose (commercial linux work, but also e.g. OSS programmers doing open projects for government or unis ), not what distro count says. That might be a better metric, since it measures what they expect to be easier.

In all fairness, GTK can be done. Lazarus/GTK2 exists (GTK3 somewhat works, but required massive debug effort, so its adaptation is still slow). I just think that for just a X/Win hybrid X=QT is way easier long term than X=GTK, though the initial starting might be a bit more involved. I dig this from memory, and suggest you do your own research based on these hints.

[jj2007]

keep on making widgetset specific most minimal guis so that they keep fitting on your 720kb floppies. Might I suggest upgrading to a HDD? :-)

The point here is that Windows doesn't need QT or GTK or whatever "framework" is around: It is built into the OS. Linux needs them, and nobody else. Using QT on Windows is like installing a second OS on top of one that maybe has its flaws but it works fine. The QT applications I have seen on Windows (very few, actually) look a bit strange, but I could tolerate that. However, they are horribly slow, and often they do not work properly.

That is why I think it is not a good idea to turn FB into a behemoth driven by the problems of an incomplete OS (if you can call it "one OS" - "Linux" seems a loose category for a dozen OSes that aren't even compatible to each other).

The solution is damn simple: Define a syntax for "MessageBox" (that seems to be in demand, see MessageBox() for linux?) or whatever, and let the OS use its native functions. If it has native functions, that is - on Linux you need the help of a "framework". On Windows, you don't - the GUI toolbox is already installed, on hundreds of Millions of user machines. I can imagine that this is difficult to accept for Linux fans, but sorry, that's life...

Btw I managed to produce a 0.5 MB Windows executable, it's here. Not sure if guests can download it, though.

[JohnK]

I was hoping this thread would lead to a lot of collaboration *yea team !!!! Let's DO IT Yea..." Then reality set in. I would really like to get back to the original post...

I think a consensus is forming that a comprehensive GUI framework that looks a lot like VB6 will not happen. That is ok, because now I know not to spend the time on a GUI framework that looks like VB6 or RapidQ. Those who program windows will use Win32 API with current tools (despite FB being a 64-bit compiler) and those that use Linux will go another way. BUT I have to still insist on these points:

Qt will still require a HUGE C-wrapper and that will cause sample code to break -- a team of devs would need to maintain it. Really sorry but I am not signing up for that.

I still believe that IUP offers the simplest solution because of its relatively small size, static compiling, simple C interface, active development with open source, and the fact it can target Win 32/64, Linux (although with a limited set and ugly look), MacOS, and Android. However, we can just use native IUP calls rather than wrapping a VB6 language around it. If anyone has a better answer that would be great.
JK out

[Munair]

Linux needs them, and nobody else.

I still think you get the wrong impression. Qt isn't around because of Linux. It's around because programmers wanted a common interface that works on all platforms. The Linux community simply decided not to write yet another API, which was a smart move. As a result, Linux desktops are highly customizable, replaceable and can even be deleted from the system if only a command line interface is required, like with servers.

[Munair]

Qt will still require a HUGE C-wrapper and that will cause sample code to break -- a team of devs would need to maintain it. Really sorry but I am not signing up for that.

Getting Qt to work in FB is A LOT of work and probably not worth the effort. By the time you have a basic setup, Qt probably comes out with a new version which would require VERY active maintenance. Look at Lazarus. AFAIK they support Qt 5.6, but Qt has already moved to newer versions. It simply wouldn't be doable.

I still believe that IUP offers the simplest solution because of its relatively small size, static compiling, simple C interface, active development with open source, and the fact it can target Win 32/64, Linux (although with a limited set and ugly look), MacOS, and Android. However, we can just use native IUP calls rather than wrapping a VB6 language around it. If anyone has a better answer that would be great.
JK out

The disadvantage of IUP and similar solutions is that you end up using three layers: FB, IUP and its underlying widget set.

The best solution would probably be to use GTK for Linux and the Win API for Windows. This would require different developers working on a common Component Library.