FLTK 1.4 Released With Wayland & HiDPI Display Support

[anda_skoa]

Qt is even worse in this way. You actually have to learn a whole new language (called Q) to even use it.

You probably meant QML but this is just one option.

Especially if we are talking about a classic widget look&feel the primary language is still C++ as this is what Qt itself is written in.
Even most of the things used through QML, e.g. QtQuick, are themselves written in C++.

[kpedersen]

Yuck, this one is ugly! Use GTK or Qt instead!

What's next, they're bringing Motif to Wayland?

The screenshot doesn't do it justice. It provides a number of themes. Can be changed easily, via i.e:

Fl::scheme("gtk+");

You end up with something like this:

https://www.fltk.org/images/fltk-widgets-gtk.png

But yes, you still need to tailor your expectations. It won't look what we currently call "modern". However many people don't like the look of current toolkits either. Its all opinion at this point.

The coolest thing about this release is Fl_Flex provides table based layouts (similar to flexbox).

https://github.com/fltk/fltk/blob/master/FL/Fl_Flex.H

</shameless_plug>

[sftw]

Yuck, this one is ugly! Use GTK or Qt instead!

No. FLTK is minimal dependency, small, lightweight, fast, and responsive all at the same time. GTK and Qt are not.

Not every app exists for you to spin around on your gaudy Compiz desktop. Some of us use apps to make money.

[Raka555]

I use it for an industrial app that runs on Windows and Linux and it's so much less hassle and B.S. than GTK or Qt!
I worked on a GTK app some time ago and once it took me two days to figure out how to write a dynamic pointer cast to make a widget work.
Also, GTK makes you write everything in GTK. You have to derive pretty much all your types from their GObject, use their storage structures in order to be able to display the data, etc. so if you eventually want to move away from GTK, it means rewriting the whole program.
Qt is even worse in this way. You actually have to learn a whole new language (called Q) to even use it. And the bloat goes beyond any measure.
So unless I'm making an app that has to appeal to teenagers hooked on Anime, I'd go for FLTK instead of GTK or Qt any day.

Ecere-C is worth a look if you want to write cross-platform applications. https://www.ecere.org/overview/
It is my favorite cross platform dev tool, for Linux and Windows at least. I haven't tried it on MacOS.

