Sugar Labs

Summer of Code/2009/Print Support: Difference between revisions

← Older editNewer edit →
IwikiwI (talk | contribs)
143 edits
IwikiwI (talk | contribs)
143 edits
Line 61: Line 61:
:A step by step abstraction:
:A step by step abstraction:
   
   
:'''1) ''' During boot of the XO laptops, Sugar will compile itself in compliance to supported file types(locally), and will have the print button enabled only when they are available.
:(The first step would essentially mean a Save as PDF hack and put the jobs for processing on moodle ) 


:'''2)''' The print button on click, prints the screen objects into PDF format. This will be turned into a nice sugar.print API.
:          (The first two steps would essentially mean a Save as PDF hack) 


:'''1)''' (this is no way related to abiword's print to pdf ability)
:The right click menu of an item in the journal will have a new option, i.e. create PDF. When clicked, the item will be sent to a local virtual CUPS-PDF printer, and the pdf will be marked with metadata attached stating its details.The PDF can be marked for printing or unmarked for printing. We will be using moodle as our interface for sending print requests on the network. The interface will have a user page and a teacher page. The page will have a report of his print jobs and a status report of his live jobs. And the ability to put 3 live jobs on queue. The no of upload slots will be dynamically updated according to his live jobs pending for teacher's approval. And the number of free slots will automatically be filled up by the browser with the to print PDFs. And then these objects can be sent to the moodle web folder.


:'''3)''' This is an interesting step, we have two implementations here: 1) the XO case 2) No XO case
:'''3)''' Through moodle the teacher will have a page displaying the contents of the print datastore along with user names attached, and he/she will be able to download them to his remote system, and  check them and approve them for printing if he/she wishes. After his/her approval or disapproval (that is a delete along with an option why) the information is held in the datastore, and the user can view it in the form of history transactions pertaining to his id, and teacher can view a finite list of previous transactions pertaining to all.  :


:In the XO case, we will have an activity in cp which prompts for Users moodle ID and password (which can be saved, and changed again if need be), and as an addition to the last step the pdf is sent to the moodle data warehouse, and a maximum of 3 live jobs in queue will be possible. The activity in cp will also show a notification of how many print jobs are in queue, and whether they have been printed or not. Also the teacher will be able to send an optional reason as to why the job was discarded.
:'''4)''' The no School Server case. The simple solution to this case is to print directly through usb. And this won't be counter productive to the idea of teacher moderated printing, as the printer won't be available for just anyone; this is only a quick alternative to the 'save to portable drive and do the printing' method.  


:In the No XO case, there will be a send-for-printing page( a moodle plugin) which allows the user to send his request to the datastore in the school server. On a successful send the user's page will display him the details of his job, whether in queue for printing and waiting for approval from the teacher or done printing or disapproved for printing along with an optional reason why, he can also cancel his request from the page. There will be a quota of maximum 3 live jobs per student.
:'''4)''' Through moodle the teacher will have a page displaying the contents of the print datastore along with user names attached, and he/she will be able to download them to his remote system, and  check them and approve them for printing if he/she wishes. After his/her approval or disapproval (that is a delete along with an option why) the information is held in the datastore, and the user can view it in the form of history transactions pertaining to his id, and teacher can view a finite list of previous transactions pertaining to all.
:          (These steps would mean a) moodle print queue, web interface b) (3) a cp activity that bypasses the need to use (2) if you're in Sugar)
:'''5)''' So we've had a no XO case, similarly we have a no XS case. The simple solution to this case is to print directly through usb. And this won't be counter productive to the idea of teacher moderated printing, as the printer won't be available for just anyone; this is only a quick alternative to the 'save to portable drive and do the printing' method.
:'''In-Depth analysis:'''
:'''In-Depth analysis:'''


:The easiest way to implement step-1 would be to check which mime types exist on the client side in the etc/cups/mime.types and mime.conv file with a simple python method (getAllowableMIMETypes) , and access it with a :python script and compile our sugar shell accordingly. So any mime type non-existent there will have its corresponding activities print button disabled. We will also write code for it to accept copy Mime info from activities .info files (whether a new activity or old)


