Sharing some thoughts on programming languages and gui toolkits.

For a long time they even dropped support for the MSVC compiler. Obviously that compiler is fairly underwhelming, unfortunately so many Win32 middleware developers have tied themselves down to it and thus it is generally important to support for GtkWin32.
As an opensource dev, I'd just ignore that, for my own sanity. I remember I had a complete build system for MSVC/VisualStudio available in the first opensource tool of some reasonable size I released, "mkd64". I really lost any interest maintaining it. One of the reasons is that MS doesn't move at all regarding C. It looks like they consider C "obsolete" and C++ the "successor". And, frankly, this is bullshit.

It's of course all different if you do development in an enterprise context. But for me, releasing my C stuff as opensource, I just say: grab MSYS2 to build it yourself on Windows if you want. And if you don't want, that's not my problem.

So, I kind of understand where the GTK guys come from ;)
 
(I am actually a big fan of our internal Gtk2/SDL. It is very portable now and completely cut off from the mad direction and mess that Gnome is going. Gtk2 theme engines are also vastly superior than that CSS nonsense. If I have time, I might see if I can push to get it opened).
That would be a game changer.
 
Hm, reading that quote again: I don't think CSS is "nonsense", but applying it outside the web is questionable ;) As is stuff like "electron". Had to be said…
 
So, I kind of understand where the GTK guys come from ;)
Absolutely but then you get some CUDA, SteamVR or FBX SDK from a vendor that only provides a MSVC .lib and you start having to faff quite a bit.

Not an absolute blocker, (I like faffing ;)). However if you then are trying to integrate *your* middleware as a downstream product, then (even) further downstream then wants MSVC again and their build system is not geared up for mingw64.

Of course, C isn't a problem. This is only C++ and a lack of ABI stability.
 
Isn't that a "critical mass" kind of thing? If all opensource C projects would stop supporting this horrible MSVC ecosystem, vendors would have to move 😈
 
Isn't that a "critical mass" kind of thing? If all opensource C projects would stop supporting this horrible MSVC ecosystem, vendors would have to move 😈
Yeah its a good point. I wish open-source communities would "weaponize" a little more and become a little more opinionated in these kinds of matters rather than compromising too easily.

But ~2005, Microsoft pushed students into believing that the only solution for games was Windows, DirectX, Visual Studio. And we are still trying to undo that ancient damage. This kind of backwards thinking still lingers in the multimedia industry annoyingly. Only now do students no longer riot when told they will be taught OpenGL this semester ;)

Edit: As for CSS. Yeah, CSS for markup is good adequate. However I tend to believe we can do a bit better with proper compiled languages in a native environment that can interact with the underlying system.
But, I could be wrong, GUI building is arguably worse today than it was when VB6 was around XD
 
But, I could be wrong, GUI building is arguably worse today than it was when VB6 was around XD
I assume I know what you mean. All this "declarative" stuff for native GUIs IMHO is heading into the wrong direction. A local GUI just isn't "web". I can just speak for myself: I prefer Qt for native GUI, but when I use it, I never use their "designer" or their specialized file format for GUI description. I just define the GUI programmatically, by creating a nice tree of objects ;)

(edit: and this is really only the GUI frontend, all my "business logic" typically resides in a C(!) library)
 
I avoid also designers.
Yeah, but it can get tedious to do the if-elses... Case 1, you call lib1, case 2, you call lib2, case 3, you call lib3... default, call libX. Those things do grow out of control, even with programming assists like code folding.

Or, trying to create a table for displaying different things. Depending on the toolkit you use, it can be a pain just to find the correct place in the code! and balancing the brackets/parentheses correctly is only part of the equation.
 
Yeah, a designer might be fun to use but think of your poor maintainer 10 years down the line who can no longer get the original designer program compiling and now has to go through all that generated cruft manually to update a button.

Though I do find the current approach of hbox, vbox, hbox, vbox a little tedious to code. And yet when it comes down to it, this row column / table approach to layout still seems the best in terms of resizing.
 
Yeah, a designer might be fun to use but think of your poor maintainer 10 years down the line who can no longer get the original designer program compiling and now has to go through all that generated cruft manually to update a button.

Though I do find the current approach of hbox, vbox, hbox, vbox a little tedious to code. And yet when it comes down to it, this row column / table approach to layout still seems the best in terms of resizing.
10 years down the road, not only the codebase will be different, but it's gonna be a whole different ballgame. Has anyone done a diff on kernel code to load a device driver into memory? What a difference 10 years will make. 10 years ago, 4 GB of RAM was sufficient for newer PC's - nowadays, 16 GB is the norm. Makes you wonder how the Linux kernel was able to run in just 32MB of RAM.
 
Even now, the kernel barely uses much memory; as I know Linux will gladly run on 2G of ram perfectly fine. The part that has been making the memory demand exploding up significantly is more of Firefox/Chrome, and the GUI. It is sad how much memory the web browser takes, just to make it look "pretty".
 
