[sugar] Presence Service D-Bus API

2008-07-14 Thread Bert Freudenberg
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

2008-07-14 Thread Mikus Grinbergs
 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

2008-07-14 Thread David Farning
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

2008-07-14 Thread Walter Bender
=== 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

2008-07-14 Thread Martin Langhoff
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

2008-07-14 Thread Jameson "Chema" Quinn
-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

2008-07-14 Thread Benjamin M. Schwartz
-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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread Marco Pesenti Gritti
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

2008-07-14 Thread Benjamin M. Schwartz
-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

2008-07-14 Thread Jameson "Chema" Quinn
> 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

2008-07-14 Thread Jameson "Chema" Quinn
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

2008-07-14 Thread Benjamin M. Schwartz
-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

2008-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Martin Langhoff
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

2008-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread Jameson "Chema" Quinn
> 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

2008-07-14 Thread Michael Stone
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

2008-07-14 Thread Michael Stone
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

2008-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread Mikus Grinbergs
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Michael Stone
> 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

2008-07-14 Thread David Van Assche
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

2008-07-14 Thread Eben Eliason
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-07-14 Thread C. Scott Ananian
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

2008-07-14 Thread Erik Garrison
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread Julka Lipkova

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!

2008-07-14 Thread Brian Jordan
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

2008-07-14 Thread Eben Eliason
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

2008-07-14 Thread pgf
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

2008-07-14 Thread Daniel Drake
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

2008-07-14 Thread Mikus Grinbergs
>> 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

2008-07-14 Thread Release Team
= 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

2008-07-14 Thread Brian Jordan
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?

2008-07-14 Thread Tomeu Vizoso
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?

2008-07-14 Thread Marco Pesenti Gritti
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?

2008-07-14 Thread Tomeu Vizoso
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

2008-07-14 Thread Tomeu Vizoso
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

2008-07-14 Thread Marco Pesenti Gritti
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