[GoLUG] Writing an internet server

[Barry Fishman]

On 2025-08-27 16:01:43 -04, Hendrik Boom wrote:
> On Wed, Aug 27, 2025 at 12:30:48PM -0500, Barry Fishman wrote:
>> 
>> No. Its a matter of multi-language support.  Gnome has gone out of their
>> way to support multi-language support, and out of the box advertises
>> their multi-language support and has a whole gobject-introspection
>> mechanism to automate building the C API interface code required.
>> 
>> KDE doesn't seem so have a similar facility.  It has a C++ interface,
>> which due to C++'s compiler specific mangling of linker names make
>> coding the required C based foreign function support (that most
>> development languages have) much harder to maintain).  KDE seem
>> supported only in large developer communities like Python, where enough
>> Qt using developers exist to make it worthwhile.
>
> You don't have to use the mangled names to call between C++ and C.
> It is possible to declare that a function in a C++ program uses
> C linkage instead of C++ linkage, and then it can be used inside
> C code with the ordinary declared name.

And who should write that code?

Should each application that uses KDE Plasma from a different language
supply the interface code they need?

The KDE Plasma APIs are quite extensive, and I'm sure there are other
important libraries that have their own Qt derived classes.

The problem seems somewhat independent of the language environment you
are targeting.  It could be part of a c++object-inspection interface to
Qt if they wanted to make multi-language support better.

It could be written by any of the language communities that have
successfully built a successful Qt interface library.  This is
open-ended since (as I said) any Qt package with their own derived
widget objects (I don't know the KDE terminology) would need to be
considered and a C interface level written.  Then there is the situation
when you want to derive your own language objects from Qt ones.  I'm not
familiar enough with Qt to know how important that is for Qt
programming.

All these cases are handled in Gtk with tools to support them.

KDE could probably do the same, but I don't know if it would be harder
for them.  Objects in Gtk are implemented in C, so the whole object
structure and protocols can be used from a target language.  Qt uses
C++'s internal objects, so its object handling may not be visible
outside of the C++ compiler, and cause issues in deriving classes
outside of the compiler.

The bottom line is they don't.  This means extra work if you want to
create a program in a language besides C++.  You may not want to do
that, so you may not care.  But some of us want to develop programs in
other languages, so we tend to avoid Qt.

I would like to have an alternative to Gtk given the direction Gnome
currently is going.  I am still looking.

-- 
Barry Fishman