Re: [Sugar-devel] Is it possible to disable "sharing" for an Activity?
On Tue, Feb 3, 2009 at 01:21, Wade Brainerd wrote: > There might be something in the Sugar Almanac, > see http://sugarlabs.org/go/ActivityTeam/Resources for a link. > Alternately, an example of how to disable sharing is here: > http://git.sugarlabs.org/projects/math/repos/mainline/blobs/master/mathactivity.py#line75 > Note to Sugar toolkit guys, I'd love to have a formal API to indicate > "collaboration not supported". Another method of removing the sharing control: http://git.sugarlabs.org/projects/terminal/repos/mainline/blobs/master/terminal.py#line61 Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] readetexts and viewslides moved to git.sugarlabs.org
On 19 Jan 2009, at 17:28, Morgan Collett wrote: > On Mon, Jan 19, 2009 at 17:52, Gary C Martin > wrote: >> On 19 Jan 2009, at 15:19, James Simmons wrote: >> >>> Over the weekend I updated Read Etexts and View Slides to be more >>> like >>> the current Read activity. Previously they only attempted to save >>> metadata on closing instead of writing a new file. I was getting >>> "keep" >>> errors because of that, so now I link a temporary file like Read >>> does. >>> I also fixed them so that you can launch them from an icon and be >>> prompted to open an existing Journal entry. This makes the >>> activities > > Great! > >>> much more useable, in my opinion, but I am disappointed that I >>> cannot >>> filter the Journal entries by MIME type. >> >> I'm sure I spotted some recent trac chatter covering a new MIME >> filtering ability for the Object Chooser, can't find it again off >> hand >> just now. > > http://dev.laptop.org/ticket/3060 -- ooh, it's been fixed. I must > update Read to filter appropriately... > >>> The code for both has been copied to git.sugarlabs.org, and I >>> think I >>> did everything OK except I forgot to put the project entry for Read >>> Etexts in the category "activities" and I don't see a way to fix >>> that. >> >> If you go to your 'Dashboard' you'll see your projects listed on the >> right, from there you land in the 'Project Overview' tab, click >> 'Project Settings' and you get to edit all the original fields as per >> when you created the project. >> >>> Currently the code is up to date in both old and new repositories. >>> Should I continue to do that, or should I abandon the old >>> repository? >> >> Same here for me with Moon, I consider dev.laptop.org (for Moon and >> other moved reps) deprecated though I have no idea how to change the >> rep description to show "DEPRECATED - see git.sugarlabs.org" like >> others have done (read and chat). Any hints? > > Someone with shell access to dev.laptop.org, and with write access to > your git repo, can edit the file - e.g. > /git/chat-activity/description. Thanks for the pointer Morgan, back then HH had kindly just given me shell access to my dev account, so I've been able to ssh into crank and update the description myself. --Gary > Regards > Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
Marco Pesenti Gritti wrote: > On Sat, Jan 31, 2009 at 2:15 PM, Tomeu Vizoso wrote: >>> Why do you think size is very important for Soas (real question)? >> If we want wide testing and people need to download 800MB each time, >> many people (me included) will have a hard time getting those bits. > > But you don't actually need to download images each time. yum update > works fine... > > Marco I tried it by hand yesterday and added our sugar repo to the yum config does work fine. The question is how we create that file now. We could do it in the kickstart file - but maybe there are other options? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] Deployment Support Mtg -- Today, 2000 UTC, #olpc-deployment
Una traduccion libre... --- Hola amigos Solo para recordarles que tendremos reunión hoy a las 2000 UTC 8 (3:00PM Boston, Lima, Bogota; 6:00PM Montevideo) en el canal IRC #olpc-deployment en irc.freenode.net para charlar sobre temas relacionados con el soporte de las implementaciones. Un detallado resumen de esta reunion aparecerá en http://wiki.laptop.org/go/Deployment_meetings/20090203 los resumenes de las reuniones anteriores se pueden encontrar en http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes Si quiere tener una agenda, por favor escriba una como es indicado al final de "meeting notes", el mismo vinvulo de arriba Gracias, Michael --- Una propuesta para los organizadores de la reunión. Si quieren más participación de personas de esta lista (olpc-sur) es recomendable que pongan a funcionar el bot de traducción (transbot0) en el canal, la unica vez que lo vi estaba funcionando entre #olpc y #olpc-ayuda, es posible que cjb, o aa, recuerden como usarlo. A proposal for the organizers of the reunion. If you want more involvement of people from this list (olpc-sur) is recommended that you make that the bot of translation (transbot0) in the channel work, the only time I saw it working, it was running between #olpc and # olpc olpc-help, it is possible that cjb or aa remember how to use it up. -- María del Pilar Sáenz On Tue, Feb 3, 2009 at 9:18 AM, Michael Stone wrote: > Hey folks, > > This is just to remind you that we'll be meeting at 2000 UTC today (3:00 PM > Boston) in > > #olpc-deployment > > on irc.freenode.net to chat about deployment support topics. > > Detailed minutes from this meeting will appear at > > http://wiki.laptop.org/go/Deployment_meetings/20090203 > > alongside the minutes from previous meetings, which can be found at > > http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes > > If you'd like to have an agenda, then please write one as indicated on the > "meeting notes" link above. > > Thanks, > > Michael > ___ > Lista olpc-Sur > olpc-...@lists.laptop.org > http://lists.laptop.org/listinfo/olpc-sur > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Digest 2009-02-03
=== Sugar Digest === Baselines, Part 1: A few months ago, Tomeu Vizoso set a baseline for the Sugar "view source" functionality that had largely gone unrealized in most Activities. In the upcoming (March) release of Sugar, the default behavior of all Activities will be to have their source code opened inside of Pippy, the Python editor written by Chris Ball and maintained by C. Scott Ananian. (This is already the default behavior of Chat—try it, you'll like it.) While this is a baseline, it is clear that for many Activities, it is not sufficient. In some Activities, such as Browse, view source is geared towards the content being browsed, rather than the Browser itself. In a manner similar to the Mosaic web browser—and most browsers built since—view-source shows the HTML content from which the page is created. Browse puts a copy of the HTML content into the Journal from where it can be viewed and modified by the Write Activity. It has often been argues by me (and many others) that view source is what made the web transparent and enabled any consumer of web content to become a producer. Indeed, this was the threshold through which a generation has passed—remix is a part of our culture, not just something for Trekkies and other fringe groups as observed by Henry Jenkins in the mid 1980s. I have been thinking about view source within the content of Turtle Art lately. I had gotten immersed in Turtle Art when some teachers on the Sur list began asking for some extensions. At the time I tried to get them to make the extensions themselves, but the floor was too high. I jumped in in order to document the process of modifying an Activity and also to try to understand first hand where the difficulties laid. My early attempts are described in the wiki ([[Patching_Turtle_Art|Patching Turtle Art]]). Between Bill Kerr's subsequent questions ([[Talk:Patching_Turtle_Art|Talk:Patching Turtle Art]]) and my own experiences, I was awakened to the fact that we have a long ways to go in terms of making view source meaningful to the teacher, the student, and the potential Sugar contributor. View source was central to the discussion I had with Bill Kerr and Tony Forster last week in Melbourne. We agreed that it worthwhile exploring the impact of the addition of some more steps between using an Activity and viewing the project's Python code; indeed, it would be necessary if any but the most dedicated would venture forth. Tony has braved the GNU/Linux shell to try to modify Turtle Art; he has been documenting his efforts ([http://tonyforster.blogspot.com/ Tony Forster blog]) Previously I had added an export function to Turtle Art so that the psuedo Logo generated in the graphical interface could be viewed inside a text-based, fully featured Logo environment—a one-way path towards more sophisticated programming concepts. As a result of the Melbourne discussion, I decided to take a slightly different approach. I have added two new blocks to Turtle Art (actually, at the moment, just to Turtle Art Portfolio, a fork of Turtle Art). One block lets you try Python code directly into it. It can be used for simple, in-line extensions, such as added new functions from the math library. It uses a simple set of assumptions: there is one input (int or float) and one output (float), e.g., typing sin(x) into the block turns the block into the sine function. It is similar to the programmable extensions found in may environments, such as [http://rupert.id.au/schoolgamemaker/morethan.htm Gamemaker]. While I expect that this will satisfy the needs of many of those who are looking for simple extensions to the Turtle Art environment, I don't think it addresses the question of how to provide a stepping stone towards modifying Turtle Art itself—in fact, it may discourage many from every bothering to view the source code because they can make changes without having to "look under the hood." I have higher hopes for the second block I introduced. Internally it calls a Python procedure, myblock, that is currently a "nop"—it simply returns without executing any code. The idea is that myblock, which is loaded as a separate module, will be modified by the end user. When Turtle Art Portfolio is launched for the first time, it makes a copy of myblock in the Journal. It can be opened in Pippy, where it can be modified and saved back to the Journal. From within Turtle Art, you can reload the myblock module by selecting a new module from the Journal. I've put some commented-out examples of what you can do with myblock into the Python code: a dotted line; some string manipulations; and the extension of the Turtle Art color space to include chroma (gray) in addition to hue and value. In using myblock, my typical work cycle is to switch between Turtle Art Portfolio, Pippy, and Log Viewer (so that I can see the error messages from the Python interpreter—I make a lot of mistakes as I code). The major limitation I face in the current implementation is that within
[Sugar-devel] Deployment Support Mtg -- Today, 2000 UTC, #olpc-deployment
Hey folks, This is just to remind you that we'll be meeting at 2000 UTC today (3:00 PM Boston) in #olpc-deployment on irc.freenode.net to chat about deployment support topics. Detailed minutes from this meeting will appear at http://wiki.laptop.org/go/Deployment_meetings/20090203 alongside the minutes from previous meetings, which can be found at http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes If you'd like to have an agenda, then please write one as indicated on the "meeting notes" link above. Thanks, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Mon, Feb 2, 2009 at 11:19 PM, Martin Langhoff wrote: > On Tue, Feb 3, 2009 at 5:10 PM, C. Scott Ananian wrote: >> You failed to convince me. How (...)? > > All I can suggest is that you go back on this thread and read my email. > > Here's a clarification (I know my writing isn't always clear): the url > in the metadata is not expected to remain static over time. How is that a problem? The activity group page lists explicit URLs. Ensure that those URLs are in the cache. If other URLs give 404 or 30x, no problem. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: > On Wed, Feb 4, 2009 at 7:21 AM, C. Scott Ananian wrote: >> On Mon, Feb 2, 2009 at 11:19 PM, Martin Langhoff >>> All I can suggest is that you go back on this thread and read my email. >>> >>> Here's a clarification (I know my writing isn't always clear): the url >>> in the metadata is not expected to remain static over time. >> How is that a problem? > > All I can suggest is that you go back on this thread and read my email > stating the use case. I am finally understanding Martin's dilemma. Every version of every Activity can potentially specify a different update URL. Therefore, the number of entries required in a proxy cache on a disconnected XS scales not as the number of bundles _to which_ one may upgrade, but rather the number of bundles _from which_ one may upgrade. Moreover, the proxy server (though not the XOs), must be aware of all those versions. Whether this is a problem is a bit of a judgment call. In the worst case, it requires the server to keep an ever-growing database, in case someone attempts to upgrade from an ancient version. This creates significant management overhead, never mind disk overhead. However, if the proxy server doesn't have an internet connection, then the XOs also likely do not have an internet connection, so the XOs are unlikely to wind up with Activity versions other than the ones on the server or the ones they were shipped with. Frankly, I don't think there will be any satisfactory solution until we implement our designs for a cryptographic bundle system, but that still seems very far away. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmImRkACgkQUJT6e6HFtqRx9wCdHXF6HoHhbzp/eEaK3SxnKfRc 2aMAn2u7m03glSUXiFZi8oEQe1VJ6uef =bS3g -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Wed, Feb 4, 2009 at 8:20 AM, Benjamin M. Schwartz wrote: > I am finally understanding Martin's dilemma. > > Every version of every Activity can potentially specify a different update Bingo. Teh interwebs has these things called redirects, and they're used all the bloody time, because stuff moves around like crazy. In a perfect world they would just _not exist_. > Whether this is a problem is a bit of a judgment call. No need to call no judge. The first use case is right here with us now -- lots of activities are moving from wiki.l.o to somewhere in sugarlabs.org. Perhaps a couple decide to move to SourceForge instead. SF may go outof fashion, and they'll move elsewhere. Resources on the internet come and go. > Frankly, I don't think there will be any satisfactory solution until we This is _trivial_ to fix -- all we need is a service announcement scheme, and use it. Scott's pointing to DNS-SD, and after reading the specs and design rationale, I like it. But I don't know if there's an easy way to use it _without_ mdns getting in the way. 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] Is it possible to disable "sharing" for an Activity?
Morgan, This is *exactly* what I was looking for, thanks. As a bonus I can get rid of the "keep" button as well, which is of no use to me. James Simmons Morgan Collett wrote: On Tue, Feb 3, 2009 at 01:21, Wade Brainerd wrote: There might be something in the Sugar Almanac, see http://sugarlabs.org/go/ActivityTeam/Resources for a link. Alternately, an example of how to disable sharing is here: http://git.sugarlabs.org/projects/math/repos/mainline/blobs/master/mathactivity.py#line75 Note to Sugar toolkit guys, I'd love to have a formal API to indicate "collaboration not supported". Another method of removing the sharing control: http://git.sugarlabs.org/projects/terminal/repos/mainline/blobs/master/terminal.py#line61 Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sur] Deployment Support Mtg -- Today, 2000 UTC, #olpc-deployment
Hola Gracias a Andres Ambrois (aa), el. bot de traducción ingles-español entre #olpc-deployment y #olpc-es estara funcionando para la reunion de implementación. Todo texto en ingles que se escriba en olpc-deployment aparecera en español en olpc-es y viceversa. No es la mejor traducción, pero ayuda. Thanks to Andres Ambroise (aa), translation bot between #olpc-deployment and #olpc-es is running for the imployment meeting. Any text written in English on #olpc-deployment appear in Spanish on #olpc-es and vice versa. It is not the best translation, it helps. --- Maria del Pilar Saenz On Tue, Feb 3, 2009 at 9:18 AM, Michael Stone wrote: > Hey folks, > > This is just to remind you that we'll be meeting at 2000 UTC today (3:00 PM > Boston) in > > #olpc-deployment > > on irc.freenode.net to chat about deployment support topics. > > Detailed minutes from this meeting will appear at > > http://wiki.laptop.org/go/Deployment_meetings/20090203 > > alongside the minutes from previous meetings, which can be found at > > http://wiki.laptop.org/go/Deployment_meetings#Meeting_notes > > If you'd like to have an agenda, then please write one as indicated on the > "meeting notes" link above. > > Thanks, > > Michael > ___ > Lista olpc-Sur > olpc-...@lists.laptop.org > http://lists.laptop.org/listinfo/olpc-sur > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Wed, Feb 4, 2009 at 7:21 AM, C. Scott Ananian wrote: > On Mon, Feb 2, 2009 at 11:19 PM, Martin Langhoff >> All I can suggest is that you go back on this thread and read my email. >> >> Here's a clarification (I know my writing isn't always clear): the url >> in the metadata is not expected to remain static over time. > > How is that a problem? All I can suggest is that you go back on this thread and read my email stating the use case. Think about the techniques people use normally in that use case. 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] A small request.
On Sun, 1 Feb 2009, Marco Pesenti Gritti wrote: > On Fri, Jan 30, 2009 at 9:54 PM, Michael Stone wrote: >> Dear Sugar team, >> >> I've been very confused (and frankly, significantly angered) by recent >> remarks that I've encountered both in person (e.g. from Bernie) and in >> #sugar (e.g. from Simon and Tomeu) about how sugar-related folk are >> thinking about the issue of mass activity installation and update. >> Consequently, I'd find it really helpful if we could sit down, lay out >> all the agreed facts, disagreements, and desires, and then figure out a >> mutually agreeable plan for the future. > > What about discussing it in the next development team meeting? > > http://sugarlabs.org/go/DevelopmentTeam/Meetings#When_and_where > > Greg has magic powers to get all of us working together. We are such > an apollo team! Oh, I so wish you hadn't said that. --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Tue, Feb 3, 2009 at 1:56 PM, Simon Schampijer wrote: > I tried it by hand yesterday and added our sugar repo to the yum config does > work fine. The question is how we create that file now. We could do it in > the kickstart file - but maybe there are other options? You could also use a package... not really sure. What about asking on fedora-olpc about the best way to do it? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Naming of "sugar", the Sugar Shell
On Thu, Jan 29, 2009 at 11:13 AM, Tomeu Vizoso wrote: > Well, sugar.datastore would clash with the toolkit, but we could and > should have chosen some other name. As it's code private to the > datastore service, could have been a nonsense name like hulahop or > jarabe. > > But when I started rewriting the old one, I kept the same name and > forgot to change it later, sorry :( > > Maybe it's not too late to change it? It's internal API, so it would be fine to change it imo. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
