143
edits
Changes
Jump to navigation
Jump to search
Line 63:
Line 63: − + − + + + + + Line 79:
Line 83: − + + + + − +
Summer of Code/2009/Print Support (view source)
Revision as of 08:05, 25 March 2009
, 08:05, 25 March 2009→About your project
:'''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.
:'''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.
:'''2)''' The print button on click, prints in PDF format locally,that is, saves them under a specific 'print objects' category in the journal. This will be turned into a nice sugar.print API.
:'''2)''' The print button on click, prints in PDF format, saves them under a specific 'print objects' category in the journal. This will be turned into a nice sugar.print API.
:'''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 will be a quota of maximum 3 live jobs per student.
:'''3)''' This is an interesting step, we have two implementations here: 1) the XO case 2) No XO case
:In the XO case, we will have an activity in cp which prompts for Users mooodle 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.
: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.
:'''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.
: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 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 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-3,
: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.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.
: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. 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.
:''Is there a disadvantage in relying upon moodle?''
:''Is there a disadvantage in relying upon moodle?''