[Sugar-devel] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)
Christoph Derndorfer writes: I honestly can't think of a use-case for including any sort of 3D acceleration into the basic Sugar and activities. There's about a million significantly more important things that people should be working on before even thinking about 3D (IMHO). One can use a 3D accelerator to greatly improve human factors in the GUI. Smooth transitions in the GUI are vital to reducing the user's sense of disorientation and confusion. This isn't just an issue for less-clueful users; you might not realize it but poor transitions are forcing needless mental effort that eats up a tiny bit of time here, a tiny bit of time there... and it all adds up. You may feel it in frustration even if you don't spot the cause. Without the 3D engine, animations are a painful compromise. They are slow, jerky, and CPU consuming. Imagine if the frame could slide into view with fast perfectly smooth motion and almost no CPU use. Think how much more usable Sugar would be. Imagine if view switching and activity switching looked like a rapid zoom out to showing a grid of all views and activities, then a rapid pan to the right grid spot, and finally a rapid zoom in to the newly selected view or activity. Better yet, make it all in one smooth motion so that the user feels as though they are jumping with a ballistic trajectory. The confusion goes away and the transition might even be attractive. You can't make this be acceptably fast or smooth without a 3D engine, even if you cheat by using static screenshot images for the activities. Imagine having every activity smoothly scaled to fit the screen. An activity opens a 320x720 window. It becomes a 400x900 window on the LCD, but the activity doesn't have to deal with that at all. Getting stuff to work well on the XO is suddenly much much easier. Users can spot objects on the screen faster if they have slightly organic shapes. Rather than having **perfectly** sharp corners on things, give them tiny anti-aliased curves. Use bump mapping and other shader features in **subtle** ways to enhance object edges. Make the edges look like they have been polished or sanded a tad, instead of being infinitely sharp and thus ill-defined to the eye. Today, pressing a GUI button normally causes the button face image to shift a bit. That's the best we could do before 3D engines. Imagine if the button face could pop from convex to concave, with perfect realism. The highlights, the density of the shadow, etc. The button metaphor would be more effectively represented to the user. BTW, stay away from the pointless stuff. It's now common to use 3D for random nonsense that hurts usability. Don't do that. Stick to the stuff that helps the eye follow things: smooth motion, softened shapes, realistic shading, quality scaling, etc. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Missing .po files in Etoys?
On 21.04.2009, at 13:19, Bastien wrote: While building sugar from sugar-jhbuild I got this error: , | + cp po/zh_TW/etoys.po Content/po/etoys/zh_TW.po | cp: ne peut créer le fichier régulier `Content/po/etoys/zh_TW.po': Aucun fichier ou dossier de ce type | make: *** [Content/po] Erreur 1 ` Looks like it happens with other .po files in etoys - see the screenshot. Any idea what's wrong? sugar_build_error042109.jpg Works for me. Both simply updating, as well as a full build. Even when I set my locale to LANG=fr_FR.UTF-8. Try this: rm -rf source/etoys ./sugar-jhbuild buildone etoys - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Print Support (journal vs activity)
[quoting tomeu] Hi all, my apologies for entering in this discussion so late, the soas and distributions deadlines played very badly with the gsoc schedule. If I understood correctly, the plan proposed in Vamsi's application implies that the conversion from the format in which activities write to a printable format like pdf would happen in the journal, I suppose through the use of cups and a set of filters. Is this right? I would like to know how we can expect that Sugar will be deployed with all the filters that the user will need as she installs more activities. Also would like to know if it has been considered to use instead the same approach that regular linux apps use. Thanks, [/quote] [quote=me]Tomeu ( from his sugar maintainer perspective) has expressed a potential disaster in the part-1 of my proposal, that is by using CUPS-Pdf we would be actually required a great load of filters which would be a nightmare for the maintainers. And also the issue to register each mime type with every install of a new activity, for which we would have to wait till a new sugar update. As an alternative he suggested I use gtkprint (for which again I have written a script and shown to tomeu), So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) But this would mean we do printing to device, and printing to pdf within activity only. For the moodle part, when in the print page, for the upload slots we limit it such that it can only upload pdfs OR what I had been thinking is, make py xmlrpc communicate with moodle's datastore, have a 'print to moodle' within the activity itself, and upload a maximum of three parallel live requests.. if 3 reached, disable the option The status updates of print requests and such can again be found in the moodle's print's user's page. The rest will be same as my proposal. [/quote] So talking to my mentor and silbe, I think I have sketched it like this, essentially each activity will be checked if it can print to pdf/ps or not, if not code in activity.py draws a cairo object (pdf) and makes an entry of it in journal. after which simple cups code can be written to print that pdf or send to moodle from journal. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] discussion of which javascript framework to use for Karma
jQuery makes the DOM suck less, that's it's main plus. I think the jQuery UI is complete enough for most tasks and doesn't have architectural constraints that keep it from getting better. It's also quite small. However, I don't think it should matter too much which framework is blessed. Web devs have their preferences (granted, most like jQuery). If jQuery in compatibility mode is used for the framework itself, web devs can use whichever framework they like. They get more consistency if they use jQuery, but it shouldn't be a problem if they don't. 2009/4/21 Bryan Berry br...@olenepal.org: Subzero, below is a conversation I had w/ my friend Christopher Marin who is a web developer. El es ecuadoreno pero crecimos juntos en Los Angeles. also, this google trends report should be of interest http://www.google.com/trends?q=dojo%2C+extjs%2C+jQuery%2C +mootoolsctab=0geo=alldate=ytdsort=0 me: hey dude, have a moment to chat? C: Sure me: I am working w/ a GSoC participant on Karma the first thing to do is evaluate which js framework to use we are going to evaluate dojo, jQuery, and at least 1 more what do you recommend? Christopher: Great My favorite general use js framework at the moment is jQuery. It seems to have the most momentum behind it, creator is js genius, and it is easy to write apps with it. The only thing it doesn't have a strong base in right now is widgets me: and widgets are what? Christopher: In my opinion ext is tops here. Things like grids, windowing and layout systems, tabs, menus, accordions, etc me: will jQuery catch up in time? or is it limited architecturally? Christopher: Ext can actually run on top of jquery So in our app at my company we run both jquery and ext Jquery has ui project me: and jquery-ui is analogous to extjs widgets? Christopher: They've made good strides lately, already have a book out just on that subproject Yes, but not as mature or near the range of functionality, yet, though I'm sure they'll catch up eventually Ext is coming out with a major new release soon, the base version of 3 is already outC Best thing to do with them is to check out their samples, documentation is also top notch. Also a few books came out on ext recently me: what about extjs community? its leadership? Christopher: Only issue with ext is licensing me: i don't like licensing problems at all Christopher: They made their licensing more strict as of 3. Free for open source projects, uses gpl But commercial is supposed to pay me: but for-profit, closed-source companies have to pay? Christopher: Community and leadership of ext good, though nothing seems as large as jquery community nowadays me: I don't like that. I want closed-source education companies to switch from Flash to js How do u compare dojo to jQuery? Christopher: Yes, those have to pay Microsoft and nokie recently standardized on jquery Nokia So lots of folks from those camps are contributing code and samples me: cool, and big for-profit edu companies will like it better if uses similar technologies to MS Christopher: Dojo is mature, probably stronger in widgets, or at least more standardized in terms of look and feel The thing is with jquery there are a million plugins, but until ui project there was no standardization of look and feel, and how components shoulkd interact Sent at 9:52 AM on Tuesday Christopher: That's the beauty of ext, you can do a full almost desktop like ui with sortable, filterable grids, even bake it all into adobe air. jquery not quite there yet Sent at 9:54 AM on Tuesday me: it's pretty critical to me that commercial companies use our little framework. Anything that slows down commercial adoption would be bad. Christopher: But back to dojo, my sense is that it has lost momentum, along with prototype and scriptaculous. Mootools is another intersting one. me: could dojo regain the momentum? does it have good leadership? Christopher: An interesting experiment would be to do a search of these on google trends. You'll see how these have fared over the last year me: sure Sent at 9:56 AM on Tuesday Christopher: If I had to pick one framework it would be jquery Chances are, someone somewhere will have solved many of the challenges you'll face me: which is what I am really hoping for what are more plusses, minuses for dojo? here is an older trend report file:///home/hitman/Desktop/Personal/Link% 20to%20docs/javascript/jquery/jquery_beginning_part1_files/trends.jpg Christopher: To be honest I haven't used it much at all. Tried one of their widgets a couple years ago. I think the thing I didn't like at the time was the skins, they weren't particularly pretty. On my cell right now, can't see links me: john resig is really impressive Christopher: Yeah, just used one of his functions of his blog a few hours ago to remove a specific element from an array (whish js had that
Re: [Sugar-devel] Print Support (journal vs activity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vamsi Krishna Davuluri wrote: [quoting tomeu] I would like to know how we can expect that Sugar will be deployed with all the filters that the user will need as she installs more activities. Also would like to know if it has been considered to use instead the same approach that regular linux apps use. [/quote] Regular linux apps print through CUPS. To print something through CUPS, you submit a file to CUPS's print queue, for example using the lpr command. This file has to be in one of the formats CUPS supports. That list of formats is different on different machines. To see the list on your machine, look at /etc/mime/mime.convs. This shows the list of supported MIME types, and the command needed to process each one into postscript (which CUPS uses internally). As you can see from that list, all common image formats like jpeg, png, tiff, and bmp are supported. Text formats, like TXT and HTML are supported. Document formats like pdf and postscript are supported. Source code formats like c, sh, csh, and perl, are supported. Mine even has support for microsoft .doc! I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. The only remaining question is: who calls lpr?. In my view, the Activity should not have to call lpr, or otherwise initiate printing. Sugar's philosophy is to make things built in, as much as possible, so that Activity authors don't have to worry about these sorts of things. There's also a potential security problem if Activities can initiate printing without user interaction. Printing directly from the Journal seems like the logical way to handle this. If you are concerned about doing all this conversion on the local machine, then we can move all the filters onto the server, and have the print system transfer the raw file. Vamsi has argued against this idea, however, because he wants users to be able to convert things to PDF locally, without server access. So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) This is not very accurate. IIUC, gtkprint is just a shim connecting Cairo to CUPS. In this case, it's equivalent to drawing stuff in Cairo, and then exporting to PDF. In other words, it's a toolbox for writing PDF conversion filters. That means that the system still contains a great load of filters, only now the Activity authors have to maintain them. That doesn't seem like an improvement to me. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkntyggACgkQUJT6e6HFtqQfhgCdFOQctGzYpZo7/4bHxu66+NT7 W44AnAmcKXA8SD6pvhoumD3URBe2XisJ =x9qR -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Digest 2009-04-21
===Sugar Digest === 1. Five Google Summer of Code projects have been selected for 2009. We are excited about all five proposals; our only regret is that we were unable to accept any more of the promising proposals we received. Thank you to everyone who participated in the selection process—the feedback on the proposals from the community has been especially of great value. To all of those who were not selected this year, we appreciate your efforts and hope that you will be able to find time to participate in the Sugar Labs community in some fashion this summer. We hope you'll reapply next year. To those of you who were selected this year, both mentors and students, let's converge on a regular weekly meeting time in IRC to exchange notes on progress and problems. Individual teams should, of course, make arrangements for regular meeting times as well. In general, let's continue to hang out on #sugar, so that the developer community can stay abreast of what is happening. Kudos to Jamison Quinn for organizing our GSoC efforts and seeing to all of the details. Finally, thanks once again to Google for this opportunity. Student: Lucian Branescu Mihaila Project: Webified Mentor: Walter Bender Student: Sascha Silbe Project: Version support for Sugar datastore and Journal Mentor: Jameson Quinn Student: Felipe Lopez Toledo Project: Karma + Activities Mentor: Bryan Berry Student: Vamsi Krishna Davuluri Project: Adding Print Support to the XOs Mentor: Andres Ambrois Student: Benjamin Schwartz Project: Decentralized Asynchronous Collision-free Editing with Groupthink Mentor: Assim Deodia 2. Caroline Meeks and I spent last Saturday at the Waltham YMCA where we exercised Sugar on a Stick with children and their parents visiting the Y for Healthy Kids Day. (I had to leave early to meet to attend to some sewer problems—don't ask.) All in all, it was a great day. From the technical point of view, Sugar on a Stick lived up to its billing. We were able to get all but one of the mismatched castaway PCs to boot, even some of which would not boot into Windows XP. (The one machine that did not boot would not power on at all—not something we could fix with software.) We did have one machine with an invisible cursor, but otherwise it ran fine. Sound worked on every machine that had speakers. We were able to assign static IP addresses and every machine was able to connect to the Internet. However something was preventing collaboration to work: we could see each other, but not share activities or interact with other users connected to jabber.sugarlabs.org. We have some debugging to do. Ideally, we would have brought a school server in to assign IP addresses, which would have assured that at least local collaboration worked. Caroline will be writing up detailed notes on the children's use of Sugar throughout the day. The way things were organized, parents and children were dropping in to the room at any time during the day. We had in the room anywhere from two to six children, as young as two and as old as seven or eight, while I was there. They went right to the machines without any introduction to Sugar. Most of the machines were either already running an activity or had the Home View visible. Popular activities included Memorize, where some children went so far as to design their own games, Jigsaw Puzzle, Turtle Art, Speak, Write, and Mini Tam Tam. While hardly a typical classroom setting, things went quite well with this somewhat haphazard introduction to Sugar: the children were engaged, as were their parents. However there was not time enough for them to discover or exploit features such as the Journal. And since collaboration was not working, all of the interactions were solo. Undoubtedly there is some more scaffolding we can provide children and parents new to Sugar. (We've already had some follow-up discussions on how to best integrate examples into activities and how to make the views and frame more readily discoverable on non-OLPC-XO hardware.) ===In the community=== 3. Lionel Laske announced that OLPC France will organize with Sugar Labs the first Sugar Camp in Europe in Paris on May 16. Sign up at http://sugarcamp.eventbrite.com/. Several workshop will be organized all around the day: technical, pedagogical and documentation. The full agenda is not closed so do not hesitate to submit a workshop proposal. These events are fully free, thanks to AFUL and GDium. There will also be a Sugar meeting on the 17th (See [[Marketing_Team/Events/MiniCamp_Paris_2009]]) where we will be discussing initial plans for Sucrose 0.86. ===Tech Talk=== 4. Christian Marc Schmidt led a discussion of potential 0.86 improvements to the UI in a Design Team meeting this past weekend. Together, we came up with a list of design goals to possibly include in our development schedule for 0.86, with concrete tasks to be accomplished in advance of SugarCamp. Christian added a meeting summary on the wiki, along with a link to the
Re: [Sugar-devel] [Server-devel] Fwd: testing backup and restore on SoaS
I poked around in git on dev.laptop.org and found this http://dev.laptop.org/git/users/martin/ds-backup.git/tree/client It looks like the code is from last October. Are these the files I am looking for? Thanks! Dave On Mon, Apr 20, 2009 at 10:39 AM, Dave Bauer dave.ba...@gmail.com wrote: On Mon, Apr 20, 2009 at 10:30 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Apr 20, 2009 at 4:13 PM, Dave Bauer dave.ba...@gmail.com wrote: Forwarded from sugar-devel, Are the backup scripts available? We have a script that allows us to register SoaS and we want to try the backup scripts with that. Grab them from the same place where you found the ejabberd pkg ;-) -- you're looking for ds-backup-client. Hmmm, I got the ejabberd from olpcxs-testing repository. I don't see ds-backup-client there. I guess I am looking in the wrong place. Dave Note that you'll need to get in motion to teach SoaS about registering to the School Server, something that Sugar knows how to do, or used to know.. Give the scripts a read so you'll see how they work, and what bits of Sugar we need (somehow, sugar profile needs to know about a backup server, etc). 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 -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 15:28, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vamsi Krishna Davuluri wrote: [quoting tomeu] I would like to know how we can expect that Sugar will be deployed with all the filters that the user will need as she installs more activities. Also would like to know if it has been considered to use instead the same approach that regular linux apps use. [/quote] Regular linux apps print through CUPS. To print something through CUPS, you submit a file to CUPS's print queue, for example using the lpr command. This file has to be in one of the formats CUPS supports. That list of formats is different on different machines. To see the list on your machine, look at /etc/mime/mime.convs. This shows the list of supported MIME types, and the command needed to process each one into postscript (which CUPS uses internally). As you can see from that list, all common image formats like jpeg, png, tiff, and bmp are supported. Text formats, like TXT and HTML are supported. Document formats like pdf and postscript are supported. Source code formats like c, sh, csh, and perl, are supported. Mine even has support for microsoft .doc! I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. That's all fine, if the user sends a file to the printer spool, it gets converted to a printable format, then sent to print. That's how printing in unix works and there's no need to change it. The only remaining question is: who calls lpr?. In my view, the Activity should not have to call lpr, or otherwise initiate printing. Sugar's philosophy is to make things built in, as much as possible, so that Activity authors don't have to worry about these sorts of things. There's also a potential security problem if Activities can initiate printing without user interaction. Printing directly from the Journal seems like the logical way to handle this. The security concern makes sense to me, though I would like to hear from Eben what his thoughts are regarding user experience. What I think is important is that activities are given a chance to produce themselves the printable document, as they are the ones that can better do that. If you are concerned about doing all this conversion on the local machine, then we can move all the filters onto the server, and have the print system transfer the raw file. Vamsi has argued against this idea, however, because he wants users to be able to convert things to PDF locally, without server access. Well, I think we want both and we already have the needed infrastructure to do that. People deploying Sugar will chose which printing infrastructure can be installed in each machine and the server and Sugar will do whatever it can so stuff gets printed. I don't see a real need to choose one approach and not the other. So anyway gtkprint makes use of a structure which is rendered to cairo objects and thus prints the screen as a pdf or prints to a printer ( a wrapper around cups) but the advantage is we dont utilisie that many filters again ( the implementation can be found in pyabiword ) This is not very accurate. IIUC, gtkprint is just a shim connecting Cairo to CUPS. In this case, it's equivalent to drawing stuff in Cairo, and then exporting to PDF. In other words, it's a toolbox for writing PDF conversion filters. That means that the system still contains a great load of filters, only now the Activity authors have to maintain them. That doesn't seem like an improvement to me. Well, that's not very accurate ;) Gtkprint makes it a bit easier to reuse the cairo code you use to draw to screen to also print to paper. And we can expect that motivated activity authors will produce a better output that a generic filter converting some standard doc format. Again, what is very important to me is that activities are given a chance to produce the printable format, because they are probably the best that know how to print their stuff and because of code distribution: we cannot anticipate all the activities that will be installed on a system, we cannot anticipate which filters will be installed by the deployer/distributor and we already have a code distribution mechanism (bundles). To summarize, this is my proposal: - (py)gtk activities use gtkprint to produce a printable format, using an API that makes easy to use the same cairo drawing for the screen and paper. This doesn't mean that you print what you see on the screen, just that you are given the chance to reuse part of the cairo drawing you already
Re: [Sugar-devel] Print Support (journal vs activity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: - (py)gtk activities use gtkprint. This means that they have an abstraction for printing to cups, lpr and to a file (ps or pdf). ... - implement a moodle module where users can upload whatever file they have in the journal. Depending on the printing filters installed on the server, there are more or less chances it can be converted to a printable format. How do these things go together? If all printing occurs by uploading files to Moodle, then why is it useful for Activities to talk to CUPS? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt8ZMACgkQUJT6e6HFtqSolgCfblZVjfoUl4l0N7kk6zTyUxEG xlkAoKLTBSC3BpeUXTQIxDCa7gFMy9z5 =vtYA -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 18:17, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: - (py)gtk activities use gtkprint. This means that they have an abstraction for printing to cups, lpr and to a file (ps or pdf). ... - implement a moodle module where users can upload whatever file they have in the journal. Depending on the printing filters installed on the server, there are more or less chances it can be converted to a printable format. How do these things go together? If all printing occurs by uploading files to Moodle, then why is it useful for Activities to talk to CUPS? Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
It seems we can attack this in simple steps (sorry for the rehash of what has already be said): (1) a mechanism for printing Journal objects (anything of mime-type .pdf, txt, jpg, png, etc.) (2) an example of optional mechanisms for activities to drop additional printable objects into the Journal (3) exploration of printing directly from Sugar. -walter On Tue, Apr 21, 2009 at 12:29 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
It's entirely unclear what this project has morphed to. Tomeu, what use is uploading arbitrary journal entries to Moodle? I thought creating pdf output in sugar and enabling uploading of the pdf to Moodle was the point of this project. That is useful in two ways. First, it is a path to assignment turn-in or printing either through Moodle or by other transports to a system configured to print pdfs. It also allows a student to review the printer-ready output to decide if it is worth getting hard copy. On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. I would actually be happy if we just implemented sending journal entries to the print queue and the moodle module. Print to pdf has several important use cases and I would like to see it implemented for 0.86 for at least Write and Browse, but I don't think it needs to be part of this GSoC. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) Yeah, I would prefer if we use simple file upload at first because it works already. There's lots of fun stuff to do in this area, but what gives most value to the user is quite straightforward. We should aim to leave the complicated stuff for the end, as extras, and focus on delivering what matters most first Regards, Tomeu - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche c...@msbit.com wrote: It's entirely unclear what this project has morphed to. Tomeu, what use is uploading arbitrary journal entries to Moodle? Because the chances that the needed filter to convert that file to a printable format is in the server are bigger than being in every machine, for some deployments. I thought creating pdf output in sugar and enabling uploading of the pdf to Moodle was the point of this project. That is useful in two ways. First, it is a path to assignment turn-in or printing either through Moodle or by other transports to a system configured to print pdfs. It also allows a student to review the printer-ready output to decide if it is worth getting hard copy. Sure, I though I had made clear than printing to PDF in Sugar has important use cases. Regards, Tomeu On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. I would actually be happy if we just implemented sending journal entries to the print queue and the moodle module. Print to pdf has several important use cases and I would like to see it implemented for 0.86 for at least Write and Browse, but I don't think it needs to be part of this GSoC. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) Yeah, I would prefer if we use simple file upload at first because it works already. There's lots of fun stuff to do in this area, but what gives most value to the user is quite straightforward. We should aim to leave the complicated stuff for the end, as extras, and focus on delivering what matters most first Regards, Tomeu - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 05:56:59PM +0200, Tomeu Vizoso wrote: I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. That's all fine, if the user sends a file to the printer spool, it gets converted to a printable format, then sent to print. That's how printing in unix works and there's no need to change it. What I don't like about this option is that the _print_ _server_ decides how the printed out document actually looks like. Font family, font size, word wrapping, even what gets put on which page (due to page length and font size) and especially advanced formatting like syntax highlighting is all undefined. You will get different results depending on whether you use the XS at school, the printer with direct network interface (e.g. HP JetDirect) at home or a printer connected to a Windows machine (IIRC current Windows versions have IPP server support) at your friends. PDF and Postscript are bad enough: I've been responsible for administering the computer pools including the printers at our department for several years and saw how documents printed fine on one printer and came out rubbish on another. And that wasn't without explicit intention - PostScript is a full programming language and you can show entirely different things on screen and on the printed page (a good friend of mine - Caspar - once had a document which showed additional text on the printout about not being allowed to be printed). I was told by the head administrator of the archive of our university hospital that large digital archives have agreed to use some ISO standard that's a subset of PDF, called something like PDF/A. What I think is important is that activities are given a chance to produce themselves the printable document, as they are the ones that can better do that. +1. It just needs to go through Journal, like downloads from Browse do. 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] Print Support (journal vs activity)
On Tue, Apr 21, 2009 at 19:20, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Tue, Apr 21, 2009 at 05:56:59PM +0200, Tomeu Vizoso wrote: I think we should solve our printing problem by extending this list to a few more common formats. Add in python source and the Open Document Format, and we're pretty much done. There are very few Activities that generate documents that could be printed, but are not in one of these formats. Those Activities will have to gain the ability to export to one of the supported formats, just as they would on any standard linux desktop. That's all fine, if the user sends a file to the printer spool, it gets converted to a printable format, then sent to print. That's how printing in unix works and there's no need to change it. What I don't like about this option is that the _print_ _server_ decides how the printed out document actually looks like. That's fine, if the user wishes to control that, then does the conversion to PDF locally and sends the PDF. Regards, Tomeu Font family, font size, word wrapping, even what gets put on which page (due to page length and font size) and especially advanced formatting like syntax highlighting is all undefined. You will get different results depending on whether you use the XS at school, the printer with direct network interface (e.g. HP JetDirect) at home or a printer connected to a Windows machine (IIRC current Windows versions have IPP server support) at your friends. PDF and Postscript are bad enough: I've been responsible for administering the computer pools including the printers at our department for several years and saw how documents printed fine on one printer and came out rubbish on another. And that wasn't without explicit intention - PostScript is a full programming language and you can show entirely different things on screen and on the printed page (a good friend of mine - Caspar - once had a document which showed additional text on the printout about not being allowed to be printed). I was told by the head administrator of the archive of our university hospital that large digital archives have agreed to use some ISO standard that's a subset of PDF, called something like PDF/A. What I think is important is that activities are given a chance to produce themselves the printable document, as they are the ones that can better do that. +1. It just needs to go through Journal, like downloads from Browse do. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ7gBLAAoJELpz82VMF3DaHjEH/1gYJB2sPRTJXcn9UizxkLCb ZqCTPG8z2a2tTZKf7Qp+UgVHbcEB3Rqp1/hw7fSebLYwA/+NeZPmaM3RNWkVkUIu xxDU//FBUkXl8NzAVcGdkTa1jiqOx2uvpxyWWqaANyPJFyKDXuyHQtQN+iMRSHN5 FB2et+pmUsVDMgAGixD8oM3EsUTZWTjYBt6q35ArGG0lXx/lVD6ka6vYiHxAfy0o jk7mt365yDMCJO9masrt1QCjNZm81HD6BIOkevXqkyE0Vck7m/iDXrGrInRiygsv kG6jBKB7evamQLKRCw5TzhaEGK0ansQlH0l7gEihOHX4tMy7IDsDaGO41wQ81rY= =FgFk -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on. Here's my refined proposal based on that conversation. Print preview option in journal Uses cups filters to convert to PDF Set of cups filters available is distribution dependent. An officially print enabled distribution would have a certain limited set of filters installed (the obvious ones). Filters outside this set would be mildly discouraged to avoid inconsistent behaviour. filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments if you had anything but the exact, limited set of print-enabled filters, printing behaviour would be officially undesigned and unsupported but nevertheless probably sane enforcement would be social, not digital the PDF thus created would have special print-me tag To add to print queue, or any other queue management, you'd use Browse there are several options for streamlining the workflow. the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for print-me tag this means making sugar understand this kind of metadata - independently useful you could make a print activity, a spin of browse, which handles PDFs it would open the PDF using a pdf-viewer plugin it would have an enqueue menu item choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick) You could modify sugar to know when to use Print instead of Read by default, based on print-me tag using something in activity.info this functionality would be independently useful Activities which wanted printing but did not naturally produce a format within our basic filter list, could have a print preview menu item and use gtkprint to export to pdfs with a print-me tag gtkprint would be a dependency of sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
Ooops, I forgot. In my proposal, local printing would be done by a separate activity which handled only PDFs. Many deployments would never install this separate activity. On Tue, Apr 21, 2009 at 11:58 AM, Jameson Quinn jameson.qu...@gmail.comwrote: OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on. Here's my refined proposal based on that conversation. Print preview option in journal Uses cups filters to convert to PDF Set of cups filters available is distribution dependent. An officially print enabled distribution would have a certain limited set of filters installed (the obvious ones). Filters outside this set would be mildly discouraged to avoid inconsistent behaviour. filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments if you had anything but the exact, limited set of print-enabled filters, printing behaviour would be officially undesigned and unsupported but nevertheless probably sane enforcement would be social, not digital the PDF thus created would have special print-me tag To add to print queue, or any other queue management, you'd use Browse there are several options for streamlining the workflow. the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for print-me tag this means making sugar understand this kind of metadata - independently useful you could make a print activity, a spin of browse, which handles PDFs it would open the PDF using a pdf-viewer plugin it would have an enqueue menu item choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick) You could modify sugar to know when to use Print instead of Read by default, based on print-me tag using something in activity.info this functionality would be independently useful Activities which wanted printing but did not naturally produce a format within our basic filter list, could have a print preview menu item and use gtkprint to export to pdfs with a print-me tag gtkprint would be a dependency of sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
Vamsi, for your reference, here is the discussion on IRC in which nobody agreed on anything, but we all wanted to take over design of your project. We're just being enthusiastic, and there's some significant degree of bike-shedding http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Trivialityhere. In the end, you are the engineer, and aa is the manager; anything you design that's OK with him is fine. Your job right now is to listen to and participate in the discussion, but set a strict time limit (a few days, I'd say). When the time is up, you write up your design, get aa's OK, and then ignore us from then on :). (the IRC discussion below is tangled and confusing. At the end we agree to do it on this mailing list, so if you want to skip reading below, that's fine. I'm just posting it in case you want to see the sausage being made.) [11:08] tomeu homunq: have some problems following your last email about printing [11:09] tomeu what means default action from journal for print-me pdfs? [11:09] -- satellitFbe-74c6 has joined this channel (n= u...@208-100-132-172.bendbroadband.com). [11:12] homunq tomeu: there would be some metadata besides mime-type, something like sub-type [11:12] homunq all pdfs created for printing would have a specific sup-type. This would make them print-me pdfs. [11:12] tomeu ok, what would that metadata be? which component would use that new property? [11:13] homunq sugar, when choosing which activity to use as a default, when several activities handle a given mime-type, would give preference to activities which have the same sub-type metadata. [11:14] homunq does that make sense? [11:14] tomeu why do activities other than Read need to open those pdfs? [11:14] homunq so both print and read would handle pdfs. [11:15] homunq print would be, within GSoC scope, an activity with no UI - just enqueue and terminate. [11:15] -- eben has left this server (Read error: 110 (Connection timed out)). [11:15] homunq eben, we hardly knew ye. [11:16] homunq is that clear? And should I make the same clarifications on ML? [11:16] tomeu homunq: why do we need an activity with no UI? [11:17] tomeu homunq: enqueue should be pretty easy to do in the journal by using gtkprint [11:17] homunq um, because that's the work flow? [11:17] tomeu just like we don't have an activity for copying files from a usb stick to the journal [11:17] tomeu homunq: which workflow? [11:17] homunq I mean, there would be several versions/updates of the activity possible. [11:18] tomeu by sending a file to the print queue is quite trivial in pygtk [11:18] homunq the no-UI version is just alpha, for GSoC. [11:18] tomeu s/by/but [11:18] homunq what print queue? [11:18] tomeu and about the preview UI, why not just use Read? [11:18] homunq the moodle queue on the XS? [11:18] tomeu homunq: cups, lpr, whatever [11:18] tomeu the moodle queue, I think it's enough with file uploading in browse for now [11:19] tomeu that gives us authentication and is already done [11:19] homunq OK, so print activity is a spin of browse. [11:19] tomeu printing from the journal means for me to just submit a file to the local printing queue [11:19] homunq the local printing queue is meaningless. [11:20] tomeu homunq: well, it's the same thing you have in windows when you send documents to print [11:20] tomeu in most cases won't make sense, but it's stuff that it's already done [11:20] homunq yes but the moodle queue is the whole point of this GSoC [11:20] tomeu and will be important for a teacher printing from sugar to an attached printer, for example [11:21] tomeu homunq: ok, I don't think it's needed to implement local printing in this gsoc [11:21] -- J5 has joined this channel (n= quint...@c-24-91-155-241.hsd1.ma.comcast.net). [11:21] homunq but we don't want to give every kid UI that only the teacher will use. Much confusion results. [11:21] tomeu so for uploading the file to moodle, can we just let the user use browse like would do for any other moodle-related stuff? [11:21] tomeu homunq: sugar will be used out from classrooms [11:22] tomeu homunq: want it or not, we are being asked to be able to directly print from sugar, and it's quite cheap to implement [11:22] tomeu homunq: but I would prefer if the gsoc project focused on moodle [11:22] tomeu don't worry about this now [11:22] homunq OK. So the workflow is: print to pdf. Resulting pdf has some print-me tag. Browse to upload - can search for print-me tag for easier upload. [11:23] homunq print to pdf is from inside journal, to journal. [11:24] tomeu not sure I understand the importance of that print-me tag [11:25] *** nubae1 is now known as Nubae. [11:25] homunq future enhancement is to do a spin of browse that handles PDF, and has a print-me menu item which will pre-fill the upload form with the given pdf. [11:25] tomeu but on the other hand, I think it may be good to start tagging entries automatically as we do stuff with entries, if it doesn't become cumbersome for the user [11:25] aa me neither...
Re: [Sugar-devel] Print Support (journal vs activity)
On Tuesday 21 April 2009 14:16:36 Tomeu Vizoso wrote: On Tue, Apr 21, 2009 at 19:02, Carol Farlow Lerche c...@msbit.com wrote: It's entirely unclear what this project has morphed to. Tomeu, what use is uploading arbitrary journal entries to Moodle? Because the chances that the needed filter to convert that file to a printable format is in the server are bigger than being in every machine, for some deployments. I thought creating pdf output in sugar and enabling uploading of the pdf to Moodle was the point of this project. That is useful in two ways. First, it is a path to assignment turn-in or printing either through Moodle or by other transports to a system configured to print pdfs. It also allows a student to review the printer-ready output to decide if it is worth getting hard copy. Sure, I though I had made clear than printing to PDF in Sugar has important use cases. Regards, Tomeu My idea for dealing with the headache of filters is assuming only pdf/ps is printable, and having the Journal display a Print button if and only if the mimetype is pdf or ps. This way we can then make the decision of sending it to moodle via xml-rpc, a local cups queue, or a remote cups server using lpr. Activities that can't output to pdf/ps will be provided with gtkprint facilities and a pdf journal entry will be generated after they draw their output. Vamsi has already hacked pdf output into Write, so that's one big activity we will have covered. For the security issues, activities will only generate a journal pdf entry, which would be displayed using show_object_in_journal or somesuch (just like Chat currently handles opnening URLs). The user will then have the ability to immediately review the printable output and/or send it to the preferred queue. This architecture follows some basic principles: 1) Paper/Ink is expensive, we need a way to easily and reliably review what's going to be printed. Requiring people to load up Browse, navigate inside Moodle, and download a PDF file for review, is not exactly user-friendly. 2) We don't need to specify a set of required filters...yet, we can easily expand this to well, HTML, JPG and PNG are probably going to be supported by every CUPS out there, so admit those as well, but I think 1) is priority here. 3) Following up on 2), the journal mechanism is orthogonal to what we end up sending to Moodle. Ben and Tomeu have sort of agreed on sending the raw journal entries to Moodle, so we can use all the CUPS filters on the server, this conflicts with 1) in my view, but it has its advantages. On Tue, Apr 21, 2009 at 9:36 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Apr 21, 2009 at 18:29, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: Printing is not limited to uploading files to moodle, we provide both local and server printing and users will use whatever works in their environment. I think this is too much for one Summer of Code project. That's why I have been recommending that we forget about local printing for now. I would actually be happy if we just implemented sending journal entries to the print queue and the moodle module. Print to pdf has several important use cases and I would like to see it implemented for 0.86 for at least Write and Browse, but I don't think it needs to be part of this GSoC. Anyway, on a purely technical level I think we have reached agreement. (I do wonder whether the Moodle print queue should also support acting as a standard print server, so that standard desktops can print into the Moodle approval queue, but that's a detail.) Yeah, I would prefer if we use simple file upload at first because it works already. There's lots of fun stuff to do in this area, but what gives most value to the user is quite straightforward. We should aim to leave the complicated stuff for the end, as extras, and focus on delivering what matters most first Regards, Tomeu - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknt9FQACgkQUJT6e6HFtqTjmwCfdM831aiEMbpRiJNQLX8Bf2FY OH8AniCGOPuqgY/GlR+V2io6+/NyiTnl =KI8s -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Andrés signature.asc Description: This is a digitally signed message part. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
[Sugar-devel] Tech note on versioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks to Sascha Silbe, versioning is actually going to happen! Woot! One of the things that's often talked about with versioning is differential compression. The purpose of this e-mail is to note a particular technology for differential compression: VCDIFF. VCDIFF is an IETF standard for differential compression.[1] Its most famous implementation is Xdelta, which is GPL.[2] Google has also released a VCDIFF implementation, under Apache 2.0.[3] Most diff algorithms that we're familiar with as developers work on a line-by-line basis. They are designed for source code, and their output is human readable. Their purpose is principally to facilitate collaborative development. Revision control systems like git typically use these algorithms to maintain version history. VCDIFF is different. Its purpose is to store deltas as compactly as possible, and to work on arbitrary binary data. Its output is not human-readable. It should also work well on plain text. I am particularly impressed with VCDIFF because of the following capability in Xdelta: The new merge command allows you to combine a sequence of deltas, to produce a single output that represents the net effect of the sequence. The command is reasonably efficient because it computes the result directly, without constructing any intermediate copies (and without access to the first-of-chain source). If versions are stored as deltas against the current head (reverse deltas), then removing a version is as simple as merging two deltas, and should be quite fast. I do not think that differential version storage is coming soon, but I think when it does, we should give great consideration to Xdelta and VCDIFF. - --Ben [1] http://www.ietf.org/rfc/rfc3284.txt [2] http://xdelta.org/ [3] http://code.google.com/p/open-vcdiff/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknuFZ0ACgkQUJT6e6HFtqRtJwCgg3eP3//x0wsI5dDa4hbFV381 45cAn1/1g/iHvevU0gTV2xIwTUSNC7Ai =JhKZ -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] Fwd: testing backup and restore on SoaS
On Tue, Apr 21, 2009 at 3:51 PM, Dave Bauer dave.ba...@gmail.com wrote: I poked around in git on dev.laptop.org and found this http://dev.laptop.org/git/users/martin/ds-backup.git/tree/client It looks like the code is from last October. Are these the files I am looking for? Looks about right, but get the rpm! A quick google leads to http://xs-dev.laptop.org/~cscott/repos/joyride/ which has a current one. 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] Notes on service discovery XS/XO
martin wrote: On Tue, Apr 21, 2009 at 2:05 AM, da...@lang.hm wrote: also note that this will require that you run some sort of DNS cache on the The standard dns resolver libs on linux (part of glibc?) caches alright. All platforms I know cache things alright, and it's fairly serious bug if your OS doesn't. really? while that was the original design intent of the resolver library, i didn't think it was ever implemented that way in practice (on unix, at any rate) -- user programs tend to only look up a name once, so caching in the resolver library wouldn't do much good. i believe caching is usually only done by servers. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Tue, 21 Apr 2009, Martin Langhoff wrote: On Tue, Apr 21, 2009 at 2:05 AM, da...@lang.hm wrote: my initial reaction to this is that it's going to look to the client exactly the same as a bad guy trying to poison DNS by sending unasked for responses, how do the clients tell the difference? They can't. That's how DNS works. Lots of ink have flowed on that very topic. I'm not interested in bikeshedding, I'm interesting in using DNS smartly, and in getting help to get it done. if the client can't tell the difference between what you are doing and what the bad guys are doing, the client has no choice but to ignore any unexpected responses, as they may be bogus. I believe this is exactly what has been done over the last few years in the DNS server/DNS cache software. they used to accept extra responses like you are trying to make, but nowdays they don't. implementing something that is on it's way out (due to it becoming a security problem) is not a smart thing to do. also note that this will require that you run some sort of DNS cache on the The standard dns resolver libs on linux (part of glibc?) caches alright. All platforms I know cache things alright, and it's fairly serious bug if your OS doesn't. actually they don't. you can run a DNS cache on your machine (and many distros do by default), but it's not part of the default resolver. take a look at packetfence. it does exactly that job today, for free, on linux (among other platforms) Doesn't look like a fit for the XS, did you look at it? I'm reasonably familiar with packetfence, I don't know the full requirements that you have for the XS, but your short description sounded like the job that it does (summarized as a hotel-like access control) Weird. I do have some things to build, but everyone ignores them and keeps bikeshedding. Code talks, peoples. you are free to ignore comments, and existing tools, but if that's what you want, why post here, just write the tools and then we'll identify that you have recreated the wheel. David Lang ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] discussion of which javascript framework to use for Karma
On Tue, 2009-04-21 at 13:47 +0100, Lucian Branescu wrote: jQuery makes the DOM suck less, that's it's main plus. I think the jQuery UI is complete enough for most tasks and doesn't have architectural constraints that keep it from getting better. It's also quite small. However, I don't think it should matter too much which framework is blessed. Web devs have their preferences (granted, most like jQuery). If jQuery in compatibility mode is used for the framework itself, web devs can use whichever framework they like. They get more consistency if they use jQuery, but it shouldn't be a problem if they don't. JQuery definitely makes it easier to manipulate the DOM but it also has a very nice plug-in architecture. I still have an extremely limited knowledge of js, js frameworks, etc. but it seems like a good route to go would be to extend dojo or jQuery existing animation facilities rather than creating a standalone animation library -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
