We have something like 3000 printers. They are named something like “MF2301” and “MF2302”. The printer properties luckily show the location of the printer.
So let’s fire up system-config-printer and search for the right printer. First thing is that it takes ages for system-config-printer to start with 3000 printers. Somewhere close to 20 seconds. What’s happening? Is it requesting the status for each printer? Is the delay caused by 3000 icons (Nautilus is faster when displaying a directory with 3000 files)? Then we have the search field. Hmmm it allows only searches on the name, not by location or description. Unfortunately our users are humans and not computers, so they usually know the location where they are, but not the number of the printer. So I first have to walk to the printer, write the name down and walk back to my thin-client to select the correct printer and click “set as default”.
Now I want to print something. So I hit <ctrl><p> in openoffice.org, and it shows MF00001 as printer? That was not my default printer! Openoffice.org shows a dropdown with all printers, so I have to scroll through the 3000 printers to select the right printer again.
So far for printing for now.
Update: let me be clear, I don’t want to bash the developers of the printer settings (I’m very glad it exists!!!!) but I just want to show some of the issues that arise in large desktop deployments.
Olivier's Blog 
Usually the developer’s problem goes something like this:
I have one printer. It is named something like “Printer”. So let’s fire up system-config-printer and search for the right printer. Why isn’t it even auto-selected? […]
And this isn’t because of malice or incompetence, it’s because they “normal people” that didn’t have this use case in mind. And I’m a GTK developer, I can tell you that GTK doesn’t have any developer using a thin client in an Enterprise environment as his usual development or target platform. In fact, I’d even go so far as to point out that the bug you’re encountering is that you’re trying to use GNOME in an environment it wasn’t and isn’t developed for.
Now there’s a way to change that, but it involves finding core developers on thin clients. They would notice these issues quickly and get them resolved quickly. But we don’t have those. I wonder why. Maybe thin clients suck so much that nobody would want to use them, let alone develop on them?
Benjamin,
that is exactly why I suggested to add this blog to planet gnome: because most developers don’t work in enterprise environments, and perhaps reading about one will in the future help to tackle these issues early in the design process.
b.t.w. it is not limited to thin-clients: a regular desktop with 3000 printers has the same problem.
kind regards
Olivier
The question for me is if an Enterprise environment is a valid use case. As I meant to point out in my comment above, for me the problem is that you are trying to use such an environment. For me the bug is not that GTK can’t handle 3000 printers. The bug is that there are 3000 printers. In fact, I’d go so far as to mention that the bug is that it is even possible to provide 3000 printers.
Side note: Every other peripheral hardware is broken, too if you attach 3000 of its kind – iPods in Rhythmbox, USB keys in Nautilus or Monitors in the Monitor configuration tool.
The thing is that our Linux desktop runs on terminal servers. The thin-clients are all over the country. So are the printers. The users are also all over the country, and not always on the same location – many users log on from multiple locations. Users also don’t know what type of printers are used. So we define all the print queue’s for them so they only need to select the right queue. Same for laptops, they can be used on all locations as well, and we can’t predict where. And that is where the above problem arises.
I agree it would be much nicer if we could provide a user with a very small set of printers that are near them. But AFAIK the printers are defined on a systems base, and not per user (and the same terminal server system might have users from all different locations).
The “recent printers” list suggested by John Palmieri would improve the situation quite a lot I think, as would “search by location”.
@Oliver: If you ever want to chat about printers and GNOME and OpenOffice, you can find me on the IRC as dave_largo. There are some tips and tricks that can be done to make life easier. We have around 75 printers and users struggle with them all the time.
With respect to Benjamin, the issues are not related to thin clients, but are instead related to not being tested with lots of printers that display to each user. If you had Linux/PCs with 3000 printers the same problems would be evident; the UI is just untested in this manner.
Similar issues arise just with a few hundred printers. It isn’t totally obvious to me what the
right solution would be. That’s why I haven’t filed a bug on it yet.
However, I do notice that I tend to use just a few printers, namely those physically close to
the locations I frequent. I believe that this small set of printers should be easy to select
from as opposed to only making it easy to re-use the last printer used. I imagine that the
small set could be auto-discovered by keeping usage counts and having them decay
over time.
The alphabetical list should clearly be a last resort, except perhaps the first time you use
a printer.
It might be obvious to you but may not be obvious to the developer since the use cases for what he or she is testing might be different. Just file a bug report
One printer seems enough to cause delays also, though perhaps for a different reason. When opening the gtk print dialog, it frequently, but not always freeze for perhaps five seconds with the text “getting printer information” shown next to the printer. The entire application is unresponsive. If it’s impossible to guarantee that this will never take more than a fraction of a seconds, it should be done asynchronously.
Ah, enterprise. Gotta love it!
Well, assuming the printing code had not being tested in an enterprise is pretty large leap. I am the person who implemented the printing backends for GTK and I had some plans for addressing issues like this before I moved off to OLPC in which printing was not a priority in places where ink and paper would cost more than e-mailing the teacher with a homework assignment. There lies the real conundrum. Printing, while still very important is a technology no one really wants to invest time or money into.
Part of the issue is the infrastructure – why would any one person want to have access to 3000 printers? You should only care about the ones which are within walking distance. CUPS was setup to use HTTP as a transport so that you could punch through firewalls and print halfway across the world. Since we have fax machines, pdfs and e-mails it seems like a bit of over thought. In any case I’m pretty sure an organization can configure their print servers to only broadcast printers in a particular location but most don’t and it may require a reorg of network infrastructure.
That leads me to the issue of blocking dialogs – it shouldn’t. I reimplemented the cups library in gtk to be non-blocking state machine that runs on the mainloop(cups was written to be used on a command line). If it is blocking it is during the http connection phase which could not be made non-blocking. However it was written at a time where Linux didn’t really have any good stand alone http libraries. Since we now have libsoup that should perhaps be swapped in to replace the cups libraries we are currently using.
As for printing from OO, it uses its own print dialog.
In any case the solution is to engage the GNOME design team and various printer gurus like Tim Waugh and Michael Sweet. We had momentum behind it once. The location search should be easy to implement. I personally don’t have any time to lend to the effort but if people are going to be at the Desktop Summit then is a great time to discuss the remaining issues. I will be there next Wednesday for the PyGObject hackfest if anyone has any questions.
—
John (J5) Palmieri
BTW GNOME devs have been talking about finding and reminding a lot lately.
My preferred solution reminding is to have a favorite/recently used printer list much like we have for the places pane in the file dialog. The idea would be that printers listed in that pane would be queried first to see if they are available. The reason this is not implemented is some things go against good design sense, like what do you do if you query a printer and it isn’t there. Do you grey it out? Do you even display it? If you don’t display it you run into the issue that items in the list will move around as printers are queried. For short lists you want to keep the number of items static and in the same place so the user can click on it from mussel memory.
Adding better searching and filtering would solve the finding part but then should we reset everytime the dialog is opened or should we keep the filter in place, potentially confusing the user who knows a printer is available but isn’t showing up in the list because he/she forgot the filter was set? Should that be per-app or global to the desktop
These are things a designer should ponder before implementation.
—
John (J5) Palmieri
The Presto UI we started developing for OpenSolaris was supposed to somewhat address this issue — the idea was a kind of “iTunes for printing”, with quick auto-detection, searching and grouping (smart or static) of printers for both sysadmins and end users, both in the print manager application and in print dialogs themselves.
Soon afterwards, though we switched from LP to CUPS by default. Presto would also have supported that backend, but we decided not to re-invent the wheel, so ironically we’re now using system-config-printer too. But the early Presto UI specs are still available here, if anyone’s interested: http://hub.opensolaris.org/bin/view/Project+presto/GUI
just like to note that this isn’t at all specific to 3000 printers. We have maybe 75 printers in our department, and there are still lots and lots of headaches.
Not meaning to necro this thread, but I run an LTSP environment with about 70 printers. I have the gnome GTK print dialog delay issue too. One thing I found is that if you disable the CUPS socket listener (it dramatically speeds up the printer display. (as in no delay).
You do have to set a generic listener though : Listen *:631
The downside of this fix is that in OO 3.2.1 (haven’t tried 3.3.0) the print dialog sometimes doesn’t fill the printer list and you have to cancel and Ctrl-P a couple of times….then it will work.
YMMV for which problem you want to deal with OO printer lists or GTK delays.