Migrating Windows CI to Qt 6.7 - Roadblocks

[christoph at cullmann.io]

On 2024-05-27 14:34, Konstantin Kharlamov wrote:
> On Mon, 2024-05-27 at 14:26 +0200, christoph at cullmann.io wrote:
>> On 2024-05-27 14:01, Ralf Habacker wrote:
>> 
>> > There is e.g. the remote control area which is implemented in KDE
>> > applications with dbus. Should we now use a separate implementation
>> > for
>> > each platform with additional effort, although there is a
>> > platform-independent solution ?
>> 
>> Yes,
>> 
>> if you want that to work properly on other systems, one need to use
>> the
>> matching IPC services they provide.
>> Or just not do it.
> 
> What would be the dbus analogue on Windows? While searching I get this
> page¹, and besides FOSS projects implementing dbus (which is not a
> "native RPC") I see no other service. The first answer enlists native
> options, but judging by the way it's formulated as well as options
> enlisting stuff like "Clipboard", "Data Copy" and "Pipes", it isn't
> really an answer.
> 
> 1:
> https://stackoverflow.com/questions/482681/d-bus-equivalent-for-windows

I would assume

https://en.wikipedia.org/wiki/Dynamic_Data_Exchange

or COM.

But for the most apps so far the single application stuff was good 
enough.

Another alternative that works is to use stdin/out with JSON, that is 
how
most of the language server stuff in Code and Co. works flawless.

But it depends on what you aim to do.

At least for Frameworks itself I think it can't be that some API just 
will
stall forever if you don't have deployed a dbus-daemon the right way on 
Windows
or macOS, that makes it just not usable for the average developer.

They want to link to the framework and bundle it and it shall work.
And after the last round of patches, most frameworks including KIO do.

Greetings
Christoph