[sugar] Presence Service D-Bus API
Am 14.07.2008 um 05:48 schrieb WikiAdmin: > anonymous user 91.179.26.46 edited Presence Service D-Bus API > http://wiki.laptop.org/index.php?title=Presence_Service_D-Bus_API&diff=0&oldid=137835 This adds the GetBuddyByTelepathyHandle() and ListChannels() methods. Should we document the PS version of when this was introduced? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
If, as is the current plan, multiple versions of an activity can coexist on an XO, ... > Two use cases: > 1. I have a journal object. I want to choose which activity to open it with. > I am presented with a multilevel menu: the top level has all activities > which open the mime type, the next level has all major versions of those > activities, the next level minor versions, etc. If click without bothering > to move over to the sublevels, I get the default version from the sublevel > of my current menu, which is the starred version (if it exists) or the > highest version (applied recursively down the sublevels). I'm sorry, but my mind boggles at the thought of a four-year old clicking on a Journal entry and being presented with a palette of seventeen different versions of 'TamTam' -- so that he may choose which of those versions is appropriate for whatever upgrade the adults had made to that XO last week. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar and OLPC release processes
On Tue, 2008-07-15 at 02:03 +0200, Marco Pesenti Gritti wrote: > Hello, > > I discussed a bit with Michael how to integrate Sugar and OLPC release > processes. I'm going to summarize the outcoming here. > > * SugarLabs should try to schedule his release a few months before the > OLPC release target date (something around 2-3 months). That will give > us enough time to ensure everything is stable before we start > integrating the new code in the OLPC distribution. Is this lead time too great? Longer lead times will give OPLC greater stabilization time at the risk of delaying new features. These delays _may_ start to increase requests for feature freeze exceptions. > * Sugar developers employed by OLPC will work on OLPC release > contracts for all the new features present in the new release. > > * After the first stable release SugarLabs will keep releasing minor > updates, which will include bug fixes and strings for the OLPC > release. > > * We should make an effort to develop all the features required as > part of the unstable development cycle. Though there surely will be > cases where OLPC will need changes outside the normal SugarLabs > schedule. We will land these in a limited and controlled way both > during the freeze periods and as part of the stable minor releases. > > I think this is pretty solid. In particular releasing Sugar a few > months before OLPC will help improving quality. It's really difficult > to do unstable development and distribution work at the same time. > > Marco Sounds like a very good plan. dfarning ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar Digest 2008-07-14
=== Sugar Digest === 1. Sugar Labs governance: There are still a few more loose ends to deal with before we are officially members of the Software Freedom Conservancy. In preparation, I've made a lot of changes on the governance page. Please comment. 2. Leaning: There were some interesting discussions about learning on the Education list this week: * Sugar Labs, LOGO and Brian Harvey (http://lists.lo-res.org/pipermail/its.an.education.project/2008-July/001275.html) * reconstructed maths (http://lists.lo-res.org/pipermail/its.an.education.project/2008-July/001279.html) 3. OLPC in the field: Jim Gettys has published an aggregate summary of Sugar in the hands of children in the various OLPC deployments around the world (http://lists.laptop.org/pipermail/community-news/2008-July/000134.html). 4. Clarity: When talking about Sugar, I never have trouble describing the collaboration features or the reflective nature of the Journal, but I struggle with describing the interface in terms of its simplicity. "Simplicity" has an undertone of "dumbed down" and limited capability. In a discussion with Nathan Felde from the Art Institute of Boston, a division of Lesley University, we used the word "clarity", which immediately struck me as a much better term than simplicity. It doesn't imply any limit and it suggests transparency and openness, both hallmarks of the interface. 5. Studio Thinking: Nathan also introduced me to a book, Studio Thinking: The Real Benefits of Visual Arts Education by Lois Hetland, Ellen Winner, Shirley Veneema, and Kimberly M. Sheridan. It is a treatise on visual arts education; the authors argue that through the arts, students learn specific "dispositions of mind" that lead to high-quality thinking. They also speak about "Studio Habits of Mind": develop craft, engage and persist, envision, express, observe, reflect, stretch and explore, and understand the world and "Studio Structures": the demonstration/ lecture, students working, and the critique. It seems there is synergy with many of the goals of Sugar. An open question is how to transfer this thinking beyond the visual arts. === Community jams and meetups === ===Tech Talk=== 6. Release process: Marco Pesenti Gritti and Michael Stone have been discussing how to integrate the Sugar and OLPC release processes: * SugarLabs should try to schedule its release a few months before the OLPC release target date (something around 2–3 months). That will give us enough time to ensure everything is stable before we start integrating the new code in the OLPC distribution. * Sugar developers employed by OLPC will work on OLPC release contracts for all the new features present in the new release. * After the first stable release SugarLabs will keep releasing minor updates, which will include bug fixes and strings for the OLPC release. * We should make an effort to develop all the features required as part of the unstable development cycle. Though there surely will be cases where OLPC will need changes outside the normal SugarLabs schedule. We will land these in a limited and controlled way both during the freeze periods and as part of the stable minor releases. 7. Sucrose: Simon Schampijer announced the Sucrose Development Release 0.81.6 this week (http://wiki.sugarlabs.org/go/ReleaseTeam/CurrentRelease/Sucrose). You can test it in OLPC joyride >= 2129. This first release after the feature freeze and therefore has only bug fixes. It contains as well a new Browse activity (Version 92). Due to an interface change in xulrunner the downloads were broken in Joyride. They are fixed with this Browse release. Simon Schampijer added refinements to the autocompletion feature #7281 and #7280. Due to a name change of the Browse activity (Web->Browse) you will likely have problems updating to the latest version. Find instructions here to work around that problem (http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4#Instructions_to_test_in_olpc_joyride). The sources can be found here: http://dev.laptop.org/pub/sugar/sources/sugar/sugar-0.81.6.tar.bz2 * #7438 sugar shuts down when you click Restart * #7365 Invites not working * #7248 Speaker device has inconsistent behavior * #7339 CPU Spins after starting an activity * #7015 Add proper alignment support to the "tray" control * #5613 Cannot set non-ASCII nick name * #7046 Deleting activity bundle with journal leaves it showing in Home list view until reboot * #7391 Make the search field in Home reveal the list view * #7248 Speaker device has inconsistent behavior * #7272 Notifications are redundant with new launching feedback * #7273 Activity icons remain colored after launch Thanks to everyone who contributed to this release (as well to the translation team for adding new languages and updating existing ones). 8. Handwriting: Julka Lipkova has been working on software for teaching children handwriting (http://code.google.com/p/olpc-dhw/); more details are available at http://olpc-dhw.blogspot
Re: [sugar] Activity versioning schema
On Tue, Jul 15, 2008 at 12:30 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > I would be happy to whip up a universal approximate ordering for version > strings in a few lines of Python. My emphasis here is on _approximate_; > nothing should depend on precisely correct interpretation of version strings. I would say - don't, unless you are doing it for the fun of it. Steal the RPM code - see my earlier reply to Scott as to why this is a better idea. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jameson "Chema" Quinn wrote: > | It is desirable for Sugar to be able to compare versions and > | guess which one is newer. > > "Newer" means "more recent". If this capability is important to you, then > we may simply include a datestamp in each bundle, separate from the > version. However, I do not know of any planned Sugar feature that would > require the ability to determine which bundle was created most recently. I misspoke. I meant, "the latest", in the same sense that Eben is using it: the version with all relevant new feature decisions (including added and dropped features) and bugfixes. This is not always the one created at the latest calendar date. > > | If, as is the current plan, multiple versions of > | an activity can coexist on an XO, it is reasonable to want sugar to > present > | these in some sane order, and possibly give hints and/or aid if the user > | wants to update and/or garbage collect. Otherwise, we might as well just > be > | using activity hash, which can be calculated without being explicitly > | included in activity.info. > > I favor including a version string with every bundle. I favor displaying > this string in places where it is needed to disambiguate multiple versions > of an Activity. I'm merely suggesting that the system not attempt to > parse it. > > You mention ordering. The Journal designs have long called for all > columns to be sorted, with the user selecting the order of sorting > precedence. One intermediate position would be for the Version column to > be sorted according to a best-effort ordering that attempts to do > something sane when faced with any of the common version string > conventions. Two use cases: 1. I have a journal object. I want to choose which activity to open it with. I am presented with a multilevel menu: the top level has all activities which open the mime type, the next level has all major versions of those activities, the next level minor versions, etc. If click without bothering to move over to the sublevels, I get the default version from the sublevel of my current menu, which is the starred version (if it exists) or the highest version (applied recursively down the sublevels). 2. I just quit an activity version which is signed (ie, not just a development build) and is a higher number than the starred version. A dialog pops up asking if I want to "update" to that version. If I click yes, Sugar moves the star to the new version (freeing the older version for possible later GC). If I choose "no", the dialog will not appear again. (Dealing with instances associated with the old version is more complicated. Say I have an instance from Write 50 and Write 60 is starred. I suggest that the ideal behaviour would be to open by default with Write 60, assuming it handles the mime type, but ask after closing if that worked; if not, remember that Write 50 instances may be incompatible with other versions and open them by default with Write 50 always. An instance of Write 70 should open with Write 70. This would not change GC behaviour: you might end up GC-ing an old version and losing access to your instances, but the old version would be available if necessary from the backup server.) I guess you could argue that use case 2 should offer to assist downgrades as well as upgrades (since we would be keeping separate already-showed-dialog metadata for each version, any version would only show the dialog once, and that would be more likely to be when it was newer), but I think that even then it would be useful to include the words "higher version" or "lower version" in the dialog. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | I guess the point here is that performing intelligent string comparisons on | several of these schemes requires parsing the string. ;) I would be happy to whip up a universal approximate ordering for version strings in a few lines of Python. My emphasis here is on _approximate_; nothing should depend on precisely correct interpretation of version strings. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh7748ACgkQUJT6e6HFtqR+PACfa4VCNDYT7iqbDyq4ER7doTbU jCsAnAmR0TWlhah9sRG6YNx/ve9tqWT6 =CxR/ -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 7:47 PM, Benjamin M. Schwartz < [EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jameson "Chema" Quinn wrote: > | It is desirable for Sugar to be able to compare versions and > | guess which one is newer. > > "Newer" means "more recent". If this capability is important to you, then > we may simply include a datestamp in each bundle, separate from the > version. However, I do not know of any planned Sugar feature that would > require the ability to determine which bundle was created most recently. I'm not sure that has to be what we mean by "newer", and if it is, we need to find a better word. Dates are *not* the criteria we want for newness. Code maturity is closer to the intended meaning, and I think is the newness that Jameson is also referring to. > > | If, as is the current plan, multiple versions of > | an activity can coexist on an XO, it is reasonable to want sugar to > present > | these in some sane order, and possibly give hints and/or aid if the user > | wants to update and/or garbage collect. Otherwise, we might as well just > be > | using activity hash, which can be calculated without being explicitly > | included in activity.info. > > I favor including a version string with every bundle. I favor displaying > this string in places where it is needed to disambiguate multiple versions > of an Activity. I'm merely suggesting that the system not attempt to > parse it. > > You mention ordering. The Journal designs have long called for all > columns to be sorted, with the user selecting the order of sorting > precedence. One intermediate position would be for the Version column to > be sorted according to a best-effort ordering that attempts to do > something sane when faced with any of the common version string > conventions. > I guess the point here is that performing intelligent string comparisons on several of these schemes requires parsing the string. ;) - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar and OLPC release processes
Hello, I discussed a bit with Michael how to integrate Sugar and OLPC release processes. I'm going to summarize the outcoming here. * SugarLabs should try to schedule his release a few months before the OLPC release target date (something around 2-3 months). That will give us enough time to ensure everything is stable before we start integrating the new code in the OLPC distribution. * Sugar developers employed by OLPC will work on OLPC release contracts for all the new features present in the new release. * After the first stable release SugarLabs will keep releasing minor updates, which will include bug fixes and strings for the OLPC release. * We should make an effort to develop all the features required as part of the unstable development cycle. Though there surely will be cases where OLPC will need changes outside the normal SugarLabs schedule. We will land these in a limited and controlled way both during the freeze periods and as part of the stable minor releases. I think this is pretty solid. In particular releasing Sugar a few months before OLPC will help improving quality. It's really difficult to do unstable development and distribution work at the same time. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson "Chema" Quinn wrote: | It is desirable for Sugar to be able to compare versions and | guess which one is newer. "Newer" means "more recent". If this capability is important to you, then we may simply include a datestamp in each bundle, separate from the version. However, I do not know of any planned Sugar feature that would require the ability to determine which bundle was created most recently. | If, as is the current plan, multiple versions of | an activity can coexist on an XO, it is reasonable to want sugar to present | these in some sane order, and possibly give hints and/or aid if the user | wants to update and/or garbage collect. Otherwise, we might as well just be | using activity hash, which can be calculated without being explicitly | included in activity.info. I favor including a version string with every bundle. I favor displaying this string in places where it is needed to disambiguate multiple versions of an Activity. I'm merely suggesting that the system not attempt to parse it. You mention ordering. The Journal designs have long called for all columns to be sorted, with the user selecting the order of sorting precedence. One intermediate position would be for the Version column to be sorted according to a best-effort ordering that attempts to do something sane when faced with any of the common version string conventions. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh75ZgACgkQUJT6e6HFtqQePgCglNaySAW67tZIHgbYjIPDmqMt gKQAn2hV9jHTrZqPfGu7dHkx7KVlvi25 =1hsE -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
> I'd like to pose an alternative goal, inspired by your comment: Glucose > should never attempt to parse version strings. I believe that we can > accomplish this without sacrificing any of the user-facing behaviors that > we truly desire. The choice of an appropriate versioning scheme may then > be left to the author. > I disagree. It is desirable for Sugar to be able to compare versions and guess which one is newer. If, as is the current plan, multiple versions of an activity can coexist on an XO, it is reasonable to want sugar to present these in some sane order, and possibly give hints and/or aid if the user wants to update and/or garbage collect. Otherwise, we might as well just be using activity hash, which can be calculated without being explicitly included in activity.info. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 4:18 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > If we're going to a 'dotted decimal' scheme, we > should use '.'. > > ... > > Is 1.1 "newer" or "older" than 1.11?) This is exactly the reason I think that 1-1 ... 1-11 is clearer (you're right, colon is unworkable because it cannot go in NTFS file names). From an educational standpoint, 1.10 is teaching kids the wrong ideas about the decimal system. I do not think that hyphens are impractical. In most cases people will get it right the first time by following examples. Those who don't will quickly learn from installation warnings. I think anything from 1-3 levels should be allowed, and that 3 == 3-0 == 3-0-0. Leading zeroes should cause warnings - that will mostly keep things from looking like dates (even in 2010, bugfix 10 should be rare). ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: | After | all, if an activity writer wants to use Klingon characters for | versioning, hey, let them go wild! This is actually the key point. Currently, the versioning system is embedded into the Glucose code itself, and our plans for handling multiple versions would require even more code to handle more complex versioning situations. I'd like to pose an alternative goal, inspired by your comment: Glucose should never attempt to parse version strings. I believe that we can accomplish this without sacrificing any of the user-facing behaviors that we truly desire. The choice of an appropriate versioning scheme may then be left to the author. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh73RoACgkQUJT6e6HFtqR2TwCfZeK//hNeyD6XxFGD1NkrtcYL BMYAn0WolFwatGoVgtqwryGHV03WbaH6 =RNKc -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 6:56 PM, Martin Langhoff <[EMAIL PROTECTED]> wrote: > Version numbers are used to communicate API/ABI compat and degree/type > of changes to users. Later in this thread Eben suggests what everyone > else in the industry is using: major.minor - sounds good to me. Even > better - and more prevalent in OSS - is major.minor.bugfix . If we were to make the change, I'd suggest supporting dotted integer sequences of arbitrary length. 1, 1.2, 1.2.3, and 1.2.3.4 are all reasonable version numbers. These are *not* floating point numbers; they sort based on integer comparison major component first, so 1.1 < 1.11. Once we've gone that far, we might as well go all the way and adopt the version number scheme fedora uses, with an epoch and everything. But this doesn't actually do anything to solve the problem Eben first posed, which is why I'm objecting: it seems needless complexity at the moment, to a format which was explicitly designed to Keep Things Simple. > In any case, this issue does not seem to deserve such a colourful > thread. Maybe we can save our time and effort for other stuff? After You think this is colorful? Geesh. I need to work harder on the other threads. > all, if an activity writer wants to use Klingon characters for > versioning, hey, let them go wild! I am compelled to strongly object. The updater needs to be able to compare version numbers. I refuse to implement Klingon numeral comparison. All this stuff is trivial until you are the one who has to implement the updater. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Tue, Jul 15, 2008 at 6:17 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > There was an extensive discussion on this topic a while back on IRC, Version numbers are used to communicate API/ABI compat and degree/type of changes to users. Later in this thread Eben suggests what everyone else in the industry is using: major.minor - sounds good to me. Even better - and more prevalent in OSS - is major.minor.bugfix . In any case, this issue does not seem to deserve such a colourful thread. Maybe we can save our time and effort for other stuff? After all, if an activity writer wants to use Klingon characters for versioning, hey, let them go wild! cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 6:48 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > I read on our wiki that the version number was supposed to be monotonically > increasing. If that were the case, doing as you suggest isn't valid, as I Who wrote this? Did they mean it to be taken this literally, or just as a guideline? > would never be able to release anything with a version below 500 once I had, > defeating the purpose. Also, the current page on activity bundles > explicitly states that "Larger versions are considered 'newer'", which is > simply not the case, even if we do allow your scheme proposed above, which, > I agree, is technically equivalent. I proposed two schemes. The one which said, "just release 10 and 11 at the same time, 10 for 8.1 and 11 for 8.2" conforms with the literal reading of that wiki page, even if I dispute its authority. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 6:41 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 6:24 PM, Eben Eliason <[EMAIL PROTECTED]> > wrote: > > I think this is still a whole bunch clearer than trying to convince > someone > > that version 5 is newer than version 10! (where 10 is a "bugfix" release > to > > what used to be version 4.) > > You're undercutting your own points: what does "newer" mean? If you > want chronological "newness", then use ISO8601 dates. Otherwise, just > release a version 11 at the same time as 10, so that versions 10 and > 11 are the chronologically newest releases, 11 for 8.2 users and 10 > for 8.1 users, and those people using '9' don't get confused. This This isn't always possible. If I release version 10 (because it takes advantage of some new feature in a new OS) and then later find out I have a critical bug in an older version of the OS that still has a wide support window, I'm forced to release 11 after 10, even though its an older code base. I'm not concerned at all with temporal newness, or this would be a non-issue. > > really seems like a non-issue to me. If your development style really > wants to use minor versions, make up your own mapping to integers: 5.0 > = 500, 5.1=501, etc. But regardless, adding dotted integers for > version numbers isn't a real concern for me: it touches a number of > pieces of code and documentation at this point, but we can go ahead > and make that change early in 9.1 if you like. But it still doesn't > actually do anything towards solving the problem you initially posed: > the only difference between 500 and 5.0 is perceptual. I read on our wiki that the version number was supposed to be monotonically increasing. If that were the case, doing as you suggest isn't valid, as I would never be able to release anything with a version below 500 once I had, defeating the purpose. Also, the current page on activity bundles explicitly states that "Larger versions are considered 'newer'", which is simply not the case, even if we do allow your scheme proposed above, which, I agree, is technically equivalent. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 6:24 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > I think this is still a whole bunch clearer than trying to convince someone > that version 5 is newer than version 10! (where 10 is a "bugfix" release to > what used to be version 4.) You're undercutting your own points: what does "newer" mean? If you want chronological "newness", then use ISO8601 dates. Otherwise, just release a version 11 at the same time as 10, so that versions 10 and 11 are the chronologically newest releases, 11 for 8.2 users and 10 for 8.1 users, and those people using '9' don't get confused. This really seems like a non-issue to me. If your development style really wants to use minor versions, make up your own mapping to integers: 5.0 = 500, 5.1=501, etc. But regardless, adding dotted integers for version numbers isn't a real concern for me: it touches a number of pieces of code and documentation at this point, but we can go ahead and make that change early in 9.1 if you like. But it still doesn't actually do anything towards solving the problem you initially posed: the only difference between 500 and 5.0 is perceptual. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 6:18 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 6:07 PM, Eben Eliason <[EMAIL PROTECTED]> > wrote: > > On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn < > [EMAIL PROTECTED]> > > I agree with almost everything jquinn said, except for the use of ':' > to delimit version numbers. Like it or not, the rest of the software > world uses '.'. If we're going to a 'dotted decimal' scheme, we > should use '.'. The cost of doing things "our own way" is just too > high otherwise. > > > I don't expect to have any encoded info which makes this decidedly easy. > I > > just want a simple way to say that versions 3.x - 5.x work on OS release > > 8.2. Nothing in the bundle needs to indicate that specifically, but at > > least we'd have a way to easily document compatibilities. I understand > what > > No, you've missed my point: it is *not possible* to put this > information in the bundle, because we don't *know* that version 8 is > incompatible with release 9.1 *until after 9.1 is released*. So the > compatibility information has to be maintained externally. > On the contrary, you are missing mine. I don't *want* this in the bundle. I want this to be a sentence that can be stated, at some point following the release of 9.1, by a wiki page, the release notes, a tech support person, a friend, or the developer herself. Nothing more. No technical magic here. The technical changes suggested (dotted decimal versioning scheme) are simply a nicety to make uttering this sentence more natural. > So, that separates our concerns into two independent problems: > a) is it worthwhile to add dotted decimal version numbers? (I remain > unconvinced that this solves any problems, and introduces ambiguities > of comparison: Is 1.1 "newer" or "older" than 1.11?) I think this is still a whole bunch clearer than trying to convince someone that version 5 is newer than version 10! (where 10 is a "bugfix" release to what used to be version 4.) - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 6:07 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> I agree with almost everything jquinn said, except for the use of ':' to delimit version numbers. Like it or not, the rest of the software world uses '.'. If we're going to a 'dotted decimal' scheme, we should use '.'. The cost of doing things "our own way" is just too high otherwise. > I don't expect to have any encoded info which makes this decidedly easy. I > just want a simple way to say that versions 3.x - 5.x work on OS release > 8.2. Nothing in the bundle needs to indicate that specifically, but at > least we'd have a way to easily document compatibilities. I understand what No, you've missed my point: it is *not possible* to put this information in the bundle, because we don't *know* that version 8 is incompatible with release 9.1 *until after 9.1 is released*. So the compatibility information has to be maintained externally. So, that separates our concerns into two independent problems: a) is it worthwhile to add dotted decimal version numbers? (I remain unconvinced that this solves any problems, and introduces ambiguities of comparison: Is 1.1 "newer" or "older" than 1.11?) b) how to *externally indicate* which versions work with a given release. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > > I agree with the signature approach. However, I don't really know what >> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and >> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to >> coincide with the "level of newness". This is something we will lose >> completely without a minor release number. The logical assumption is that >> "the bigger the number, the better/newer it is", which is blatantly false >> when point releases are intermixed with brand new versions with >> ever-increasing version numbers. I might decide I need to clear up space, >> and so delete versions 37 and 38, thinking I was keeping the latest and >> greatest version 39 and be quite disappointed. >> >> - Eben >> > > This idea works well when developers time their new-features releases to > coincide with Sucrose updates. It starts to break down when that does not > hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds > essentially the same feature-set as 3.0" or some combination of both? I > think that Eben is assuming the former - that nobody would go back and > release lower version numbers except in order to maintain system > compatibility - but this conflicts with a common assumption that major > version changes are synonymous with major new features. > > Basically, there are two separate problems here, and we should not be > solving them together. One is that the latest release may not be the > greatest - because of bugfix releases. I agree with Eben's proposal of minor > version numbers as a (totally optional) solution; as long as the minor/major > separator is not a decimal separator (that is, [.,]), the meaning is pretty > self-evident. (I think that : is the best candidate, by analogy with times > and bible verses.) > This is actually my primary concern. > But the second problem is harder: how do you tell people which versions run > on which Glucose. Any attempt to encode this implicitly in version numbers > is, I think, bound to fail, and not too helpful anyway. The update_url > solution for #4951 fixes the most useful version of this problem - "what is > the latest working version on my system". I think we can live without a more > general solution to "will version X run on system Y" - even though that > means some ugly trial-and-error when sharing activities across Glucose > versions. > I don't expect to have any encoded info which makes this decidedly easy. I just want a simple way to say that versions 3.x - 5.x work on OS release 8.2. Nothing in the bundle needs to indicate that specifically, but at least we'd have a way to easily document compatibilities. I understand what you mean in that activity cycles won't necessarily match OS cycles, and it's true. It's possible for several releases to be "designed for" a single OS version, and likewise possible that a major activity version would span several OS versions. I'm mostly trying to safegaurd against the possibility of future API or other incompatibilities which come from Sugar itself. It would be up to the activity developer to decide if they wanted to jump to a new major version to support a new API or feature which isn't around in older versions of the OS. - Eben > > ... > > and cscott just wrote an email which says many of the same things. > > Jameson > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 5:34 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 4:49 PM, Eben Eliason <[EMAIL PROTECTED]> > wrote: > > I'm not sure this satisfies me. It might accurately handle the use case > of > > updating when upgrading, assuming that activity developers are very > careful > > to add extra info about compatibility into the .info file. It doesn't > > however, make it easy to decide what version of an activity to download > if > > I've never used it before, and I'm not on the most recent release of > Sugar. > > No, this problem is already solved by the scheme I outline. Can you explain how? For instance, if I'm looking at a wiki page for an activity, how does that page tell me which version I need? How can a tech-support guru tell the person on the other end of the line what they need? It seems your approach only works when software is working it's magic on the extra info in the .info file. > > > > I agree with the signature approach. However, I don't really know what > > happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, > and > > 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, > to > > coincide with the "level of newness". This is something we will lose > > completely without a minor release number. The logical assumption is > that > > "the bigger the number, the better/newer it is", which is blatantly false > > when point releases are intermixed with brand new versions with > > ever-increasing version numbers. I might decide I need to clear up > space, > > and so delete versions 37 and 38, thinking I was keeping the latest and > > greatest version 39 and be quite disappointed. > > I don't see how your solution solves this problem either. Say the > activity author has released 0.4, 0.6, 1, 1.2, and 1.3. Versions 0.6, > 1.2, and 1.3 only work on 8.1 (because of a bug in 1.3), but version > 0.4 and 1.2 work on 8.2 (because 0.4 didn't use the "new" feature that > was broken in the 8.2 update, and 1.2 didn't have the bug introduced > in 1.3). What's the "level of newness"? > I still think it mostly solves it. You're confusing "newer version of an activity" with "runs on newer version of OS", I think. For instance, even though 0.4 runs on 8.2 because it didn't use some new feature of 8.1 doesn't make it any newer. It's still old, less mature code, and the UI and feature set would certainly back that up. The bugfixes in 1.2 might also make the activity work on both 8.1 and 8.2, but that doesn't change the fact that the fixes were still to a version of the activity less mature than 1.3, and likewise containing fewer features. Most importantly, you've demonstrated that the "natural ordering" of the versions is 0.4, 0.6, 1.2, 1.3, which is true regardless of the fact that 1.2 might have been released months after 1.3. The level of newness seems intact to me. Sadly, I think that it's up to the activity authors to ensure that > newer versions work on older releases. I admire your desire to make > more powerful version numbers, but simply adding an extra digit isn't > going to materially change anything. > I think you're wrong. I think that exposing single digit version numbers is, subconsciously or not, going to indicate to them that the largest number is the newest version of the activity. The problem is that the definition of newest isn't in sync with expectation. It's only newest in that it was released most recently, but that's not what really matters. What matters is which of them is the most mature in terms of code/features. I think the most interesting question is "what's the newest version > compatible with my release", and that's the problem I've solved. I Again, I disagree. Take, for instance, your example from above. It was clear that both versions 1.2 and 1.3 work on 8.2. If 1.2 was released after (temporally) 1.3, it's technically "newer" and would have a higher version number (in the old scheme). It's also compatible with 8.2. So the newest version compatible with my release is therefore 1.2, even though there's actually a newer-as-in-features 1.3 release that I'm really after. agree that it would be interesting in the future to be able to mark > activities in the activity list that "can't possibly be expected to > run" for some reason or another (like an API incompatibility), but I > don't think I agree that manually putting information in an > activity.info file is the best way to do that -- for starters, the > information you'd like to add all have to find its way into that file > *retroactively* after the new release has come out which is > incompatible. A better method would be to provide a standardized way What? All I'm suggesting is a minor version number. Nothing needs to be added retroactively to existing activities. We can just assume that absence of a minor version means that it's X.0 instead. > > for a python app to run code which performs tests and returns
Re: [sugar] Activity versioning schema
> I agree with the signature approach. However, I don't really know what > happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and > 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to > coincide with the "level of newness". This is something we will lose > completely without a minor release number. The logical assumption is that > "the bigger the number, the better/newer it is", which is blatantly false > when point releases are intermixed with brand new versions with > ever-increasing version numbers. I might decide I need to clear up space, > and so delete versions 37 and 38, thinking I was keeping the latest and > greatest version 39 and be quite disappointed. > > - Eben > This idea works well when developers time their new-features releases to coincide with Sucrose updates. It starts to break down when that does not hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds essentially the same feature-set as 3.0" or some combination of both? I think that Eben is assuming the former - that nobody would go back and release lower version numbers except in order to maintain system compatibility - but this conflicts with a common assumption that major version changes are synonymous with major new features. Basically, there are two separate problems here, and we should not be solving them together. One is that the latest release may not be the greatest - because of bugfix releases. I agree with Eben's proposal of minor version numbers as a (totally optional) solution; as long as the minor/major separator is not a decimal separator (that is, [.,]), the meaning is pretty self-evident. (I think that : is the best candidate, by analogy with times and bible verses.) But the second problem is harder: how do you tell people which versions run on which Glucose. Any attempt to encode this implicitly in version numbers is, I think, bound to fail, and not too helpful anyway. The update_url solution for #4951 fixes the most useful version of this problem - "what is the latest working version on my system". I think we can live without a more general solution to "will version X run on system Y" - even though that means some ugly trial-and-error when sharing activities across Glucose versions. ... and cscott just wrote an email which says many of the same things. Jameson ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Sugar] Browse extension/plugin structure
Please speak to me of your thoughts on the security implications of making Browse extensible. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity Backward Compatibility
As I have suggested before, I think that these sorts of checks also matter enourmously to the quality of user experience that we'll be able to provide when we start seriously attempting to provide 'easy code sharing' features. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 4:49 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > I'm not sure this satisfies me. It might accurately handle the use case of > updating when upgrading, assuming that activity developers are very careful > to add extra info about compatibility into the .info file. It doesn't > however, make it easy to decide what version of an activity to download if > I've never used it before, and I'm not on the most recent release of Sugar. No, this problem is already solved by the scheme I outline. > I agree with the signature approach. However, I don't really know what > happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and > 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to > coincide with the "level of newness". This is something we will lose > completely without a minor release number. The logical assumption is that > "the bigger the number, the better/newer it is", which is blatantly false > when point releases are intermixed with brand new versions with > ever-increasing version numbers. I might decide I need to clear up space, > and so delete versions 37 and 38, thinking I was keeping the latest and > greatest version 39 and be quite disappointed. I don't see how your solution solves this problem either. Say the activity author has released 0.4, 0.6, 1, 1.2, and 1.3. Versions 0.6, 1.2, and 1.3 only work on 8.1 (because of a bug in 1.3), but version 0.4 and 1.2 work on 8.2 (because 0.4 didn't use the "new" feature that was broken in the 8.2 update, and 1.2 didn't have the bug introduced in 1.3). What's the "level of newness"? Sadly, I think that it's up to the activity authors to ensure that newer versions work on older releases. I admire your desire to make more powerful version numbers, but simply adding an extra digit isn't going to materially change anything. I think the most interesting question is "what's the newest version compatible with my release", and that's the problem I've solved. I agree that it would be interesting in the future to be able to mark activities in the activity list that "can't possibly be expected to run" for some reason or another (like an API incompatibility), but I don't think I agree that manually putting information in an activity.info file is the best way to do that -- for starters, the information you'd like to add all have to find its way into that file *retroactively* after the new release has come out which is incompatible. A better method would be to provide a standardized way for a python app to run code which performs tests and returns a go/no-go, or else to just mark activities which fail during launch. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
Comments follow...
On Mon, Jul 14, 2008 at 4:09 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <[EMAIL PROTECTED]>
> wrote:
> > They don't get it? Or they don't get how a single integer is supposed to
> be
> > sufficient, and therefor use their own methods? Do you have examples of
> > specific "random and bogus" strings we can look at to see what's been
> tried?
>
> On an XO:
> $ python2.5
> >>> act_page = 'http://wiki.laptop.org/go/Activities'
> >>> import urlparse, re, urllib
> >>> import bitfrost.update.actutils as actutils
> >>> urls = [urlparse.urljoin(act_page, url) for url in
> re.findall(r'href="([^"]*)"', urllib.urlopen(act_page).read()) if
> url.endswith('.xo')]
> >>> for u in urls:
> ... try:
> ... cp = actutils.activity_info_from_url(u)
> ... except:
> ... print "BAD activity.info", u
> ... continue
> ... if not cp.has_option('Activity','activity_version'):
> ... print "MISSING VERSION", u
> ... continue
> ... try:
> ... pass
> ... except: pass
> ... v = cp.get('Activity','activity_version')
> ... try:
> ... assert not v.startswith('0')
> ... assert not '.' in v
> ... v = int(v)
> ... except:
> ... print "BAD VERSION", u, v
> ...
> MISSING VERSION http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo
> BAD activity.info http://wiki.laptop.org/images/7/7e/Gmail-2.xo
> BAD activity.info http://opteron.9grid.us/olpc/inferno-012808.xo
> MISSING VERSION http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo
> BAD activity.info http://www.linuxuser.at/dl.php?i=ImageQuiz.xo
>
> This is under-reported, since many of the bad activities just set
> activity_version=1:
>
> >>> def bad_ver(v):
> ... try:
> ... assert not v.startswith('0')
> ... int(v)
> ... return False # good
> ... except:
> ... return True
> ...
> >>> vers = [v for v in re.findall(r' class="olpc-activity-version">([^<]*)',
> urllib.urlopen(act_page).read()) if bad_ver(v)]
> >>> vers
> ['\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '1-beta', '1.4', '1.7', '\xe2\x80\x93', '0.29', '3.3', '\xe2\x80\x93',
> '012808', '\xe2\x80\x93', '\xe2\x80\x93', '0.4', '', '0.33 - beta 3',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '0.2',
> '080601', '080601', '080601', '080601', '080601', '080601', '080601',
> '080601', '080601', '080601', '', '\xe2\x80\x93', '[beta-1]',
> '\xe2\x80\x93', '0.1', '\xe2\x80\x93', '0.1']
> >>>
>
> >> b) There is an alternative mechanism already in place for handling
> >> dependencies on specific versions, documented in the [[Activity
> >> bundles]] entry for 'update_url'. Basically, you can specify a
> >> different version number as appropriate based on the current OS build,
> >> release version, and release major version. So you can say, "version
> >> 8 if you are using 8.1, or version 9 if you are using 8.2".
> >
> > How does this actually help the user, or the tech support team when
> someone
> > wants to know "what version of chat works with 9.1.0?" Short of saying
> > "Well, the system will (should) know if it can support an activity, so
> > download it and see..." what do we have? We say "Well, versions 36-38,
> and
> > also 40, and also 42, work with 9.1, but not 39 and 41...those are
> bugfixes
> > for 8.2". This seems silly to me. Just say versions 4.x and 5.x work
> with
> > 8.2 and 6.x works with 9.1. This also makes displaying multiple versions
> > (activity "threads") possible in the OS. Otherwise how can we reasonable
> > sort/group the activities in any way that makes sense?
> > - Eben
>
> Just say, "does the activity updater show an update for your version
> of Chat? if so, install it, please."
>
I'm not sure this satisfies me. It might accurately handle the use case of
updating when upgrading, assuming that activity developers are very careful
to add extra info about compatibility into the .info file. It doesn't
however, make it easy to decide what version of an activity to download if
I've never used it before, and I'm not on the most recent release of Sugar.
What if I still have 8.1 even though 8.2 is out, and I find a cool new
science activity I want. What version to get? Well, maybe 23. Maybe 32.
Maybe 24-31 are all incompatible because of a new API in 8.2, but how would
I know? Is the best suggestion to download a really old version and then
wait for it to inform me of an update?
>
> The alternative is not going to work, because the activity authors
> can't keep their bundle ids straight, much less collectively agree to
> use release-synchronized version numbers in a sane way. You are
> proposing a more complicated system, which just introduces more ways
> to go wrong w/o actually addressing any part of the real metadata
> probl
Re: [sugar] Activity Backward Compatibility
The way I see it, there are TWO kinds of items for which "compatibility" needs to be provided -- executables + data : * Executables : The problem arises from the "quickness" with which some users (such as I) can switch operating system versions. I sometimes have two different "streams" on my XO (for example, the two "builds" in the /versions directory might be from Update.1 vs. Joyride) -- I can switch in minutes to a different "stream" by just rebooting. Others (including kids) can switch in tens of minutes to a different "stream" by installing a new build from an USB stick. The problem (of providing "compatibility" between Activities and the operating system on which they run) originated when Activities were no longer packaged into the "build". Now, unless the "build" to be fetched is accompanied by a set of Activity EXECUTABLES known to be compatible with that build, any "leftover from previous times" XO Activities might *not* receive the particular version of services from the new-fetched operating system "build" that they expect. The only solution I see is to provide a set of "compatible" Activity versions whenever a "build" version is provided. For kids, that would mean using a facility similar to 'Customization' to put BOTH a "build" and its "Activities" on the same USB stick. [I used the word 'similar' because the kid ought to have the options of either doing a "completely clean" install, or else installing the new build+Activities __without__ wiping out the existing /home/olpc content. (The question of providing "backward compatibility" between leftover /home/olpc data and changed Activity executables is left to another discussion.)] * Data : The problem is that Activities compiled in July might not work correctly with DATA placed into the datastore in February (by the version of the Activity that was installed at that time). The only solution I see is to *insist* that each new version of the Activity __verify__ that it can work with the data (e.g., formats) that are made available to it. If not, the Activity should notify the user of the incompatibility. mikus p.s. One of my "hot buttons" is 'hooking up' additional Activities which are resident on a removable storage device. Obviously, such Activities might be at the wrong version level. Therefore I am interested in there being a "checker" at activity-launch time, which would compare the current operating-system level against the level expected by the activity to be launched -- and at least warn the user if an incompatibility is found. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 3:49 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > Otherwise how can we reasonable sort/group the activities in any way > > that makes sense? > > I suggested one (stupidly slow, but very general) approach based on the > Travelling Salesman problem. To recap: > > Regard all activities as nodes in a fully connected graph. Let > activities state that they are close to some collection of other > activities according to any system you please. (e.g. specify a metric on > activities, plug in some heuristics on names and numbers, give a list of > 'similar' activities, do cosine similarity on keyword vectors, etc.) > > When you learn that A thinks it should be close to B, shorten the edge > between A and B. > > "Solve" the TSP for the graph. Approximate solutions are fine. > An interesting idea, for sure, but not ultimately what concerns me. We actually know the "grouping"...it will be determined by the signature of the bundle, with broken signatures splitting the grouping. I was more concerned with sorting the available versions in a "meaningful" way. Perhaps this is too lofty a goal. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> They don't get it? Or they don't get how a single integer is supposed to be
> sufficient, and therefor use their own methods? Do you have examples of
> specific "random and bogus" strings we can look at to see what's been tried?
On an XO:
$ python2.5
>>> act_page = 'http://wiki.laptop.org/go/Activities'
>>> import urlparse, re, urllib
>>> import bitfrost.update.actutils as actutils
>>> urls = [urlparse.urljoin(act_page, url) for url in
>>> re.findall(r'href="([^"]*)"', urllib.urlopen(act_page).read()) if
>>> url.endswith('.xo')]
>>> for u in urls:
... try:
... cp = actutils.activity_info_from_url(u)
... except:
... print "BAD activity.info", u
... continue
... if not cp.has_option('Activity','activity_version'):
... print "MISSING VERSION", u
... continue
... try:
... pass
... except: pass
... v = cp.get('Activity','activity_version')
... try:
... assert not v.startswith('0')
... assert not '.' in v
... v = int(v)
... except:
... print "BAD VERSION", u, v
...
MISSING VERSION http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo
BAD activity.info http://wiki.laptop.org/images/7/7e/Gmail-2.xo
BAD activity.info http://opteron.9grid.us/olpc/inferno-012808.xo
MISSING VERSION http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo
BAD activity.info http://www.linuxuser.at/dl.php?i=ImageQuiz.xo
This is under-reported, since many of the bad activities just set
activity_version=1:
>>> def bad_ver(v):
... try:
... assert not v.startswith('0')
... int(v)
... return False # good
... except:
... return True
...
>>> vers = [v for v in re.findall(r'>> class="olpc-activity-version">([^<]*)',
>>> urllib.urlopen(act_page).read()) if bad_ver(v)]
>>> vers
['\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'1-beta', '1.4', '1.7', '\xe2\x80\x93', '0.29', '3.3', '\xe2\x80\x93',
'012808', '\xe2\x80\x93', '\xe2\x80\x93', '0.4', '', '0.33 - beta 3',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '0.2',
'080601', '080601', '080601', '080601', '080601', '080601', '080601',
'080601', '080601', '080601', '', '\xe2\x80\x93', '[beta-1]',
'\xe2\x80\x93', '0.1', '\xe2\x80\x93', '0.1']
>>>
>> b) There is an alternative mechanism already in place for handling
>> dependencies on specific versions, documented in the [[Activity
>> bundles]] entry for 'update_url'. Basically, you can specify a
>> different version number as appropriate based on the current OS build,
>> release version, and release major version. So you can say, "version
>> 8 if you are using 8.1, or version 9 if you are using 8.2".
>
> How does this actually help the user, or the tech support team when someone
> wants to know "what version of chat works with 9.1.0?" Short of saying
> "Well, the system will (should) know if it can support an activity, so
> download it and see..." what do we have? We say "Well, versions 36-38, and
> also 40, and also 42, work with 9.1, but not 39 and 41...those are bugfixes
> for 8.2". This seems silly to me. Just say versions 4.x and 5.x work with
> 8.2 and 6.x works with 9.1. This also makes displaying multiple versions
> (activity "threads") possible in the OS. Otherwise how can we reasonable
> sort/group the activities in any way that makes sense?
> - Eben
Just say, "does the activity updater show an update for your version
of Chat? if so, install it, please."
The alternative is not going to work, because the activity authors
can't keep their bundle ids straight, much less collectively agree to
use release-synchronized version numbers in a sane way. You are
proposing a more complicated system, which just introduces more ways
to go wrong w/o actually addressing any part of the real metadata
problem.
As regard to sorting/grouping: we already discussed that at our last
mini-conference: simple ordering by version number, with group breaks
when signature changes. There is an additional grouping mechanism in
the updater, as well, that lets countries define things like "G1G1
activities" or "Peru activities".
--scott
--
( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
> Otherwise how can we reasonable sort/group the activities in any way > that makes sense? I suggested one (stupidly slow, but very general) approach based on the Travelling Salesman problem. To recap: Regard all activities as nodes in a fully connected graph. Let activities state that they are close to some collection of other activities according to any system you please. (e.g. specify a metric on activities, plug in some heuristics on names and numbers, give a list of 'similar' activities, do cosine similarity on keyword vectors, etc.) When you learn that A thinks it should be close to B, shorten the edge between A and B. "Solve" the TSP for the graph. Approximate solutions are fine. Designate a starting point (I suggest a 'Help' activity) and order your activities according to your solution. You can even do fancy grouping tricks for small-diameter subgraphs. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [Sugar] Browse extension/plugin structure
Hi, Me and Tomeu were discussing the way browse should handle extensions/plugins and we came to the conclusion that really, it should do this the same way firefox does it, thereby making it far easier to make future extensions/plugins... Right now, xulrunner already has a way of doing this directly, even with an installer that injects the .xpi where it should go... the question is, does it work that way with browse already? In which case, maybe someone (Marco?) can shed some light onto where all the unzipped .xpi stuff should go... Here is the recommended mozilla structure for .xpis and the way Firefox 3 is doing it: helloworld.xpi/ chrome.manifest install.rdf components/ defaults/ preferences/ mydefaults.js chrome/ helloworld.jar content/ overlay.js overlay.xul locale/ en-US/ overlay.dtd skin/ overlay.css Kind Regards, David Van Assche ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Mon, Jul 14, 2008 at 3:09 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > 2008/7/14 Eben Eliason <[EMAIL PROTECTED]>: > > There was an extensive discussion on this topic a while back on IRC, > which I > > unfortunately don't have a record of. There was also mention of this in > the > > mailing lists not too long ago, initiated by > > Morgan: http://lists.laptop.org/pipermail/sugar/2008-May/005895.html. > > Finally, I brought this up at the end of a recent tech team meeting (1 > or 2 > > weeks ago?) as a topic that needed our attention in order to make the > > update/upgrade system work (specifically, regarding the need for minor > > versions so that we can make bugfixes to older versions of an activity > (say, > > 4.x) while keeping 5.x for all versions that work with the next version > of > > the OS). I think deciding how we version activities is a critical part > of > > making our OS releases work, and can assist in the problem of answering > > "Which activities work with my release?". Answering 4.x is nicer than > [34 - > > 42], and MUCH nicer than [36-38, 40, 42]. > > The "agreement" I speak of was really a lack of any voiced disagreement > when > > I mentioned this issue at the meeting. > > From extensive auditing of current activity version numbers: > a) a large number of activities are using completely random and bogus > strings for their version numbers. "Just an integer" is about the > simplest possible scheme, and people still don't get it. I'm > unconvinced that any more complicated scheme will work better. They don't get it? Or they don't get how a single integer is supposed to be sufficient, and therefor use their own methods? Do you have examples of specific "random and bogus" strings we can look at to see what's been tried? > > b) There is an alternative mechanism already in place for handling > dependencies on specific versions, documented in the [[Activity > bundles]] entry for 'update_url'. Basically, you can specify a > different version number as appropriate based on the current OS build, > release version, and release major version. So you can say, "version > 8 if you are using 8.1, or version 9 if you are using 8.2". How does this actually help the user, or the tech support team when someone wants to know "what version of chat works with 9.1.0?" Short of saying "Well, the system will (should) know if it can support an activity, so download it and see..." what do we have? We say "Well, versions 36-38, and also 40, and also 42, work with 9.1, but not 39 and 41...those are bugfixes for 8.2". This seems silly to me. Just say versions 4.x and 5.x work with 8.2 and 6.x works with 9.1. This also makes displaying multiple versions (activity "threads") possible in the OS. Otherwise how can we reasonable sort/group the activities in any way that makes sense? - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
2008/7/14 Eben Eliason <[EMAIL PROTECTED]>: > There was an extensive discussion on this topic a while back on IRC, which I > unfortunately don't have a record of. There was also mention of this in the > mailing lists not too long ago, initiated by > Morgan: http://lists.laptop.org/pipermail/sugar/2008-May/005895.html. > Finally, I brought this up at the end of a recent tech team meeting (1 or 2 > weeks ago?) as a topic that needed our attention in order to make the > update/upgrade system work (specifically, regarding the need for minor > versions so that we can make bugfixes to older versions of an activity (say, > 4.x) while keeping 5.x for all versions that work with the next version of > the OS). I think deciding how we version activities is a critical part of > making our OS releases work, and can assist in the problem of answering > "Which activities work with my release?". Answering 4.x is nicer than [34 - > 42], and MUCH nicer than [36-38, 40, 42]. > The "agreement" I speak of was really a lack of any voiced disagreement when > I mentioned this issue at the meeting. >From extensive auditing of current activity version numbers: a) a large number of activities are using completely random and bogus strings for their version numbers. "Just an integer" is about the simplest possible scheme, and people still don't get it. I'm unconvinced that any more complicated scheme will work better. b) There is an alternative mechanism already in place for handling dependencies on specific versions, documented in the [[Activity bundles]] entry for 'update_url'. Basically, you can specify a different version number as appropriate based on the current OS build, release version, and release major version. So you can say, "version 8 if you are using 8.1, or version 9 if you are using 8.2". A dotted integer scheme would let you "make space" between 8 and 9 if needed, but there is no technical reason why you couldn't update the activity info later to say, "version 10 if you are using 8.1, or version 11 if you are using 8.2". It's not quite as pretty, but the goal was to keep the activity bundle information as simple as possible, and there is no *technical* reason we need to complicate it. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 05:36:44AM -0400, Brian Jordan wrote: > On Mon, Jul 14, 2008 at 12:06 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > > > > I like Brian's idea but felt similarly about the difficulty in deciding > > which hand button executes which function. SHIFT-HAND is a good > > solution, and relatively easy to implement. > > Agreed, SHIFT-HAND +1 > > UI wise, will there be a way to distinguish between SHIFT-HAND and a > regular click? For example, in Physics, I can imagine having > SHIFT-HAND move objects around even if a non-grab tool is selected. > I think it would be possible at the price of a degree of software complexity. We would probably have to modify the keyhandler to issue some kind of signal about the grab state. Your application would have to listen for that signal. I suspect there is a way to manage this at your client application's level. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity versioning schema
There was an extensive discussion on this topic a while back on IRC, which I unfortunately don't have a record of. There was also mention of this in the mailing lists not too long ago, initiated by Morgan: http://lists.laptop.org/pipermail/sugar/2008-May/005895.html. Finally, I brought this up at the end of a recent tech team meeting (1 or 2 weeks ago?) as a topic that needed our attention in order to make the update/upgrade system work (specifically, regarding the need for minor versions so that we can make bugfixes to older versions of an activity (say, 4.x) while keeping 5.x for all versions that work with the next version of the OS). I think deciding how we version activities is a critical part of making our OS releases work, and can assist in the problem of answering "Which activities work with my release?". Answering 4.x is nicer than [34 - 42], and MUCH nicer than [36-38, 40, 42]. The "agreement" I speak of was really a lack of any voiced disagreement when I mentioned this issue at the meeting. - Eben On Sat, Jul 12, 2008 at 10:52 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > That's true, however I think it's also been agreed that... > > Could you please cite the discussion leading up to the agreement you're > referring to? > > Thanks, > > Michael > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] info about my GSoC project
Hi, If you're interested in software for teaching children handwriting (didactic handwriting), you can download it at http://code.google.com/p/olpc-dhw/ or to look at my GSoC blog: http://olpc-dhw.blogspot.com/ -- Julka Juliana Lipkova web: http://ksp.sk/~julka ICQ: 292350370 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC-Games] Physics -- Newtonian mechanics.. for kids!
On Sat, Jul 12, 2008 at 4:21 PM, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: > At Thu, 10 Jul 2008 16:58:32 -0700, > Edward Cherlin wrote: >> >> On Thu, Jul 10, 2008 at 4:20 PM, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: >> >> So we could simulate a pendulum or a Newton's cradle? How do you >> >> handle collisions? >> > >> > A pendulum for sure, but my version of three pendulums putting >> > together doesn't show the expected behavior. The elasticity isn't >> > right for it, it seems. >> >> What does it do? Can you get it to tell you what values of momentum >> and energy are passed through from balls 1-->2-->3? > > Heh, of course you can try by yourself. But if you put a circle on > the floor (stand still), and make another hit from the side, the > momentum is shared by these two circles and both of them move together > at the same speed. > >> Have you tried two pendula hanging from a horizontal string? Do you >> get the expected transfer of energy back and forth? > > Yes, but no. I'm not sure what you mean by a horizontal string, but > the string I made is not flexible enough to make it happen. > > Speaking of examples, the screenshots at > http://wiki.laptop.org/go/Physics_(activity) aren't exactly something > I found "physics-y"; these are more like story telling in picture > books. I made some examples (two pendula and a mesh, I did an arch > but it is gone). These might catch more attention from teachers and > educators. Yoshiki, This gave me an idea... Just after adding motors to the most recent version of Physics (too fun), I took a BULB-exposure shot of Physics in motion on my camera. Here is the result: http://wiki.laptop.org/go/Image:Housegolf.jpg Neat! Thanks, Brian > > -- Yoshiki > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] profile information
On Mon, Jul 14, 2008 at 12:22 AM, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]> wrote: > Hi, > > Is it possible for Sugar users to have an extensible profile? Currently, > this only encompasses nickname and colors, but are there plans to extend > this somehow? > > I propose using a dictionary to represent an extensible list of > key/value pairs, some of which will be mandatory, like nickname, colors, > key (countries may want to enforce other mandatory fields, like grade, > class etc). This dictionary would be loaded from storage on boot and > saved on every change. Absolutely, I hope to have this as well. I also hope to take it one step further and expose a similar key:value mapping in Journal entries (in the detail view). For instance, in the future when we have a "you made a friend" entry, this entry can contain fields for name, age, grade, phone, address, etc. Activities could also, via some API, choose to expose specific metadata keys for entries they create, and perhaps indicate whether they are writable (by the kids) or not. A song composed in Tam Tam might expose the composer and the duration, etc. I think such a system would go a long way to making the Journal useful, both since it makes the details view customizable based on the type of object in question, and because it exposes useful metadata directly to the user for informational purposes and also so they know what parameters they can search on in the future. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
marco pesenti gritti wrote: > On Thu, Jul 10, 2008 at 8:39 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > > Sugar devs: > > > > This is a copy of my bug report for #447. I have completed a first pass > > of the grab key implementation. > > Have you considered implementing this at the X level? If so, why did > you decide to go for a Sugar specific solution? I have no idea if/how > that's possible but I see that the synaptic driver has a > TwoFingerScrolling option and I've seen something similar for > thinkpads a while ago. for thinkpads? do tell? i'd love to be able to scroll using the eraserhead thing -- along with ALT, maybe. actually, any scrolling accelerator would be welcome. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride shutdown flaky
On Mon, 2008-07-14 at 11:27 +0200, Tomeu Vizoso wrote: > On Sun, Jul 13, 2008 at 10:03 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > > Running recent Joyride on my G1G1. When I request a shutdown, it > > sometimes proceeds "hands off". But sometimes, after the Sugar > > shell has closed - nothing further seems to happen. On those > > occasions, sometimes the ending-picture (with the "don't do this" > > icons) is presented if I press alt-ctl-F2 (the Sugar shell was on > > alt-ctl-F3). If I can get to the ending picture, the shutdown > > completes by itself after what seems like a LONG time. But if I > > don't get to the ending picture, I'm left to complete the shutdown > > process by holding down the power button for more than four seconds. > > Hi, this is http://dev.laptop.org/ticket/7350 , AFAICS. I disagree. #7350 just makes the shutdown menu item appear to do nothing. In this case the shutdown process is clearly started. I think I have seen the issue too. Mikus, can you please file a trac ticket? Thanks, Daniel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride shutdown flaky
>> Running recent Joyride on my G1G1. When I request a shutdown, it >> sometimes proceeds "hands off". But sometimes, after the Sugar >> shell has closed - nothing further seems to happen. On those >> occasions, sometimes the ending-picture (with the "don't do this" >> icons) is presented if I press alt-ctl-F2 (the Sugar shell was on >> alt-ctl-F3). If I can get to the ending picture, the shutdown >> completes by itself after what seems like a LONG time. But if I >> don't get to the ending picture, I'm left to complete the shutdown >> process by holding down the power button for more than four seconds. > > Hi, this is http://dev.laptop.org/ticket/7350 , AFAICS. I believe I've seen this problem while PolicyKit-0.8-2.fc9.i386 was installed on my system. I'm o.k. if #7350 fixes this problem. But the initial #7350 description talks about "can't shutdown .. if multiple sessions". I normally don't use the text console, and I clicked on 'Shutdown' in the Home view -- so I think I've had this problem even when I did not have "multiple sessions". [Also, the initial #7350 description does not talk about seeing the ending picture on ctl-alt-F2 instead of on ctl-alt-F3.] mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Reviews report
= New requests = The intro screen should be RTL in RTL locales http://dev.laptop.org/ticket/3108 = Approved requests = Battery indicator's icon fullness inconsistent with indicator %. http://dev.laptop.org/ticket/4208 Object chooser has wrong icon for 'cancel' http://dev.laptop.org/ticket/7482 Order control panel modules logically http://dev.laptop.org/ticket/7476 Closing an activity reenters the activity launch splash for another running activity http://dev.laptop.org/ticket/7354 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 12:06 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Sun, Jul 13, 2008 at 11:19:46AM -0400, Eben Eliason wrote: >> On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan <[EMAIL PROTECTED]> wrote: >> > Brilliant work, Erik! I had a chance to play with your first working >> > hand scroll, and it's beyond explanation how fun it is to be able to >> > scroll around using the touchpad without aiming for a gtkScrollBar. >> >> Great to hear! I can't wait to give it a try myself...it's been a >> long time in coming. >> > > I'll give you a demo tomorrow. > >> > For all to consider: there are two grab buttons. What if one tended to >> > grab + move *objects*, and the other grabs + moves >> > *scenes/backgrounds*? From what I've heard, kids tend to have a hard >> > time left-clicking and dragging with their same hand (as with the >> > touchpad). So, for applications like Browse, both grab buttons could >> > still just scroll up/down. But for graphical editors (e.g., layout >> > programs, Physics, Model, anything with a scene and objects), this UI >> > behavior may be a real time saver and fun to use. This would require >> > giving applications the ability to process events from these two >> > scroll buttons in a way that identifies them separately. >> >> That's an interesting idea. However, the reason there are two keys is >> so that interaction works well for both left- and right-handed users, >> without the need for them to cross their arms to scroll around. What >> we might be able to do, though, is map an SHIFT-HAND shortcut to a >> drag/drop action instead. (I suggest shift because it's the only >> modified which is present on both sides of our keyboard, for the same >> reason as above.) >> > > I like Brian's idea but felt similarly about the difficulty in deciding > which hand button executes which function. SHIFT-HAND is a good > solution, and relatively easy to implement. Agreed, SHIFT-HAND +1 UI wise, will there be a way to distinguish between SHIFT-HAND and a regular click? For example, in Physics, I can imagine having SHIFT-HAND move objects around even if a non-grab tool is selected. > >> To make that work well, I think we'll need to manage the display of >> the cursor appropriately. perhaps we can use the >> horizontal/vertical/fleur arrows to indicate scrolling options, switch >> to the open hand when shift is pressed to indicate drag mode, and >> switch to a closed hand after a drag has been started. >> People always did enjoy the open/closed hand of Adobe Reader. :) I think this is a fantastic idea. > > How is the cursor pixmap currently set? Is there an existing function > in the sugar codebase to set the cursor pixmap? > > Erik > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Drop activity launch limitation?
On Mon, Jul 14, 2008 at 4:54 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > > Yeah, I'm unsatisfied, too. Perhaps we can shorten the interval, but > better than that we should be actively attempting to detect failure > (how can we do this?) so that when a launch fails "hard" for some > reason, we can immediately indicate that. I think that many (most?) windows have a property that indicates the pid of the owner process. Perhaps we could check for those windows every X seconds during launch if that process still exists? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Drop activity launch limitation?
On Mon, Jul 14, 2008 at 11:29 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 12:32 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> Hello, >> >> we have logic in the shell to limit launching activity of the same >> type at the same time (i.e. before the first activity launch has been >> completed). It seem to be that this is obsoleted by the new launch >> feedback. Should we drop it? > > +1 Although I would add a 0.5s. timer so that double clicking doesn't > result in two launches. Are you actually able to start two activities with double click? The view switch seems to already take care of that... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Drop activity launch limitation?
On Mon, Jul 14, 2008 at 12:32 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > Hello, > > we have logic in the shell to limit launching activity of the same > type at the same time (i.e. before the first activity launch has been > completed). It seem to be that this is obsoleted by the new launch > feedback. Should we drop it? +1 Although I would add a 0.5s. timer so that double clicking doesn't result in two launches. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride shutdown flaky
On Sun, Jul 13, 2008 at 10:03 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > Running recent Joyride on my G1G1. When I request a shutdown, it > sometimes proceeds "hands off". But sometimes, after the Sugar > shell has closed - nothing further seems to happen. On those > occasions, sometimes the ending-picture (with the "don't do this" > icons) is presented if I press alt-ctl-F2 (the Sugar shell was on > alt-ctl-F3). If I can get to the ending picture, the shutdown > completes by itself after what seems like a LONG time. But if I > don't get to the ending picture, I'm left to complete the shutdown > process by holding down the power button for more than four seconds. Hi, this is http://dev.laptop.org/ticket/7350 , AFAICS. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 6:06 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > How is the cursor pixmap currently set? Is there an existing function > in the sugar codebase to set the cursor pixmap? No, we just use the gdk functions. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
