Mail Archives: geda-user/2016/08/02/10:14:51
On 08/02/2016 07:22 AM, Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com] wrote:
>> Why not QT4 or QT5?
> No C bindings for QT, unless I missed something. It's natively C++,
> which is a big no-no for some people.
>
> My personal feelings are quite different, I hated C++ until C++11
> arrived. C++11 (and later) really is a different language altogether.
So, the straight C GUI toolkits are limited to GTK+, XAW?
Searching on "C bindings for QT" gives these interesting results:
============http://stackoverflow.com/questions/1728509/does-qt-have-a-c-interface=============
To use Qt, you must have a C++ compiler. But it doesn't mean that your "application logic" can't be written in C, compiled with a
C compiler and carefully linked to the C++ part (the GUI with Qt). This application logic can be generic, linkable into other
executables (pure-C, mixed C/C++, etc.) It all depends on what you need.
you may shape your program as set of libraries achieving your business logic and write them in C, then you can use a little C++ to
bind what you wrote as library with a GUI using QT.
This is a good approach also because later you can reuse your library and implement many other front-ends with different toolkits
or languages!
https://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_5
Qt 5 language bindings go, Python PyQt[4], Python PyOtherSide – only for QML,
QML QtQuick – built into Qt[5], Rust qmlrs – only for QML
From Richard Dale:
I used to maintain C bindings that were used by Objective-C and Qt# bindings. But the Smoke library is much better although
it isn't a C binding, and I scrapped the QtC bindings to use smoke instead.
[https://techbase.kde.org/Languages/Smoke "The main purpose of SMOKE is making it easier to write bindings from scripting
languages to Qt and KDE - with an emphasis on ease of use and flexibility. "]
============http://stackoverflow.com/questions/1728509/does-qt-have-a-c-interface=============
===============http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5===================
Rust and QT seems a time pit:
"Another heavily used feature in C++ is overloading. Apparently Rust doesn’t support functions overloading either. Yes, I know
it’s intentional and no, I strongly disagree with all philosophical reasons that try to “justify” it. I’m developing software in
C++ starting from 90’s and while I’ve seen some rare examples of poor functions overloading use - this is still “must have”
feature for any non-trivial framework, both from convenience and learning perspectives.
Anyway, arguments aside - the lack of overloading means there’s no reasonable way to use C++ methods names as Rust methods names
without some form of deduplication. Because there’s no way I’m going to maintain the list of “intelligent” mappings for all Qt5
methods, the renaming is done automatically by adding a number after the function name - hence “QString::new7”, “toString2”,
“arg12” etc.
There are 5 overloads like this in Digital Clock example and 26 (!) in Image Viewer.
Note this is completely non-obvious for bindings user (why not “new6” or “new8”?), require lengthy look-up in the generated
bindings code for each such case - plus can easily change from version to version if overloads are added or removed, breaking code
compilation."
- Raw text -