The Printer Device Icon

June 23, 2009

The XS installation leached away almost a week of mine, the previous one I mean. And with moodle I have officially wasted 2 weeks, hence to avoid not being productive at all, I’ve decided to finish the sugar side asap, and at least get a working model done here soon:

After a kick start from Andres, and looking up D-BUS tutorials and the HAL spec,
and of course extracting source from system-config-printer, and hacking our own Network device icon, and volume device icon, I have written a Printer Device Icon
here is the code for it:

and here’s how it looks:

Feedback most welcome!


Moodle plan sketched!

June 9, 2009

Talking to Martin Langhoff had been VERY helpful, I now have an architecture to work on:

1)As pointed by Dave( thanks Dave), we already have implementation that sets a cookie and authenticates users courtesy the webactivity
And Martin had said auth/olpcxs/auth.php should yield good stuff on the implementation.
2) The two ways this would be integrated into moodle could be:
i) As a new tab under the moodle’s user page
ii) As a module under courses

Both have use-cases ,
for i) This can be a global event without any relevance to courses, so one wont have to really be in a course to use printing.
ii) having this within a course allows group management to be easy, and we could easily restrict which teacher gets to accept/reject printing for which student
I’m inclined towards ii) as implementation wise, and use-case wise that seems to have an upper hand.

Now to sketch a detailed plan for 3 weeks to come:

Authenticate myself, and send files under a specific user, via HTTP-POST vs XML-RPC.
Start building a skeleton for a new module under courses.

fill it with a print queue, based on cron.php. also in case a teacher logs in, have a print button when ever a printer is available.

fill it with anything else that is left. Get back to sugar part.

Also, so far my moodle expeditions only lead to a better undertsanding of how the system works.
Last week was adding a few more bug fixes to the print activity, and code- and-prune moodle side.
And mostly testing new theories.

So anyway since i have concrete goals this time, I should do this asap.
A detailed discussion can be found here:

Print Metamorphoses..

June 3, 2009


last week was pretty mundane, I was mostly with #moodle taking tips and trying to create a plugin for assignments that does printing, constraints uploads to PDFs and also displays them as thumbnails. Martin L had said there is definitely a much better way to do this, and we should be having a meeting this weekend.

From what I understood with moodle is the following:
Moodle has amazing extensibility:

1) It allows plugins to be placed with simple ‘tag’ code

2) You never have to build anything new for a moodle feature, It already exists within the core libraries (lib), you just need to properly play with it.

3) moodle has comments for every three lines of code

Only pitfall is, you can never figure out where to place new code, code which is non-moodle, that is:P

I had taken the existing upload assignments type plugin and made a new type print plugin, added new strings to get_string(). And played with the upload_lib.php so I could do pre-checks for PDF, and was looking up where exactly to put the thumbnail code. I guess this would have made my job quite trivial.



What I had proposed in my previous post is pretty much alive now. To sum up:

I made a 140 line basic print API that (for the time being only) parses filetypes like rtf and odt to cups-pdf, gets a temp pdf, and opens it in Print ( yes, this is the metamorphosis I was talking about, It is Print NOW!). And a new function in takes care of saving the pdfs. homunq had said saving a journal entry by default is good, I will have to edit it sometime.

*From my time with the pycups wrappers and system-config-printer, I’ve discovered that there is great scope to put print devices on share, or print to shared devices, display print queues, cancel jobs and what not. If only thing that might be of some work is, is the page config options. All this I sum upto a +300-400 lines of code in the print API.

Now comes the question of how to display all of this jargon to the sugar user. ‘How and When?’ .Tomeu had said he would help me on this one by posting a mail on the lists, I will also look up other activities and try to create mockups.

Andres and I got to do a few bugsquashing

And we were worried about Rainbow getting in the way, as cups-pdf could save to locations beyond rainbow provided freedom. Thanks to a discussion with Benjamin M. Schwartz, that got sorted out.

And I got around to making this function today:.

def _printPDF (self, _printer, _filename, _title = None):

Plan for the following week:
* Make Mock-ups
* Talk with Andres and team about where everything(such as queues, printer selection etc) would show up
* Talk with Martin and get the moodle plan sketched
* If all works out write out a rigid deadline for each week.

And when I’m not doing any of that:
* Code on elongating the sugar Print API