Till, I'm surprised.

Do we have to repeat the discussion we had via mail now on bugzilla ?
I'm happy to copy-paste my reply here if it helps...for now I'll just say two things:

1. 'Integrating s-c-p into the control-center is a non-starter. We already have a printer panel, that works very well.

2. s-c-printer and the printer panel are not 'two independent projects'. mkasik and twaugh are cooperating, and there is an active discussion about reusing some pieces of s-c-printer functionality.

No repetition of the discussion needed, sorry if this made the impression to do so. I was asked to put up a bug report by the Ubuntu developers.

We should paste our private discussion here to make it public.

Here we go:

----------
Till Kamppeter wrote:

Hi Marek,

I Till Kamppeter, leader of the OpenPrinting project (http://www.openprinting.org/) and important contributor for system-config-printer.

Many Linux distributions, especially Red Hat and Ubuntu use system-config-printer for years and in that time system-config-printer evolved to an easy-to-use printer setup tool for both beginners and advanced users.

At the OpenPrinting Summit in April this year I heard about the new printer tool in the System Settings of GNOME 3. It is nice to have this integration in GNOME, but it is also a reinventing of the wheel and dropping system-config-printer for it will lead to a loss of many nice features, especially features which are useful for beginners.

You have done great work and I do not want to consider your work as bad, but we should join forces to get a universal printer setup tool which makes printer configuration as easy as possible. Therefore I want to suggest to merge the projects somehow.

In system-config-printer there are a lot of special features to make setting up printers as easy as possible, mostly by working around the shortcomings of CUPS and the existing printer drivers:

- Creating a list of detected printers with exactly one entry per physical printer. Especially the output of the CUPS backends for detecting network printers (snmp, dnssd) is not easy to identify as coming from the same printer.
- Comparing manufacturer and model names. They are written in many different forms in PPD files, device ID entries and printer databases. system-config-printer uses an algorithm based on how humans read the model names.
- Finding the best driver if there is more than one driver available for a printer. system-config-printer uses a special set of rules here.
- Printer driver auto download from OpenPrinting. The OpenPrinting web site lists manufacturer-supplied printer driver and PPD packages for automatic download. This way a printer, even if it is not supported by the installed Linux distribution, can be set up fully automatically.
- HPLIP integration. system-config-printer joins detected HPLIP URIs to the USB URI of the same printer and selects the HPLIP URI by default, it finds the HPLIP URIs for network printers, and automatically also creates the fax queues for multifunction devices.
- Plug'n'Print: New USB printers are automatically detected and set up when plugging them in. Also queues of USB printers are disabled when the printer is turned off and re-enabled when the printer is turned on, even if the printer is controlled by HPLIP.
- Server Settings: The server settings settable with the CUPS web interface (and some more) can also be set with system-config-printer.
- Easy setup of queues pointing to SMB/Windows shares

A switchover to the GNOME tool would lead to most of these features getting lost and printer setup getting more complicated for unexperienced users.

So somehow we should get these features into the new tool without rewriting them from scratch.

They are all written in Python and AFAIK the GNOME tool is written in C. To avoid rewriting all this in C I suggest to create a D-Bus service containing functions for all the features listed above and making the GNOME tool calling these functions. The GNOME tool could even be reduced to a pure D-Bus frontend for the system-config-printer D-Bus service which does not communicate with CUPS by itself.

This avoids the need to move the implementations to another programming language or reimplement the stuff for other reasons. system-config-printer's GUI can be continued to be maintained (as a D-Bus-only frontend not communicating directly with CUPS at all) for non-GNOME systems like Xubuntu.

KDE's printer module could then be done this way as well.

Most important is that in system-config-printer the GUI part and the algorithmic part need to get well separated, so that all printer setup tools share system-config-printer's algorithmic part as a D-Bus service. So Tim's and my work get available for everyone and we avoid the reinventing of the wheel.

We will discuss this also on the Ubuntu Developer Summit in May. See

https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-system-config-printer-vs-gnome-3-control-center

TYhe discussion session will be somewhere on May 11-13 and remote participation will be possible. Marek, please create a Launchpad account (if you have none yet) and subscribe to the Blueprint linked above to stay informed.

Tim, Marek, WDYT about these plans?

   Till 


----------
Marek Kasik wrote:

Hi,

I'm CC-ing Matthias Clasen, since he has really good knowledge of
printing stack in our desktop applications.

Marek


----------
Till Kamppeter wrote:

Marek, thank you for forwarding. Who has written the printer tool for the GNOME System Setting? You or Matthias?

   Till 


----------
Matthias Clasen wrote:

Hey, thanks. I'll put some comments inline below. Don't be alarmed if
they sound a bit negative, I just want to make my position clear and
avoid misunderstandings.


> On 04/28/2011 12:42 PM, Till Kamppeter wrote:
>> Hi Marek,
>>
>> I Till Kamppeter, leader of the OpenPrinting project
>> (http://www.openprinting.org/) and important contributor for
>> system-config-printer.
>>
>> Many Linux distributions, especially Red Hat and Ubuntu use
>> system-config-printer for years and in that time system-config-printer
>> evolved to an easy-to-use printer setup tool for both beginners and
>> advanced users.
No need to sell us our own tool 
 
>> At the OpenPrinting Summit in April this year I heard about the new
>> printer tool in the System Settings of GNOME 3. It is nice to have this
>> integration in GNOME, but it is also a reinventing of the wheel and
>> dropping system-config-printer for it will lead to a loss of many nice
>> features, especially features which are useful for beginners.
>>
>> You have done great work and I do not want to consider your work as bad,
>> but we should join forces to get a universal printer setup tool which
>> makes printer configuration as easy as possible. Therefore I want to
>> suggest to merge the projects somehow.
Just to be clear from the outset: 'universal' is not among the goals of
the printer panel. 'easy' is. I don't see the printer panel replace
s-c-printer or the cups web interface fully in the near future (or ever,
really, unless printing becomes a lot less arcane and more
straightforward, which it really should...). 

That being said, you can certainly argue for the addition of useful
features in the printer panel, but that has to be done by explaining how
they fit in the scope and design of the printer panel. 's-c-p has this'
is not a very convincing argument on its own.

>> In system-config-printer there are a lot of special features to make
>> setting up printers as easy as possible, mostly by working around the
>> shortcomings of CUPS and the existing printer drivers:
Here is the key insight: shortcomings of cups. 
Or, to put it more bluntly: cups sucks, badly.
We need to stop putting bandaids around 'shortcomings' and start
addressing them at the source. Of course, with cups, that is difficult
(some might say impossible).

>> - Creating a list of detected printers with exactly one entry per
>> physical printer. Especially the output of the CUPS backends for
>> detecting network printers (snmp, dnssd) is not easy to identify as
>> coming from the same printer.
>> - Comparing manufacturer and model names. They are written in many
>> different forms in PPD files, device ID entries and printer databases.
>> system-config-printer uses an algorithm based on how humans read the
>> model names.
>> - Finding the best driver if there is more than one driver available for
>> a printer. system-config-printer uses a special set of rules here.
All of these are basically just 'cups sucks' and should really be fixed
there and/or the drivers.

>> - Printer driver auto download from OpenPrinting. The OpenPrinting web
>> site lists manufacturer-supplied printer driver and PPD packages for
>> automatic download. This way a printer, even if it is not supported by
>> the installed Linux distribution, can be set up fully automatically.
I really don't see us promoting binary-only, non-packaged drivers. 

>> - HPLIP integration. system-config-printer joins detected HPLIP URIs to
>> the USB URI of the same printer and selects the HPLIP URI by default, it
>> finds the HPLIP URIs for network printers, and automatically also
>> creates the fax queues for multifunction devices.
Why again does hp needs to have its own, separate framework that doesn't
really integrate into the system printing framework ?

>> - Plug'n'Print: New USB printers are automatically detected and set up
>> when plugging them in. Also queues of USB printers are disabled when the
>> printer is turned off and re-enabled when the printer is turned on, even
>> if the printer is controlled by HPLIP.
This clearly belongs between udev, the usb subsystem and cups. I don't
see why any user-level software should be involved here.

>> - Server Settings: The server settings settable with the CUPS web
>> interface (and some more) can also be set with system-config-printer.
>> - Easy setup of queues pointing to SMB/Windows shares
Remote management of print servers is just not in scope for the desktop
printer panel. For remove administration, there's a web interface, or
s-c-printer.

>> A switchover to the GNOME tool would lead to most of these features
>> getting lost and printer setup getting more complicated for
>> unexperienced users.
>> So somehow we should get these features into the new tool without
>> rewriting them from scratch.
>>
>> They are all written in Python and AFAIK the GNOME tool is written in C.
>> To avoid rewriting all this in C I suggest to create a D-Bus service
>> containing functions for all the features listed above and making the
>> GNOME tool calling these functions. The GNOME tool could even be reduced
>> to a pure D-Bus frontend for the system-config-printer D-Bus service
>> which does not communicate with CUPS by itself.
>>
>> This avoids the need to move the implementations to another programming
>> language or reimplement the stuff for other reasons.
>> system-config-printer's GUI can be continued to be maintained (as a
>> D-Bus-only frontend not communicating directly with CUPS at all) for
>> non-GNOME systems like Xubuntu.
>>
>> KDE's printer module could then be done this way as well.
[...]

>> Most important is that in system-config-printer the GUI part and the
>> algorithmic part need to get well separated, so that all printer setup
>> tools share system-config-printer's algorithmic part as a D-Bus service.
>> So Tim's and my work get available for everyone and we avoid the
>> reinventing of the wheel.
Here is one part I agree with. UI and algorithmic parts ought to be
separated. We already have one wrapper around cups (cups-pk-helper) to
address one aspect of cups suckiness. Now you are proposing to add
another wrapper around cups to house the s-c-printer innards that work
around other parts of cups suckiness. At some point, it might be more
productive to stop the wrapping, and start the replacing...

>> We will discuss this also on the Ubuntu Developer Summit in May. See
>>
>> https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-system-config-printer-vs-gnome-3-control-center
>>
>>
>> TYhe discussion session will be somewhere on May 11-13 and remote
>> participation will be possible. Marek, please create a Launchpad account
>> (if you have none yet) and subscribe to the Blueprint linked above to
>> stay informed.
>>
>> Tim, Marek, WDYT about these plans?
>>
>>    Till

Matthias


----------
Marek Kasik wrote:

Hi Till,

I did. You can see it in g-c-c's git log.

Marek


On 04/28/2011 06:19 PM, Till Kamppeter wrote:
> On 04/28/2011 04:42 PM, Marek Kasik wrote:
>> I'm CC-ing Matthias Clasen, since he has really good knowledge of
>> printing stack in our desktop applications.
> Marek, thank you for forwarding. Who has written the printer tool for
> the GNOME System Setting? You or Matthias?
>
>    Till


----------
Marek Kasik wrote:

On 04/28/2011 12:42 PM, Till Kamppeter wrote:
> Hi Marek,
>
> I Till Kamppeter, leader of the OpenPrinting project
> (http://www.openprinting.org/) and important contributor for
> system-config-printer.
>
> Many Linux distributions, especially Red Hat and Ubuntu use
> system-config-printer for years and in that time system-config-printer
> evolved to an easy-to-use printer setup tool for both beginners and
> advanced users.
>
> At the OpenPrinting Summit in April this year I heard about the new
> printer tool in the System Settings of GNOME 3. It is nice to have this
> integration in GNOME, but it is also a reinventing of the wheel and
> dropping system-config-printer for it will lead to a loss of many nice
> features, especially features which are useful for beginners.
I'm implementing those missing features in gnome-control-center right now.

> You have done great work and I do not want to consider your work as bad,
Thank you.

> but we should join forces to get a universal printer setup tool which
> makes printer configuration as easy as possible. Therefore I want to
> suggest to merge the projects somehow.
As Matthias wrote before, this should be an easy tool and not universal one.

> In system-config-printer there are a lot of special features to make
> setting up printers as easy as possible, mostly by working around the
> shortcomings of CUPS and the existing printer drivers:
>
> - Creating a list of detected printers with exactly one entry per
> physical printer. Especially the output of the CUPS backends for
> detecting network printers (snmp, dnssd) is not easy to identify as
> coming from the same printer.
> - Comparing manufacturer and model names. They are written in many
> different forms in PPD files, device ID entries and printer databases.
> system-config-printer uses an algorithm based on how humans read the
> model names.
> - Finding the best driver if there is more than one driver available for
> a printer. system-config-printer uses a special set of rules here.
I'm working on this right now and when finished these features will be
available in g-c-c too (without need of another dependency).

> - Printer driver auto download from OpenPrinting. The OpenPrinting web
> site lists manufacturer-supplied printer driver and PPD packages for
> automatic download. This way a printer, even if it is not supported by
> the installed Linux distribution, can be set up fully automatically.
This is a problem. As Matthias said, we can not automatically install
binary drivers.

> - HPLIP integration. system-config-printer joins detected HPLIP URIs to
> the USB URI of the same printer and selects the HPLIP URI by default, it
> finds the HPLIP URIs for network printers, and automatically also
> creates the fax queues for multifunction devices.
If this is really needed, I'll add it to g-c-c too.

> - Plug'n'Print: New USB printers are automatically detected and set up
> when plugging them in. Also queues of USB printers are disabled when the
> printer is turned off and re-enabled when the printer is turned on, even
> if the printer is controlled by HPLIP.
This is part of system-config-printer-udev and used by
gnome-settings-daemon's print-notification plugin. I'm not sure about
the re-enabling right now, but it shouldn't be hard to add it there.

> - Server Settings: The server settings settable with the CUPS web
> interface (and some more) can also be set with system-config-printer.
This was not intended to be included in g-c-c.

> - Easy setup of queues pointing to SMB/Windows shares
>
> A switchover to the GNOME tool would lead to most of these features
> getting lost and printer setup getting more complicated for
> unexperienced users.
I don't agree with this. I try to make it easy for users.

> So somehow we should get these features into the new tool without
> rewriting them from scratch.
Most of the tool is already written and is already part of Fedora 15.
Who do you suggest to work on this?

> They are all written in Python and AFAIK the GNOME tool is written in C.
> To avoid rewriting all this in C I suggest to create a D-Bus service
> containing functions for all the features listed above and making the
> GNOME tool calling these functions. The GNOME tool could even be reduced
> to a pure D-Bus frontend for the system-config-printer D-Bus service
> which does not communicate with CUPS by itself.
> This avoids the need to move the implementations to another programming
> language or reimplement the stuff for other reasons.
> system-config-printer's GUI can be continued to be maintained (as a
> D-Bus-only frontend not communicating directly with CUPS at all) for
> non-GNOME systems like Xubuntu.
>
> KDE's printer module could then be done this way as well.
>
> Most important is that in system-config-printer the GUI part and the
> algorithmic part need to get well separated, so that all printer setup
> tools share system-config-printer's algorithmic part as a D-Bus service.
> So Tim's and my work get available for everyone and we avoid the
> reinventing of the wheel.
This should be done on the s-c-p side at first. We can consider
application of such service in g-c-c after that.

> We will discuss this also on the Ubuntu Developer Summit in May. See
>
> https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-system-config-printer-vs-gnome-3-control-center
>
>
> TYhe discussion session will be somewhere on May 11-13 and remote
> participation will be possible. Marek, please create a Launchpad account
> (if you have none yet) and subscribe to the Blueprint linked above to
> stay informed.
OK, I'll subscribe to the blueprint.

> Tim, Marek, WDYT about these plans?
>
>    Till
Regards

Marek


----------

From a discussion with Marek in the last few weeks I need to implement and expose via D-Bus some methods in system-config-printer.  Using these, the GNOME printer settings can gain most of the sensible features it currently lacks:

1. getBestPPD

device_id,
device_make_and_model,
device_uri
    ->
ppd_name

2. missingPackagesAndExecutables

(We never actually agreed a specific interface for this if I remember correctly: should it operate on a large string, being the PPD file content itself?  Or a ppd_name?)

3. groupPhysicalDevices

a{sa{ss}} DEVICES DICT
   ->
aas     URI LIST

> 2. missingPackagesAndExecutables
> 
> (We never actually agreed a specific interface for this if I remember
> correctly: should it operate on a large string, being the PPD file content
> itself?  Or a ppd_name?)

I would go with the "ppd_name" but I'm not 100% sure whether we can pass to it a custom PPD (e.g. downloaded manually by user). Can "ppd_name" contain "file:///..." type URIs?

Marek

No, if it's possibly it won't be one that CUPS knows about we'd better use the PPD content as a string (actually "ay" because PPDs come in all sorts of weird encodings), or else pass the filename around like cups-pk-helper does.

OK, maybe it would be better to create the separate method which accepts ppd_filename instead of ppd_name. I don't like the idea of sending whole PPD file over DBus.

system-config-printer 1.3.5 contains the D-Bus methods.

I've modified current g-c-c master so that it uses GetBestDrivers and GroupPhysicalDevices if they are available. I'll add MissingExecutables method soon (hopefully tomorrow).

Marek

I've modified g-c-c so that it uses also the MissingExecutables method now. All these changes will be part of 3.1.5 release of g-c-c.

Regards

Marek

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new bug report at
  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/

Thank you for your understanding and your help.