[Development] [Interest] Printer-specific options in Qt5's print dialog (Linux, CUPS)

[Andrew, Shaw]

Development på vegne av Thiago Macieira <development-bounces+andy.shaw=qt.io at qt-project.org på vegne av thiago.macieira at intel.com> skrev følgende den 30.01.2017, 17.57:

    Resending this to the development mailing list.
    
    Others: please read Michael's email below.
    
    On segunda-feira, 30 de janeiro de 2017 14:12:32 PST you wrote:
    > Hi,
    > 
    > in September 2015, I asked about the status of printer-specific options
    > in the Qt 5 print dialog on Linux (with CUPS as printing system), s.
    > thread at [1].
    > 
    > As John Layt explained, a rework of the print dialog had started for Qt
    > 5 but could not be finished until then. The implementation for
    > printer-specific options had been rather broken in Qt 4 and was removed
    > for Qt 5, with the plan to reimplement them as part of a new printing
    > system. John explained that unfortunately, work on the new printing
    > system could not be continued then due to lack of time and money. As far
    > as I can see, the situation now is still mostly the same.
    
Unfortunately it would seem that John is no longer working on the printing system in Qt, so little has been done on it lately, though there are some of us doing changes to it still but they are mainly fixes and not actual features.

    > As printer-specific options (like e.g. selecting a particular input
    > tray, setting a PIN for a confidential print job, punching, creating a
    > booklet, ...) are quite an important feature for us (City of Munich), we
    > are currently evaluating different options for how to continue. One
    > option is to implement that functionality ourselves or have a contractor
    > implement it for us.
    > 
    > We would very much like this feature to be available upstream so that
    > everybody can benefit from it and we do not have to maintain it in our
    > own "fork" of Qt.
    > 
    > Before we make any further plans, I wanted to ask about the Qt project's
    > current plan for the print dialog.
    > 
    > While I am very grateful for the links John has given about the new
    > print system back then, some points are still a bit vague to me and I
    > currently do not know what the next concrete steps in the implementation
    > of the new print system would be to get closer to the desired goal. (Any
    > further information on that is welcome.)
    > 
    > Back then, John had written that various new features need to be
    > implemented for the new Qt print system and a temporary solution based
    > on the current code might be a better approach at first. In case no
    > activities are currently planned on Qt's side, our current technical
    > approach would probably be to implement the feature based on the current
    > 
    > code base and make an implementation similar to what John wrote in [2]:
    > > Given the dependency tree of new features required to reach the end
    > > point, a temporary implementation might be a better bet than waiting
    > > for the new print system, i.e. reimplement the old extra page but
    > > smarter. The main problem with the old page was it duplicated settings
    > > from the main dialog, and hid the fact you could actually edit the
    > > values. The UX I had in mind for Qt4 was to choose all the features
    > > that could be supported directly in the main dialog and add them
    > > there, then filter those out in the extra page in a generic editing
    > > view. It would require a lot of work around parsing PPD's and matching
    > > option codes to existing ui, but it's doable.
    > 
    > I would be very grateful for any further information on the topic,
    > particularly on the following questions:
    > 
    > 1) Are there (concrete) plans for the next steps considering the Qt
    > print dialog?

Currently there are none as, to my knowledge, no one is working on the print dialog specifically.

    > 2) Is the Qt project interested in us working together with them to get
    > the feature implemented upstream?

I would be willing to look at the changes and review them, I am sure there are others out there too who would be willing too.

    > 3) Is a temporary implementation as described above considered as a good
    > approach for now?

To be honest I am not entirely sure, I personally would be in favour of implementing it the right way the first time if it is going to go into Qt rather than having a stop-gap solution. There is nothing to gain I think from an intermediate solution, though if you are referring to doing it in your own code then it is probably ideal for the short-term.

    > 4) Are there other people/organisations that have the same problem? Do
    > you have approaches to deal with that?

Not to my knowledge, but that is not to say that there is no one out there.

    > Possibly, Qt's development mailing list might be a better place when it
    > comes to more details about a a possible implementation, but I wanted to
    > start here where the discussion took place in 2015.

Personally I would go ahead and submit what you have then we can at least look at the code and take anything further from there in that respect. As for the overall direction of the printing module this would probably be a good place to discuss that.

Andy