Part 3 Action "the GUI library"

[angros47]

Feel free to add these instructions in the forum, then. But it was not the subject of this discussion

[St_W]

The Linux kernel was developed based on UNIX architecture (hence the X in the name) in a time when NT was still in its infancy and Windows 3.1 was merely an attempt to make DOS more user friendly. Even the first GNU/Linux OSs, Debian, Slackware/SuSE predate any serious Windows OS.

Development of the NT Kernel began in 1989, development of the Linux Kernel began in 1991, so at about the same time. Unix is older and both systems are in parts inspired by it, Linux a lot more than Windows. NT implements some more modern concepts than Linux, but Linux evolved greatly over time due to less importance of backwards compatibility.

[..] UNIX-like systems have been superior from the beginning and they have been around since the late 60s. The difference is, they have never been commercial and were therefore not interesting from a business model's point of view.

I wouldn't say that one of them is superior over the other, they are just different and focus on different things. Various Unix implementations have been used a lot by companies in the old days of computing. It's just the consumer market, that has never been a target for Unix based systems (Android may have changed that).
___

To get a little bit back on the road to original topic of the thread: If a GUI library is created for FB it needs to be based on native libraries of all operating systems it supports. This is the Win32 API on Windows and probably GTK on Linux. I don't think that FB should suggest a third-party GUI toolkit of choice, yet bindings should be provided so that they can be easily used (which is already the case for a lot of them).

[JohnK]

I don't think that FB should suggest a third-party GUI toolkit of choice, yet bindings should be provided so that they can be easily used (which is already the case for a lot of them).

I just suggested that since a lot of the **grunt** work has already been done. Starting from scratch is a lot of work and may never be finished (seen this before). More IUP devs than FB?? Also you bring up a good point -- IUP has both 64 and 32-bit distributions. If we develop Win 32, we will always require 32-bit under WOW?

for some reason IUP doesn't and the interface looks like GTK fallback without theme support.

I am not a Linux guy but maintaining all these different distributions would drive me crazy. I see the IUP has about 12 different Linux packages.

[marcov]

Killed, see below

[Munair]

I suspect you have a gaping deficiency of both Windows, its internals (and how they compare/map to *nix), the administration in a typical department server scenario (let alone a 20000 machine domain, like the said university), and vastly overrate *nix security.

Well, I'm not here to brag, so I'll leave you with your idea of deficiency. Looking at your comments in general, some of them are structurally suggestive in favour of Windows. At other points you seem to misunderstand completely. I will leave it at that.

[marcov]

I suspect you have a gaping deficiency of both Windows, its internals (and how they compare/map to *nix), the administration in a typical department server scenario (let alone a 20000 machine domain, like the said university), and vastly overrate *nix security.

Well, I'm not here to brag, so I'll leave you with your idea of deficiency.

Looking at your comments in general, some of them are structurally suggestive. At other points you seem to misunderstand completely. I will leave it at that.

Likewise. But I do really mean that you have shown no sign of understanding Windows or understanding its security situation. And I did spend time on both sides of the fence.

That said, generalizations are always dangerous. Specific scenarios may lean one way or the other, and even that depending on circumstances. Buying a Windows license for a PHP server might be strange, but if you already pay an admin to look after a bunch of windows boxes it is small potato. In reverse, similar scenarios exist.

P.s. I was already a bit uneasy with the post so I deleted it.
p.s.2 back on topic, I still think QT -windows hybrid is easier than a GTK - Windows hybrid. The apis are more similar, and QT Is less buggy. Though admitted that is mostly experience from QT4 times.

[St_W]

I still think QT -windows hybrid is easier than a GTK - Windows hybrid. The apis are more similar, and QT Is less buggy. Though admitted that is mostly experience from QT4 times.

The probably most important reason why to not choose Qt is because it's written in C++ and provides no C interface. But I agree that it's a very good GUI library (if you're programming in C++).

[jj2007]

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?

[St_W]

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?

When we are talking about Qt I'd rather say 20 MB onwards (or even more).

[JohnK]

One thing to keep in mind is UPX (at least on windows) can compress exe size 2 - 5x smaller without any noticeable performance in launch time.

It seems to me, as pointed out by St_W, that Qt is C++ and doing a C-wrapper would be a lot of work because it is so big. I have looked at FLTK C-wrapper and that could serve as a template... BUT I it will make programming in the library look clumsy -- and the sample code would not work...

I was hoping that FB GUI 'programming style' 'look' would look something like Visual Basic 6 or RapidQ (or ??) Is that not possible? Should I give up on this then?

[Munair]

Development of the NT Kernel began in 1989, development of the Linux Kernel began in 1991, so at about the same time.

Yes, but NT came from OS/2 which was an IBM/Microsoft effort since 1987 and it was initially meant to become OS/2 version 3. While IBM's OS/2 Warp became available as a true 32 bits operating system to consumers, it was not until Windows 2000 Professional that NT (5.0) made it to the PC market. In contrast, influential Linux based distributions were developed and published throughout the 90s. I remember my own first experience with SuSE 4 in 1998.

But this is all not very important. What is important is that Linux is a tremendous non-commerical effort with unmatched flexibility, brought forth by many programmers around the world with a similar philosophy in mind: free, open-source software available to everyone. One can study it, adjust it and one knows what it does. There is no commerical pressure or enforcement.

Today's desktops or GUI libraries are likewise great efforts. And like I said before, I like KDE/Qt because of its professional look and feel, but I prefer GTK because of its license, which better matches the GNU/Linux philosophy. In this regard and also because GTK is extensive and can be used directly in FreeBASIC, I think GTK is currently the best option as a Linux GUI.

[angros47]

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?

Perhaps if you compiled it with XPB!Basic (an old compiler that has been abandoned years ago). But most BASIC dialects produce much bigger executables

[jj2007]

most BASIC dialects produce much bigger executables

Bigger than 500kB? You are not serious... I know the argument is "RAM and disk space don't cost anything", but all that bloat under the hood slows everything down. This morning, when I tested QT Creator, I got the creeps - it is unbelievably slow, similar to VS Community. It would be horrible if FB became like that. Bloat is not only dead code, it is usually also a symptom for lousy code architecture. My editor loads its own source (20k lines) in under a second, it builds in 1.2 seconds. For every character that I typed in QT Creator to change an edit control text, I had to wait 2 seconds to see an effect. CRAP.

[angros47]

I am serious: XBasic produces executables of about one megabyte, RapidQ of at least 300-400 kb , QB64 produces executables of about 600 kb (that requires additional DLLs, too), BlitzBasic of 900kb and more. Check yourself if you don't believe

[Josep Roca]

But not Free Basic... unless you begin to add crap to it. See this application (FBPiano), made with my WinFBX framework. Size: 110 Kb.

http://www.planetsquires.com/protect/fo ... 2#msg31242