It uses the eC language, which is a superset of C.
Very powerful, easy and fun to use. (https://redmonk.com/dberkholz/2013/0...xpressiveness/)

image.png

It use to be one of the most expressive languages. This data is old now, but it should still be up there.
It really deserves more attention from people.

It is still actively maintained and developed: https://github.com/ecere/ecere-sdk
The last release was a long time ago, but it is easy to build from source, last time I checked.

I wrote a commercial app with it for Windows for a government institution and it gets used by more than 5000 people daily. Been running 100% stable for more than 5 years now

[uid313]

I use it for an industrial app that runs on Windows and Linux and it's so much less hassle and B.S. than GTK or Qt!
I worked on a GTK app some time ago and once it took me two days to figure out how to write a dynamic pointer cast to make a widget work.
Also, GTK makes you write everything in GTK. You have to derive pretty much all your types from their GObject, use their storage structures in order to be able to display the data, etc. so if you eventually want to move away from GTK, it means rewriting the whole program.
Qt is even worse in this way. You actually have to learn a whole new language (called Q) to even use it. And the bloat goes beyond any measure.
So unless I'm making an app that has to appeal to teenagers hooked on Anime, I'd go for FLTK instead of GTK or Qt any day.

Qt is good enough for software such as Autodesk 3ds Max, Battle.net, DaVinci Resolve, EA, Krita, OBS Studio, Telegram, Unigine, VirtualBox, Wireshark, Wolfram Mathematica, TeamSpeak, TeamViewer, etc. Many software companies rely on Qt for their commercial software so it is good because it is good enough for real companies to make real products in Qt that work in the real world and provide value. Nobody really uses shitty old FLTK.

[kpedersen]

Qt is good enough

The premier VNC client (TigerVNC) didn't find Qt good enough. They use FLTK.

Qt doesn't even use standard C++. C++/MOC is risky to commit to for long lived projects.

[anda_skoa]

Qt doesn't even use standard C++

Common misunderstanding.

All Qt code is standard C++, both the libraries as well as the application using it.

People who have not done (much) C/C++ development can easily get confused by C pre-processor macros which C/C++ frameworks often use to hide boilerplate code or provide so-called "syntactic sugar".

Other languages don't have this capability or handle it in different way, so people mistakenly think of them as some form of language extension which they are not.

For example in Qt code you can often find such a macro named "emit" or "Q_EMIT" which gets removed by the C pre-processor.
It helps developers reading the code to understand that the function call following the macro will result in function calls elsewhere (callbacks).

[kpedersen]

All Qt code is standard C++, both the libraries as well as the application using it.

No its not. Stating otherwise is misleading. A standard C++ compiler will throw a syntax error when parsing the "slots" keyword that Qt code requires. I would suggest you try it but you already knew that didn't you .

Instead you need to pass it through the non-standard MOC preprocessor. You are trying to get people to confuse this with, CPP, the standard C Pre-Processor. Very different things. The latter is a part of the C, C++ standards. If people try to define those keywords with the standard preprocessor; it will help them understand the process and why MOC is required to avoid compile errors.

Otherwise, you are suggesting that the following code is valid C++ which is obviously completely wrong. Luckily even a first year compsci student will able to point that out.

#include <QMainWindow>
#include <QPushButton>
 
class MainWindow : public QMainWindow
{
  Q_OBJECT
public:
  explicit MainWindow(QWidget *parent = nullptr);
private slots:
  void handleButton();
private:
  QPushButton *m_button;
};

https://wiki.qt.io/How_to_Use_QPushButton

I recommend people read up on Signals & Slots and also have a think about why projects such as Copperspice were created.

[anda_skoa]

No its not.

It is.
And a common misunderstanding to think it is not, so don't be too hard on yourself.

A standard C++ compiler will throw a syntax error when parsing the "slots" keyword that Qt code requires.

Why would it?
"slots", or its all-upper-case variant "Q_SLOTS", is a C pre-processor "#define" that gets replaced with nothing.
Essentially removed by the compiler's pre-processing stage before the C++ parse sees the input stream.

Anyone who has access to a C++ compiler, e.g. g++, can easily verify that.

Instead you need to pass it through the non-standard MOC preprocessor.

No, MOC is a code generate that reads the same header files the C++ compiler reads and then generates additional C++ code for some of the macros.

If you want more details you will find a good explanation here

You are trying to get people to confuse this with, CPP, the standard C Pre-Processor. Very different things.

The same header files are consumed by two processes:

• the C++ compiler, which uses its standard pro-processor to replace the defines with their respective substitution
• the MOC code generatro which interprets these macros as markers/input to know what code to generate.

These two work in parallel, not in sequence.

Otherwise, you are suggesting that the following code is valid C++

It is, any C++ compiler can easily consume that.

Their pre-processor sees the Q_OBJECT macro and expands it to the substitution.
You can find the define in qtmetamacros.h

Luckily even a first year compsci student will able to point that out.

First year compsci students have often only background in "modern" languages and not yet experienced C or C++ and are not aware how the pre-processor and its marcos work.
Once they have done even minimal programming in either of those two languages they can easily find the macro definitions and understand how the pre-processor will do its replacement operations.

[kpedersen]

It is.
And a common misunderstanding to think it is not

Nope. Its not standard C++. People don't just convolute their build systems with MOC for the fun of it haha. Perhaps you need to be a little harder on yourself if you can't quite grasp the concept (though I am sure you can, you are just trying to turn this into a silly debate and waste everyone's time aren't you?).

"slots", or its all-upper-case variant "Q_SLOTS", is a C pre-processor "#define" that gets replaced with nothing.
Essentially removed by the compiler's pre-processing stage before the C++ parse sees the input stream.

You can #define many words in C++ to "nothing". Doesn't mean it will compile.

Likewise, if you don't pass your code through MOC first, the software will not compile. You can try to argue around it as much as you can but Qt's reliance on MOC is well known as a disadvantage.

Unless you are saying that non-compiling code is "standard C++"? I think you are confused.

int main
  std::cout hello world"
  return 0
}

"Completely standard C++.. I just didn't include the additional syntax to make it actually compile"

Anyone who has access to a C++ compiler, e.g. g++, can easily verify that.

Yeah, you get these kinds of errors obviously. Very easy to verify:

https://stackoverflow.com/questions/3607262/why-wont-this-compile-link-with-the-q-object-macro-in-place

As per the obvious answer here:

This kind of errors usually happen when you add the Q_OBJECT macro and forget to rerun moc. If you use qmake, just run make qmake after you added the macro.

Simples! (until of course, MOC rots and you now need to personally maintain a specific version of an entire build system for your project)

No, MOC is a code generate that reads the same header files the C++ compiler reads and then generates additional C++ code for some of the macros.

Most preprocessors generate additional code. Even the standard C Pre-Processor. Are you trying to argue that that additional C++ code generated by MOC is "optional"? You are very incorrect.

First year compsci students have often only background in "modern" languages and not yet experienced C or C++ and are not aware how the pre-processor and its marcos work.

MOC and other non-standard pre-processing tools were a crap idea decades ago too. Nothing has changed in that regard really. Whether they were a first year compsci student in class of 2000 or class of 2024, they can still identify non-standard C++.