https://bugs.documentfoundation.org/show_bug.cgi?id=165954

Michael Weghorn <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]
                   |                            |om

--- Comment #2 from Michael Weghorn <[email protected]> ---
As far as I know, LibreOffice currently implements the low-level printing logic
(interaction with CUPS, PPD file parsing,...) directly, not using the existing
toolkit logic to communicate with CUPS.

I'm not familiar with the Print portal, but while it might technically be
possible for LO to implement the logic to use the portal directly, I would
rather expect that (in the usual case) support for that should presumably be
implemented by the UI toolkit (i.e. GTK and Qt) and apps would get that "for
free" when they use the default UI toolkit print logic/API.
In that case, "making use of the portal" would mean switching to use the
corresponding GTK/Qt APIs for printing/the print dialog.

Is that correct? (At a quick glance, I can see GTK seems to implement this, but
am less sure about Qt.)

There was a previous attempt to use the native GTK print dialog, eventually
dropped in

    commit ed07ec7606cb24cccaf6b7b81b2bd308debaa2e6
    Author: Caolán McNamara
    Date:   Sun Dec 20 16:49:12 2020 +0000

        drop never completed GtkSalPrinter

Caolán might know more about the background and why that wasn't continued, but
one reason might have been that it wasn't possible to support custom
options,... to the extent that the LO dialog does.

Does anybody have insights on how flexible the print portal is (and how
flexible corresponding toolkit APIs are), i.e. whether it would allow providing
everything relevant that the LO print dialog currently does?

For the file dialog, there was e.g.
https://gerrit.libreoffice.org/c/core/+/124234 earlier suggesting to switch to
GtkFileChooserNative which would have supported the FileChooser desktop portal,
but that didn't provide everything needed and therefore wasn't a viable option.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to