Yeah, late to the party (as always 😂), but i'm going to throw FreePascal/Lazarus in here.
Write once, compile anywhere
Choose WidgetSet (and yes, QT is supported), choose target-platform, hit compile (if you have the cross-compiler installed), have fun.

No test for FreeBSD, but i did write a small program on a Linux-Dev-Machine, moved the source-code onto a Windows-Machine, compiled there, it ran, moved the source-code to a Mac, compiled there, it ran (with one exception because of a very specific component).

The easiest way to install is to use fpcupdeluxe which itself is written in FreePascal/Lazarus
Nota bene: any dependencies have to be installed beforehand (QT, GTK, my dirty socks, whatever)
 
Even if you use a so-called 'cross-compiler', there are still limitations. If the 'cross compiler' lives on FreeBSD, there's very little chance that the resulting binary will run on Windows. Even with Java trying to enter the conversation as a counter-example, you still need to find a JVM to install on Windows first, and make sure the versions match, and this needs to happen before you copy the compiled binary from one system to another.

Even when moving source code from one system to another (From FreeBSD to Windows), you have to make sure that on both systems, a usable compiler is installed beforehand.

HTML5 is pretty nice that way, but it's limited to displaying info, no serious computation like 'Show me 1 + 1' to spit out 2.
 
Even if you use a so-called 'cross-compiler', there are still limitations. If the 'cross compiler' lives on FreeBSD, there's very little chance that the resulting binary will run on Windows.
It would be a fairly rubbish cross compiler if this was the case.
If you have wine installed, you should have wineg++. This is a fairly good gcc / mingw-w64 based cross compiler. There is an older win32 one here too devel/mingw32-gcc.

The clang in base can also output to WebAssembly and Android. Considering that we also have a decent Linux compat layer, FreeBSD actually makes a fantastic build server platform. It can pretty much compile to all common platforms except for locked down macOS (which needs other crap like DRM signatures, provisioning profiles, etc).
 
I worked off and on as a freelancer, jobber, or full-time staff programmer, from 1981 to 2009, mostly using various platform-dependent flavors of BASIC, Assembler, Pascal, and C++, in approximately that order. I attempted unsuccessfully to break platform-dependency using web-based Java applets in the late 80s & early 90s, but eventually abandoned that effort, and from the mid-90s through the early 21st century started leaning more and more towards web-based applications, mainly using PHP-generated HTML in conjunction with CSS, ECMAScript (javascript), and SQL, initially using MySQL, but eventually switching completely over to PostgreSQL, after supporting both for about 2-3 years. Throughout all this time I've done a lot of shell scripting, mostly with ksh and sh, but also dabbling a bit in old-school JCL, and more than a few MS-DOS style "batch" files.

A lot of this thread reads like Greek to me, once again confirming the widely-held notion that any programmer needs to learn new skilllsets every 3 to 5 years just to keep up.
 
Even if you use a so-called 'cross-compiler', there are still limitations. If the 'cross compiler' lives on FreeBSD, there's very little chance that the resulting binary will run on Windows. Even with Java trying to enter the conversation as a counter-example, you still need to find a JVM to install on Windows first, and make sure the versions match, and this needs to happen before you copy the compiled binary from one system to another.

Even when moving source code from one system to another (From FreeBSD to Windows), you have to make sure that on both systems, a usable compiler is installed beforehand.

HTML5 is pretty nice that way, but it's limited to displaying info, no serious computation like 'Show me 1 + 1' to spit out 2.
I think you misunderstood: The crosscompiler of FreePascal creates native target-binaries


No VM needed

And FreePascal/Lazarus comes with native compiler(s) for each ( ! ) Dev-Platform
Reason: The compiler is self-hosted (a.k.a. the compiler itself is written in Freepascal)
 
I think you misunderstood: The crosscompiler of FreePascal creates native target-binaries


No VM needed

And FreePascal/Lazarus comes with native compiler(s) for each ( ! ) Dev-Platform
Reason: The compiler is self-hosted (a.k.a. the compiler itself is written in Freepascal)
Even with that, you still need a version of FreePascal for FreeBSD, and a copy for Windows, and make sure the versions match. You can copy source code and set target flags... it would be interesting to see the results of using FreePascal to compile a native Windows .exe binary: Will it make a difference if compiled on FreeBSD with proper flags set versus compiling the unmodified source with default settings on Windows? To properly answer a question like that, you gotta set up a tightly controlled experiment with a null hypothesis.
 
You can make a dlang-gtkd-gui application on freebsd/linux/windows without the need to change any line of code except for the building process.
 
My CSS circle:

Code:
#circle {
background: #000000;
border-radius: 50%;
width: 100px;
height: 100px;
}
 
I am currently using FreePascal for a FreeBSD/Linux/Windows app. I will see how that works out.
Writing software in FPC is different. You find that the language forces better design on you. The last Win/Linux tool I did (on the job) is horrible, in C#.
 
Back
Top