[cups.development] Custom printer list for all applicatons

Francis Giraldeau francis.giraldeau at revolutionlinux.com
Wed Nov 12 09:12:08 PST 2008


Tim Waugh a écrit :
> On Wed, 2008-11-12 at 10:42 -0500, Francis Giraldeau wrote:
>   
>> Hi,
>>
>> I would like to discuss issues with printer list displayed to users
>> within open source desktop.
>>
>> In large environment, the cups printer list may get very long, and we
>> need a way to display only relevant printers to the user.
>>
>> There are so much printing panel out there, and they are not using a
>> printing framework other than libcups. So, I changed the libcups library
>> to return only printers defined in a configuration attribute. (Well, the
>> code itself is not high quality, but it shows the concept)
>>
>> https://svn.revolutionlinux.com/MILLE/XTERM/branches/ltsp-cluster/cups-client-filter/libhideprinters/libhideprinters.c
>>     
>
> An alternative approach is this:
> http://www.opensolaris.org/os/project/presto/Documents/GUI/presto-ux-0.3.pdf
>
> The idea is to modify the GTK+ print dialog in two ways:
> 1. Add a 'filter box' for filtering by description, info, or location
> 2. Add a 'printer groups' listview to filter by user-defined groups
>
> See the screenshot on page 29, which shows these modifications.
>
> The list of printer groups is sourced from an XML file in the user's
> home directory.  The version of system-config-printer in the 'master'
> branch currently has support for managing these printer groups.  When no
> groups are defined, system-config-printer hides this groups list, and
> the GTK+ print dialog could do the same.
>   

It matches what I think users want. The problem I see with this solution
is that each applications should use the GTK+ print dialog, and many
applications aren't, like KDE applications, and even OpenOffice. How
could we manage that?

If every toolkit manages their own printer lists, then the user may have
to define them in multiple places, and we should avoid that.

If multiple frontends are available to configure the same printer groups
preferences, then it make sens.

I see few possibilities :
* Provide a new layer on top of libcups and update every print panel.
This will need a huge effort from a large number of people. It's
unlikely to work except if it becomes a freedesktop standard ;)
* Provide a kind of "client cups proxy" that manage printers groups, and
configure cups clients to that proxy.
* Adding group feature to cups client library itself.

Each solutions have their own advantages and downside. First, is there
other solutions? Then, which is the best solution?

Cheer,

Francis

-- 
Francis Giraldeau, Ing jr.
Analyste Infrastructure
Directeur Qualité
Téléphone : (819) 780-8955 poste 1111
Sans frais : 1-800-996-8955
Télécopieur : (819) 780-8871

Revolution Linux Inc.
2100 King ouest - bureau 260
Sherbrooke (Québec)
J1J 2E8 CANADA

http://www.revolutionlinux.com

Toutes les opinions et les prises de position exprimees dans ce courriel
sont celles de son auteur et ne representent pas necessairement celles
de Revolution Linux

Any views and opinions expressed in this email are solely those of the
author and do not necessarily represent those of Revolution Linux






More information about the cups-devel mailing list