Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April

[Konstantin Ritt]

Hi Tuuka,

By that link I didn't mean QTBUG-102962 exactly, but 23 matching bugs for a
single component (which is not even one of the top-wanted components).
On vanilla 6.2.4, QCamera simply doesn't work on many Android devices. All
these issues were resolved for 6.2.5. Coincident?

> We are no holding back on bug fixes, though.
> so the fix is in Qt 6.3.1
Technically you aren't. But in fact you are!
That is what I called "please stick to unstable, semi-functional versions
of Qt, test them and report bugs".
6.3 brought a bunch of new bugs and regressions, and some of them still
aren't fixed. As for example, look at --
https://bugreports.qt.io/browse/QTBUG-98964?jql=text%20~%20%22Binding%20on%20contentItem%20is%20not%20deferred%20as%20requested%20by%20the%20DeferredPropertyNames%20class%20info%20because%20one%20or%20more%20of%20its%20sub-objects%20contain%20an%20id%22
-- (and not only at QTBUG-98964).
Fixed in 6.3.0? Sure it is. But it is still reproducible in dev...
Maybe it is not really important? Well, I personally can live with it.
Until I get a hang/crash report in release due to this issue...

And that's just a single example of many.
Okay, perhaps I should stick back to 6.2.4, keep my eye on commits
picked-up to mysterious 6.2.5 and apply them manually. Thanks,
cherry-picking monkey is a job I was dreaming of!

When I chose Qt for developing my apps, it was "Code less, create more[,
deploy everywhere]".
I was ok with building Qt from sources when you started selling binaries to
your commercial folks. Waste of an hour of my machine power per several
months was not a big price for stability update.
But we definitely didn't choose to be your free testing crowd!


Regards,
Unhappy monkey


пн, 19 сент. 2022 г. в 20:15, Tuukka Turunen :

