[Sugar-devel] Print Support proposal (need input) Beta
Vamsi Krishna Davuluri
vamsi.davuluri at gmail.com
Thu Mar 19 12:43:27 EDT 2009
class room/school server as the print server*
On Thu, Mar 19, 2009 at 10:11 PM, Vamsi Krishna Davuluri <
vamsi.davuluri at gmail.com> wrote:
> Carol, thanks for replying! Much appreciated!
>
> So in a classroom environment, can I assume the classroom server will be
> acting as the server?
> The thing is I never got proper input on what I branded obscure. Yes, I
> agree, if its a classroom environment I'll definitely add permission access
> and queuing management.
>
> Permissions I'd grant as follow:
>
> Only the requester and the print server owner can remove the requesters job
> from the queue, otherwise there is no way to stop the job.
> Implementation to check match IP address should do the trick, a read in the
> configuration file, and the originating signal.
>
>
>
> On Thu, Mar 19, 2009 at 10:00 PM, Carol Farlow Lerche <cafl at msbit.com>wrote:
>
>> Print queue management and quotas are key to this feature being usable in
>> a classroom/school environment. Consumables are very expensive and kids
>> love to hit print, often without thinking. So providing a way to place
>> print jobs in a "hold for review" status is very important, IMHO, as well as
>> providing a way to look through the queue releasing only the jobs you really
>> want to print.
>>
>> 2009/3/19 Vamsi Krishna Davuluri <vamsi.davuluri at gmail.com>
>>
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>
>>
>> --
>> "It is difficult to get a man to understand something, when his salary
>> depends upon his not understanding it." -- Upton Sinclair
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090319/478ed36c/attachment.htm
More information about the Sugar-devel
mailing list