Re: Idea: guix printer configuration generation

[swedebugia]

On 2019-01-17 13:08, Gábor Boskovits wrote:
> Hello,
>
> swedebugia <address@hidden> ezt írta (időpont: 2019. jan. 17., Cs, 8:22):
> > "Gábor Boskovits" <address@hidden> skrev: (16 januari 2019 16:00:30 CET)
> > > Hello,
> > >
> > > <address@hidden> ezt írta (időpont: 2019. jan. 16., Sze, 15:35):
> > > > Hi
> > > >
> > > > I would rather not have to learn the CUPS web interface just to
> > > > configure my printer. Do we have a way to do this yet from
> > > config.scm? I
> > > > think we should abstract away everything CUPS.
> > > >
> > > > Maybe we could make a guix printer importer?
> > > >
> > > > The idea is to extract information about the printer via Guile and
> > > print
> > > > what the user need to add to the config.scm.
> > > >
> > > > Something like this:
> > > > $ guix printer
> > > >
> > > > "Found 1 USB printer: HP DeskJet 4330
> > > > (cups-configuration
> > > >   (printer
> > > >     (name "HP DeskJet 4330"
> > > >     (connection "usb://34234556"
> > > >     (settings
> > > >       (paper "a4"
> > > >       (source "default"
> > > >       ..."
> > > >
> > > > When the user adds this to their config.scm and reconfigures the
> > > printer
> > > > JUST WORKS.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Cheers
> > > > Swedebugia
> > >
> > > I've found the CUPS config stuff somewhat problematic.
> > > The config file is generated from another config file, and some other
> > > things, that trigger
> > > regenerating the config. Sometimes even the printer ink level is
> > > regenerating cups configs,
> > > which is really annoying. Modifying files in /etc is not a very nice
> > > way to handle that indeed.
> > > The problem is known upstream, and seems to be won't fix. If we could
> > > get around that in any sane way,
> > > I would be very happy.

Thanks for the link.

This morning I read parts of the source code for the filters.

I was not impressed.

As this program is essentially the work of one person and not a well 
oiled community that can be reasoned with it really begs to be 
forked/replaced.

In my view it should be split into a few well working interacting 
programs instead of this one big C program that tries to do everything 
from backend to converting to-from postscript, (rasterization), 
filtering, web admin system & printer sharing over the web.

I would be very happy with a tool set like this:
* frontend gui program to orchestrate the whole thing and help the user 
understand what is going on (display progress, errors, cancel job).
* guile-wrapper for ghostscript that helps converting pdf documents (if 
any program wants to print output pdf or ps please) + guile-wrapper to 
apply filters for a given printer configuration.
* backend to communicate with the printer (exposes API) (this could be a 
patched cups-minimal package).

Configuration is done in 1 file that is written by the user or guix when 
reconfiguring.

So to print I could either use the wrapper directly from the command 
line or use the frontend gui.

A cli frontend could easily be created that informs the user about the 
current state of the printer, the queue and maybe history of printed jobs.

If anybody wants to share the printer then this will be another 
server-frontend component developed apart from but interacting via APIs 
with the other parts.

--
Cheers Swedebugia