> Hi Konstantin,
>
>
>
> I am sorry to hear that you are unhappy with Qt 6.2 moving to the
> commercial-only long-term-support phase with release of Qt 6.2.5.
>
>
>
> We are no holding back on bug fixes, though.
>
>
>
> All applicable bug fixes go to dev and are picked to all active branches.
> The fix to QTBUG-102962 was merged to 6.3 branch at the end of April, so
> the fix is in Qt 6.3.1 released in June, as well as in the latest Qt 6.3.2
> release as well as the soon-to-be released Qt 6.4.0 release.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
>
>
> *From: *Development  on behalf of
> Konstantin Ritt 
> *Date: *Monday, 19. September 2022 at 15.46
> *To: *development@qt-project.org 
> *Subject: *Re: [Development] Commercial-only 6.2 LTS phase starts:
> Closing the 6.2 branch(es) on 20th April
>
> It is probably the most destructive and annoying thing you did!
>
>
>
> I'll try to rephrase what you said in that announcement: "Dear community,
> please stick to unstable, semi-functional versions of Qt, test them and
> report bugs you've found (for free), so we could better support our
> valuable customers (not you). Your contributions are welcomed (but you have
> to pay some money to us to get any gain from your fixes, unless you're ok
> with sticking to some newer semi-functional version of Qt). Thanks for
> everything you did for Qt project (we don't appreciate that). That's how
> Open Governance works, b???h!"
>
>
>
> Am I exaggerating? Let's briefly look at
> https://bugreports.qt.io/browse/QTBUG-102962?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20Multimedia%20and%20fixVersion%20%3D%206.2.5
>
>
>
> Okay, you won: I'll buy your commercial license, just to share your
> commercial-only repositories to everyone!
>
>
> Regards,
> Konstantin
>
>
>
>
>
> ср, 20 апр. 2022 г. в 10:01, Tarja Sundqvist :
>
> Hi,
>
>
>
> With Qt 6.3.0 released and the first patch release (Qt 6.3.1) coming soon,
> it is time to enter the commercial-only LTS phase for Qt 6.2 LTS. All the
> existing 6.2 branches remain publicly visible, but they are closed for new
> commits and cherry-picks. The exception is the Qt WebEngine, which has a
> 3rd party LGPL dependency.
>
>
>
> Closing happens today, 20th April 2022. After this, the cherry-picks go to
> another repository that will be available only for the commercial license
> holders. We will arrange repository access to the commercial license
> holders, so in addition to the official releases, it is possible to use the
> repositories.
>
>
>
> The first commercial-only Qt 6.2.5 LTS patch release is planned to be
> released in May.
>
>
>
> The external module maintainers that have access to the Qt 5.15
> commercial-only repositories, will also have access to the Qt 6.2
> commercial-only repositories. If you notice that you don’t have access even
> if you should have, please contact me (tarja.sundqv...@qt.io) as I am the
> release manager for the commercial-only LTS releases.
>
>
>
> Best regards,
>
> Tarja Sundqvist
>
> Release manager
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
__

Re: [Development] Adding CPD support to Qt print dialog

[Albert Astals Cid]

El dilluns, 19 de setembre de 2022, a les 14:59:46 (CEST), Shawn Rutledge va 
escriure:
> On 2022 Sep 19, at 12:38, Till Kamppeter
> mailto:till.kamppe...@gmail.com>> wrote:
 
> On 16/09/2022 08:32, Shawn Rutledge wrote:
> But Qt has its own D-Bus implementation, so we tend to prefer using that,
> rather than using some external library that uses some other library that
> talks to D-Bus.  But if you really want to use the library, maybe /that/
> could be a reason to do dynamic loading?
 
> A re-implementation of the frontend part of CPDB with Qt's D-Bus
> implementation to overcome the need of two different libraries for D-Bus
> access in the whole Qt print dialog would lead to a maintenance overhead.
> Any change in the D-Bus interface in the original OpenPrinting
> implementation needs to get reflected in the Qt implementation.
 
> Yes, but do you think it needs any changes?  It’s been a few years.  The
> D-Bus interface is a kind of contract, usually you want to be sure you got
> that right.
 
> We still don’t have a print dialog in Qt Quick Dialogs, and I think we need
> to add one within the next couple of years (if we get around to defining
> how printing is supposed to work; I have a reasonable idea for that, I
> think, but nobody has implemented anything like that AFAIK).  So we do need
> a nice interface, suited to implementing that kind of dialog.
 
> And what is the print dialog we see opened by Qt/KDE apps then? Where does
> it come from?
 
> Have you seen a Qt Quick print dialog?  Most likely it’s still only widget
> applications that have printing functionality, and use QPrintDialog or the
> one that’s described here:
> https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog  But I
> don’t know for sure.

There has not been a KDE print dialog for decades at this point that tutorial 
is KDE 4 and it still basically gave you a regular QPrintDialog with 
potentially some custom tabs.

https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/4.14/kdeui/dialogs/kdeprintdialog.cpp#L44

Cheers,
  Akbert


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April

[Tuukka Turunen]

Hi Konstantin,

I am sorry to hear that you are unhappy with Qt 6.2 moving to the 
commercial-only long-term-support phase with release of Qt 6.2.5.

We are no holding back on bug fixes, though.

All applicable bug fixes go to dev and are picked to all active branches. The 
fix to QTBUG-102962 was merged to 6.3 branch at the end of April, so the fix is 
in Qt 6.3.1 released in June, as well as in the latest Qt 6.3.2 release as well 
as the soon-to-be released Qt 6.4.0 release.

Yours,

Tuukka


From: Development  on behalf of Konstantin 
Ritt 
Date: Monday, 19. September 2022 at 15.46
To: development@qt-project.org 
Subject: Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 
6.2 branch(es) on 20th April
It is probably the most destructive and annoying thing you did!

I'll try to rephrase what you said in that announcement: "Dear community, 
please stick to unstable, semi-functional versions of Qt, test them and report 
bugs you've found (for free), so we could better support our valuable customers 
(not you). Your contributions are welcomed (but you have to pay some money to 
us to get any gain from your fixes, unless you're ok with sticking to some 
newer semi-functional version of Qt). Thanks for everything you did for Qt 
project (we don't appreciate that). That's how Open Governance works, b???h!"

Am I exaggerating? Let's briefly look at 
https://bugreports.qt.io/browse/QTBUG-102962?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20Multimedia%20and%20fixVersion%20%3D%206.2.5

Okay, you won: I'll buy your commercial license, just to share your 
commercial-only repositories to everyone!

Regards,
Konstantin


ср, 20 апр. 2022 г. в 10:01, Tarja Sundqvist 
mailto:tarja.sundqv...@qt.io>>:
Hi,

With Qt 6.3.0 released and the first patch release (Qt 6.3.1) coming soon, it 
is time to enter the commercial-only LTS phase for Qt 6.2 LTS. All the existing 
6.2 branches remain publicly visible, but they are closed for new commits and 
cherry-picks. The exception is the Qt WebEngine, which has a 3rd party LGPL 
dependency.

Closing happens today, 20th April 2022. After this, the cherry-picks go to 
another repository that will be available only for the commercial license 
holders. We will arrange repository access to the commercial license holders, 
so in addition to the official releases, it is possible to use the repositories.

The first commercial-only Qt 6.2.5 LTS patch release is planned to be released 
in May.

The external module maintainers that have access to the Qt 5.15 commercial-only 
repositories, will also have access to the Qt 6.2 commercial-only repositories. 
If you notice that you don’t have access even if you should have, please 
contact me (tarja.sundqv...@qt.io) as I am the 
release manager for the commercial-only LTS releases.

Best regards,
Tarja Sundqvist
Release manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 19 Sep 2022, at 18:21, Till Kamppeter  wrote:
> 
> On 19/09/2022 15:43, Tor Arne Vestbø wrote:
>>> 
>>> First is to create a new Qt print backend, what, instead of communicating 
>>> directly with CUPS, communicates with the CPDB backends. It is some kind of 
>>> "middle end", on one end being a Qt print backend and on the other end 
>>> being a CPDB frontend.''
>> This sounds like a good first step. It doesn’t involve any of the GUI bits, 
>> just the enumeration and communication with the various CPDB-exposed 
>> printers.
>> Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the 
>> CPDB print backend should be a plugin.
>> 
> 
> OK, Gaurav so you should be able to provide the CPDB support as a plugin 
> (Tor, is this a Qt print backend like the one for CUPS for example?).

Correct. Note that for Qt 6, some of the print engines that were previously 
plugins were moved into the QtPrintSupport library directly, such as the macOS 
print engine, but the interface for enumerating these from Qt’s point of view 
is still as print engine “plugins”. The CUPS engine is a fully standalone 
plugin, so it’s a good basis for the CPDB work.

Cheers,
Tor Arne 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 19/09/2022 15:43, Tor Arne Vestbø wrote:


First is to create a new Qt print backend, what, instead of communicating directly with 
CUPS, communicates with the CPDB backends. It is some kind of "middle end", on 
one end being a Qt print backend and on the other end being a CPDB frontend.''


This sounds like a good first step. It doesn’t involve any of the GUI bits, 
just the enumeration and communication with the various CPDB-exposed printers.

Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the CPDB 
print backend should be a plugin.



OK, Gaurav so you should be able to provide the CPDB support as a plugin 
(Tor, is this a Qt print backend like the one for CUPS for example?).



The second is to throw the backend concept of the Qt dialog over board and 
replace it by CPDB, the Qt print dialog itself using cpdb-libs to connect to 
backends, which are now only the CPDB backends, no Qt print backends any more. 
By conditional compiling one could decide here at build time to use the CPDB 
concept, the old Qt print backend concept, or both (and in that case which has 
priority).


This can only be done if CPDB is available on all platforms Qt supports.


OK, so replacing Qt's backend concept by CPDB would only work under 
Linux, requiring conditionals to stay with the Qt concept for other 
platforms. So we stay with the approach of implementing the CPDB support 
in a Qt print backend/plugin.


   Till
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 19/09/2022 14:59, Shawn Rutledge wrote:
A re-implementation of the frontend part of CPDB with Qt's D-Bus 
implementation to overcome the need of two different libraries for 
D-Bus access in the whole Qt print dialog would lead to a maintenance 
overhead. Any change in the D-Bus interface in the original 
OpenPrinting implementation needs to get reflected in the Qt 
implementation.


Yes, but do you think it needs any changes?  It’s been a few years.  The 
D-Bus interface is a kind of contract, usually you want to be sure you 
got that right.




I think, once Gaurav having done the 2 dialogs, GTK and Qt, the D-Bus 
interface should be rather stable, as with the 2 dialogs we know our 
needs more or less. Then an implementation in Qt D-Bus could be done.


Have you seen a Qt Quick print dialog?  Most likely it’s still only 
widget applications that have printing functionality, and use 
QPrintDialog or the one that’s described here: 
https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog 
 
But I don’t know for sure.




No, I did not actually know which variants of print dialog exist for 
Qt/KDE and where they actually come from. If there is only Qt and 
nothing more, is there already a print dialog readily available?


[...]

Does this mean that we make the Qt/KDE apps use the GTK print dialog 
for which Gaurav has already done the CPDB support? Would be a lot of 
library overhead for pure KDE/Qt distros or for containerized apps.


No, but it should probably end up similar to the behavior with the file 
dialog: if you are running Gnome, and a Qt application creates a 
QFileDialog, on your desktop you will see a GTK file dialog instead. 
  That way you have a consistent desktop experience across applications. 
  That checking happens at runtime here:


https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/dialogs/qfiledialog.cpp#n838 



|if (d->canBeNativeDialog()) { if (d->setNativeDialogVisible(visible)) { ...|



So this would look like in Flatpak where the app connects to the portal 
and the desktop opens the dialog (KDE app under GNOME -> GNOME dialogs).



Our CPDB support should work in all Qt apps not only in KDE apps.


Obviously; but if KDE developers want to start making any customized 
print dialogs, they may depend on some things that we are adding; or if 
they are already working on it, it would be good to find out.


If the CPDB support would be simply another backend for the Qt print 
dialog, would it then also work with these customized KDE dialogs?


   Till

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Szabolcs David as Approver

[Allan Sandfeld Jensen]

Hi,

I'd like to propose Szabolcs David as an Qt Project Approver.

Dashboard: https://codereview.qt-project.org/dashboard/1002939

Szabolcs has been working for us as an external contributor for at least 8 
years now. With that many years of experience contributing to Qt WebEngine, I 
think it is about time we grant him approver rights.

Best regards,
Allan Sandfeld Jensen




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 19 Sep 2022, at 00:51, Till Kamppeter  wrote:

> We do not do any GUI design or change as part of our project. We only add a 
> new method to obtain the available printers, their capabilities and options, 
> and to send off print jobs to them.

That’s good news.

> 
> First is to create a new Qt print backend, what, instead of communicating 
> directly with CUPS, communicates with the CPDB backends. It is some kind of 
> "middle end", on one end being a Qt print backend and on the other end being 
> a CPDB frontend.''

This sounds like a good first step. It doesn’t involve any of the GUI bits, 
just the enumeration and communication with the various CPDB-exposed printers.

Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the CPDB 
print backend should be a plugin.

> The second is to throw the backend concept of the Qt dialog over board and 
> replace it by CPDB, the Qt print dialog itself using cpdb-libs to connect to 
> backends, which are now only the CPDB backends, no Qt print backends any 
> more. By conditional compiling one could decide here at build time to use the 
> CPDB concept, the old Qt print backend concept, or both (and in that case 
> which has priority).

This can only be done if CPDB is available on all platforms Qt supports.

Cheers,
Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 19, at 12:38, Till Kamppeter 
mailto:till.kamppe...@gmail.com>> wrote:

On 16/09/2022 08:32, Shawn Rutledge wrote:
But Qt has its own D-Bus implementation, so we tend to prefer using that, 
rather than using some external library that uses some other library that talks 
to D-Bus.  But if you really want to use the library, maybe /that/ could be a 
reason to do dynamic loading?

A re-implementation of the frontend part of CPDB with Qt's D-Bus implementation 
to overcome the need of two different libraries for D-Bus access in the whole 
Qt print dialog would lead to a maintenance overhead. Any change in the D-Bus 
interface in the original OpenPrinting implementation needs to get reflected in 
the Qt implementation.

Yes, but do you think it needs any changes?  It’s been a few years.  The D-Bus 
interface is a kind of contract, usually you want to be sure you got that right.

We still don’t have a print dialog in Qt Quick Dialogs, and I think we need to 
add one within the next couple of years (if we get around to defining how 
printing is supposed to work; I have a reasonable idea for that, I think, but 
nobody has implemented anything like that AFAIK).  So we do need a nice 
interface, suited to implementing that kind of dialog.

And what is the print dialog we see opened by Qt/KDE apps then? Where does it 
come from?

Have you seen a Qt Quick print dialog?  Most likely it’s still only widget 
applications that have printing functionality, and use QPrintDialog or the one 
that’s described here: 
https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog  But I 
don’t know for sure.

 I don’t see any “dialog helpers” for print dialogs yet; 
qtbase/src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.h doesn’t have a GTK 
print dialog.  Other Qt Quick Dialogs like 
https://doc.qt.io/qt-6/qml-qtquick-dialogs-filedialog.html 
 use such helpers 
to show native platform dialogs, and we also have QML/Qt Quick Controls 
implementations of the same dialogs that are designed to look like (or better 
than) the widget dialogs.  (A Qt Quick application should never need to load 
the widget library, for any of its functionality.  That’s a goal… not always 
achieved so far. https://doc.qt.io/qt-6/qtlabsplatform-index.html 
 exists for the few cases 
when widgets are still needed, and we are actively trying to shrink that module 
by finding ways to implement the same functionality without widget 
dependencies.)
So I think there are several areas to start work in:
- a Qt D-Bus implementation of the CPDB interface

Probably the simplest to overcome the glib-D-Bus library overhead.

- add code to src/printsupport/dialogs/qprintdialog_unix.cpp to use that D-Bus 
implementation (wrapped with #if QT_CONFIG(cpdb) or whatever, and without 
removing other functionality for now)

What do you mean here exactly? Using cpdb-libs with its D-Bus access if the 
code enclosed by #if QT_CONFIG(cpdb) is used?

- some QPA abstraction that a QML-implemented PrintDialog can use: that 
probably includes a QAbstractItemModel or QAbstractListModel subclass for the 
list of printers, maybe another model for the choices that a particular printer 
can present to the user, and so on
- add the GTK print dialog helper; that’s unrelated to the rest, but when we 
add a QML PrintDialog, we may want to have the usual “native dialog” 
alternative; and perhaps it already uses CPDB?  Users of Gnome and other 
GTK-based desktops will expect it, but almost nobody else.

Does this mean that we make the Qt/KDE apps use the GTK print dialog for which 
Gaurav has already done the CPDB support? Would be a lot of library overhead 
for pure KDE/Qt distros or for containerized apps.

No, but it should probably end up similar to the behavior with the file dialog: 
if you are running Gnome, and a Qt application creates a QFileDialog, on your 
desktop you will see a GTK file dialog instead.  That way you have a consistent 
desktop experience across applications.  That checking happens at runtime here:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/dialogs/qfiledialog.cpp#n838

if (d->canBeNativeDialog()) {
if (d->setNativeDialogVisible(visible)) { ...

- add print dialog helpers to all other platforms where it’s possible (macOS, 
Windows, iOS/iPadOS, Android, …?)

We need CPDB only for Linux and similar OSes not for Windows?mac/Android/iOS.

Sure, the point was just that those platforms might need new dialog helpers 
too, similar to the GTK dialog helper, but using the respective native APIs.  
That’s work for us to try to get around to some day (or some interested 
volunteer).

- work with KDE, sync up with their approach to this

Our CPDB support should work in all Qt apps not only in KDE apps.

Obviously; but if KDE developers want to start making any customized print 
dialogs, they may depend on some things that we ar

Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April

[Konstantin Ritt]

It is probably the most destructive and annoying thing you did!

I'll try to rephrase what you said in that announcement: "Dear community,
please stick to unstable, semi-functional versions of Qt, test them and
report bugs you've found (for free), so we could better support our
valuable customers (not you). Your contributions are welcomed (but you have
to pay some money to us to get any gain from your fixes, unless you're ok
with sticking to some newer semi-functional version of Qt). Thanks for
everything you did for Qt project (we don't appreciate that). That's how
Open Governance works, b???h!"

Am I exaggerating? Let's briefly look at
https://bugreports.qt.io/browse/QTBUG-102962?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20Multimedia%20and%20fixVersion%20%3D%206.2.5

Okay, you won: I'll buy your commercial license, just to share your
commercial-only repositories to everyone!

Regards,
Konstantin


ср, 20 апр. 2022 г. в 10:01, Tarja Sundqvist :

> Hi,
>
>
>
> With Qt 6.3.0 released and the first patch release (Qt 6.3.1) coming soon,
> it is time to enter the commercial-only LTS phase for Qt 6.2 LTS. All the
> existing 6.2 branches remain publicly visible, but they are closed for new
> commits and cherry-picks. The exception is the Qt WebEngine, which has a
> 3rd party LGPL dependency.
>
>
>
> Closing happens today, 20th April 2022. After this, the cherry-picks go to
> another repository that will be available only for the commercial license
> holders. We will arrange repository access to the commercial license
> holders, so in addition to the official releases, it is possible to use the
> repositories.
>
>
>
> The first commercial-only Qt 6.2.5 LTS patch release is planned to be
> released in May.
>
>
>
> The external module maintainers that have access to the Qt 5.15
> commercial-only repositories, will also have access to the Qt 6.2
> commercial-only repositories. If you notice that you don’t have access even
> if you should have, please contact me (tarja.sundqv...@qt.io) as I am the
> release manager for the commercial-only LTS releases.
>
>
>
> Best regards,
>
> Tarja Sundqvist
>
> Release manager
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 16/09/2022 08:32, Shawn Rutledge wrote:


Along with Chris, I’m wondering why you think it should be a plugin.

Anyway it seems some misunderstandings are possible.  Lars wrote "code 
that uses the CPDB dialogs instead of our own implementations”… but are 
there replacement GUI dialogs? The web site says it’s about "separating 
the print dialogs of different GUI toolkits and applications (GTK, Qt, 
LibreOffice, …) from the different print technologies (CUPS/IPP, Google 
Cloud Print, …) so that they can get developed independently”.  And they 
use D-Bus.  Here are the current D-Bus specifications (which have been 
modified recently): 
https://github.com/OpenPrinting/cpdb-libs/tree/master/cpdb/interface 
 So now 
it seems we bump into the typical GTK/glib pattern that they like to 
provide a stable C interface, as a higher priority than a 
stable D-Bus interface.  But Qt has its own D-Bus implementation, so we 
tend to prefer using that, rather than using some external library that 
uses some other library that talks to D-Bus.  But if you really want to 
use the library, maybe /that/ could be a reason to do dynamic loading?




First, as I told already in my answer to Lars' post in this thread, we 
do not create a new print dialog, no GUI design and change needed. We 
only change the method how the already existing Qt dialog obtains 
available printers, their cpabilities and options, and send print jobs. 
We move the communication with the print technologies (CUPS, 
print-to-file, cloud printing, ...) into separate D-Bus-coupled modules 
which get maintained by the maintainers of each print technology, 
removing the burden of keeping the print dialogs up-to-date with changes 
in the print technologies from the GUI toolkit developers.


The CPDB frontend library in the cpdb-libs package contains a D-Bus 
interface to communicate with the modules (the backends) and an API for 
the print dialogs (the frontends) on its other end.


The easiest way to obtain CPDB support in a print dialog is just using 
cpdb-libs, not caring about what the library does internally (in our 
case using D-Bus). This is also the safest way to keep everything 
working should the internals of CPDB change (modifications in the D-Bus 
interface or even replacing the D-Bus connection by something completely 
different).


The problem that cpdb-libs and Qt use different D-Bus 
implementations/libraries is best to overcome by having the CPDB support 
in a dynamically loaded Qt print backend and not directly in the Qt dialog.


A re-implementation of the frontend part of CPDB with Qt's D-Bus 
implementation to overcome the need of two different libraries for D-Bus 
access in the whole Qt print dialog would lead to a maintenance 
overhead. Any change in the D-Bus interface in the original OpenPrinting 
implementation needs to get reflected in the Qt implementation.


On most Linux distros, Qt gets installed as normal packages, so it’s up 
to the packagers to ensure that Qt’s dependencies shall be installed as 
pre-requisites.  In that case, if it ends up that cpdb-lib is a 
dependency, and it gets installed automatically, that’s fine.


Linux distros are not such a problem. They will come with cpdb-libs and 
auto-install it if an installed print dialog or app needs it.


But 
commercial applications, and applications on other operating systems, 
tend to get developed with a version of Qt that comes from the Qt 
installer, so then dependency management is trickier, and we sometimes 
use dynamic loading of “iffy” libraries that may or may not already be 
installed.  (But if CPDB really becomes universal, then maybe within a 
few years we could assume that it’s always installed.)




Yes, here dynamic loading would be the solution, either cpdb-libs itself 
or the CPDB Qt print backend.


Sandboxed packages, like Snaps, must contain cpdb-libs to support CPDB, 
and they must be set to allowthe encapsulated application to access the 
host systems D-Bus.


If you’d develop with Qt D-Bus https://doc.qt.io/qt-6/qtdbus-index.html 
 you would not have a library 
dependency problem; but instead, you’d have the problem that the D-Bus 
interface for this service may change, that requires maintenance, and 
someone has to follow along with the changes that are being done in 
cpdb-lib, so that our implementation keeps working like theirs does. 
  But so far, we are getting away with this approach in other cases, 
such as the AppMenu and StatusNotifier interfaces.  So I think I’d still 
try to do it that way; I just hope they don't break compatibility often. 
  GTK/glib people may say they want to be able to break compatibility at 
any time, but to me it doesn’t make sense to say that an interface 
/specification/ is more fluid than a C interface that implements it. 
  The XML has to be published and versioned.  When it’s stable, both the 
C and D