Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Mon, May 4, 2009 at 1:47 AM, Andrés Ambrois andresambr...@gmail.com wrote: On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote: Vamsi Krishna Davuluri writes: The priority is on sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review. It is a good idea to have the code that sends docs for printing (to Moodle, a local printer, or one discovered by avahi) in a reusable module that a /usr/bin/lpr script can use. Sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review can be done via /usr/bin/lpr, eliminating the trouble of having multiple data paths. Adding a print dialog to every activity (e.g. Adding some gtkprint support in sugar-toolkit) should be optional for GSoC. First we should concentrate on getting entries printed, and getting teacher review right. Then we can move code around for legacy support and nice print me buttons. If you start with what you disdain as legacy support, then you can trivially test getting entries printed from the command line. The same goes for getting teacher review right. You could even test with the TuxPaint activity, using real kids. the teacher checks his print page in moodle, views the file (either through fancy javascript or a download) and approves/disapproves for printing. Kennedy then logs into his moodle print page and checks if the job was success or not, and if he has a comment from his teacher. I can barely imagine that happening in a real classroom. Try this: The student brings his XO to the teacher's desk, with his work shown on the screen. The teacher looks at the work, then lets the student plug his XO into a printer which sits on the teacher's desk. Printing resources can be very expensive for most schools, so the system should include a way for students to submit jobs to a queue and for an administrator to preview and approve or denie them. Tux Paint can rate limit a student's printing. For example, a setting of 60 will be once per minute. Do not forget that this issue is more social than technical. In addition to any discipline, the teacher can simply turn off the printer. This is advisable in any case; many printers use excessive power in standby. I dont see a teacher having a printer on her desk. Most schools here in Uruguay (and I dare say in Perú) don't even have printers. If there is one, it will be where the server/administration is. And possibly locked in a cage (like we have the servers now). So that scenario is going to be priority one. That sounds like a printer that students aren't allowed to use. Such a school might not need printing support at all. Teachers are unlikely to learn a complicated (probably slow too) interface for approving printer use. I just don't see it happening with regular normal everyday human teachers. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Mon, May 4, 2009 at 10:44 AM, Albert Cahalan acaha...@gmail.com wrote: That sounds like a printer that students aren't allowed to use. Correct! But may be used seldom, as a special case, prize, etc. And teachers _are_ allowed to print -- while there's a good chance, the computers there are all or amost all XOs so this is quite relevant. Teachers are unlikely to learn a complicated (probably slow too) interface for approving printer use. Agreed, so if we keep it simple rather than complicated... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Mon, May 04, 2009 at 04:44:33AM -0400, Albert Cahalan wrote: Sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review can be done via /usr/bin/lpr, But that would sidestep the Journal and prevent review of the actual output (i.e. what it looks like on paper, not on screen - that can be vastly different!) before printing. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Mon, May 4, 2009 at 12:48 PM, Sascha Silbe sascha-ml-ui-sugar-i...@silbe.org wrote: On Mon, May 04, 2009 at 04:44:33AM -0400, Albert Cahalan wrote: Sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review can be done via /usr/bin/lpr, But that would sidestep the Journal and prevent review of the actual output (i.e. what it looks like on paper, not on screen - that can be vastly different!) before printing. It wouldn't have to. That could be how all activities put print jobs into the Journal. You are essentially using the Journal as client-side print queue, and Moodle as server-side print queue. You might as well use the normal (highly compatible) way to submit to a print queue. FYI, preview isn't going to be perfect anyway. PDF code can ask the printer for exact dimensions; this info is unavailable to the Read activity. It can be used for landscape/portrait rotation, scaling, or whatever. Some enterprising kid may even concoct a PDF that looks nice in Read, but offensive on paper. Getting your teacher to approve printing goatse is priceless. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
Vamsi Krishna Davuluri writes: So, talking to Tomeu, we agreed that for Write and Read using the gtkprint would be best as both support it as a printing API. The focus on Write and Read is short sighted and may lead to inflexible solutions. Now, the current plan is: 1) We do journal printing only, albeit, the respective activity opens the file. Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf or directly runs gs. This lets normal software, which is already designed to output standard Postscript to lpr, work just fine. After conversion, put the PDF into the journal. Better yet, just toss the file into the journal without conversion. BTW, this can also be implemented as a filter script that the normal lpr program invokes for the default printer. Now here a cross road is presented: 1) Do we use a print dialog inside each activity that can save it as pdf, print or export a pdf to moodle 2) Do we use separate buttons for each of these operations? What of the user experience? Separate buttons provides a distinction that will be important in some environments. Some places will want immediate printing. For now, the print button can be almost the same as the other, but with the output PDF marked for near-term deletion. Make PDF and Print now seem like fine names. The initial plan was to make Read the global printing station, how do you find this idea? Starting up Read just to print something is not nice. Read may even cause an out-of-memory condition. For sure, there is no need to very slowly render a big document that doesn't even need to be seen on the screen. the teacher checks his print page in moodle, views the file (either through fancy javascript or a download) and approves/disapproves for printing. Kennedy then logs into his moodle print page and checks if the job was success or not, and if he has a comment from his teacher. I can barely imagine that happening in a real classroom. Try this: The student brings his XO to the teacher's desk, with his work shown on the screen. The teacher looks at the work, then lets the student plug his XO into a printer which sits on the teacher's desk. Printing resources can be very expensive for most schools, so the system should include a way for students to submit jobs to a queue and for an administrator to preview and approve or denie them. Tux Paint can rate limit a student's printing. For example, a setting of 60 will be once per minute. Do not forget that this issue is more social than technical. In addition to any discipline, the teacher can simply turn off the printer. This is advisable in any case; many printers use excessive power in standby. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote: Vamsi Krishna Davuluri writes: So, talking to Tomeu, we agreed that for Write and Read using the gtkprint would be best as both support it as a printing API. The focus on Write and Read is short sighted and may lead to inflexible solutions. Read was selected to contain the send to print code because Tomeu expressed some concerns about the maintainability of that code in the Journal. Also, we agreed that going through read is good for reviewing the pdf output and saving paper on badly formatted docs. Now, the current plan is: 1) We do journal printing only, albeit, the respective activity opens the file. Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf or directly runs gs. This lets normal software, which is already designed to output standard Postscript to lpr, work just fine. After conversion, put the PDF into the journal. Better yet, just toss the file into the journal without conversion. BTW, this can also be implemented as a filter script that the normal lpr program invokes for the default printer. The priority is on sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review. It is a good idea to have the code that sends docs for printing (to Moodle, a local printer, or one discovered by avahi) in a reusable module that a /usr/bin/lpr script can use. Now here a cross road is presented: 1) Do we use a print dialog inside each activity that can save it as pdf, print or export a pdf to moodle If we are going to keep everything inside Read for now. It'll be best to have the print button only in Read. The use case we had discussed was like this: open the file in Read, if its not ps/pdf Read converts it using cups-pdf, displays it, and then you can use the print button in its toolbar. The converted file gets added as a journal entry right after conversion. The datastore already contains code to hard link identical files, so disk space usage in multiple conversions is kept to a minimum. Read could add a pointer to the pdf in the original entry's metadata as well. Adding a print dialog to every activity (e.g. Adding some gtkprint support in sugar-toolkit) should be optional for GSoC. First we should concentrate on getting entries printed, and getting teacher review right. Then we can move code around for legacy support and nice print me buttons. 2) Do we use separate buttons for each of these operations? What of the user experience? Separate buttons provides a distinction that will be important in some environments. Some places will want immediate printing. For now, the print button can be almost the same as the other, but with the output PDF marked for near-term deletion. Make PDF and Print now seem like fine names. I agree. Just a print button for now. The PDF will be generated on startup anyway. We can have the cups-pdf local printer in the printer selection dialog when we provide other printing methods. The initial plan was to make Read the global printing station, how do you find this idea? Starting up Read just to print something is not nice. Read may even cause an out-of-memory condition. For sure, there is no need to very slowly render a big document that doesn't even need to be seen on the screen. This is to encourage review and to keep the code away from the Journal. The code can then be moved to Glucose. Also, distributing a modified Read for testing will be considerably easier than patching the Journal. the teacher checks his print page in moodle, views the file (either through fancy javascript or a download) and approves/disapproves for printing. Kennedy then logs into his moodle print page and checks if the job was success or not, and if he has a comment from his teacher. I can barely imagine that happening in a real classroom. Try this: The student brings his XO to the teacher's desk, with his work shown on the screen. The teacher looks at the work, then lets the student plug his XO into a printer which sits on the teacher's desk. Printing resources can be very expensive for most schools, so the system should include a way for students to submit jobs to a queue and for an administrator to preview and approve or denie them. Tux Paint can rate limit a student's printing. For example, a setting of 60 will be once per minute. Do not forget that this issue is more social than technical. In addition to any discipline, the teacher can simply turn off the printer. This is advisable in any case; many printers use excessive power in standby. I dont see a teacher having a printer on her desk. Most schools here in Uruguay (and I dare say in Perú) don't even have printers. If there is one, it will be where the server/administration is. And possibly locked in a cage (like we have the servers now). So that scenario is going to be priority one. Next will be of course provide local
