[Sugar-devel] Print Support proposal (need input) Beta

[Vamsi Krishna Davuluri]

Hello!

So here is a refined and less abstract approach for the Print Idea. (input
credit Luke, Ben, Tomeu)

Initial problem:

 where do we get the cups daemon/server from, and how do we have it working
on python since its written in c?
solution:
 The cups daemon would only need to be running on the core distro (add it as
a dependency), and we have the amazing pycups bindings which wrap it up, so
we can use in our configuration program and other apis which we will
discuss.

Now, that we have CUPS ready, lets step into implementing it

problem 2: Interacting with the CUPS daemon to actually configure the
printer

solution:

Debian has a python version of print-system-configure UI, hacking into the
code will yield a decent template for fedora. Which can then be tailored to
fit the sugar guidelines.


problem 3: Who does the actual printing of the files?!

solution:

well, again there's these amazing pygtk print modules that take care of it.
They make the CUPS API a backend, and work as a decent printing API, they
again access the print-system-configure UI(or diving more deeply, the files
postscript files (PPD) ) ( I have written a sample printing program
demonstrating it on fedora)



NOW LETS SUGARIZE THEM! (oh sweet sugar)

problem4: We have everything ready but where do we put our
print-system-conifguration?

solution: we strip the debian (python based) UI, and dress it up with our
nice sparkling UIs (the sugar design apis ) and put it in the control panel
              Here's where I propose an extra credit : Make the
configuration An Interactive Wizard, (someone add groovy animations later
on, or its on the end list on me) , as we will have
              to provide a default printer configuration at least once,
despite cups having the ability to automatically select the printer.

problem5: Okay, okay most of the job is done. Now where do we print from?

answer:
We print from that one place ofcourse, The Journal! (after all its he
uncrowned king bad joke)

   As it is it is against the bitfrost system for a program to both access
the network and the journal at the same time - secuirty constrictions. and
also as to see that activity writers dont have to struggle with the print
code, we can just see that the print requests are rendered into nice pdfs
(CUPS again, we can print to pdfs) with the click of a magical button,store
them at a known location and send those 'hit coordinates' and if any
metadata by the IPC, and queue them up on journal for print. As an ACK send
back a notification to the activity stating, "You have a print job waiting,
print it with default settings? or go to journal to edit settings" Remember
how i said pygtk can interact with the CUPS settings, well we will implement
the relatively important ones in the journal as an option.

Extra credit: I've been thinking about this make the school server take in
network print requests (feasible/required or not? input please)

Obscure stuff: CUPS server, Quota management, and permissions,

CUPS server is a background process (hence daemon) which loopsback over the
listening ports and ips.
CUPS already benefits from a standard print quota management, the secrets of
the implementation are in our debian configuration UI.
permissions: ( I need input here) print permissions should be of any matter
only if its a network assignment as far as i know.



So what's the end result::

A nice interactive printer configuration wizard!
Minimal work for the activity author! (an addition of 3 modules to print to
pdf, but it will be of great value, as the user can present his work in as a
pdf within the activity)
Journal acting as print dock!
pdf printing!
And everything sugarized

P.S. My actual application will be formal, please dont kill me :P

Input Input Input please!

Thank You
Vamsi Krishna Davuluri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090319/8d6e2fbc/attachment.htm