:for step-1, We use CUPS. The API has a nice array of functions, one of which is to get the printer's name (the cups-pdf virtual printer).( Since we know the name is CUPS-PDF, we can check it) and print our file as a PDF in the journal. For the sake of our python convenience we will be using a python wrapper to cups, pycups. The print objects will have metadata attached to them through the sugar datastore API.
For the second part of it when ever the print page url is found, we make browse communicate with the moodle print queue through xmlrpc get the details, and upload to that many slots (as the number of slots will also be dependent on the print queue)
This would essentially mean a rainbow hack so that browse can communicate with journal without a dialog. The execution part of this will take place as the


:for step-2, We use CUPS. The API has a nice array of functions, one of which is to get the printers name (the cups-pdf virtual printer). Since we know the name is CUPS-PDF, we can check it, and print our :file as a PDF to the journal. And the API can be made by generalising the pycups methods and sugar api in general.
:For the sake of our python convenience we will be using a python wrapper to cups, pycups. We will be using our Sugar api to create a nice simple widget for this. And we will use D-Bus for transfer of :objects to journal. The print button will be just saving the file in its original mime format, and then a Cups-PDF job takes place and outputs a pdf in the to print objects category. And, the original :saved mime type is destroyed.


:for step-3,
:for step-2, We will be using the interface already created, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests, and the approve button will initiate shell commands to send the particular file to a network printer through CUPS installed on the server.This can again be achieved through hacking into moodle and understanding how notifications are sent to the students from teacher. The notifications would be relating to whether the teacher has approved or disapproved the print. case a, we would just make  
:For a), We will create an activity in control panel which takes in the moodle id/password. And within activities when the PDF is created, through '''xmlrpclib'' for python we write code which sends the print jobs directly to the moodle datastore (web folder) and with each successful send show the file and queue no in the control panel activity.
 
:For b) We will be creating a new print management page in moodle, which accepts at most 3 print requests(the pdfs) from the user at a time until one of them is processed or deleted. We will be :creating a plugin with the FILE_API of moodle( which enables us to do things like uploading client side files, and sending them, and receiving back the files, deleting them)  in php, and access the local :to print files, send upload them to the moodle server datastore. I will be taking the already available "upload one file for teacher's review" plugin's code as basis for this. [http://docs.moodle.org/en/Upload_a_single_file_assignment]
 
:for step-4, We will be using the /same plug-in/interface already created/, but for the teacher we will issue global access privileges enabling him/her to access all the sent requests, and the approve :button will initiate shell commands to send the particular file to a network printer through CUPS installed on the server.This can again be achieved through hacking into moodle and understanding how notifications are sent to the students :from teacher. The notifications would be relating to whether the teacher has approved or disapproved the print. And when going with step 3) case a, we would just make moodle talk back to our activity through xmlrpc, and tell the user whether his job has been printed or discarded, and provide a reason why.
 
:for step-5, no new code is required, just a slight modification of the cp activity to select the type of printing. A few more dependencies, Which wont exceed 17mb.


:for step-3, no new code is required, just a slight modification of the cp activity to select the type of printing. A few more dependencies, Which wont exceed 17mb.


:''Is there a disadvantage in relying upon moodle for network printing?''
:''Is there a disadvantage in relying upon moodle for network printing?''
:Since the whole concept relies upon network printing, it will be feasible for moodle to coexist with the system on the school server. We will just be adding moodle as a :requirement for printing.
:Since the whole concept relies upon network printing, it will be feasible for moodle to coexist with the system on the school server. We will just be adding moodle as a requirement for network printing.  




Line 105: Line 91:
:* Will be able to print to any USB printer
:* Will be able to print to any USB printer
:* Will be able to output a print as a PDF
:* Will be able to output a print as a PDF
:* Can be extended to include any activities MIME types for PDF printing or USB printing
:* Includes a local queue and a teacher queue
:* Includes a local queue and/or and a teacher queue
:* automatically parses print requests to the print page
:* Has a nice control panel activity that takes care of sending files from activities and locally queueing them
:* CP activity will have the feature to select the type of printing, which will by default be pdf.
:* CP activity communicates directly with moodle data store through XMLrpc.
:* Uses moodle as interface for teacher moderated printing
:* Uses moodle as interface for teacher moderated printing
:* A 3 live/pending jobs at a time queue.
:* A 3 live/pending jobs at a time queue.
:* Teacher can approve/ disapprove printing from the queue.
:* Teacher can approve/ disapprove printing from the queue.
:* Student will have status updates in his page and/or in his cp activity.
:* Student will have status updates in his page.
:* Has a no XO case, no school server case.
:* Has a no school server case.




Line 146: Line 129:


:'''4 What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.'''
:'''4 What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.'''




Line 159: Line 143:


:'''Week 1 : '''
:'''Week 1 : '''
:Start writing script which actually configures the network printer server side.
:Write code which prints to any selected printer. (CUPS-pdf will be the primary case till gsoc), and add the print button to the item right click menu of journal.
:Write code which prints to any selected printer.  
:Start working on code browse hack to parse file paths to a specific pages forum input box.


:'''Week 2 : '''
:'''Week 2 : '''
:Start Work on writing a control panel activity which takes in the moodle account details, integrate this with a print button in each activity.
:Finish with browse.  
 
Mile stone 1 result : Sugar side of our code will be done. get community feedback
 
'''Milestone 2'''


:'''Week 3 : '''
:'''Week 3 : '''
:Finish working on UIs, and append a new printer module(api) to Sugar packages (api) which abstracts a lot of code. Also write code to save to journal for our case 3) b)
:Start working on moodle's userpage.
 
:Hack the 'upload an assignment' code and make a new plugin out of it.
:Mile stone 1 :'' See to it that the code can print to the pdf virtual printer and attached printer. Obviously apart from these both network printing from the XOs will be disabled. Get mentor and community feedback.  




Line 174: Line 161:


:'''Week 4 '''
:'''Week 4 '''
:Start working on moodle, build a 'For printing' page plug-in, see to it that it accepts files from client side, and stores them in moodle's webfolder (datastore) and from our control panel activity that we wrote previously
:start working on moodles teacher page, and see that he/she can review only his group's assignments


:'''Week 5'''
:'''Week 5'''
:Add interfaces for teacher logins and student logins, and write code to perform operations depending on the users/teachers interactions.
:And start working on a php script for shell commands to directly print to the
:And start working on a php script for shell commands to directly print to the network printer.
network printer.
 
:Mile stone 2 result :'' The teacher review feature and student upload features are working
Get mentor and community feedback. 
 
'''Milestone 3'''


:'''Week 6'''
:'''Week 6'''
:Finish working on the logical part and start working on creating a nice html layout for the page, get feedback and make corrections accordingly.
:Start working on creating a nice html layout for the page, get feedback and make corrections accordingly.


:'''week 7'''
:'''week 7'''
:Test code on a server with a printer, and test if everything works, get mentor and community feedback, and if any integration bugs remain, drill them out.   
:Test code on a server with a printer, and test if everything works, get mentor
and community feedback, and if any integration bugs remain, drill them out.   
 
:Milestone 3 result: '' It would be to finish the moodle plugin, and see to it that
printing can be done through it by the teacher''
 
Beyond GSoC:


:Milestone 2: '' It would be to finish the moodle plugin, and see to it that printing can be done through it by the teacher''
Make the printing feature an integral part of the API so that printing can be done directly without the journal UI's intervention
Make a CP activity to select the default printer.


====You and the community====
====You and the community====
Retrieved from "https://wiki.sugarlabs.org/go/Summer_of_Code/2009/Print_Support"