Any thoughts on how to display a printer with multiple instances
Should the parent appear as well as the instances ? or just the instances ?

Different instances of the same printer differ only in the settings, so I had
thought that they should appear as differnet settings. Currently every printer
in gnome-print has a single setting called default. I think the "default"
setting should be setting for the parent printer (Instance==NULL). The other
instances should be shown as other instances. (As they were just prior to
turning the print dialog into a print manager. I guess the UNIX idea of
separating different functions has gone out of the window.) 

Interesting.  I had a rather different perspective on the function of instances.
 I'd always seen them as specific printers in a pool.

PS
  The new printer selector seems like an improvement from the old static list. 
We don't want a full on printer manager in there, but having the list include
the number of outstanding jobs is an improvement in my eyes.

Cups also has the concept of classes, that are a pool of printers to which you
can send a print job and then cups figures out which printer to use.

Of course I have no idea how they are reflected in the new dialog if at all.
They are really more important than to see how busy an individual printer is. If
several printers could be used for the same purpose then a class should have
been configured, rather than having the user look at the number of jobs pending
for each printer.

Has there been any progress on this issue since last year? For now, I can get by
using xpp to see my instances but I'd really like to be able to select them from
the gnome print dialog. There's some commented-out code for instances in
libgnomeprint/modules/cups/gnome-print-cups.c but that doesn't compile when the
comments are removed.

The commented-out code used to support instances. Then, when a-synchronous
access was introduced the code was commented out, and support for instances lapsed.

I currently work around the limitation by creating duplicate printers with
different defaults rather than setting up instances. Perhaps that may be a
solution for you too.

I noticed that printing has recently been committed to gtk - does that have any bearing on this bug? In particular, is libgnomeprint slated to be removed? If so, maybe it'd be good to try to get support for instances into the gtk printing while people are still actively hacking on it.

Yeah, new features should definitely go into gtk+ at this point.

Moving to gtk+

Seems to be working correctly for me. Please reopen if this is still a problem.

Hi Timothy,

I don't see the instances in the print dialog. Which version of Gtk+ and CUPS do you have? How have you created the instances?

(In reply to Marek Kašík from comment #11)
> Hi Timothy,
> 
> I don't see the instances in the print dialog. Which version of Gtk+ and
> CUPS do you have? How have you created the instances?

I also cannot see CUPS printer instances in a recent master build of GTK+. It would be great if this bug could therefore be reopened.

I don't have time to look at this right now but I've reopened the bug.

I have worked on an implementation that treats each CUPS printer instance as a GtkPrinter.

I attach the 3 patches that add support for printer instances.
The first two patches do some refactoring to avoid that the implementation introduces a lot of duplicate code.
The 3rd patch contains the "actual implementation" of printer instances.

Please let me know whether the approach taken in that implementation is OK in general and which things I should improve to get this accepted. (I am not a very experienced C programmer, particularly when it comes to C89 and the Gtk+ coding style.)

Created attachment 312507 [details] [review]
first patch with refactoring to avoid duplicate code

Created attachment 312508 [details] [review]
second patch with refactoring to avoid duplicate code

Created attachment 312509 [details] [review]
patch that adds support for CUPS printer instances

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

Created attachment 369731 [details] [review]
first patch with refactoring to avoid duplicate code

Created attachment 369732 [details] [review]
second patch with refactoring to avoid duplicate code

Created attachment 369733 [details] [review]
patch that adds support for CUPS printer instances

(In reply to Matthias Clasen from comment #18)
> We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO
> if they haven't seen activity in more than a year. If this issue is still
> important to you and still relevant with GTK+ 3.22 or master, please reopen
> it and we will migrate it to gitlab.

This is still relevant. Can somebody with sufficient privileges please reopen? (It seems I don't have permissions to do so myself, since I am not the initial reporter.)

I have attached updated patches that implement support for CUPS printer instances for the current "gtk-3-22" git branch. The update also includes a few small fixes for memory leaks that a colleague who is a more experienced C programmer found while getting over the patches.

Those patches (and a Gtk 2 backport) have been in use in our organisation (about 18,000 Linux clients) for more than two years now, with no problems being reported so far.

Is it still the right way to attach patches here or should I rather create a merge request on GNOME's GitLab instance?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/236.