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