143
edits
Changes
Jump to navigation
Jump to search
Line 51:
Line 51: − + + + − + − + − + − + − + − + − + − − :'''In-Depth analysis:''' − + − + − + + − + − :For the sake of our python convenience we will be using a python wrapper to cups, pycups. − + − :for step-5, We will be saving the printed pdf files into a web folder, and we will add a page which lists the contents dynamically to moodle.And provide access rights only to the teacher's log in. The :teacher can download the file to his/her terminal from the page, view it and approve it for printing. Here comes to light a background program written in C which listens to requests every sleep(30) secs, :and this will every time it wakes up access the moodle's datastore( mysql table) and checks if the approve has been hit for a specific id(id is generated with respect to job arrival, and every time a job :in between is printed or removed, the ids sort themselves back). Consequently a remove buttom will also be provided, which does just what it says. − − :for step-6,With the function cupsCancelJob() the student can cancel the job before his request goes to server (or before it can be printed to pdf). − : And after actually entering the web folder, The cool background program running on the server comes into picture − : 1) we would send in a query with the name of the file and a .pdf extension − : 2) if that file exists on web folder delete, otherwise do nothing − : 3) send suitable message back − : This latter would be done only when cupsCancelJob() yields an error.
Summer of Code/2009/Print Support (view source)
Revision as of 15:17, 24 March 2009
, 15:17, 24 March 2009→About your project
:'''2 Describe your project in 10-20 sentences'''.
:'''2 Describe your project in 10-20 sentences'''.
:As the self explanatory name suggests, the project is to add print support to the laptops.For the time being, the print requests will be sent to the school server which would be connected to a printer/or :to a machine with a printer. Later on as we are going with a CUPS architecture, we can include USB printing on demand!
:As the self explanatory name suggests, the project is to add print support to the laptops.For the time being, the print requests will be sent to the school server through a moodle print page
then the teacher can view the files through his login in the same application, and approve them for printing to a print server. Later on as we are going with a CUPS architecture, we can include USB
printing on demand!
:''Why should my idea be considered:''
:''Why should my idea be considered:''
:My refined version of the print support idea is actually a better way of ensuring that paper abuse can be curbed, as the kids wouldn't really take into account :all the predicaments associated with :printing. And needless to say printing does take place with the teacher's intervention.
:My refined version of the print support idea is actually a better way of ensuring that paper abuse will be curbed, as the kids wouldn't really take into account :all the predicaments associated with printing. And needless to say printing does take place with the teacher's intervention.
:A step by step absraction:
:A step by step abstraction:
:'''1) ''' During boot of the XO laptops, Sugar will compile itself in compliance to supported file types, and have the print button enabled only when they are available.
:'''1) ''' During boot of the XO laptops, Sugar will compile itself in compliance to supported file types, and will have the print button enabled only when they are available.
:'''2)''' The print button on click saves the file to journal.This will have the same implementation as of a save file.
:'''2)''' The print button on click, prints in PDF format locally,that is, saves them under a specific 'print objects' category in the journal
:'''3)''' There will be a file-transfer-wizard (an activity) which allows the user to send server recognized formats to the school server. This will be provided as a notification in the activity the user is using when he clicks the print button and asks whether the user would like to go to the file-transfer-wizard.
:'''3)''' There will be a send-for-printing interface( 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 wll a quota of maximum 3 live jobs per student.
:'''4)''' The file-transfer-wizard will be a simple interface. It will send the current /stacked up/ files to the school server by the users intervention, this can even be configured to send automatically as well.
:'''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.
:'''5)''' The school server converts the requests into PDF and will store them in a web folder. And through moodle the teacher will have a page displaying the contents of the folder(a type of queue), 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 approval, a background process on the school server prints to a network printer. Otherwise the job will be left to remain, or be discarded.
:'''In-Depth analysis:'''
:'''6)''' There will a system to cancel print outs, the user would just have to hit the cancel button.
:The easiest way to implement step-1 would be to check which mime types exist on the server side in the etc/cups/mime.types file with a simple python method (getAllowableMIMETypes) and make it available :on the server's web folder, and access it with a c program during the XO laptops boot and append the list to our client side mime.types. So anything non-existent here will have its corresponding activities :print button disabled
: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 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.
:As an Alternative, CUPS print function returns a python -1/ C 0 when a non-supported MIME type is used, so we can take advantage of that and display a non supported format error.
:As an Alternative, CUPS print function returns a python -1/ C 0 when a non-supported MIME type is used, so I can take advantage of that and display a non supported format error.
:Sugar already comes with a nice save feature which saves files to the journal and categorizes them under the activity name. I will use a similar implementation for the print button in activities (which :is activated from step-1) and have it save files under a 'To Print' category/tag in the journal.
: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 under a special category. We will also be using a automatic script to configure the network printers client sides when user (although only
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, we use CUPS. The API has a nice array of functions, one of which is to get the printers name (we will be having the network printer, and especially the cups-pdf printer installed on the :server). Since we know the name is CUPS-PDF, we can check it, and print our file as a PDF on the server.
:for step-3, 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 our Sugar api to create a nice simple interface, and for communicating with the journal through the D-BUS IPC, this will just be a click of a button. And when a print is :finally done(see step -5 expansion), an acknowledgement notification pops back. The server background program sends a string packet back.This will be done with minimal client/server code. (the sending :back of a notification)
: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.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.