Re: [Sugar-devel] xephyr error on Fedora 16

[Michael Stone]

On Thu, 15 Mar 2012 at 11:08:51 -0300, Manuel Kaufmann humi...@gmail.com 
wrote:


Hello,

After compiling sugar with jhbuild in Fedora 16, I'm tryin to run the
emulator but I'm getting this error:

Failed to start server. Please check output above for any message

A window appears and dissappears twice with the title Sugar in a
window and then this:

 * http://www.diigo.com/item/image/1msf9/rojc?size=o

I'm running Fedora 16 inside a VM with QEMU (kvm).

Do you know what's happening here and how to solve it?


Manuel (and other folks CC'ed),

Based on your screenshot and the fact that you're running Xephyr inside KVM, I
suspect that you're running into the (still open!) Xephyr-in-KVM-segfault bug:

  https://bugs.freedesktop.org/show_bug.cgi?id=32765

in its Fedora form:

  https://bugzilla.redhat.com/show_bug.cgi?id=518960

If I'm right, then you can probably fix the segfault you're seeing with a patch
similar to the one attached to the second ticket.

As for getting this fixed upstream:

  @Matthew: according to bugs.fd.o, #32765 is assigned to you. Are you in fact
the right owner for this ticket?

  @Keith: in http://patchwork.freedesktop.org/patch/1327/, you asked Ajax for a
tweak to his patch. Could you please spell out a little bit more explicitly
what changes are needed, e.g., for those of us who are not yet expert X
hackers but who might nevertheless be able to rebase, tweak, and test the
patch...?

  @others -- I've added you to the CC list since you've all been previously
involved in conversations about this bug...

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Reflect internet connectivity in the 'Network' frame icon

[Michael Stone]

On Mon, 14 Feb 2011 at 10:12:40 -0500, Martin Langhoff 
martin.langh...@gmail.com wrote:

On Sun, Feb 13, 2011 at 8:59 PM, Michael Stone mich...@laptop.org wrote:

So what network affordances [1, 2] are we supposed to make discoverable? :)


Martin,

I don't want to hijack any threads this month, so, if the following isn't worth
your time, please ignore it and move on to more pressing matters.

Let's not get too academic. 


FYI, this remark stings rather more than I think you intended. Perhaps you
have a constructive criticism to substitute?


Reading back the thread:

 - can we reach the internet? (or it might be a controlled WAN)
 - can we reach an XS?

In both cases, ping + HEAD can work. 


No argument that ping + HEAD are useful and usefully cheap. Frankly, for the
two cases you mention above, HEAD alone should suffice.


Keep it simple, this is for a simple, low cost (cognitive _and_
computer-resources wise) indicator.


Anish started a thread with a [DESIGN] tag. I took that to mean, in part, that
he wanted feedback about the interplay of his idea with the Sugar HIG and the
broader intended Sugar UX and I tried to recast the discussion in those terms. 


To that end, I asked whether the goal of the network UI is to reassure people
whose network is already working or to help people whose network is broken,
e.g., by making the tools for diagnosing the failure more discoverable. I also
tried to provide sufficient detail to establish the feasibility of both
approaches and to support robust and concrete debate. 


Finally, regarding your keep it simple comment above: what do you know that I
don't that convinces you that all of the above is a waste of time?

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Reflect internet connectivity in the 'Network' frame icon

[Michael Stone]

On Thu, 10 Feb 2011 at 12:46:18 -0300, Anish Mangal an...@activitycentral.org 
wrote:

Hi,

Currently, the 'network' icon on the frame tells us whether we're
connected to a network or not. Would it make sense for it to test for
internet connectivity and maybe reflect that by displaying a small
globe overlaid on the 'Network' icon?


Folks,

Speaking as someone who has spent a fair bit of time thinking through a few of
the narrow technical issues [1], I'd like to gently suggest that we might get
better design ideas from our design team if we focused a bit more on the core
UI problem before diving into a long thread on the relative merits of HTTP vs.
ICMP sensors. 


Therefore, with this gentle suggestion in mind, what do you all think of the
following design thesis:

  The Sugar UI should make network health discoverable.

In particular, is this the core issue?

If so, what kinds of affordances does it suggest?

If not, then what, in your words, is the core issue?

Regards,

Michael

[1]: http://wiki.laptop.org/go/Network2/Paper#Self-Test_Algorithm
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Reflect internet connectivity in the 'Network' frame icon

[Michael Stone]

On Sun, 13 Feb 2011 at 19:41:32 -0500, Martin Langhoff 
martin.langh...@gmail.com wrote:

On Sun, Feb 13, 2011 at 6:38 PM, Michael Stone mich...@laptop.org wrote:
 The Sugar UI should make network health discoverable.

Good point in general. 


(Thanks! :)


To what is trying to get solved, I'd word it as Sugar UI should make network
_affordances_ discoverable.


So what network affordances [1, 2] are we supposed to make discoverable? :)

In particular: 


  a) are we trying to expose affordances that are useful when the network is
 working perfectly or are we more interested in making discoverable those
 affordances that will be useful when things are broken?

  b) are we more interested in making indicators (whose status is automatically
 updated) or in sensors that can be activated to learn about the world?


We can get a rough initial version with a ping to 'schoolserver', and
a ping to a configurable internet host.


For the sake of concreteness, here are some examples of how these
considerations might affect Anish's general idea:

  1) Let's make an autonomous binary internet indicator to be displayed on
  the frame and in the network-view. 
  
  The sensor driving the indicator will periodically make HTTP HEAD requests at

  a deployment-configured rate against a URL chosen uniformly at random from a
  deployment-configured list.
  
  The indicator will be happy when the most recent request succeeded with

  status code 200 and will be sad otherwise.

  2) Let's make a three-state autonomous indicator to be displayed on the frame
  and in the network view.

  The sensor driving the indicator will periodically run a complete network
  diagnostic procedure which, at a minimum, checks that we:
  
1) have a network interface,

2) that is up,
3) with an IP address, 
4) that the interface IP is pingable

5) with default route configured
6) that the default route is pingable
7) with a nameserver entry in resolv.conf
8) that is pingable
9) that successfully resolves a list of test addresses
10) such that the resolved IPs are pingable
11) such that there are HTTP servers running on port 80 on the IPs returned
from a configured subset of the resolved names that that return status
code 200 for HTTP 1.0 HEAD requests for url /

  The indicator will be happy if all tests past in the most recent test run.

  The indicator will be sad if any hard tests failed.

  The indicator will be worried if all hard tests passed but some soft tests
  failed.

  If the indicator is sad or worried, then hovering or clicking on the
  indicator will display a modal dialog or palette listing all tests, showing
  their pass/fail status, and showing folded blocks of logs for all tests.
  
Thoughts?


Michael

[1]: As background, I'm going to assume that an affordance is a quality of
 an object, or an environment, that allows an individual to perform an
 action (http://en.wikipedia.org/wiki/Affordance). Please correct me if
 you prefer a different definition.

[2]: For example, are all these opportunities included?

   * to join a shared activity
   * to send an object to a friend
   * to store or to load a backup and
   * to browse the web
 
 How about these?
 
   * to join #sugar-devel

   * to host a web page
   * to copy an activity from a friend's journal
 
 Or these?
 
   * to ping a default route?

   * to resolve names to IP addresses?
   * to send IP packets to and to receive packets from public IPs?
   * to communicate without interference from middlepeople?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Sugar] Extend sugar-launch with more options

[Michael Stone]

Gentlefolks,

Here are some brief thoughts for you.


Martin:
Any good reason to not include it? :)


@Martin: The gains sure seem to me to out-weigh the costs.


Sascha:
Yes, there is: It encourages activity authors to start other activities
from within their own activities, exactly like you're going to do. 


@Sascha: Thereby affording a better learning experience than is available
today?


Sascha:
We shouldn't give them easy access to functionality that we already know
will stop working in the future.


@Sascha: I'm not as sure as you are that this functionality will stop working
in the future. I am, however, considerably more sure that Martin's change would
be of educational value in the meantime.


Sascha, responding to his recap of Martin's goal:

Launching activities from within another activity won't work on
Rainbow-enabled systems (by design). 


@all:

Remember that the goal of Bitfrost is to prevent software from doing bad
things like damaging the machine, compromising privacy, damaging the
user's data, doing bad things to other people, and impersonating the user,
all in the service of making computers that are better things to think with
than were previously available. 


Given this background, what reason is there to prevent a Podcast activity from
using Browse to implement a publication and search UI while simultaneously
using Record to capture its recordings? The important point is just that
Podcast shouldn't be able to delete all my documents.

Similiarly, what reason is there to prevent Arithmetic from launching Wikipedia
through clickable links associated with each mathematical operation for which
Arithmetic implements puzzles? Again, there's no reason to prevent this useful
interoperation of software written by separate people. The real goal is just to
prevent Arithmetic from being turned into a spambot by the new puzzle
algorithm that Bernie shared with me.


Gary:
Well, it is a common UI in other operating systems, so I would not
specifically call this out as poor from a UI stand point. 


@Gary: 


The fashion in which it is poor is that, in implementations to date, it gives
the operating system little or no information about what ambient authority the
human operator actually wants to delegate to the software being launched. 


As a result, most of these other operating systems are widely regarded as being
utterly unsafe for use as platforms on which to try out unvetted code such as
might be produced by mischievous youngsters like the ones who grew up to be,
well, us. :)


Gary:
There have been many long threads about this in the past, with folks wanting
to launch activities from each other (common case cited is having lesson
plan documents of some kind, that can launch the related activities as you
work through them). 


@Gary: Please count me among them:

  http://www.youtube.com/user/cscottdotnet#p/u/32/6k5MtEJ3Osc

Gary: 
However, in the discussions I remember, all of them hit the issue of

breaching Rainbow and its desired security model.


@Gary: Rainbow is just a tool for setting up fences. It's up to the UI to
figure out, based on the user's actions, what fences need to be set up.
Currently, that part is what isn't working so well. 


(...well, that and the fact that we have no trustworthy supervisors which which
to implement the fences.)

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] tracking CTRL and ALT keys in a sugar activity

[Michael Stone]

On Fri, Dec 17, 2010 at 4:48 PM, Erik Blankinship er...@mediamods.com wrote:

On Fri, Dec 17, 2010 at 4:52 PM, Walter Bender walter.ben...@gmail.comwrote:

On Fri, Dec 17, 2010 at 4:48 PM, Erik Blankinship er...@mediamods.com wrote:

I would like to know when CTRL or ALT are being pressed in my sugar
activity. To be complete, I would need to know if they are pressed when
the activity regains focus (e.g. changing activities or if the focus was in
a textfield).

I am not sure of the right way to do this. My current thinking is to keep a
dictionary with CTRL_L, CTRL_R, ALT_L, and ALT_R key states which are
updated on key-press and key-release events.

But this model breaks as soon the application loses focus and the user
releases one of those keys -- I would never know when there is a mouse-up.
My workaround is to clear the dictionary when the application loses focus. 
I can also attempt to update the dictionary when there are mouse events by

skimming information from these events regarding CTRL and ALT modifiers.

Is this a good approach? Maybe I am missing something obvious?


Maybe I am misunderstanding the complexity of what you are trying to
do...


I want to change my cursor into a magicwand whenever CTRL or ALT are held
down, and when none of them are pressed, I want to change my cursor into the
system pointer.  I do not want someone to cheat by switching out of the
activity with CTRL down and return with my activity thinking CTRL is still
down.


don't you simply check the mode mask when you get a keyboard event to
determine whether or not Alt or Ctrl is pressed?


Thank you!  Yes, I can do that while the activity is running.  That sure
makes things simpler while the activity has focus.

But to determine if CTRL or ALT are pressed when returning to the activity?  


I am not sure what signal to listen to that would have the correct mode mask.


Erik,

I'm not sure how to get to these data from GTK and Python but I do know that
you want X's KeymapNotify event and XQueryKeymap() query:

  http://www.sbin.org/doc/Xlib/chapt_09.html

Perhaps with this hint, someone else on the list can help you further.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar UI Dictator

[Michael Stone]

On Wed, 24 Nov 2010 at 10:43:24 -0500, C. Scott wrote:

On Wed, Nov 24, 2010 at 1:37 AM, Michael Stone mich...@laptop.org wrote:

That reduces time commitment without diluting buck-stopping
responsibility.


A committee-of-three with people like Gary, Martin, and Walter on it will
have adequate buck-stopping capacity, no?


I think that it is possible that a committee of three will actually
get less accomplished (and less coherently) than one
person-who-really-doesn't-have-time.


You're right that it's a risk... but isn't it a lesser risk than the risk of
failing to find an appropriate rock star? 


(...unless you've got someone in mind who I've overlooked?)


I'm suggesting that you work on reducing the time commitment


And I have been, by doing what I can to prune the responsibilities of the job
and by making sure to leave the committee members free to decide their own ways
and means. 


(That is, if they decide that the right way to do the job is to try a merge
window for HIG changes, to delegate to lieutenants, or to _, then they
Decide to do it and we'll find out whether or not it works.)


rather than dilute the responsibility.


Relative to the current situation, my proposal greatly concentrates the
responsibility *and* lays the groundwork for a proper dispute-resolution
mechanism.


I like and respect Gary, Martin, and Walter, and I think I'd have no
trouble convincing them of any UI change I'd wish to make.


I know a simple way to test. :)

More seriously though, it seems that several of your concerns revolve around
ways in which the system I'm proposing might fail to make good decisions due to
inefficiency, overload, suasion, or other environmental factors. 


Would it help if we built some kind of big red button into the process like
the ones famously installed by Toyota to permit their workers to halt the
assembly line when they find defects?


Failing a good candidate, I think do no harm should be the motto --
concentrate on the (many!) design-related tasks which *don't* involve
making design decisions.  


Unfortunately, failing to make the decisions that need to be made *is* doing
harm. That's why Bernie asked for a dictator.

I think a self-appointed Design Dictator Committee 


Not self-appointed -- appointed by the Oversight Board. 


(You and I are just discussing candidates who we like, trying to convince
ourselves that success is possible.)


composed entirely of developers


Gary and Walter are not primarily developers. Nor are Eben and Christian, who I
would expect to provide regular expert testimony.


some who may well have written portions of the patches under review, can
easily do more harm than good.


See above about the big red button idea. Would it help here?


I'd rather see an all-developer Designer Enablement Committee whose
job was to maintain design docs, collect issues for review, and
generally make it possible to have a productive one-hour once-a-month
design review meeting with the best *designers* we could get to do it.
(Or once-a-release-cycle, as Christoph would have it.)


The two ideas aren't necessarily mutually exclusive. Do you know people who
want to do the job?


If the problem is that the good designers don't have enough time, I
don't think the solution is to use whoever we can find who has the
time.


Agreed -- but Gary, Martin, and Walter aren't whoever and they're aren't
being suggested because they're rolling in free time -- they haven't got it
either. What they do have (I think!) is the *collective* design skills, the
good-will, and *enough* free time to get the community unstuck and to do more
good than harm in the process.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar UI Dictator

[Michael Stone]

Scott,

Thanks for your thoughts! 


3) I see a little bit of buck-passing going on, as a third-party
observer. It seems like the real reason for a 3-person committee is
that no one wants to actually step up and take on the responsibility
of UX lead. 


Here's the chain of reasoning that leads me to the 3-person committee design:

0. We want help getting UX decisions made and reviving the HIG. We think that
   the benevolent dictator model might work well. However, we're having
   trouble finding the right person to be dictator.
   
1. To be a good UX dictator, you need competence, time, and trust.


2. None of the people who have adequate competence and trust to be dictator
   (i.e., Eben) have the time to do the job.

3. However, we have a small number of people (Gary, Martin, Walter, Eben, and
   Christian) all of whom have a few quanta of time, are well-regarded, are
   able to work together, and have relevant skills and aptitudes.

4. Since none of the available people can do the whole job alone, we have to
   find some way to divide the job up among them.

5. A three-person group seems like the smallest, most lightweight, most agile
   arrangement of people that could work. 


Thus, what you call buck-passing, I call recognition of the human and
political realities of the moment.


Unfortunately, lack of clearly defined responsibility is
the crux of the problem you're trying to solve, so I'm not certain
that splitting the horcrux is part of the solution.


As above, committee-of-three just seems (to me, anyway) like the most
likely-to-succeed way to implement the clearly defined authority part.

(Again, I'd vote for single dictator too if I could think of someone
appropriate to elect.)

Maybe it would be help to identify a single dictator and lieutenants 


Lieutenants are a good idea regardless. 


(rather than the committee-of-3) with hat-passing as necessary -- so, for
example, we can have 4 (!) design leads, but each one is ultimate dictator
for one week a month. 


Do remember that continuity of design is also a goal. :)


That reduces time commitment without diluting buck-stopping responsibility.


A committee-of-three with people like Gary, Martin, and Walter on it will have
adequate buck-stopping capacity, no?

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar UI Dictator

[Michael Stone]

On Sat, 20 Nov 2010 at 09:32:53 +, Martin Dengler wrote:

On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote:

P.S. - Later [...] we discovered a confusion about the mandate of
the proposed committee; to wit:

  Is the main purpose of the committee to act as a UI Maintainer (e.g., by
  deciding which UI-related patches to merge) or is the main purpose of the
  committee to make UI-related decisions on an as-requested basis?


I think it is both act as maintainer and make UI-related decisions.


@Martin -- Choosing both seems like a bad idea to me because it:

  a) balloons the scope of the problem to be solved,
  b) shrinks the population of qualified participants, and
  c) seems likely to cause turf wars.

Instead, I would prefer to stay focused on the need for UI-decision-making that
Bernie identified in his initial email.


It seems we're re-invented the Design Team.  I spoke with Gary Martin and
Bernie and, despite having lost the logs of my conversation with Gary, my
hazy recollection is that that they also came to this conclusion.


Re-invented is a rather ambiguous term. If you mean defined the scope of,
winnowed the membership of, empowered, and sought concrete commitments from...
then perhaps we agree. If you mean something else, then perhaps you should be
more explicit.


With that in mind, I think we should just have more people actively
participate in the design team.  I'm interested, so have put my name
down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members
I hope anyone else interested in being active, will do the same.
Michael Stone, Bernie Innocenti, I'm looking at you.

Gary, can you add / correct anything from our conversation?

Michael, is there anything I've misunderstood/misremembered about your
proposal?  Would you want the Design Team to adopt your what does the
committee do[1] responsibilities?


I care about the substance, not the name: the UI committee that I'm describing
has a fixed membership, offers a service-level agreement, and is answerable to
the Oversight Board. In short, it is *designed* to meet Bernie's need for
competent, respected, decisive, and dependable UI decision-making.  Does the
Design Team that you, Gary, and Bernie are thinking of share these properties?

---

On Sat, 20 Nov 2010 at 08:42:42 -0500, Walter Bender wrote:
I mostly kind of agree with this. 


@Walter -- I'm not sure what this refers to.


But adding a bunch of developers to the design team will not help it
accomplish its design goals.


Two comments:

  1. I don't see a bunch of developers; I see specific people (Gary, Martin,
 Eben, Christian, Bernie, ...) with specific talents, predispositions, and
 availabilities. 


  2. Of the available choices, who would you be most comfortable empowering?

We need more designers involved. 


What is your plan for getting them involved?

(My plan, such as it is, is:

  a) to make a place where they will want to come and

  b) to develop the pre-existing skills and sensibilities of the people we
 already have)


And we need to stay focused on Sugar's core design principles. One thing I do
remember from your IRC discussion with Gary (I was on the edge of the
conversation) is the need to bring the HIG up to date. While this may be
considered tactical, I think it is strategic, in that sets the tone for all
further actions. (For the same reason, I have been advocating for an
architectural document from the Engineering perspective.)


First, I completely agree with you that these are important tasks. 


However, I don't see anyone willing to work on them at this time.

Do you? 

If so, who did I miss? 


If not, why is no one willing to do the work that many people agree is
important?

Might they be unwilling because they don't see how the work can be completed
successfully in the prevailing organizational conditions?

---

On Sat, 20 Nov 2010 at 09:38:57 -0500, Barbara Barry wrote:

As an advocate for Sugar in the field in my work, I'm chiming in to support
Walter's point.

What might help Sugar is a designer who can articulate a strong design point
of view by understanding the needs of the users and translating them, guided
by the Sugar core design principles, into a plan for development.

Design is not a set of isolated decisions about what features to add or take
away but how to move consistently toward a goal, in Sugar's case an OS and
computing environment that can help children as they learn.

Designers have particular skills that are not obvious. Good ones are masters
at modeling the needs of users in astonishing detail and accuracy, and it is
their job to negotiate the terrain between the stated design goals of an
organization, the user experience, and the implementation by developers.

It's not only Apple that has a distinct design point of view but really any

Re: [Sugar-devel] Sugar UI Dictator

[Michael Stone]

On Wed, 10 Nov 2010 at 09:16:41 +, Martin Dengler wrote:

On Tue, Nov 09, 2010 at 12:27:18PM -0500, Michael Stone wrote:

On Tue, 9 Nov 2010 at 03:12:41 +, Martin Dengler wrote:
On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote:
[UX design might be better] if we agreed to delegate all design
decisions to one clever dictator

Great idea.

[...]

[if noone steps forward], perhaps we could just agree
on some group of people who will be the dictators, and not revisit
that for a while.

Agreeing on small group of people seems easy to arrange. Here's a strawman
proposal[1]


Your proposal seems like a good way to do it. I propose another decent way as
an appendix[2]. I welcome someone else implementing either.  


Gentlefolks,

Martin and I talked for bit this evening and I believe that I managed to
persuade him to support my proposal.

Here were the key arguments:

  1. We're currently very vulnerable to diffusion of responsibility.

 Concentrating responsibility in three specific people will help to address
 this problem.

  2. We don't really have a dispute resolution mechanism other than drop it.

 The Oversight Board is ideally positioned to help resolve disputes
 generated by its committees' decisions and procedures.

  3. It's not okay to block patches on feedback or decisions from an absent
 Design Team.

 As with diffusion of responsibility, being explicit about the time frame
 on which decisions will be made will help prevent these patches from
 languishing.

  4. We need to be able to work smoothly with OLPC if and when they succeed in
 hiring a Sugar UX Designer [1].

 Being able to elect said designer to a seat on a previously established
 design committee seems like a potentially good way to involve this person
 in our decision-making while still preserving fairness, transparency, and
 appropriate continuity with the past.

Regards,

Michael

P.S. - Later, after finding our common ground, we spoke further about the
issues that we each hoped the committee might be able to address. In the course
of the conversation, we discovered a confusion about the mandate of the
proposed committee; to wit:

  Is the main purpose of the committee to act as a UI Maintainer (e.g., by
  deciding which UI-related patches to merge) or is the main purpose of the
  committee to make UI-related decisions on an as-requested basis?

[1]: 
http://laptop.org/en/utility/people/opportunities.shtml#Sugar%20UI%20Designer

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar UI Dictator

[Michael Stone]

On Tue, 9 Nov 2010 at 03:12:41 +, Martin Dengler wrote:

On Mon, Nov 08, 2010 at 07:49:19PM -0500, Bernie Innocenti wrote:

On Fri, 2010-10-29 at 10:02 +0100, Martin Dengler wrote:

IMO a decent justification and a willingness to update the affected
wiki pages - including the HIG - to a similar or better standard as
what existed before should almost be enough for me.

What I'm worried about is the HIG that exists - incomplete as it is -
is being chipped away and we're left with UI that's justified by
nothing but a patchwork of ad-hoc decisions made by very different
people with very different users in mind.


While I strongly believe in the power of loosely-managed
volunteer-driven development, distributed authority doesn't seem to work
equally well when it comes to human interface design.

Good design implies one consistent vision, which is hard to obtain
collaboratively. A case-by-case decision process results in either
inconclusive discussions or UI inconsistency.

It might work better if we agreed to delegate all design decisions to
one clever dictator


Great idea.

Sebastian is calling for a HIG update as part of his SLOBs platform -
perhaps the new HIG Dictator should commit to doing that in some fixed
period of time?

Failing one Dictator, erm, seizing power, perhaps we could just agree
on some group of people who will be the dictators, and not revisit
that for a while.


Agreeing on small group of people seems easy to arrange. Here's a strawman
proposal for how that might look: 


  1. Per [1], the Oversight Board creates an ad-hoc 3-person UI Committee.

  2. The initial voting members will be mtd, garycmartin, and  (a third
 person to be determined).

  3. The initial term will be for six months.

Next, there are details that we need to agree upon. For example, what does the
committee do and at what rate does it do it? Another strawman:

  4. The committee will meet as needed in order to address Queries received by
 any of its voting members.

  5. The committee will meet within 2 weeks of receiving a Query.

  6. Proposed Responses will be accepted by the committee by majority vote.

  7. Minutes, received Queries, proposed Responses, and related discussion will
 be archived and organized by the Committee Secretary on the wiki.

Finally, there some harder questions that I don't have easy answers for: 


  a) Who do we expect to do the work of formulating responses to Queries?

  b) How will we make the committee successful and fun? In particular, how do
 we expect to organize the performance of the work that is necessary to
 prepare for and to follow through on the committee's decisions?

 (i.e., who's actually going to go out to collect experience reports,
 to perform user testing, or to develop prototypes when the Committee
 determines that these actions are necessary in order to properly respond
 to a Query?)

  c) What kinds of disputes and/or grievances do we anticipate and how do we
 expect to resolve them?

Thoughts?

Regards,

Michael

[1]: http://wiki.sugarlabs.org/go/Sugar_Labs/Governance#Committees
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Development Meetings

[Michael Stone]

On Wed, Oct 27, 2010 at 16:51:00 + Aleksey Lim wrote:

These are good questions. I personally think that having more formalized
ML discussion (to take core team decisions) will be a huge plus (it is
impossible to take any decision only during a meeting) and not only for
people who prefer email to IRC.

Does anyone have ready to use recipes?


Yes, several. Three outlines that come to mind immediately are:

  1. parliamentary procedure, which James brought up implicitly in his
 comment when he mentioned the words motions and deliberative assembly. 
 (See Robert's Rules.)


  2. consensus, e.g. as exemplified in the IETF processes, which I brought up
 when I mentioned RFCs. (See RFC 2026.)

  3. dictatorship/oligarchy. (See LKML.)

Which are you interested in recipes for?

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Memory leak in Sugar -- how to dump Py data

[Michael Stone]

See http://dev.laptop.org/ticket/10386 for details. The sugar-session
process in 10.1.2 grows slowly...

There's some form of leak somewhere. Maybe we are triggerin a real
python leak, maybe we have reference loops. How do we trace this?


Tomeu wrote some instructions here:

  http://wiki.laptop.org/go/Memory_leak_testing
  http://wiki.sugarlabs.org/go/Development_Team/Memory/Leak_testing  (mirror)

that might be of use to you.

Also, it looks like guppy is now available directly from Fedora, packaged under
the name python-guppy.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Design] Resume/New pie menu menu mockup

[Michael Stone]

Gary C Martin wrote:

 Actually this whole pie concept is starting to feel like a conversation
 Michael Stone started with me off list a year ago :)

I always scatter acorns as I walk so that, one day, we may rest beneath the
shade of mighty oaks.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity packaging

[Michael Stone]

Aleksey wrote:
 On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote:
 Bernie wrote:
 On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote:
  I think you are missing an important requirement: installation without
  elevated permissions.
 
  Rainbow has been bit-rotting for the past 2 years 
 
 Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and 
 still
 received no independent testing despite repeated calls for same.

 To be honest I wasn't a fan of rainbow a bit time ago..

 But having Zero Sugar fully implemented and potential possibility to launch
 almost any piece of software... rainbow should be more then essential
 requirement.

Let's be clear: the actual requirement is for something more like safety or
isolation. 

Rainbow is merely one of several reasonable approaches -- and competition and
interoperability would be no bad thing here.

Michael

P.S. - Several other isolation shells that might be worth thinking about, if
only to better understand the tradeoffs that rainbow makes, are briefly
described at 

   http://sandboxing.org

P.P.S. - Also, either way, thanks for your encouragement. :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH 1/3] Add models for detecting and parsing

[Michael Stone]

  from jarabe.model.network import GSM_USERNAME_PATH, GSM_PASSWORD_PATH, \
  GSM_NUMBER_PATH, GSM_APN_PATH, 
 GSM_PIN_PATH, \
  GSM_PUK_PATH

 +from cpsection.modemconfiguration.config import PROVIDERS_PATH, \
 +PROVIDERS_FORMAT_SUPPORTED, \
 +COUNTRY_CODES_PATH
 +
  def get_username():
 client =3D gconf.client_get_default()
 return client.get_string(GSM_USERNAME_PATH) or ''
 @@ -68,3 +77,103 @@ def set_puk(puk):
 client =3D gconf.client_get_default()
 client.set_string(GSM_PUK_PATH, puk)

 +def has_providers_db():
 +if not os.path.isfile(COUNTRY_CODES_PATH):
 +return False
 +try:
 +tree = ElementTree(file=PROVIDERS_PATH)
 +elem = tree.getroot()
 +if elem is None or elem.get('format') != PROVIDERS_FORMAT_SUPPORTED:
 +return False
 +return True
 +except IOError:
 +return False

 Consider checking for file existence and readability with
 os.access(). 

As a general safety rule, it's better to open the file, catch any errors, and
do any further work via fstat(), openat(), and friends because doing so avoids
some annoying time-of-check-to-time-of-use (TOCTTOU) races without being any
more difficult. However, beware: when designing for a hostile environment, more
care is needed [1].

[1]: http://www.usenix.org/events/fast08/tech/tsafrir.html

 +class CountryListStore(gtk.ListStore):
 +COUNTRY_CODE =3D locale.getdefaultlocale()[0][3:5].lower()
 +
 +def __init__(self):
 +gtk.ListStore.__init__(self, str, object)
 +codes =3D {}
 +with open(COUNTRY_CODES_PATH) as codes_file:

 Using 'with' like that makes us depend on Python 2.6. 

Fortunately, using 'with' with a

   from __future__ import with_statement

import is Python-2.5 compatible.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity packaging

[Michael Stone]

Bernie wrote:
On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote:
 I think you are missing an important requirement: installation without
 elevated permissions.

 XO and SoaS distributions are configured for sudo with no password.

Yes. However, Uruguay does not maintain this configuration choice.

 Rainbow has been bit-rotting for the past 2 years 

Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still
received no independent testing despite repeated calls for same.

Rainbow, on the other hand, has seen a major new release, feature development
that spurred new work in general Linux sandboxing, and is now available in more
distributions than ever before thanks to dedicated support by folks like Luke,
Sascha, and Jonas. 

Finally, if rainbow itself now receives little day-to-day attention, this is
because it mostly does what its authors require and it does it well enough not
to require their continued hand-holding. 

 and nobody volunteered to work on it. 

If you check the dates carefully, you'll find that most of my recent work on
rainbow and rainbow/sugar integration has occurred while I was on vacation from
my real job. So please do count that as volunteer hours.

 The bottom line is that *nowadays*, any activity can escalate root
 privileges.

Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then
we will all rue the day when we had the opportunity to make it safe and chose
not to.

 A non-privileged account can already effectively do anything that a spammer
 would like to do.

And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch?

(Or have you a better approach?)

 Even in a Rainbow-enabled environment, privileged vs unprivileged
 installation isn't by itself the source of security issues. Packages
 could easily be checked to ensure that all bundled files are within a
 specific path, like we currently do with the zip files. Post-install
 scriptlets can be disabled.

I am still much more satisfied with the approach taken by 0install. [2]

Regards,

Michael

[1]: Except by accident, like with GNOME and Sugar today.

[2]: Thanks again, Aleksey, for pushing this work forward and for all the
improvements you've already contributed back to 0install to make this work
better for us!

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Patches to mail list, or patches to trac?

[Michael Stone]

My personal suggestions follow:

 Patches to mail list, or patches to trac?

Use the mailing list to get feedback.

Use Trac to publish histories of work on a theme.

 Personally I read mail in a bunch of different places/devices and there's no
 way I can currently (and sanely) keep track of all the list activity and know
 who suggested what, what was actually agreed, and what is still outstanding.

I read mail all over the place too. Patchwork and the ability to download the
complete sugar-devel archives in mbox form help me keep it all together.

 I've had a few patches and reviews now from kind folk posting to the 
 mail-list,
 but for me, I've ended up having to ask folks to create git clones so I can
 pull in patches in a maintainable work flow.

Like you, I also find 'pull this branch' instructions helpful for testing
purposes. Maybe folks who want their patches to be tested or merged (as well as
read) should be publishing 'pull this branch' instructions or headers?

(NB: When 'pull this branch' instructions aren't available, I use patchwork to
group the patches I'm interested in. Then I download the resulting mbox for use
with git am. This works pretty well.)

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] 0.90 Meeting --- 30. June 2010 (14:00 UTC)

[Michael Stone]

 On Tue, Jun 29, 2010 at 6:17 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
 On Tue, Jun 29, 2010 at 11:43, Bert Freudenberg b...@freudenbergs.de
 wrote:

 On 29.06.2010, at 10:30, Simon Schampijer wrote:

 Hey,

 I would like to do a short developer meeting tomorrow Wednesday
 30.06.2010 at 14:00 UTC in #sugar-meeting (freenode).

 The topic is the upcoming 0.90 release. We will talk about the schedule,
 the focus of the release and any other points that come up regarding the
 release. I have started the draft for 0.90 roadmap [1]. I will work on
 it more later today.

 Have a nice day,
 =A0 =A0 Simon

 [1] http://wiki.sugarlabs.org/go/0.90/Roadmap
 [2] How can I convert UTC into localtime? You can use the command: date
 -d '2010-06-30 14:00 UTC' or one of the many websites offering a
 UTC-service.

 This lists the local time directly:
 http://tinyurl.com/26zgff4

 Unfortunately, I most probably can't attend :(

 What time would be good for you? (And for anybody who is interested in
 attending).

 An hour earlier (13UTC) would be better for me. (or after 17UTC).

13:00 UTC is better for me as a time. Also, email is better for me as a medium.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Make initial DCON unfreeze conditional on the presence of a DCON.

[Michael Stone]

Presently, Sugar tries to unfreeze the XO's secondary display controller (DCON)
regardless of whether or not a DCON is present. This generates unsightly error
messages every time Sugar starts.

To fix the problem, we test for the presence of a DCON following the advice of

   http://wiki.laptop.org/go/DCON_Linux_Driver

by testing for the existence of /sys/devices/platform/dcon.

Cc: David Farning dfarn...@gmail.com
Signed-off-by: Michael Stone mich...@laptop.org
---
  bin/sugar-session |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/bin/sugar-session b/bin/sugar-session
index cc8358c..b4a68cc 100755
--- a/bin/sugar-session
+++ b/bin/sugar-session
@@ -240,7 +240,8 @@ def main():
  
  # this must be added early, so that it executes and unfreezes the screen
  # even when we initially get blocked on the intro screen
-gobject.idle_add(unfreeze_dcon_cb)
+if os.path.exists(/sys/devices/platform/dcon):
+gobject.idle_add(unfreeze_dcon_cb)
  
  intro.check_profile()
  
-- 
1.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RFC] Better disk format for journal entries

[Michael Stone]

 On 27.06.2010, at 05:06, Michael Stone wrote:
 
 Folks,
 
 I've longed, for quite some time, for an encoding of Sugar's journal entries
 that is more amenable to manipulation with standard Linux tools and APIs.
 I've also longed for a format that is friendly to rainbow and which can
 encode both the data necessary for today's journal as well as the data
 necessary for Eben's Journal redesign mockups.
 
 A few days ago, I wrote a little bit about what I think such a format might
 look like over here:
 
   http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024908.html
 
 Unfortunately, this note didn't generate much of a response
 
 Duh! Who would have expected that the actual message went on below the
 top-reply and quote? 

Only someone who knew me and my shy, tentative ways. :)

 I have simply not seen it. Even glancing over it now it did not read like an
 actual proposal.

That's because it was a musing, not a proposal.

 -- thus, to whet
 your appetite further, here's a (rough!) exporter from today's DS into the
 format sketched in that note, available both in the the patch following this
 note and in my combined sugar git repo [1] in the xos branch. 
 
 Already, I find it helpful both for browsing my DS with filesystem tools and
 for resuming activities from the Terminal. 
 
 What cool things can you think of to do with it?
 
 Regards,
 
 Michael
 
 [1]: Links to my sugar git repo:
 
http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos
http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz
git://dev.laptop.org/users/mstone/sugar

 I like the directory layout. Could you explain why you see a need for the
 generality of a custom ./resume script?

I chose this approach mainly, for the sake of encapsulation and ease-of-use
rather than for generality.

Here's what I mean:

   a) if an activity session is represented as directory

 ./Photos+of+Butterflies_1a21458b

  then being focused on such a session corresponds to having a shell whose
  current working directory is the dir in question:

 ~/Photos+of+Butterflies_1a21458b $ ...

   b) if I want to resume the currently focused activity session dir, then there
  are three basic things I can imagine doing:

 1) exec ./resume
 2) exec sugar-resume
 3) use IPC to tell some daemon to do one of the above.
   
  (1) is nicely language-agnostic, direct, and easy to test in isolation of
  other components. however, it is very opaque.

  (2) imposes some helpful consistency on how resumes happen at the cost of
  making it hard to experiment with new ways to implement resume.

  (3) is, in my experience, a pain.

  I picked (1) for my scheme because it seems better suited to my current
  goals. 

Further questions?

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RFC] Better disk format for journal entries

[Michael Stone]

Excerpts from Michael Stone's message of Sun Jun 27 05:06:31 +0200 2010:

 I've longed, for quite some time, for an encoding of Sugar's journal entries
 that is more amenable to manipulation with standard Linux tools and APIs. 
 I've
 also longed for a format that is friendly to rainbow and which can encode 
 both
 the data necessary for today's journal as well as the data necessary for 
 Eben's
 Journal redesign mockups.
 
 If we are to introduce a new transport format for Journal entries, I'd
 much rather have us try to use one that's interoperable with other
 software. 

You and I may simply have different ideas of what other software it is most
important to interoperate with.

For me, the relevant software includes:

ls, cat, head, rm, cp, du, grep, find, rsync, vim, emacs, git, *httpd, and
rainbow

What software are you thinking of?

 During past discussions on this list a few candidates were named
 (I don't have references handy, but the list archives should help locating
 them).

I googled for a bit but couldn't find your references. Could you be more
specific with either search terms or links?

 As for changes to the data model: While the Journal obviously needs to
 change, I believe the current data store to be generic enough to store
 anything we're going to need for now. The object ids are globally unique
 and can thus be used for inter-object references. Actions can be stored
 in metadata-only entries.

I appreciate your skill in encoding a more complex data model into the dark
corners of the current DS API but I have to say that the encoding feels forced
and, so far as I can tell, the resulting human factors still suck. No?

 Already, I find it helpful both for browsing my DS with filesystem tools and
 for resuming activities from the Terminal. 
 
 You might find datastore-fuse [1] useful as well. It's still experimental,
 but works well enough that I use it for transferring attachments from my
 MUA directly to the data store / Journal (which I use for managing photos
 besides other things).
 
 While it's still rather basic, it provides access to the full data store
 content (including metadata as extended attributes) with full
 read/write/delete support (data+metadata).

Thanks for the link.

 What cool things can you think of to do with it?
 [1]: Links to my sugar git repo:
 
 http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos
 http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz
 git://dev.laptop.org/users/mstone/sugar
 
 Could you be convinced to move your repositories to (or duplicate them
 on) git.sugarlabs.org? 

I am far from convinced but, as a favor to you and Bernie, here is

   http://git.sugarlabs.org/projects/sugar/repos/mstone

(and if you keep pestering me, then I might even manage to keep it synced for
you...)

 This is also half of an answer to your mail re. rainbow patches: My
 repo is on my home server which only has a public IPv6 address

This is not a problem: I already have IPv6 access both at home and through
*.laptop.org and I am considerably interested [1] in helping more people to get
it.

 I don't want to create a rainbow project on git.sugarlabs.org myself because
 it might look like the official one.

Sascha, you're as much a rainbow maintainer these days as I am. Therefore,
please go ahead and create it, push your patches to it, and let me know when
you have patches that you want me to look at. Then we'll do a release and we'll
move on to the next set of patches.

Michael

[1]: http://wiki.laptop.org/go/Network2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export

[Michael Stone]

El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribió:

* whose name is URL-encoded with spaces encoded as pluses

 Why pluses? 

Because they're nicer than %20 and python provides urllib.quote_plus?

 Can't we simply leave spaces as spaces?

Have you got a shell that doesn't require me to escape them in order to process
the resulting files?

 Or convert them to '_' and use '~' or ';' as a version separator?

Thanks; I prefer characters which don't need to be shell-escaped.

 I like the idea, but I would also like to see a Journal feature for
 exporting objects to removable volumes without loosing their
 accompanying metadata.

I don't understand this suggestion; could you please rephrase it?

Thanks for your thoughts,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Add ds2xos conversion script to export

[Michael Stone]

Scott wrote:
On Sun, Jun 27, 2010 at 9:53 PM, Michael Stone mich...@laptop.org wrote:
 El Sat, 26-06-2010 a las 23:07 -0400, Michael Stone escribi=C3=B3:

 * whose name is URL-encoded with spaces encoded as pluses

 Why pluses?

 Because they're nicer than %20 and python provides urllib.quote_plus?

 Can't we simply leave spaces as spaces?

 Have you got a shell that doesn't require me to escape them in order to
 process the resulting files?

 Or convert them to '_' and use '~' or ';' as a version separator?

 Thanks; I prefer characters which don't need to be shell-escaped.
 
 FWIW:
 shell will only expand ~ in first position; a~b is fine.
 using ; as a version separator has a long and distinguished history
 (http://en.wikipedia.org/wiki/Files-11)

Good points. Thanks. 

 anyone who hasn't figured out how to use -0 options to grep, xargs,
 find, etc in order to properly handle spaces is living in the past

Null-separation works well with find and xargs and not-so-well with pretty much
everything else, no?

 filenames in spanish will look terrible with %-escapes for 

I've been thinking about this for a while but I don't see any easy solutions.
(Other than saying screw it; let's go with Plan 9...)

Is this:

   http://tools.ietf.org/html/rfc3987

still your recommended reading?

 anyway, and utf-8 is not reliable on FAT (sigh).  if you can get
 people to format their USB sticks with NTFS, whose kernel support is
 pretty good, you can use utf-16 and a much smallest set of bad
 codepoints.

My main goal was to produce directory names that are 

   a) fully determined by the activity metadata, 
   b) vaguely human readable, and 
   c) shell-friendly 

from whatever crap I'm handed. 

My further thought was that smarter viewers like the Journal would use the
authoritative data in the .xos/metadata.json to figure out how to render the
session.

Regards, and thanks very much for your comments,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RFC] Better disk format for journal entries

[Michael Stone]

Folks,

I've longed, for quite some time, for an encoding of Sugar's journal entries
that is more amenable to manipulation with standard Linux tools and APIs. I've
also longed for a format that is friendly to rainbow and which can encode both
the data necessary for today's journal as well as the data necessary for Eben's
Journal redesign mockups.

A few days ago, I wrote a little bit about what I think such a format might
look like over here:

   http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024908.html

Unfortunately, this note didn't generate much of a response -- thus, to whet
your appetite further, here's a (rough!) exporter from today's DS into the
format sketched in that note, available both in the the patch following this
note and in my combined sugar git repo [1] in the xos branch. 

Already, I find it helpful both for browsing my DS with filesystem tools and
for resuming activities from the Terminal. 

What cool things can you think of to do with it?

Regards,

Michael

[1]: Links to my sugar git repo:

http://dev.laptop.org/git/users/mstone/sugar/commit/?h=xos
http://dev.laptop.org/git/users/mstone/sugar/snapshot/sugar-xos.tar.gz
git://dev.laptop.org/users/mstone/sugar
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Add ds2xos conversion script to export journal entries as .xos session dirs.

[Michael Stone]

This script converts the contents of whatever datastore is accessible on the
current session bus to subdirectories of the current working directory.

The purpose of this conversion is to encode all the data needed to show a nice
journal entry into a wire format that is easy to process with standard
filesystem tools and APIs.

The chosen format consists of one .xos session dir per journal entry.

A session dir is a directory:

   * whose name is URL-encoded with spaces encoded as pluses

   * which contains a directory named .xos:
   * which contains a file called metadata.json
   * which, optionally, contains an image named preview.png
   * which, optionally, contains an executable called resume

   * and which may contain any other files or directories you like

When creating session dirs from pre-existing journal entries:

   * we do our best to come up with human-meaningful and unique names by
 concatenating a few bytes of the journal entry's activity_id field onto
 the journal entry's title field separated by an underscore,

   * we try to create stand-alone resume files and to ensure that all the data
 that we put into such files is shell-quoted, and

   * we try to hard-link any files associated with the journal entry into our
 session dir with names derived from the title and mime-type of the stored
 file.

Signed-off-by: Michael Stone mich...@laptop.org
---
  datastore/bin/ds2xos |  133 ++
  1 files changed, 133 insertions(+), 0 deletions(-)
  create mode 100755 datastore/bin/ds2xos

diff --git a/datastore/bin/ds2xos b/datastore/bin/ds2xos
new file mode 100755
index 000..79565ff
--- /dev/null
+++ b/datastore/bin/ds2xos
@@ -0,0 +1,133 @@
+#!/usr/bin/env python
+from __future__ import with_statement, division
+
+import sys, cgitb
+cgitb.enable(format=plain)
+cgitb.handler = sys.excepthook.handle
+
+from pprint import pprint
+from sugar.datastore import datastore as ds
+from os.path import exists, join, splitext
+from os import makedirs, rename, link, chmod
+from commands import mkarg
+from errno import EEXIST
+from urllib import quote_plus
+from jarabe.model.bundleregistry import get_registry
+from sugar import env
+import cjson
+import sugar.mime
+
+def mkdir_p(path):
+try: makedirs(path)
+except OSError, e:
+if e.errno == EEXIST: pass
+else: raise
+
+def get_bundle(md):
+return get_registry().get_bundle(str(md['activity']))
+
+def get_command(md, bundle):
+command = bundle.get_command().split(' ')
+command.extend(['-b', str(md['activity'])])
+command.extend(['-a', str(md['activity_id'])])
+
+if 'object_id' in md and md['object_id'] != :
+command.extend(['-o', str(md['object_id'])])
+if 'uri' in md and md['uri'] != :
+command.extend(['-u', str(md['uri'])])
+
+# if the command is in $BUNDLE_ROOT/bin, execute the absolute path so there
+# is no need to mangle with the shell's PATH
+if '/' not in command[0]:
+bin_path = join(bundle.get_path(), 'bin')
+absolute_path = join(bin_path, command[0])
+if exists(absolute_path):
+command[0] = absolute_path
+
+return [mkarg(v)[1:] for v in command]
+
+def get_environ(md, bundle):
+ret = {}
+bin_path = join(bundle.get_path(), 'bin')
+activity_root = env.get_profile_path(str(md['activity']))
+
+ret['SUGAR_BUNDLE_PATH'] = bundle.get_path()
+ret['SUGAR_BUNDLE_ID'] = str(md['activity'])
+ret['SUGAR_ACTIVITY_ROOT'] = activity_root
+ret['PATH'] = bin_path
+
+if bundle.get_path().startswith(env.get_user_activities_path()):
+ret['SUGAR_LOCALEDIR'] = join(bundle.get_path(), 'locale')
+
+return ret
+
+def export(e):
+md = e.metadata.get_dictionary()
+md['object_id'] = e.object_id
+print md['activity_id']
+
+title = str(md.get('title', ''))
+if 'activity_id' in md and md['activity_id'] != :
+title = title + _ + str(md.get('activity_id', '')[0:8])
+title = quote_plus(title)
+print title
+
+preview = md['preview']
+del md['preview']
+
+final_dir = title
+dir = final_dir + .tmp
+
+if exists(final_dir):
+print 'already exists'
+return
+
+xos_dir = join(dir, .xos)
+
+mkdir_p(xos_dir)
+
+with open(join(xos_dir, metadata.json), w) as f:
+f.write(cjson.encode(md))
+
+with open(join(xos_dir, preview.png), w) as f:
+f.write(preview)
+
+if e.file_path != :
+base, ext = splitext(title)
+if ext == '':
+mime_type = md['mime_type']
+ext = sugar.mime.get_primary_extension(mime_type)
+if ext == None: ext = .bin
+else: ext = . + ext
+link(e.file_path, join(dir, base + ext))
+
+if 'activity' in md and md['activity'] != '' and \
+'activity_id' in md and md['activity_id'] != '':
+bundle = get_bundle(md)
+cmd = get_command(md, bundle)
+env

Re: [Sugar-devel] [IAEP] Proposal release management

[Michael Stone]

Simon wrote:

 What do others think about this?

I'm glad that you have a proposal that excites Bernie, Bert, and Tomeu.

I'm not sure what to think for myself because I don't know whether I
correctly understood your intent from my reading of your, Bernie's,
and Tomeu's words. (See below.)

Bernie and Tomeu wrote:

 Regarding proposed patches, during our development cycle we have
 collected a number of patches fixing bugs and adding small features.
 
 Just in case, note that the RM doesn't really care about what code
 goes in as long as features have been approved and we are in the right
 moment in the cycle (no freezes apply).

Let's be clear: I want *nothing* to do with any software process that works
this way -- you've described a bad shell-script, not a release manager.

However, I'm not sure that this description is actually what Simon was
talking about. Perhaps we should instead be talking about whatever role
describes the people who /do/ care about the code that goes in?

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Dynamically set number of control panel columns

[Michael Stone]

On Sun, Jun 20, 2010 at 10:27:46PM -, Anish Mangal wrote:
From: anishmangal2002 anishmangal2...@gmail.com

This patch sets the number of icon-columns in the control
panel based on the screen resolution. This patch also sets
the table row spacing to GRID_CELL_SIZE.

Anish,

I like the basic idea underlying this patch but I'm not really satisfied
with the current results.

With 8 icons at 1024x768, I get two vertical columns of icons, each with
four rows. Three rows scan be displayed at a time.

With 8 icons at 800x600, I get one horizontal row of icons with four
icons initially displayed.

Neither of these layouts seems ideal.

Thoughts?

Michael

P.S. - This problem actually reminds me rather strongly of the how do
we place activity icons? problem that we had when activity icons were
stuck on the frame. Do we have enough control panel entries now that we
should think about re-using the home-view layout to place control panel
icons too?

P.P.S. - In any case, thanks for the patch!
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] datastore situation (was Re: Hypothetical sugar-0.90 material, draft 1.)

[Michael Stone]

Dear Tomeu and other Gentle Readers,

Thanks for bringing this thread to my direct attention by CC'ing me. 

Since, I'm not exactly sure what feedback you'd like from me, I've tried to
respond in a way that will lead to a fun and productive discussion on 

   where do we want to go over the next few years and, concretely, what might
we do to get there?

I hope this is helpful. Therefore, if it's not, please let me know and we can
try something else.

Finally, please note that, in the interests of perspicacity and getting at
least a few hours of sleep tonight, I've left out the background of /why/ I
think we want the things that I claim we want below. If you'd like me to fill
this in, please speak up.

Regards,

Michael

...

On Mon, Jun 21, 2010 at 12:06:49PM +0200, Tomeu Vizoso wrote:
On Thu, Jun 10, 2010 at 17:48, Martin Langhoff
martin.langh...@gmail.com wrote:


I think this is an unfair recount of my work, so I'm going to put some
light on it and ask that my frankness is excused.

  - Reworking the datastore... while I welcome efforts in a new
 datastore... _every Sugar release has a new DS implementation_

Not sure how you are counting, only 2 datastore implementations have
ever been released as part of a Sugar release (more details below).

Agreed.

 they get little testing and I've seen extremely light thinking about
 what is _actually_ needed.

 ...

 What should I have done instead, limit myself to publish papers and give
 talks about my prototype and just re-release the old implementation in every
 Sugar release?

You did good work in your rewrite.

 We need _a good, polished DS that covers
 many aspects sanely_... a new DS is unlikely to do so. IOWs the
 barrier to merge a new DS should be high. It just triggers my CADT
 alarms http://www.jwz.org/doc/cadt.html

Martin: CADT doesn't accurately describe the DS situation so please either
recalibrate your alarms or be more specific about what immortal bugs concern
you.

Not sure how we can agree on rewriting or not rewriting if we haven't
agreed yet on what features should have the future releases of the DS?

So let's talk about what we might want to see in later 0.9x releases...

For me, the three biggies concern the data model, the compatibility story, and
the safety story. Here are my thoughts on each:

On the data model:

   model v0.8x: 

  in the grammar of sugar-0.8x, the journal records one-word sentences in
  which instances simultaneously represent both nouns and verbs.

   claim:

  in the short term, we want to get to a Journal that looks like Eben's
  slideshow and that works like Scott's journal2 mockup.

   model v0.9x:

  in the grammar of sugar-0.9x, the journal records multiword sentences in
  which instances are verbs and objects are nouns.

   Walter's paraphrased claim:

  in the long run, we're going to want a richer data model that includes
  grammatical features like adverbs and adjectives. however, it seems likely
  that we're not going to be able to get a richer model right before first
  gaining some experience with the simpler model described above.

On the compatibility story:

   we need to maintain compatibility with

  a) the current D-Bus API and
  b) the ability to loselessly import older DS data.

   however, to grow our universe of apps, we need to create compatibility with
   existing software based on hierarchically structured files and directories.

   to do merge this with the v0.9x data model, we should create a new 0.9x
   activity API which specifies the interpretation of top-level files,
   directories, and file metadata in the activity root. 

   as a simple, hypothetical, example:

 activity sessions are identified by session dirs with extension .xos.

 activity sessions are resumed by executing ./resume in the session dir.

 bespoke resume-related data are stored in hidden files or subdirs in the
 session dir.

 the reusable objects of an activity session are non-hidden files in
 standard formats in the session dir or its subdirs.

 activity metadata is stored in ./metadata.json in the session dir.

   (alternate design: metadata is stored as xattrs on whatever files or dirs
   it applies to)

 limited versioning is enabled when we find a top-level hidden dir with
 supported vcs state. for 0.9x, this would mean basic support for .git dirs.

On the safety story:

   * the overriding themes of DS safety are undoability and limited isolation:

 a) session-level undo (versioning)
 b) system-level undo (backup/restore)
 c) isolation (sandboxing + ACLs)
  
   the session-level undo I'm thinking of is adequately provided by the current
   keep button and an additional toolbar that, when opened, displays an
   MRU-sorted list of previous commits. (The keep button should record a commit
   message, then call something like git add *; printf msg | git commit -F -

   * I don't yet 

[Sugar-devel] A Tale of Sugar and Pippy

[Michael Stone]

Last Friday, I visited the MIT Science Fiction Society's library to pick up
some books. While visiting, I spoke with a friend about our recently discovered
mutual interest in Python in education.

Upon hearing that he was unfamiliar with our work, I opened my XO, started
Pippy, and left him to play for a few minutes. 

   +1: This experience *rocked*: I can think of no other operating system
   which so directly brought his interest from theory to reality.

Now, after playing with several Pippy examples, my friend stumbled onto
XOlympics. In honor of the World Cup, I challenged him to game.

After playing for some time -- perhaps 10 rounds -- we discovered that we had
lost track of which ball was currently contested. We looked at one another for
a moment and simultaneously exclaimed: we can fix this!

   +1: I can think of no other operating system and application which so
   directly exposes us to the possibility and desirability of making small
   changes.

We sat down to fix the problem. Since no example was available for how
to set the color of an already constructed ball, I had to go behind the
scenes by grepping the Pippy source code. Then I was able to work out exactly
what to do by several small experiments with dir() and with raise.

   -1: I think there's an important missing stepping stone here -- I'm not
   convinced that most people would have been able to figure out how to set
   the ball color from the currently available view-source interface and
   Pippy training materials.

The final change consisted of six insertions to the XOlympics example. It was
this long only because I decided to try something fancy -- smoothly
interpolating the contested ball between two colors over time -- instead of
something simpler.

Here, we reach the end of my tale. You see, my friend and I agreed that our
desired next step would be to send our change to sugar-devel@ along with, well,
this story. 

   -1: Unfortunately, there's no obvious way to do this with Sugar and
   Pippy today. 

Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide
to make this act of reflection and sharing feel as natural as the act of
starting Pippy or of making the change that we want to describe and to share?

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Defining sugar HEAD.

[Michael Stone]

Hi folks,

We've done some good work in the past few weeks getting the Sugar patch
generation and review processes unstuck. Interesting new patches are now being
published and reviewed with some frequency, which is great. 

(Particular thanks are due to James, Bernie, and Tomeu for their work reviewing
patches and bringing patches to sugar-devel@ for review.)

However, in order for us to be able to make an awesome release in a couple of
months, we need to get the merge and testing processes unstuck too.

What do you think of these suggestions on how to approach these issues?

   1. Can we get better at gently nudging people to review or to merge patches
  that have been overlooked so that fewer patches slip by into limbo? 

   2. Can we define a single sugar HEAD, updated on a weekly basis, which
  folks can test on whichever [1] platform they like best? 

   3. Can we start organizing the creation and publishing of test results for
  whatever sugar HEAD turns out to be, much like we did for Friends in
  Testing for OLPC? 

Regards, and thanks in advance for your thoughts,

Michael



[1]: Platforms that I know people like testing on so far include:

 * jhbuild
 * XO-1's
 * XO-1.5's
 * SoaS
 * normal distros
 * distro chroots
 * iPads
 * LTSP?
 * your platform here

Did I miss anyone?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Wrong exception when copying an entry with no file to a removable device.

[Michael Stone]

On Sun, Jun 13, 2010 at 08:43:19PM -0300, Andrés Ambrois wrote:
In that case write() was called with file_path=None by copy() and a
TypeError was raised by os.path.exists().

Signed-off-by: Andrés Ambrois andresambr...@gmail.com
---
 src/jarabe/journal/model.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/jarabe/journal/model.py b/src/jarabe/journal/model.py
index ae77e72..fd3d3db 100644
--- a/src/jarabe/journal/model.py
+++ b/src/jarabe/journal/model.py
@@ -492,7 +492,7 @@ def write(metadata, file_path='', update_mtime=True, 
transfer_ownership=True):
  file_path,
  transfer_ownership)
 else:
-if not os.path.exists(file_path):
+if not file_path or not os.path.exists(file_path):
 raise ValueError('Entries without a file cannot be copied to '
  'removable devices')
 
-- 
1.6.3.3

Reviewed-by: Michael Stone mich...@laptop.org

Looks good to me; merged into my personal tree.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Add NotifyRedAlert inherited from NotifyAlert

[Michael Stone]

On Mon, Jun 14, 2010 at 02:51:23AM +0530, anishmangal2...@gmail.com wrote:

Hi Anish,

Thanks for the patches. Here are one small question and one comment for you...

From: anishmangal2002 anishmangal2...@gmail.com

Adds the NotifyRedAlert class which is an alert inherited from
 NotifyAlert. When the alert message is displayed, it glows the
alert bar Red before slowly fading out to black, thus resulting
in a more visible notification.

Signed-off-by: anishmangal2002 anishmangal2...@gmail.com
---
 src/sugar/graphics/alert.py |   46 +++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/src/sugar/graphics/alert.py b/src/sugar/graphics/alert.py
index 4441909..b4dfee1 100644
--- a/src/sugar/graphics/alert.py
+++ b/src/sugar/graphics/alert.py
@@ -432,3 +432,49 @@ class NotifyAlert(Alert):
 self._response(gtk.RESPONSE_OK)
 return False
 return True
+
+class NotifyRedAlert(NotifyAlert):

Is this alert really about being red or about notifying the user about errors
in a more eyecatching fashion?


+
+Timeout alert with only an OK button and a glowing Red border- just for 
notifications
+
+Examples
+
+
+.. code-block:: python
+  from sugar.graphics.alert import NotifyRedAlert
+  ...
+ Method: _alert_notify, create a NotifyRed alert (with only an 
'OK'
+ button)
+# and add it to the UI.
+def _alert_notify(self):
+#Notice that for a NotifyRedAlert, you pass the number of seconds 
in
+#which to notify. By default, this is 5.
+alert = NotifyRedAlert(10)
+alert.props.title=_('Title of Alert Goes Here')
+alert.props.msg = _('Text message of notify alert goes here')
+alert.connect('response', self._alert_response_cb)
+self.add_alert(alert)
+
+
+
+def __init__(self, timeout=5, **kwargs):
+NotifyAlert.__init__(self, timeout, **kwargs)
+self.saturation = 255
+
+gobject.timeout_add(20, self.__modify_color_timeout)
+
+def __modify_color_timeout(self):
+if self.saturation:
+self.saturation -= 1
+
+# Form the hex color representation
+if self.saturation = 15:
+color = '#0%s' % hex(self.saturation)[2:]
+else:
+color = '#%s' % hex(self.saturation)[2:]

The value of the color variable can be more concisely calculated like so:

 color = #%02x % self.saturation

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Alerting users in case of write errors

[Michael Stone]

Gary wrote:
 On 13 Jun 2010, at 12:57, Anish Mangal anishmangal2...@gmail.com wrote:
 An alert like a chat or Activity sharing invitation would be nice, but one
 with a more visible signal is needed.
 
 We really really really ... need a general notification system. :D
 
 Please no popup error dialogue windows if you can avoid it ;) The alert
 strip that displays under the toolbar is a much more friendly notification
 for the Sugar UI design.
 
 Thanks for the insightful responses. I have used a slightly modded
 version of NotifyAlert (aptly called NotifyRedAlert). A sample
 screen-capture can be found here...
 
 http://people.sugarlabs.org/~anish/sl1842-journal.gif
 Note: The link above is a big animated gif (~1.8M) and some browsers
 may struggle to display it.

 Yea, my iPad chocked half way through :)

 If this seems fine, I'll mail the patch for reviewing.
 
 Looks nice. The colour fade (red to black over the time-out countdown) is
 something new and not in the Sugar HIG, but I don't have an objection — makes
 fair warning UI sense and could be something we adopt elsewhere when needed
 (if there aren't too many objections).

Anish, Gary,

I like the color fade too but the red hue is, for me, a bit overpowering.

Have you considered any alternatives like, for example, only applying the red
to the border of the alert or using the user's colors instead of red?

Kind regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Revised hypothetical material for sugar-0.90

[Michael Stone]

First, thanks very much to everyone who commented on my previous thread about
wild rumors for sugar-0.90. Your comments are very helpful to me because they
inform my mental picture of what changes might be available within the next few
months to be released. They are also valuable in their own right for creating
excitement, engagement, and a sense of healthy community. Therefore, keep up
the good work!

Second, to tomeu, rgs, aa, mabente, epastorino, esteban, erikos -- I'd like
to hear more from you! In particular, if you could please speak up about the
rightness or wrongness of my guesses on what you're going to be working on,
I would be most appreciative.

Third, to those who are reading this email but who are not yet comfortable
replying in public -- don't worry! Public responses are good, but private
ones can be okay too and I really want you to be involved. Therefore, please
feel free to write to me privately. I'll do what I can to write back and to
fold your ideas into future conversations.

Regards,

Michael

...

Sugar-0.90 Integration and Testing Needs

Here's a slightly updated list of integration and testing needs based on last
week's comments. Further discussion is encouraged.

Bigger integration needs:

  1.  Aleksey: 0install integration
  2.  Sascha: versioned datastore
  3.  Tomeu: collaboration refactoring
  4.  Raul: rainbow
  5.  Michael: git repo reorganization and build system rewrite
  6.  you: your feature here

Smaller integration needs:

  7.  Gary + Christian: alternative activity launch UI
  8.  Gary + Scott: preliminary touch-related UI tweaks
  9.  Esteban: virtual keyboard
  10. Lucian: browser abstraction
  11. Martin L.: polish
  12. Walter: write to journal any time
  13. Walter: enhanced color selector
  14. Jorge + Martin A.: journal backup + restore
  15. Andres: journal entry sorting
  16. you: your tweak here

I'm not sure yet:

  17. Walter: multiple home views
  18. Simon: dotted activity versions
  19. Peter: support new gnome libraries

Certification / testing needs :

  20. Aleksey: Vala-based sugar-toolkit
  21. you: your activity here
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal Implementation

[Michael Stone]

 Hello, my name is Bao Vuong. I am trying to implement a feature to the irc
 that lets a journal entry store the nickname and channels. I read that I
 need to define read_file and write_file methods. Are there any simple
 examples I can use? Or a tutorial of how to make one to work?

Dear Pippy folks,

I think your assistance has just been requested! :)

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Devel Team vacancies + On sugar-0.90.

[Michael Stone]

On June 7, Simon Schampijer wrote:
 On 06/06/2010 10:30 PM, Tomeu Vizoso wrote:
 SeanDaly  if tomeu were here, he would say: we need someone 
 experienced, who knows the open source way, and does not need lots of 
 briefing to get up to speed (he will correct me if I err)

 You can count on me for that :)

 So the idea of team coordinator is that of someone who takes care for:

 * keeping the list of team members updated in the wiki,

 * making sure the mission statement is in sync with the team's activities,

 * announce and moderate regular meetings and publishing its minutes.

 So I don't think you need any special skills, just be willing to
 donate a few hours per month.

 If we had a community team, we would have a structure for the people
 who want to work together on such issues ;)

 cjb  (I think the most important job the release manager does is 
 decide whether a late change constitutes acceptable risk, and I think doing 
 that requires deep understanding of programming and the complexity of a 
 given bug/solution.)

 There seems to be a misunderstanding, maybe because OLPC had a
 position with the same name (and maybe our use of it is not totally
 appropriate). In Sugar's case, who decides what goes in and what not
 is the schedule, the maintainer and the release team, with input from
 several others.

 The schedule says what kind of changes can go in at every moment in
 the release cycle, the maintainer is expected to have enough criteria
 to classify every change accordingly and the release team votes on
 exceptions to the schedule.

 All about releases: http://wiki.sugarlabs.org/go/Development_Team/Release
 New features process and what is the release manager:
 http://wiki.sugarlabs.org/go/Features/Policy

 In this way, the release manager doesn't have as much responsibility
 as was implied in the meeting but he's mainly responsible for making
 sure that the process _for proposing new features_ is followed. It's
 largely an administrative role, but much more exigent than
 coordinating a team.

 The reason for having a weaker release manager and relying more on the
 criteria of maintainers is because by SLs being an upstream these
 decisions won't affect as directly to our users as downstreams are
 anyway expected to do integration, testing and maybe some amount of
 patching after each release is made. For a downstream such as OLPC or
 Fedora, someone needs to control very strictly what gets in at the end
 of the cycle because there's more pressure to get stuff in and because
 once you have sent the image to the factory or have started to seed a
 torrent it's much harder to go back and fix some bug.

 In the Sugar case, if a maintainer made a goof and introduced a major
 bug just before release, it will take some time before the code is
 packaged, then distributed to testers, then submitted to a stable
 release that users will use with some expectation of not finding major
 regressions.

 It would be great if people could search the wiki before entering in
 discussing a process or a role, because as you can see from the link
 above, that took someone quite a bit of time to write and would be sad
 to waste time discussing something else. Also, the docs in the wiki
 indeed could be clearer and any help will be welcome.

 To make it clearer:

 * the release manager is not needed to make module releases,

 * the release manager doesn't decide by herself if a change goes in or not,

 * the release manager makes sure the feature process is followed.

 Maybe a more appropriate name for what we call the release manager
 would be new feature process manager but as it's a bit long and we
 don't have a release manager, we ended up using that name instead.

 Regards,

 Tomeu
 
 Thanks for taking the time to lay this out as detailed. 

Indeed, thanks!

 It is true indeed that the main role of the release manager, as Sugar Labs 
 interpreted that role...

The stumbling block for me for several other people here is this line from the
current Feature Policy:

   The main goal of the feature policy is to make systematic and
   predictable the process by which community ideas on how Sugar should
   evolve get transformed into actionable proposals.

and its emphasis on process, predictability, and rigid schedules.

Why is predictability the thing we want to optimize for here?

You see, I want us to create a Sugar release that is *as much improved as
we can get in the time allowed*, even if it winds up being improved in ways
that we didn't foresee -- that we merely recognized and adopted immediately as
they were suggested.

To do this, we should concentrate on building the leanest, meanest, fastest
coding and integration machine that we can so that we create as much
opportunity as we can stand to make changes that will really improve the user
experience and technology that we're providing. 

Velocity, momentum, and ferment should be our bywords.

The reason why I want these things is that there are still 

[Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Michael Stone]

Hi folks,

Under the temporary working hypothesis that we want to make a Sugar release in
a couple of months, I'd like to know more about what we might find ourselves
integrating. Here's my current list of, er... mostly unvetted rumors. :)

   1.  Aleksey: 0install integration, Vala-based sugar-toolkit
   2.  Sascha: versioned datastore
   3.  Tomeu: collaboration refactoring
   4.  Gary + Christian: alternative activity launch UI
   5.  Michael: git repo reorganization and build system rewrite
   6.  Gary + Scott: preliminary touch-related UI tweaks
   7.  Raul: rainbow
   8.  Esteban: virtual keyboard
   9.  Lucian: browser abstraction
   10. Martin L.: polish
   11. Walter: write to journal any time
   12. Simon: dotted activity versions
   13. Walter: enhanced color selector
   14. Jorge + Martin A.: journal backup + restore
   15. Andres: journal entry sorting
   15. you: your patch series here

Comments? Additions? Substitutions? Deletions?

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] On sugar-0.90.

[Michael Stone]

Folks,

At yesterday's oversight board meeting [1], there seems to have been some
discussion of how to get the sugar-0.90 release process unstuck. To my surprise
and great amusement, my name came up [2]. 

Unfortunately, there is still the unresolved matter of whether or not I can
actually do anything useful for a rowdy bunch like us. :)

Here are my current concerns:

   1. Unlike the last time around with OLPC's 8.2.0 OS release, I'm only
  regularly available mornings, evenings, and weekends EST/EDT.

  Is this fact (and the resulting need to do most of our coordination via
  asynchronous means like email) something that you folks think could work
  out okay?

   2. We don't yet have a clear, widely agreed-upon goal like ship sugar-0.82
  to Uruguay. Thus:

* What are we really trying to achieve with this release?

* Who are the principal agents whose needs are driving the release?

  (Suggestions and discussion are hereby invited.)

   3. I have some strong opinions [3..7] about why Sugar is valuable, about how
  it ought to be built, and about how the task of building it ought to be
  organized.

  These opinions undoubtedly differ from many of yours.

  Thus: are we going to be able to find enough common ground to make this
  work? -- that is, to make something that we're all going to be proud of?

Regards, and thanks for your time and interest,

Michael 

[1]: http://me.etin.gs/sugar-meeting/sugar-meeting.log.20100604_.html
[2]: (Dear Chris, Mel, Martin, and Walter: thanks for thinking of me. :)
[3]: http://lists.sugarlabs.org/archive/sugar-devel/2008-July/007441.html
[4]: http://lists.sugarlabs.org/archive/iaep/2009-July/007415.html
[5]: http://wiki.laptop.org/go/Network2/Paper
[6]: http://dev.laptop.org/~mstone/draft-sugar-core-priorities-01.txt
[7]: http://wiki.laptop.org/go/User:Mstone/Commentaries/Releases_3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Adjusting/reworking patches with git (was: Re: Patch:

[Michael Stone]

Excerpts from James Cameron's message of Mon May 31 10:59:18 + 2010:

 1.  git checkout HASH where hash is the patch to be fixed,
 
 2.  git reset HEAD^ to undo this last commit without changing the
 working copy, then
 
 3.  git add and git commit again.
 
 Even easier to use is git rebase -i origin/master (where origin/master
 is the upstream branch). 

Tagging with a throwaway tag (e.g. good) before interactive-rebasing has
saved me a lot of time because it's much easier to remember git reset --hard
good than to read the output of git reflog to get back to the working but
ugly patch that you haven't yet pushed.

Also, another trick that has been quite handy for splitting up big patches is:

   git add -p

(which is an abbreviation for git add -i; p; *;)

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard

[Michael Stone]

Tomeu, Bert, James, Martin D., and Michael wrote:

 T: Thanks a lot for lending a hand here.
  
My pleasure, and thanks for mentioning the ticket.
  
 M: Final remark: this patch names variables, methods, and classes in
 Spanish. Anyone troubled by this?

 (I ask because, while it's fine with me personally, I don't think I know
 consensus opinion on the subject.)

 T: I'm not so happy about it, I think it raises considerably the effort
 needed to read the code, even for spanish speakers like me.

 B,J,MD: IMHO the whole code base should be in English. This is the language
 we use for collaborating. 

You and I certainly collaborate in English but the folks dealing with Sugar on
a daily basis in Uruguay, Peru, and Paraguay largely do not, at least in their
daily dealings among themselves. 

For this sole strategic reason, I think we need to consider accepting
well-written patches that come to us in Spanish or in English.

The main cost of pursuing this course is that patches written in Spanish are
somewhat harder for some prominent Sugar contributors to read than are patches
written in English. Additionally, having a mixed-language codebase may be
off-putting to some potential contributors. 

On the other hand, does it not seem likely that by welcoming patches written in
the first and most common language of our largest groups of users, we would
receive more patches, thereby gaining more contributors, some of whom might
grow to become integral members of our community?

(Finally, if we don't receive many patches, then what will be the loss for
having tried? At most, we will have a small number of patches to translate from
Spanish to English. Not a big deal, right?)

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard

[Michael Stone]

 First of all, thanks Esteban for the great work! I hope we can spin a
 new build soon and give it a try. 

Thanks, that would indeed be helpful.

Meanwhile, something else that you might spin around in your head while you
make the build is how do we make a virtual keyboard that works for all the
languages we have keyboards for? (and/or, is there another program that
already does this that could be integrated with Sugar?)

 On the other hand, even though I also come from a Spanish speaking
 country, I'd say having all the code in English (the defacto lingua
 franca for code) would be best on the long term. 

I'm not yet convinced, though I certainly appreciate your feedback.

Here are three prominent memories that still sway my opinion:

   1) I read multi-language files and communications nearly every day so, for
  me, they're already a fact of life. For example, every time I read my
  email, every time I write a Makefile, and every time I write a web-app (in
  SML, HTML, CSS, JS, and SVG) I'm facing the same general problem posed by
  Spanish-flavored vs. English-flavored patches.

   2) When OLPC sent me to visit LATU and Ceibal Jam, I was struck by the large
  quantities of interesting code written by both of those organizations...
  in Spanish. I know that I want both that code and the people writing it to
  be participating more directly in the daily development of Sugar. My best
  idea for how to achieve this goal is to try to meet them halfway.

   3) When I (briefly) taught English in a public school in Dharamsala, India, I
  found that I could not function effectively without learning enough Hindi
  to establish a working pidgin communications channel. This channel
  mattered for two reasons: first, because it served as a control plane 
for
  collaboration and second, because it generated enough mutual respect and
  interest to sustain collaboration. I feel both these needs here too.

 It's an extra effort (and I volunteer to help with translations if Esteban is
 short on time) but I think it is important to maintain consistency in
 variable names, methods and comments.

I agree that it's important be (sufficiently) consistent. However, I also
believe that an acceptable degree of consistency can be found in a codebase
that contains both Spanish and English text. Instead, the kind of inconsistency
that I am most concerned with is inconsistency in control and data flow idioms.

Regards,

Michael

 P.S.: we try to produce all of our code (in git.paraguayeduca.org) under
 the same rules (all English) so we can share it among deployments.. we
 hope it results useful for someone some day! :) 

P.S. - Thanks for the links and for the thought-provoking discussion!
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] touchpad section for Sugar Control Panel

[Michael Stone]

Sascha wrote:

 PS: Please give git send-email a try. It sends the patches in a way that
 makes them easier to review.

I've never been comfortable with git send-email because it doesn't let me
adequately review the email headers of the messages that are going to be sent
before I hit send.

Instead, what works well for me is to use

   git format-patch ...  mbox

to generate an mbox full of emails which I can hand-edit to my satisfaction (in
my case, in mutt, with 'e') before resending (with mutt, with 'Esc e').

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] Avoid popping an empty list in the

[Michael Stone]

 On Sun, May 23, 2010 at 02:50:16PM -0400, Michael Stone wrote:
  When you run Sugar with no activities installed,
  UpdateModel._bundles_to_check is empty. Attempting to unconditionally
  pop this list results in an IndexError.  Instead, the updater should
  stop trying to update bundles when it determines that it has no more
  bundles to check.
  
  Signed-off-by: Michael Stone mich...@laptop.org
 
 It will work where it is, but the check could go another two lines
 higher up, or even in check_updates.
 
 It's also odd that you're returning False and the function otherwise
 returns None.  gobject.idle_add is specified as removing the function
 from the main loop when False is returned, but I've tested and it is
 doing so with a None return as well.
 
 The patch below (on top of your two patches) implements what I mean:
 
 diff --git a/main/extensions/cpsection/updater/model.py 
 b/main/extensions/cpsection/updater/model.py
 index 5bb8cf4..9bf0330 100755
 --- a/main/extensions/cpsection/updater/model.py
 +++ b/main/extensions/cpsection/updater/model.py
 @@ -64,14 +64,13 @@ class UpdateModel(gobject.GObject):
  def check_updates(self):
  self.updates = []
  self._bundles_to_check = list(bundleregistry.get_registry())
 -self._check_next_update()
 +if len(self._bundles_to_check)  0:
 +self._check_next_update()
  
  def _check_next_update(self):
  total = len(bundleregistry.get_registry())
  current = total - len(self._bundles_to_check)
  
 -if len(self._bundles_to_check) == 0:
 -return False
  bundle = self._bundles_to_check.pop()
  self.emit('progress', UpdateModel.ACTION_CHECKING, bundle.get_name(),
current, total)

Good suggestion.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Avoid popping an empty list in the software updater.

[Michael Stone]

When you run Sugar with no activities installed, UpdateModel._bundles_to_check
is empty. Attempting to unconditionally pop this list results in an IndexError.
Instead, the updater should stop trying to update bundles when it determines
that it has no more bundles to check.

Signed-off-by: Michael Stone mich...@laptop.org
---
  extensions/cpsection/updater/model.py |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/extensions/cpsection/updater/model.py 
b/extensions/cpsection/updater/model.py
index f2de65b..c45dcd3 100755
--- a/extensions/cpsection/updater/model.py
+++ b/extensions/cpsection/updater/model.py
@@ -71,6 +71,8 @@ class UpdateModel(gobject.GObject):
  total = len(bundleregistry.get_registry())
  current = total - len(self._bundles_to_check)
  
+if len(self._bundles_to_check) == 0:
+return False
  bundle = self._bundles_to_check.pop()
  self.emit('progress', UpdateModel.ACTION_CHECKING, bundle.get_name(),
current, total)
-- 
1.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Simplify the definition of UpdateModel._bundles_to_check.

[Michael Stone]

The only purposes of the list comprehension in UpdateModel.check_updates() is
to set self._bundles_to_check to a list containing the elements returned by
bundleregistry.get_registry(). This purpose can be more succinctly achieved by
means of the list() constructor.

Signed-off-by: Michael Stone mich...@laptop.org
---
  extensions/cpsection/updater/model.py |3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/extensions/cpsection/updater/model.py 
b/extensions/cpsection/updater/model.py
index c45dcd3..5bb8cf4 100755
--- a/extensions/cpsection/updater/model.py
+++ b/extensions/cpsection/updater/model.py
@@ -63,8 +63,7 @@ class UpdateModel(gobject.GObject):
  
  def check_updates(self):
  self.updates = []
-self._bundles_to_check = \
-[bundle for bundle in bundleregistry.get_registry()]
+self._bundles_to_check = list(bundleregistry.get_registry())
  self._check_next_update()
  
  def _check_next_update(self):
-- 
1.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH v1 00/10] Journal sorting by file size and creation time.

[Michael Stone]

On Sun, May 23, 2010 at 09:02:30AM -0300, Andrés Ambrois wrote:
See [0] for the rationale behind this patchset.

[0] http://lists.sugarlabs.org/archive/sugar-devel/2010-May/023664.html

v0: Initial submission to sugar-devel
v1: Separated ctime and filesize patches. Implemented sorting for removable 
devices.

Andrés Ambrois (10):
  Journal: Retrieve filesize from the datastore
  Add a filesize column to the journal list model
  Journaltoolbox: Add add_separator method for convenience.
  Add a ListViewButton to the journal search toolbar.
  Rename the date column to 'sort_column'
  Display the sorting property in the last column.
  Expandedentry: Try to use the filesize property.
  Implement sorting for removable devices.
  Add sort by creation time option to the ListViewButton
  Add ctime property to the journal model.

 src/jarabe/journal/expandedentry.py  |5 +-
 src/jarabe/journal/journaltoolbox.py |   86 ++
 src/jarabe/journal/listmodel.py  |   22 ++--
 src/jarabe/journal/listview.py   |   33 +++--
 src/jarabe/journal/model.py  |   22 ++--
 5 files changed, 140 insertions(+), 28 deletions(-)


Andrés,

I've read these patches and tested them locally (with minor changes due to
merge conflicts with some of my experimental work) and the results are quite
pleasing to me.

The one issue that I would like you to fix before I merge these patches into my
tree is that I would like you to include additional patches for the new icons
that your ListViewButton requires to function as intended. 

(I don't really care whether the new icons are different from the old icons; I
merely care that I still have a normal-looking ListViewButton after I select
one of your new sort modes rather than the thin grey bar that I currently see.)

Regards, and thanks for all your hard work here,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard

[Michael Stone]

On Wed, May 19, 2010 at 03:10:52PM +0200, Tomeu Vizoso wrote:
On Sat, May 15, 2010 at 23:48, Sugar Labs Bugs
bugtracker-nore...@sugarlabs.org wrote:
 #1686: Accessibility - virtual keyboard
 --+-
    Reporter:  earias                     |          Owner:  tomeu
        Type:  defect                     |         Status:  new
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by 
 Release Team
   Component:  sugar                      |        Version:  Unspecified
    Severity:  Unspecified                |       Keywords:  r?
 Distribution:  Unspecified                |   Status_field:  Unconfirmed
 --+-
 Changes (by bernie):

  * keywords:  = r?


 Comment:

  Can someone please review this patch?

Any volunteers in the mailing list?

I'll offer a couple of observations. First, though, I'll reproduce the patch
inline so that I can reply inline and so that everyone can take a good look at
it.

Michael

 From 6781e1bec2c387a740aafe0943c0aa9250482e1a Mon Sep 17 00:00:00 2001
From: Esteban ear...@localhost.localdomain
Date: Mon, 25 Jan 2010 14:52:17 -0200
Subject: [PATCH] virtualkeyboard

---
  extensions/globalkey/Makefile.am|4 +-
  extensions/globalkey/virtualkeyboard.py |   12 +
  src/jarabe/model/Makefile.am|3 +-
  src/jarabe/model/virtualkeyboard.py |  184 +++
  src/jarabe/view/Makefile.am |3 +-
  src/jarabe/view/virtualkeyboard.py  |  865 +++
  6 files changed, 1068 insertions(+), 3 deletions(-)
  create mode 100644 extensions/globalkey/virtualkeyboard.py
  create mode 100755 src/jarabe/model/virtualkeyboard.py
  create mode 100755 src/jarabe/view/virtualkeyboard.py

diff --git a/extensions/globalkey/Makefile.am b/extensions/globalkey/Makefile.am
index 69afac2..dff13fb 100644
--- a/extensions/globalkey/Makefile.am
+++ b/extensions/globalkey/Makefile.am
@@ -3,4 +3,6 @@ sugardir = $(pkgdatadir)/extensions/globalkey
  sugar_PYTHON =\
__init__.py \
screenshot.py   \
-   viewsource.py
+   viewsource.py   \
+   virtualkeyboard.py
+
diff --git a/extensions/globalkey/virtualkeyboard.py 
b/extensions/globalkey/virtualkeyboard.py
new file mode 100644
index 000..9291142
--- /dev/null
+++ b/extensions/globalkey/virtualkeyboard.py
@@ -0,0 +1,12 @@
+import os
+import gtk
+import logging
+
+from jarabe.model import shell
+import jarabe.view.virtualkeyboard
+
+BOUND_KEYS = ['altk']
+
+def handle_key_press(key):
+   logging.debug('load virtual keyboard')
+   jarabe.view.virtualkeyboard.Teclado()
diff --git a/src/jarabe/model/Makefile.am b/src/jarabe/model/Makefile.am
index 18d44da..ae3dce9 100644
--- a/src/jarabe/model/Makefile.am
+++ b/src/jarabe/model/Makefile.am
@@ -14,4 +14,5 @@ sugar_PYTHON =\
shell.py\
screen.py   \
  session.py\
-   sound.py
+   sound.py\
+   virtualkeyboard.py
diff --git a/src/jarabe/model/virtualkeyboard.py 
b/src/jarabe/model/virtualkeyboard.py
new file mode 100755
index 000..6867f10
--- /dev/null
+++ b/src/jarabe/model/virtualkeyboard.py
@@ -0,0 +1,184 @@
+#!/usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+# virtualkeyboard
+# Copyright (C) 2009 Plan Ceibal
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see http://www.gnu.org/licenses/.
+#
+# Contact information: comuni...@plan.ceibal.edu.uy
+# Plan Ceibal http://www.ceibal.edu.uy
+
+import pygtk
+pygtk.require('2.0')
+import gtk
+import sys, os
+import time
+import pango
+import Xlib.display
+import Xlib.X
+import Xlib.XK
+import Xlib.protocol.event
+
+class Teclado:
+special_X_keysyms = {
+   ' ' : space,
+   '\t' : Tab,
+   '\n' : Return, 
+   '\r' : BackSpace,
+   '\e' : Escape,
+   '!' : exclam,
+   '#' : numbersign,
+   '%' : percent,
+   '$' : dollar,
+   '' : ampersand,
+   '' : quotedbl,
+   '\'' : apostrophe,
+   '(' : parenleft,
+   ')' : parenright,
+   '*' : asterisk,
+   '=' : equal,
+   '+' : plus,
+   ',' : comma,
+   '-' : minus,
+   '.' : period,
+   '/' : slash,
+   

Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard

[Michael Stone]

On Sun, May 23, 2010 at 03:18:47PM -0400, Michael Stone wrote:
 On Wed, May 19, 2010 at 03:10:52PM +0200, Tomeu Vizoso wrote:
 On Sat, May 15, 2010 at 23:48, Sugar Labs Bugs
 bugtracker-nore...@sugarlabs.org wrote:
 #1686: Accessibility - virtual keyboard
 --+-
    Reporter:  earias                     |          Owner:  tomeu
        Type:  defect                     |         Status:  new
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by 
 Release Team
   Component:  sugar                      |        Version:  Unspecified
    Severity:  Unspecified                |       Keywords:  r?
 Distribution:  Unspecified                |   Status_field:  Unconfirmed
 --+-
 Changes (by bernie):

  * keywords:  = r?


 Comment:

  Can someone please review this patch?

 Any volunteers in the mailing list?

 I'll offer a couple of observations. First, though, I'll reproduce the patch
 inline so that I can reply inline and so that everyone can take a good look at
 it.

 Michael

 From 6781e1bec2c387a740aafe0943c0aa9250482e1a Mon Sep 17 00:00:00 2001
 From: Esteban ear...@localhost.localdomain
 Date: Mon, 25 Jan 2010 14:52:17 -0200
 Subject: [PATCH] virtualkeyboard

 ---
  extensions/globalkey/Makefile.am|4 +-
  extensions/globalkey/virtualkeyboard.py |   12 +
  src/jarabe/model/Makefile.am|3 +-
  src/jarabe/model/virtualkeyboard.py |  184 +++
  src/jarabe/view/Makefile.am |3 +-
  src/jarabe/view/virtualkeyboard.py  |  865 
 +++
  6 files changed, 1068 insertions(+), 3 deletions(-)
  create mode 100644 extensions/globalkey/virtualkeyboard.py
  create mode 100755 src/jarabe/model/virtualkeyboard.py
  create mode 100755 src/jarabe/view/virtualkeyboard.py

 diff --git a/extensions/globalkey/Makefile.am 
 b/extensions/globalkey/Makefile.am
 index 69afac2..dff13fb 100644
 --- a/extensions/globalkey/Makefile.am
 +++ b/extensions/globalkey/Makefile.am
 @@ -3,4 +3,6 @@ sugardir = $(pkgdatadir)/extensions/globalkey
  sugar_PYTHON =   \
   __init__.py \
   screenshot.py   \
 - viewsource.py
 + viewsource.py   \
 + virtualkeyboard.py
 +
 diff --git a/extensions/globalkey/virtualkeyboard.py 
 b/extensions/globalkey/virtualkeyboard.py
 new file mode 100644
 index 000..9291142
 --- /dev/null
 +++ b/extensions/globalkey/virtualkeyboard.py
 @@ -0,0 +1,12 @@
 +import os
 +import gtk
 +import logging
 +
 +from jarabe.model import shell
 +import jarabe.view.virtualkeyboard
 +
 +BOUND_KEYS = ['altk']
 +
 +def handle_key_press(key):
 + logging.debug('load virtual keyboard')
 + jarabe.view.virtualkeyboard.Teclado()
 diff --git a/src/jarabe/model/Makefile.am b/src/jarabe/model/Makefile.am
 index 18d44da..ae3dce9 100644
 --- a/src/jarabe/model/Makefile.am
 +++ b/src/jarabe/model/Makefile.am
 @@ -14,4 +14,5 @@ sugar_PYTHON =  \
   shell.py\
   screen.py   \
  session.py   \
 - sound.py
 + sound.py\
 + virtualkeyboard.py
 diff --git a/src/jarabe/model/virtualkeyboard.py 
 b/src/jarabe/model/virtualkeyboard.py
 new file mode 100755
 index 000..6867f10
 --- /dev/null
 +++ b/src/jarabe/model/virtualkeyboard.py
 @@ -0,0 +1,184 @@
 +#!/usr/bin/env python
 +# -*- coding: iso-8859-1 -*-
 +# virtualkeyboard
 +# Copyright (C) 2009 Plan Ceibal
 +#
 +# This program is free software: you can redistribute it and/or modify
 +# it under the terms of the GNU General Public License as published by
 +# the Free Software Foundation, either version 3 of the License, or
 +# (at your option) any later version.

First observation: the patch is GPLv3+, yet Sugar is usually distributed under
GPLv2+. Yes?

 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program.  If not, see http://www.gnu.org/licenses/.
 +#
 +# Contact information: comuni...@plan.ceibal.edu.uy
 +# Plan Ceibal http://www.ceibal.edu.uy
 +
 +import pygtk
 +pygtk.require('2.0')
 +import gtk
 +import sys, os
 +import time
 +import pango
 +import Xlib.display
 +import Xlib.X
 +import Xlib.XK
 +import Xlib.protocol.event

Next observation: the patch introduces a dependency on python-xlib, which I
don't think we've depended on before. This doesn't seem hard to support but it
does need to be more clearly explained.

 +
 +class Teclado:
 +special_X_keysyms = {
 + ' ' : space,
 + '\t' : Tab,
 + '\n' : Return, +  '\r' : BackSpace,
 + '\e' : Escape,
 + '!' : exclam

Re: [Sugar-devel] Patchwork

[Michael Stone]

I like James' suggestion that people who are merging patches should insist on
high-quality commit messages. 

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.

[Michael Stone]

On Thu, May 06, 2010 at 05:14:44AM +, Aleksey Lim wrote:
On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote:
 This patchset implements sorting in the Journal UI as described in [0]. 
 
 This feature was requested in [1] and sponsored by Activity Central [2].
 
 Sorting by filesize is vital in the field where users need to free up disk
 space. Currently, the only way to find candidates for deletion is to access
 the expanded view of each entry, one by one. This can be a very time 
 consuming
 process and often leads to indiscriminate deletion and thus potential loss of
 valuable data. This is bad.
 
 Sorting by creation time (ctime) is also implemented as described in the 
 Design
 Proposal.
 
 This implementation currently lacks two aspects which I hope will be sorted 
 out
 in the review process:
 
 1- The proposal does not include a specification for changing the order of 
 the
 sort. This patch assumes an ascending order.
 
 2- There are no icons for the sorting criteria. Or at least I couldn't find 
 the
 ones presented in the proposal. I'm sure someone from the design team could
 vectorize the ones there.
 
 v0: Initial submission to sugar-devel

As current datastore and journal maintainer, some points:

I'm still not sure will ml path proposal scheme work on not, it removes
some bugs.sl.o issues but adds new e.g. it is pretty hard to collaborate
(in my mind) via ml history, in case of bugs.sl.o, someone can just
share http link to complicated query. Other thing is that on bugs.sl.o
it is easy to query tickets by keywords for example.

And since having patches both on bugs.sl.o and ml is pretty useless and
there is no regular way to attach 0.90 targeted keyword to ml posts,

The man page for git format-patch from git 1.7.1 shows options like

   --subject-prefix
   --add-header

which can be used to tag patches for branches.

These options can also be configured in .gitconfig or .git/config like so:

   [format]
   headers = Organization: git-foo\n
   subjectprefix = CHANGE

(@Martin, Bernie: how would one configure branch-specific format settings?)

Finally, Trac-like querying capabilities can be easily regained via email
search tools like notmuch.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] bundlebuilder should not use locale name

[Michael Stone]

On Mon, 26 Apr 2010 17:42:37 -0400, Walter Bender walter.ben...@gmail.com 
wrote:
 diff --git a/src/sugar/bundle/activitybundle.py
 b/src/sugar/bundle/activitybundle.py
 index a1f10b9..c83257f 100644
 --- a/src/sugar/bundle/activitybundle.py
 +++ b/src/sugar/bundle/activitybundle.py
 @@ -69,6 +70,9 @@ class ActivityBundle(Bundle):
  if linfo_file:
  self._parse_linfo(linfo_file)

 +if self._local_name == None:

This line should test self._local_name against None with is rather
than with == to better conform to PEP-8.

Otherwise, the patch looks good to me.

I have merged it into my repo:

  http://dev.laptop.org/git/users/mstone/sugar/commit/?id=78a59e6c

with the change mentioned above.
  
Michael


pgpeUl1rNLTQI.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] #1725: Resize home window on screen size change

[Michael Stone]

On Mon, 26 Apr 2010 10:09:02 +1000, James Cameron qu...@laptop.org wrote:
 Looks good; checked it against pygtk docs.
 Not tested, can't resize on OLPC XO, so no impact expected.
 
 Reviewed-by: James Cameron qu...@laptop.org

Merged as 

  http://dev.laptop.org/git/users/mstone/sugar/commit/?id=cd845ea5

Michael


pgpgrgAvhsuH3.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Experimental work... updated.

[Michael Stone]

Thanks, Michael, this has been the first viable method for getting Sugar
0.88 working on an XO-1.5 ... I'd been needing that for some time; to
check new bugs we find in 0.84 against 0.88, and to develop changes
against 0.88 after I've done them on 0.84.


Double-apologies then for all the rough edges; since I never expected the work
to be useful to anyone but me, I spent rather less time polishing it than is
usual for me.


The missing package was python-decorator.  It's not in the build
dependencies in the Makefile.  See attached patch.


Merged; thanks for the patch!


The next stop was more interesting ... assuming that I would no longer
need any of the existing Sugar packages, I had removed them prior to
make install, using this command:

rpm -e \
sugar-datastore-0.84.1-1.fc11.i586 \
sugar-toolkit-0.84.9-2.fc11.i586 \
sugar-artwork-0.84.1-3.fc11.i586 \
sugar-presence-service-0.84.0-2.fc11.noarch \
sugar-0.84.15-1.fc11.i586 \
sugar-base-0.84.1-1.fc11.i586 \
sugar-update-control-0.23-1.fc11.noarch \
olpc-library-2.0.3-1.fc11.noarch \
ds-backup-client-0.11.1.g71d2f16-1.olpc3.noarch \
olpc-switch-desktop-0.7-1.fc11.noarch


I only removed the sugar-* packages (via rpm -e --nodeps). I haven't done any
work to replace the others yet. 


The result was failure to render the home window; because the
computer-xo icon could not be found.  Log from /tmp/olpc-dm-client.log
placed here:

http://dev.laptop.org/~quozl/2010-04-29-olpc-dm-client.log

I'm not sure why this has happened, but my guess is that there is a file
used that isn't installed by make install, but left over from the
RPMs.  When I reinstalled the removed RPMs, it all began to work again.


I took a quick look at this traceback and at my Makefile and I think that it
might be a simple order of operations bug in the Makefile. 


Does the attached patch fix the problem for you?

Regards,

Michael
From b3d094c5d63383fd32a267aebb62b6f98abbca51 Mon Sep 17 00:00:00 2001
From: Michael Stone mich...@laptop.org
Date: Thu, 29 Apr 2010 01:56:47 -0400
Subject: [PATCH] Update the gtk icon cache after all icons are installed.

---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 581f1dc..91d886f 100644
--- a/Makefile
+++ b/Makefile
@@ -240,7 +240,6 @@ install-slow: all
 	(export GCONF_CONFIG_SOURCE=`$(GCONFTOOL2) --get-default-source`;\
 	 $(GCONFTOOL2) --makefile-install-rule $(SCHEMADIR)/sugar.schemas);
 	$(UPDATE_MIME_DATABASE) $(DATADIR)/mime;
-	gtk-update-icon-cache -f $(ICONDIR)
 	for d in $(shell ls artwork/icons/scalable); do \
 		install -d $(ICONDIR)/scalable/$$d; \
 		for f in artwork/icons/scalable/$$d/*; do \
@@ -248,6 +247,7 @@ install-slow: all
 		done; \
 		(cd $(ICONDIR)/scalable  $(ICONMAP) -c $$d) \
 	done
+	gtk-update-icon-cache -f $(ICONDIR)
 
 install: install-fast install-slow
 
-- 
1.7.0

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Experimental work... updated.

[Michael Stone]

On 4/28/10, Daniel Drake d...@laptop.org wrote:
 On 28 April 2010 11:57, Michael Stone mich...@laptop.org wrote:
 You couldn't find logs of the failure because olpc-dm is redirecting
 stdout and
 stderr to /dev/null.

 I don't think this is true.

I wrote from memory and, as you say, the details of what I wrote are
inaccurate:

   http://dev.laptop.org/git/projects/olpc-utils/tree/src/olpc-dm.c#n348

in that stdout and stderr are redirected to log files rather than to /dev/null.

Looking over my notes, I compiled with

   make -f Makefile.build CFLAGS=-DDEBUG

This removed the freopen() calls.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Experimental work... updated.

[Michael Stone]

On Tue, Apr 27, 2010 at 10:46:05PM -0400, Michael Stone wrote:
 I particularly like that I can test sugar*-0.88 directly on my XO by running
 something comparable to
 
   yum install git-core gcc glibc-devel make vim
   git clone git://dev.laptop.org/users/mstone/sugar; cd sugar
   make xo-builddeps
   env PREFIX=/usr ./configure
   make; make install

 All these steps worked on XO-1.5 os121.

Good.

 but the next step escapes me.

I was testing on os201; I haven't updated the XO yet. This may be the cause of
the difference.

 At the moment, olpc-session starts, Sugar starts with the nickname
 prompt, but doesn't proceed beyond colour choice dialog.

The color choice dialog doesn't load very much of the sugar codebase.

The doesn't proceed beyond behavior strongly suggests that an exception is
being thrown.

 Looking at logs, presence service isn't sticking around once it is
 launched by D-Bus.  I couldn't find any logs of the failure.

You couldn't find logs of the failure because olpc-dm is redirecting stdout and
stderr to /dev/null.

Fortunately, olpc-utils rebuilds easily on the XO as soon as its builddep,
ConsoleKit-devel, is installed.

   (Just run make -f Makefile.build; make -f Makefile.build install.)

Then you can redirect the stdout/stderr output to the log file of your choice
or, as I do, you can run /etc/X11/prefdm manually.

   (To enable this, I usually tell /etc/event.d/prefdm to run /bin/true and to
   not restart, thereby dropping me off at the virtual terminals on each
   reboot.)

Also, alternately, you can install Xephyr and use it from Gnome or raw
X+metacity to find out what's going on.

 Looking at an strace of a startx with .xinitrc containing olpc-session,
 the presence service isn't passing import decorator, so I'll look into
 that.  Maybe it needs another package.

Entirely possible.

 Oh, and the colour choice XO icon wasn't there.  Just the click to
 change message, back and forward buttons.

Thanks for the report; I'll see if I can produce the same behavior.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Experimental work... updated.

[Michael Stone]

This is just a quick note to let interested parties know that I've updated my
experimental repo at

   http://dev.laptop.org/git/users/mstone/sugar
   git://dev.laptop.org/users/mstone/sugar

to sugar*-0.88.

For those who are curious, this repo:

   * combines all six of the sugar, sugar-toolkit, sugar-base, sugar-artwork,
 sugar-datastore, and sugar-presence-service repos into a single repo [1],

   [1]: To see how, google for git subtree merge. The progit.org and
   kernel.org hits are both helpful.

   * replaces the complete autotools infrastructure of all six repos mentioned
 above with a single top-level Makefile of some 250 lines, and

   * removes most uses of logging from the sugar python source code in favor of
 error-reporting via cgitb's verbose tracebacks [1] and info reporting via
 print.

   [2]: cgitb is a little-known module in the Python standard library which
provides verbose tracebacks in either plaintext or HTML.

Regards, and apologies in advance for the remaining rough edges,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Experimental work... updated.

[Michael Stone]

On Tue, Apr 27, 2010 at 11:44:39AM -0400, Michael Stone wrote:
 This is just a quick note to let interested parties know that I've updated my
 experimental repo at
 
http://dev.laptop.org/git/users/mstone/sugar
git://dev.laptop.org/users/mstone/sugar

Looks good.  Even has my #897 fix in it.  Thanks!

My pleasure; thanks for the patch. 

 I like the idea of one repository, it makes working with it much easier.

I particularly like that I can test sugar*-0.88 directly on my XO by running
something comparable to 

   yum install git-core gcc glibc-devel make vim
   git clone git://dev.laptop.org/users/mstone/sugar; cd sugar
   make xo-builddeps
   env PREFIX=/usr ./configure
   make; make install

I also like how easy it is to consider patches that touch multiple subsystems
in their entirety.

 Have you noticed a significant performance improvement from removing
 logging?  I did before I found the O_SYNC on a slow system.

Neat!

(I haven't timed it yet myself -- I made the change soley because, for me, it
improves the signal-to-noise ratio in the codebase.)

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] use ConsoleKit instead of HAL for

[Michael Stone]

On Wed, Apr 21, 2010 at 01:19:54AM -0400, Michael Stone wrote:

   For what it's worth, I would prefer to see a patch which simply
 called sudo /sbin/shutdown -h now and sudo /sbin/shutdown -r now. I don't
 see the value that D-Bus and ConsoleKit are providing here.

 That patch was rejected some time ago. [1]
 
 [1] https://bugs.sugarlabs.org/ticket/615

Sigh. :(

 It is, nevertheless, true that the authentication details vary from
 platform to platform. I just don't think they vary enough to be worth making 
 more
 use of D-Bus and ConsoleKit.

 I guess the worth of going through ConsoleKit comes from keeping close
 to the Gnome codebase and being able to apply parts of their
 documentation to Sugar - we're rather sparse on the latter.

Do you still feel the same way, Tomeu?

 P.S. - I might feel differently if I knew how to make D-Bus and
 ConsoleKit work sanely with chroots, which I care about deeply for purposes
 of testing.
 
 I do most of my development work inside chroots, usually with no system
 DBus available. 

Whereas I do most of my work with the system bus available via 

   mount --bind /var/run/dbus $(CHROOT)/var/run/dbus

and with internal and external /etc/passwd databases that match on the relevant
uids.

 I've recently landed several patches in mainline that allow this to work. 

Neat; I'll go take a look.

 To me, having shutdown/reboot not work inside a chroot is a feature, not a
 bug. ;)

ln -sf /bin/true /sbin/shutdown completely addresses my need in this regard.

What's the equivalent with ConsoleKit?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] use ConsoleKit instead of HAL for shutdown/reboot

[Michael Stone]

Sascha wrote:

 HAL is dead, ConsoleKit now handles shutdown / reboot.

I still prefer the /sbin/shutdown approach taken in sl#615 to the D-Bus based
mechanisms that Tomeu prefers but I am concerned that this may be an area of
irreconcilable difference between Tomeu and myself. Therefore, in the interests
of momentum, let's merge your patch and move on. It's easy to change in the
future if the communual opinion on ConsoleKit shifts.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] use ConsoleKit instead of HAL for

[Michael Stone]

Paul wrote:
 james wrote:
   On Tue, Apr 20, 2010 at 07:55:45PM -0400, Chris Ball wrote:
Hi James/Sascha,
Reviewed-by: James Cameron qu...@laptop.org
Did you test on XO-1 or XO-1.5?  I'm curious how much of a backwards-
compatibility break this is.
   
   No, I only did a code review and cross-check against ConsoleKit API
   documentation.
   
   However, I've just applied the patch on os119 on XO-1.5, restarted Sugar
   and tested Restart and Shutdown options, and they function correctly.
   Restart causes a UL screen and reboot.  Shutdown causes a UL screen and
   power off.
 
 so, can someone tell me (gently) why either of these techniques
 is better than simply invoking /bin/reboot or /bin/shutdown? 
 (other than the fact that those will work even if hal isn't
 running?)

Sascha, Paul,

For what it's worth, I would prefer to see a patch which simply called sudo
/sbin/shutdown -h now and sudo /sbin/shutdown -r now. I don't see the value
that D-Bus and ConsoleKit are providing here.

Reactions?

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] use ConsoleKit instead of HAL for

[Michael Stone]

Paul wrote:
 michael wrote:
  Paul wrote:
   james wrote:
 On Tue, Apr 20, 2010 at 07:55:45PM -0400, Chris Ball wrote:
  Hi James/Sascha,
  Reviewed-by: James Cameron qu...@laptop.org
  Did you test on XO-1 or XO-1.5?  I'm curious how much of a backwards-
  compatibility break this is.
 
 No, I only did a code review and cross-check against ConsoleKit API
 documentation.
 
 However, I've just applied the patch on os119 on XO-1.5, restarted 
   Sugar
 and tested Restart and Shutdown options, and they function correctly.
 Restart causes a UL screen and reboot.  Shutdown causes a UL screen and
 power off.
   
   so, can someone tell me (gently) why either of these techniques
   is better than simply invoking /bin/reboot or /bin/shutdown? 
   (other than the fact that those will work even if hal isn't
   running?)
  
  Sascha, Paul,
  
  For what it's worth, I would prefer to see a patch which simply called sudo
  /sbin/shutdown -h now and sudo /sbin/shutdown -r now. I don't see the 
  value
  that D-Bus and ConsoleKit are providing here.

 that would certainly solve OLPC's problem, but i suspect sugar
 wants something more portable than that in the codebase.

The path /sbin/shutdown is mandated by the FHS and supported by all three
major BSDs. The suggested commandline options are also quite portable. 

It is, nevertheless, true that the authentication details vary from platform to
platform. I just don't think they vary enough to be worth making more use of
D-Bus and ConsoleKit.

Michael

P.S. - I might feel differently if I knew how to make D-Bus and ConsoleKit work
sanely with chroots, which I care about deeply for purposes of testing. 

I know how to make the /sbin/shutdown approach work sanely with chroots.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Hi; GSoC?

[Michael Stone]

Isaac,

Welcome, and thanks for setting such a good example for other potential GSoC
participants. 

 I wonder if this Zero/Sugar project could use some GSOC support, 

I agree with Ben that 0install-related Sugar work likely encompasses at least
one good and worthy GSoC project.

First, it's a good springboard toward networking, cryptography, and UI design,
if you have interests in any of these areas.

Second, you'll get to meet and to work with maintainers from both 0install and
Sugar, so it will be a great open-source educational experience.

Thrid, it's got an exceptionally direct educational benefit; namely,
tremendously improved access to software for connected Sugar learners like
those in Uruguay, Paraguay, and elsewhere.

 or if there are more useful/important things to work on?

First, *definitely* take Walter up on his offer of advice. (In fact, if you're
both willing, please take notes and publish them; I'd like learn from your
conversation!)

Second, take a look at ideas that people have expressed interest in mentoring
in the past. Many of them are still relevant. 

Third, talk to people visiting OLPC or Sugar deployments. Bernie Innocenti,
Daniel Drake, Bryan Berry, Caroline Meeks, and Simon Schampijer are all great
people to track down. (And there are many more, especially if you're interested
in making friends in the southern hemisphere.)

Finally, here's a short list of various people's essays and emails on exciting
technical problems and potential solutions from which you (or others) might
fashion an interesting and useful project:

   networking:
 http://wiki.laptop.org/go/Network2/Paper
 http://wiki.laptop.org/go/Network_principles
   
   platform:
 http://dev.laptop.org/~mstone/draft-sugar-core-priorities-01.txt
 http://lists.sugarlabs.org/archive/sugar-devel/2008-July/007441.html
 http://lists.laptop.org/pipermail/devel/2008-June/015838.html
   
   journal+datastore:
 http://wiki.laptop.org/go/Journal2
 http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal
 http://wiki.laptop.org/go/Olpcfs
   
   security:
 http://dev.laptop.org/git/security/plain/bitfrost.txt
 http://wiki.laptop.org/go/Rainbow/Next_Steps

More questions?

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Seeking enlightenment...

[Michael Stone]

Dear Tomeu, 

Thanks for writing back so promptly. 

I wrote to you initially because you were the person who touched the ticket,
but it seems that my remarks are probably better directed to Simon. Therefore:

-

Dear Simon,

 Right, we have a processes in place [1] [2] [3] and those help us to 
 make our work possible. 

I see that you have written and adapted many processes containing several
valuable ideas about how to make good releases.

 We can not discuss each ticket, enhancement, Feature again and again and
 create a new strategy each time. 

Indeed not. 

For what it's worth, one strategy that has served me well for quenching
discussions of this nature is to promptly merge the changes when a maintainer
ACKs them, as Tomeu did for the approach in #1447 all the back in October:

   http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg09878.html

and as other developers have done periodically ever since.

 There are people following those processes, so it can't be a that hard thing
 to do.

It's good that you've written a process that some people are able and willing
to follow. 

However, as Mel and Chris regularly remind us, the fact that a small number of
people are able and willing to participate in a process does not indicate that
the process is actually accessible, appropriate, or benign.

As a recent example, consider your discoveries about hover palettes. They
definitely work well for several people. Unfortunately :)

 If you have a look at our schedule [4], you will understand in which 
 phase we are in.

The purpose of my email was to (forcefully) remind you of the opportunity to do
a good thing for everyone who tests activities and for Wade, Gary, Bernie, and
me. 

As the release manager, you are authorized to make the call. 

(However, in exchange, you are also accountable for the consequences of the
decision.)

 Back to work, as I have to release modules, write release notes, make 
 sure the testers have an image to work on, etc. I might even look at the 
 new patch that Aleksey has submitted to #1447 because he seems to care 
 about it.

Thanks. 

 Michael, If you have free cycles I am sure you will find a place to 
 contribute to the 0.88 Release and help to make it a successful Sugar 
 Release.

I try, in my own small way.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Seeking enlightenment...

[Michael Stone]

Tomeu,

In what way is Sugar or the Sugar community materially improved by deferring
Wade's patches in #1447 to sugar-0.90?

Michael

[1]: http://bugs.sugarlabs.org/ticket/1447#comment:16
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] TurtleArt-83

[Michael Stone]

 I have a new refactored version of Turtle Art (a fructose module) that
 has many new features for the Sucrose 0.87.4 unstable release. Still
 some debugging to do, but generally it seems to be in good shape. The
 tarball is available here:
 
 http://download.sugarlabs.org/srv/www-sugarlabs/download/sources/sucrose/fructose/TurtleArt/TurtleArt-83.tar.gz

Walter,

This URL works better for me:

   
http://download.sugarlabs.org/sources/sucrose/fructose/TurtleArt/TurtleArt-83.tar.bz2

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Rainbow in F-11 and F-12

[Michael Stone]

 I'd like to import rainbow 0.8.6 in Fedora devel and backport it to
 F-11, for the purpose of getting it in the Paraguayan build, and maybe
 also in the F11-XO1 and SoaS, if there's interest.

Thanks. Let me know what assistance you'd like.

 Anything important I should be aware of?

My suggestion is to first try following the installation instructions for Sugar
by hand and to play with the result for a few minutes. That will provoke some
questions which you should send to me. Then you might want to write a script
that implements those instructions for inclusion in your build-system of choice.

One notably issue not covered in the current installation instructions is the
need for a cronjob or bootjob to periodically call rainbow-gc.

Finally, in the long run, it would be nice to figure out how to make use of
rainbow-0.8's ability to resume individual uids. (Martin Langhoff expressed
some interest in this issue in dlo#8814.)

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Mockups of Home view showing Start new

[Michael Stone]

Gary C Martin wrote: (edited)
 Some quick mockups of a Home view idea mentioned in previous discussions.
 Just intended as extra material for todays irc design meeting.
 
 1) Ring of activity icons reverts to the Start new behaviour; Journal icon
 is always shown for easier access, with recent activities shown below for 
 quick
 resuming. Journal icon and recent activities are shown horizontally for better
 screen balance (at cost of not matching the real Journal list display
 orientation).
 
  
 http://wiki.sugarlabs.org/go/File:Home_mockup_with_horizontal_journal_and_start_new_defaults.png
 
 2) Same as above except that the Journal icon is top left and a top to bottom
 resume icon order is used so that recent activities are shown in the same 
 order
 and direction as is experienced in the Journal list view:
 
  
 http://wiki.sugarlabs.org/go/File:Home_mockup_with_journal_and_start_new_defaults.png
 
 3) Here's a 3rd for the mentioned double ring of activity icons; inside
 non-colour icons for Start new behaviour, outside ring of coloured icons
 for Resume behaviour. Journal icon shown at top of ring for easy access
 (note that its coloured icon in the Start now ring is now out of place):

  
 http://wiki.sugarlabs.org/go/File:Home_mockup_with_double_ring_of_start_new_and_resume.png

Gary,

These mockups are very nice; thanks. Naturally, I particularly like your
rendition of the double-ring. :)

Several comments on the vertical and horizontal displays suggested by Eben: 

   a) the displays would be better if they grouped activities by type. the
  reason is that your visual memory would then be of some use in finding the
  thing that you want.

   b) the journal icon isn't distinctive enough to really nail down the arrow
  of time. perhaps narrowing the icons as they recede into the past or
  adding more explicit temporal labels would help?

   c) both the vertical and horizontal designs are visually unbalanced and fail
  to integrate meaningfully with the page's primary graphical elements.

   d) how will the frame interact with the horizontal and vertical displays?

More generally, though, I really like the idea of expanding the layout
algorithms to place both start new icons and resume icons. 

Some of the neat displays that I think we could envision as a result of this
look like:  

pre
  (* = start new,  .  = resume)

   .  .*:
 *.. .**  *
 *o ..*  or :*o  
 *.   X  .*   X*
 *..  *   *  .
:*.  *
/pre

Note that the ASCII * and . are much too large in relation to the central XO
figure.
  
Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity

[Michael Stone]

Simon,

 Most of the kids click on the activity icon when they want to start a 
 new activity. 

Would you care to try patches to show both start new and resume icons on
the home view (and maybe in the journal too)?

Yours,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] ANN: rainbow-0.8.6 release.

[Michael Stone]

Friends,

I am pleased to announce the release of rainbow-0.8.6. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.

The key differences between this release and its predecessor include support
for garbage collection of uids, ui sugar for resuming uids, bug fixes to the
resume logic, and a simplified singly-linked list library.

This release was made possible by encouragement and suggestions from Sascha
Silbe, Bernie Innocenti, and Benjamin Mako Hill. It has been (minimally) tested
on Debian Sid, Ubuntu Karmic, and Fedora Rawhide and has been packaged in
Fedora Rawhide for your convenience.

Interesting links for this release include:

 git:git://dev.laptop.org/users/mstone/security
 tar:
http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.6.tar.bz2
 browse: 
http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.6
 setup:  http://wiki.laptop.org/go/Rainbow/Installation_Instructions
 tests:  http://wiki.laptop.org/go/Rainbow/Testing

The shortlog from rainbow-0.8.5..rainbow-0.8.6 is:

Bernie Innocenti (1):
   Capture XAUTHORITY.

Michael Stone (19):
   Remove unused flexibility from the spool option parsing code.
   First pass at updated rainbow-gc.
   Clean up group membership.
   Protect sticky uids from garbage collection.
   Clean up some per-uid Xephyr data.
   Improve spool detection checks.
   Install rainbow-gc.
   Add some logging to rainbow-gc.
   Make xephyr usage resumable.
   Teach rainbow to resume uids with more auxiliary groups.
   Add a simple resume subcommand.
   Add INIT() and COPY() operators from dnshash.
   Add a novel singly-linked list implementation.
   Add test_endgrent script.
   Simplify list traversal logic.
   Fix Karmic sudo segfault.
   Tweak warnings and link flags.
   Set default spool location in rainbow-gc.
   rainbow-0.8.6.

Kind regards,

Michael 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels

[Michael Stone]

Tomeu wrote: 

 Yes, but what about security? Right now the shell process only
 executes code in /usr, executing activities in a separate process.

Executing activities in separate processes provides no security benefit unless
the resulting processes are in some way isolated from the rest of the system.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] ANN: rainbow-0.8.5 release.

[Michael Stone]

Friends,

I am pleased to announce the release of rainbow-0.8.5. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.

The key differences between this release and its predecessor are bug fixes,
preliminary support for network isolation, and a better rainbow-sugarize
plugin.

This release was made possible by encouragement from Fabian Affolter, Luke
Faraone, Martin Langhoff, and my friends at sandboxing.org. 

Interesting links for this release include:

git:git://dev.laptop.org/users/mstone/security
tar:http://dev.laptop.org/~mstone/releases/SOURCES/rainbow-0.8.5.tar.bz2
browse: 
http://dev.laptop.org/git/users/mstone/security/tree/?id=rainbow-0.8.5
setup:  http://wiki.laptop.org/go/Rainbow/Installation_Instructions
tests:  http://wiki.laptop.org/go/Rainbow/Testing

The shortlog from rainbow-0.8.4..rainbow-0.8.5 is:

   Michael Stone (10):
   Correct a logging statement.
   Make rainbow-sugarize set up /{data,instance,tmp}.
   Temporarily disable $XAUTHORITY processing in rainbow-sugarize.
   Drop config file management from rainbow-sugarize.
   Add a network option enabling unshare(CLONE_NEWNET).
   Make nss-rainbow's return and error codes more accurate.
   Correctly calculate number of members of a struct group.
   Make getpwent() resume on the correct uid.
   Grant network access to rainbow-easy programs.
   rainbow-0.8.5.

Finally, please note that:

   * rainbow-run now calls unshare(CLONE_NEWNET) unless the -o network
 command-line argument is given. This argument is given by the
 rainbow-easy helper since X11 clients are unable start without it.

   * rainbow's nss module must still be activated in /etc/nsswitch.conf in order
 for the software to function correctly. See the setup instructions linked
 to above for details.

Kind regards,

Michael 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] some efforts that would be really useful for

[Michael Stone]

Gary,

 I'm curious, is there something flawed with the current process where
 deployments add translations to pootle via translate.sugarlabs.org so strings
 are pushed over to activities held in git.sugarlabs.org ready for re-release?

There are many things flawed with this process. The most important ones from my
perspective are that:

  a) this translation process relies too heavily on low-latency internet access,

  b) this translation process sucks for OS software because it means that new
 deployments can't use old OS releases as-is: they either have to hack them
 up or they have to wait for a new release with their translations, and

  c) this translation workflow requires a lot of training and technical
 expertise to use. I think that there are adequate systems with lower
 floors.

Anyway, Sayamindu and a bunch of other folks (including me) developed an
outline last year for how to address these issues: 

   http://lists.laptop.org/pipermail/devel/2008-June/015838.html

That outline led to the following presentation at last year's SugarCamp and
FUDCon:

   http://sugarlabs.org/wiki/images/0/00/Sugarcamp-cscott-i18n.pdf
   (Video may be available. Scott?)

which included a demo based on the following additional code:

   http://dev.laptop.org/git/users/cscott/click2trans

which may be of interest to you.

More questions?

Michael

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] 0depend feature request

[Michael Stone]

Aleksey wrote:

 To have some implementation mockups for next 0install debates,
 I've coded how(I'm thinking) 0install integration could be implemented
 in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned
 repos[2] and follow simple test case[3].
 
 [1] http://wiki.sugarlabs.org/go/Zero_Depend
 [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope
 [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test

Aleksey,

I tried out your patches in a Debian Sid chroot with

   zeroinstall-injector-0.42.1-1

installed and got the following exception in shell.log when running your test
case:

   Traceback (most recent call last):
 File /usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py, 
line 519, in __button_release_event_cb
   self._activate()
 File /usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py, 
line 531, in _activate
   self._resume(self._journal_entries[0])
 File /usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py, 
line 524, in _resume
   shell.resume(journal_entry, self._activity_info.get_bundle_id())
 File /usr/lib/python2.5/site-packages/jarabe/util/shell.py, line 222, in 
resume
   launch(bundle, handle, get_icon_color(metadata))
 File /usr/lib/python2.5/site-packages/jarabe/util/shell.py, line 238, in 
launch
   launcher.add_launcher(bundle, activity_handle, color)
 File /usr/lib/python2.5/site-packages/jarabe/view/launcher.py, line 185, 
in add_launcher
   zdepend.fetch(zfeed, progress, create_activity, cancel)
 File /usr/lib/python2.5/site-packages/jarabe/util/zdepend.py, line 49, 
in fetch
   downloaded = policy.download_uncached_implementations()
 File /usr/lib/python2.5/site-packages/zeroinstall/injector/policy.py, 
line 393, in download_uncached_implementations
   assert self.solver.ready, Solver is not ready!\n%s % 
self.solver.selections
   AssertionError: Solver is not ready!
   {Interface http://rox.sourceforge.net/2005/interfaces/ROX-Lib: None, 
Interface /home/sugar/Activities/Terminal.activity/activity/0depend.xml: v1 
(/home/sugar/Activities/Terminal.activity/activity)}

The problem seems to be that you haven't told the policy object to solve the
feeds. You can do that with 

   policy.solve_with_downloads()

and maybe in other ways too.

Anyway, after teaching zdepend.py to solve the policy, I ran into into further
trouble because my zeroinstall trust-db doesn't contain the ROX keys.

To deal with this, I think you need to construct the policy object with a
Handler object

   
http://0install.net/python-api/html/zeroinstall.injector.handler.Handler-class.html

and override its confirm_keys method.

@Thomas, Rene: is this about right?

Michael 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] 0depend feature request

[Michael Stone]

Aleksey wrote:

 yeah, in my testing environment I have remains from previous 0install
 sessions
 
 I've pushed new commits with fixed these issues and added cancel button

Aleksey,

Your test case passes on my system with these additional commits.

Nice work,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] DNS Mischief, cont'd: dnshash-0.3.0 released!

[Michael Stone]

Friends,

I am pleased to announce the release of dnshash-0.3.0. dnshash implements the
hash-based DNS resolver described in Scott's Network Principles document. 

The key features of this release are better testing and more reliable results. 

   * Better testing was accomplished via the network containerization features
 of recent kernels.

   * More reliable results are achieved by returning only live addresses:
 i.e., those which successfully respond to a ping within one second.

Many thanks to Bernie Innocenti for his patches, to Cortland Setlow and
Andres Salomon for assistance with testing, and to Aurelian Jarno for his
prompt assistance with (e)glibc bugs.

Interesting links for this release include:

   git:git://dev.laptop.org/users/mstone/dnshash
   browse: http://dev.laptop.org/git/users/mstone/dnshash/tree/?id=dnshash-0.3.0
   readme: http://dev.laptop.org/git/users/mstone/dnshash/tree/README
   tests:  
http://dev.laptop.org/git/users/mstone/dnshash/tree/docs/unit_testing.txt
   bugs:   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557596
   env:http://wiki.laptop.org/go/Network2

The shortlog from dnshash-0.2.0..dnshash-0.3.0 is:

Bernie Innocenti (2):
   Eat up extra space in nsswitch.conf on 'make disable'.
   Make redirection work in /bin/sh; fix lint.

Michael Stone (8):
   Only return live addresses as results.
   Add newnetns subcommand to ease testing.
   Teach dnshash to answer AF_INET6 queries.
   Add a manual unit-test script based on network namespaces.
   Teach dnshash to specify the proper prefix for addresses it suggests 
adding.
   Tuck in modprobe instructions, just in case.
   Add maintainer script.
   dnshash-0.3.0.

Kind regards,

Michael 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Display a message when an activity fails to start

[Michael Stone]

Wade,

 Would love to get some testing on the latest patch!  There was an
 occasional crash bug but it seems to be fixed now.

I just tried out your current patches in ticket #1447 and I am very
happy with them so far. They make it much more pleasant to test systems
for missing dependencies by running lots of activities because it is now
easy to close the failed activity launch windows.

Thanks for the good work,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Zero-install-devel] Summary of the chat on #sugar-meeting

[Michael Stone]

Dear z-i folks and sugar folks,

Three members of the 0install.net community [1] met with several members
of the Sugar community [2] yesterday to exchange knowledge and, in the
case of the Sugar folks, to learn more about z-i and whether it might be
a good fit for use in Sugar activity installation. 

After the meeting, Thomas wrote up a great set of notes (mostly
describing his answers to Ben's questions) here:

   http://comments.gmane.org/gmane.comp.file-systems.zero-install.devel/2776

Please peruse this QnA if you'd like to know what was discussed and
please follow up with someone who seems approachable if you develop new
questions as a result of reading.

Next, it seems that several of the z-i participants decided after our
meeting to try out Sugar (on a variety of platforms) and to share their
experiences in replies to the z-i-d thread I mentioned above. 

Therefore, for your convenience, I have collected a few of their notable
remarks in the sequel of this email. Please read through them and
respond if you feel so moved.

Kind regards,

Michael

P.S. - Eben and Sebastian: you are both personally CC'ed since I saw
several experience reports that looked like they would be of specific
interest to each of you.

P.P.S. - Ben and Rubén: you are CC'ed because you both mentioned to me
after the meeting that you found it useful for solidifying your
perspective on the relevance of technology like z-i to Sugar. Could you
each please reply with a summary of what you learned?

[1]: The z-i folks: Anders [afb], Rene [rsl], and Thomas [talex]
[2]: The sugar folks: Bernie [bernie], Sebastian [sdziallas], 
  Ben [bemasc], Aleksey [alsroot], Rubén [quidam] and myself

Now for the experience reports:

Anders F Björklund wrote:
 I tried to use the Ubuntu 9.04 version of Sugar, but it seems like
 it has some problems (wouldn't even start) and trying to use the PPA
 version seems to have messed up the whole system (so had to revert)

 Eventually I went with Fedora Sugar on a Stick (strawberry flavor),
 but we couldn't really make sense of it in the default boot setting
 with the black-and-white icons and all the small help text in english.

 Will try to look for some better testing instructions, but so far
 it has stumped both adult and child trying to run it on the Netbook.
 (Couldn't even figure out how to turn it off, so had to hard-power.)

--

Thomas Leonard wrote:
 Typing halt in the Terminal activity worked for me :-/

--

Rene Lopez wrote:
 The version that worked right for me was 0.86 (Debian unstable) and it's
 configured to work inside xephyr. I also didn't understood how it works
 but so far this is what I have found:
 * The X symbol represents you and your computer to shut it down right
 click it and a menu should appear.

 * The symbols that are around the X are the favorite Activities, left
 click will open them.

 * The small symbol under the X is the last used open activity.

 * To switch applications you move the pointer to a corner and a frame
 should appear.

 * And finally if your computer only has a one button mouse you can leave
 the button pressed to get the same behavior as the right click.

--

Anders F Björklund wrote:
 So I guess my experience with Sugar was similar to their experience
 with Zero Install and trying to run the old Subversion feed etc...
 But it seems less than smooth (chunky?) with Ubuntu 9.04 or Fedora 11.

--

Rene Lopez wrote:
 I think that the problem is that their target users have a teacher to
 explain how to use it and the teacher has a printed manual so it's not
 hard to them but for an outsider it will be very different to anything
 that you have used and it doesn't self document making it somewhat
 frustrating.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

Tomeu,

 If you insist on thinking that I have something against you, then I
 will stop having this discussion with you. 

I insist only on the reasonableness of taking you literally at your word.

Naturally, I'm quite certain that you have nothing against me that you
don't also have against anyone else who is as damn persnickety as I
am... 

except when you write otherwise.

 I'm really tired of you continuously bringing this as a problem but not 
 hearing anyone else caring about your troubles contributing.

Three points:

   1. It makes sense that you're tired of hearing about it; I'm tired of
  it being a problem. 

   2. The phrase but not hearing anyone else caring... confuses me. I
  can't tell whether you mean that I'm deaf to other people caring,
  that no one else cares, or both. Both cases seem implausible to me,
  but evidence is always welcome.

   3. My troubles contributing are adequately controlled for by avoiding
  sending actual patches. You saw this one only because Bernie said
  that he liked the effect when I showed it to him and because I told
  him that if he liked it, then he should recommend that others try it. 

  (Actually, you might have seen it earlier when I mentioned it to
  you in IRC a few weeks ago, but I can easily understand how a
  single line of IRC traffic is easy to miss.)

 I stand by what I said: substantial user experience changes will be
 considered only after discussion involving the design and deployment
 teams (which we are having now). This is not just for you but for
 anybody else that proposes patches for the modules that I maintain.

I understand but continue to question the usefulness of the decision
given its obvious overhead and consequences. Enjoy the fruits of your
choice.

 Try going to a GNOME or KDE module and proposing that they accept such
 a patch so people can test it, they are going to laugh at your face.

Sugar is not GNOME or KDE (nor the kernel, where experience demonstrates
that the pattern you refer to is actually fairly common). Consequently,
we should find out what's right for Sugar. There's nothing wrong with
you having one position which is different from mine.

 Maintenance is already a hard enough task, if the community thinks
 that a maintainer should also be accepting all patches, releasing
 them, packaging them, making soas spins, asking for feedback,
 reverting them, etc. Then I will be glad to pass maintenance to
 whoever is available to do these kinds of things.

If you find such a person, then please consider it -- I think Sugar
would benefit greatly from having a maintainership community with the
resources to do those things in that order, as I suggested in more
detail in the remaining part of my last email to which you didn't reply.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

A word of initial warning: please turn on your sense of the absurd
before reading. This response is written with a deep sense of amusement,
rather than angst.

Tomeu wrote:

 I'm more concerned about developers proposing big user experience
 changes because they feel it's better. 

Yay, more roadblocks and stereotyping! :)

Are you actually saying that you'd prefer either

   a) no patches or,
   b) patches that I think make the system worse?

 Before I look at the patch I would like to know if there's agreement
 from people close to our users that this behavior change is desired.
 How can we get that?

Well, trying it might be one good way to start. :)

After that, shipping it in an explicit beta is another more heavyweight
but nevertheless time-tested approach.

Failing that option, you likely need to find some product specialists.

...

For what it's worth, I do view this patch as a UI bandaid to the
underlying problem that hover-to-click-somewhere-else is the wrong UI
affordance for the home screen to use in supporting discovery of and
access to variant or associated behaviors. The patch is, however, still
a big improvement that is available today.

Now, as for what better look like: treat each view has having a
primary layout algorithm for Sugar-level UI actions. This algorithm
should effectively arrange logically related groups of capabilities as
determined by metadata attached to the capabilities and as determined by
the current filtering criteria for the view.

In actual activities, this layout algorithm is the new toolbar
approach. The filtering criteria are hover-or-click on an expandable
toolbar item.

In the circle view, I'd like to see the layout algorithm expanded to lay
out arcs of smaller option icons each with the same prelighting and
saturation behavior as partial halos around the exterior perimeter of
the activity icons. Naturally, there are some obvious interesting
extensions involving zoom effects and more subtle saturation behaviors.

Lastly, it seems to me that a similar approach might also be effective
in the mesh view and around the central XO-figure.

Kind regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

Simon wrote: 

 On 10/13/2009 04:36 AM, Bernie Innocenti wrote:
  I'm loving how the menus suddenly are now snappy and responsive. 

  From: Michael Stone ...
  Subject: Make various palette animations happen more quickly.
  ...

 Can you describe what the patch will change from the user point of
 view? 

Of course I can. In fact, I believe that Bernie and I already did, in
the lines of your message that I quoted above. Do you actually find
these lines to be obscure?

(I inquire most particularly because I'm nearly certain that you could
have learned the user-visible effect of the patch more quickly and
more easily by trying out the change yourself than by asking. Maybe you
had a more complex goal in mind than simply learning the nature of the
user-visible change which justifies the additional delay and round-trips
that your request incurs?)

 Is this to get rid of the delayed build up of palettes when hovering 
 over icons?

Yes, this is the purpose of setting the length of the build-up animation
to be 0.0 seconds.

 The delay is on purpose.

Of course it is. Unfortunately, that does not make it good.

Now, after trying out the patched version vs. the unpatched version, do
you actually find that you prefer the current behavior?

Kind regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

Tomeu wrote:
On Wed, Oct 14, 2009 at 16:57, Michael Stone mich...@laptop.org wrote:
 Tomeu wrote:

 I'm more concerned about developers proposing big user experience
 changes because they feel it's better.

 Yay, more roadblocks and stereotyping! :)

 You shouldn't take this personal, most of Sugar contributors including
 me have done this in the past. 

humorI don't take it personally; I take it on behalf of oppressed
contributors everywhere...!/humor 

(In other words, judging the patch by its author rather than by its text
and its effects does seem to me to be a rather risky business. Your
choice, though.)

 I'm just saying that now might not be such a good idea any more to
 accept changes in the user experience without user feedback.

Far better to accept the changes, get the user feedback on the changed
versions, then revert the changes if they turn out to be inappropriate.
Everyone will be happier. (That's my opinion, anyway.)

  Are you actually saying that you'd prefer either
 
  a) no patches or,
  b) patches that I think make the system worse?

 Yup, this is certainly absurd. 

I'm glad that we agree.

 If, say, Gary comes later and proposes a patch to revert yours, should
 I accept it in fear that I may discourage him otherwise?

Yes, but in awareness rather than in fear, (though only unless you have
an overriding reason not to.)

Being concerned about developers proposing big user experience changes
does not seem to me to meet that criterion. To my mind, overriding
reasons not to include the patch is...

   * incorrect
   * illegal
   * an obviously bad idea
   * a subtly bad idea
   * more trouble than it's worth

At best, it has been argued so far that merging the patch I showed to
Bernie is a subtly bad idea because it leaves the obvious possible of
refactoring of the context menu code to remove the use of the animation
code unimplemented.

In the middle, Eben expressed uncertainty on the basis of a specific
vision and private memories. This shouldn't impede merging the patch; it
should just encourage more testing and thought based on his experiences,
vision, and thought experiment so that we get more data.

At worst, it has been argued that merging the patch is an obviously bad
idea because it was developed by a developer (me; who else was supposed
to develop it?) engaged in critical dialogue with and reflection on the
Sugar user experience (I do feel that it's better) via methods that I
find congenial as opposed to by methods that I find prohibitively
expensive. 

Did I miss any other positions in the debate?

C'mon, I'm just asking that when substantial changes to the user
experience are proposed, that we have some discussion that involves
the design team and the deployments. Is this really so off?

I'd call it more timid than off. Or at least inappropriately
deferential to the wishes of the design team and the deployments who
talk to you at the expense of receiving more contribution by making
contribution more dynamic and fulfilling and therefore at the expense of
exploring more possible Sugar experiences.

 Before I look at the patch I would like to know if there's agreement
 from people close to our users that this behavior change is desired.
 How can we get that?

 Well, trying it might be one good way to start. :)

 After that, shipping it in an explicit beta is another more heavyweight
 but nevertheless time-tested approach.

You know how easy is making a spin of SoaS with such changes for
people to try out, or are you saying that you want me to do this work
for you?

I'm saying three things; namely, that:

   1. I trust that you and the other people on this list are empowered
  and able to make reasonable UI decisions when presented with clear
  alternatives,

   2. Patches are an appropriate way of exchanging proposals for software
  modification and a good medium for discussion of those proposals, and

   3. Applying a 6-line patch to a jhbuild root, to a Sugar chroot
  produced with my scripts, or to a live Sugar install is a hell
  of a lot easier (and more valuable to know how to do) than my
  cooking up a SoaS image just for interested people to try out said
  patch.
   
(For the record, I'm more sympathetic to the SoaS argument with rainbow
stuff but the rainbowish work that I'm doing at the moment lies in the
area of network isolation and community-building [c.f. my new playground
at sandboxing.org] rather than in Sugar integration.)

 Now, as for what better look like: ...

I'm having trouble getting your proposal, maybe some mockups would help.

A fair request, but one that is probably doomed to wait until someone
with graphics and/or animation skills comes along to help me transform
my words into pictures and movies. 

(Interested folks should please contact me; I'd be very happy to work
with you on obtaining such visual materials.)

Regards,

Michael

P.S. - For even more humor, count how many words have gone into this
thread so far

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

 Daniel wrote:
 2009/10/13 Bernie Innocenti ber...@codewiz.org:
  Hello,
 
  Michael just passed by the Acetarium and, since the dinner was late,
  we found the time to test and review his latest prototype^W patch.
 
  I'm loving how the menus suddenly are now snappy and responsive.
 
 I haven't tried it, and your mail also lacks an explicit explanation
 of what your patch actually does, but based on the hints you have
 provided, :
 
 It makes all menus that currently have a delay appear instantly?

It makes the menus appear and disappear much more quickly by setting the
length of their animations to be 0.0 seconds, thereby simulating
snappy and responsive. Whether or not their appearance and
disappearance is instantaneous depends on your processor; Python and
GTK are still surprisingly slow.

 I don't like the idea, as I think that the delay has influenced
 Sugar's UI design quite heavily.

You're obviously entitled to your opinion. I'd still appreciate it if
you tried out the patch.

 For example, a user is on the home screen with ring view enabled, and
 the mouse cursor is on the left side of the screen. The user wants to
 shut down the XO. He moves the cursor towards the XO figure in the
 middle of the screen, but while doing so passes over an activity icon
 in the ring. The menu immediately appears, completely obscuring the XO
 figure that he was going to click on.

I have actually tried to produce this behavior. In practice, I can't
find anyway to make it frustrating because the menus also *disappear*
quickly when the cursor leaves their boundary.

(I would nevertheless be interested in hearing about actual experience
reports from frustrated users.)

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

Eben wrote:

 We should definitely get feedback. I wouldn't be entirely opposed to a
 change, but I do want to make sure that we make such a change for the
 right reasons, and that it's actually the right change to make.

 So try it, and encourage your friends to do the same! :)

 I don't feel inclined to myself, as I've never had a problem with the
 delay, and actually used to find the speed with which these palettes
 obstructed my view of the screen frustrating before the delay was
 increased. 

Do I correctly understand that 

   a) when you wrote we should definitely get feedback up above, you
  actually meant YOU should get feedback and bring it to me. and
  that

   b) when you wrote I definitely want to make sure that we make such a
  change for the right reasons you were not, in fact, considering
  does it feel good to use? to be a critical part of the right
  reasons?

 I have no itch.

You don't need to have an itch to try to help someone else accomplish a
reasonable goal that you do not actively oppose. That's called

   Encouraging Contribution.

 The initial design intent was to develop a system which worked in a
 sufficiently complete manner without needing palettes at all. Kids
 should be able to start activities, resume activities, join
 activities, write, paint, stop, etc. without ever seeing a palette at
 all. [1] This is the low floor. For kids with more experience or
 curiosity, we decided to provide contextual palettes which grouped
 related actions and provided more complex interactions with the
 system. This is no ceiling. Furthermore, we wanted to help introduce
 kids to the availability of additional options in a discoverable way,
 which is why the hover effect was chosen to provide increasing levels
 of detail and interaction for a given object.

 This is a good story, but a bad implementation. A better implementation
 would be to provide the extra options in a *visible but unobtrusive

 I disagree that this is an obviously better implementation. 

Which of the following do you disagree with?

   a) visible but unobtrusive is a lower floor than hover

   b) visible but unobtrusive is a higher ceiling than hover

   c) visible but unobtrusive is provides increasing levels of detail
  better than hover

   d) other objection

 It's better if you're one who frequently has needs for the additional
 complexity. 

I'm actually claiming that it's uniformly better: hover without a lock
open as is available in the new toolbars is Just A Bad Idea,
particularly as we see more devices with touchscreens.

 It's arguably not if you use only (or mostly) primary actions.

Having the sub actions be always available in the same field of view but
unobtrusive, e.g. by means of effective use of color, contrast, and size
just seems like a better solution to me. I'm sorry that I don't have the
code or animations necessary to demonstrate this today. However, that
lack should in no way alter our consideration of the current patch.

 form* or, if you absolutely must hide them, to make them visible with a
 device like a complexity slider or like the new toolbar's transient
 hover; lock on click behavior.
 
 Adding a preference for the delays for these palettes, as we have for
 the frame, is a another reasonable possibility, and a literal
 incarnation of the complexity slider you suggest.

It's one choice, but it's a bad one. We can do better.

Also, it is not a complexity slider, most notably because it is not
visible in the same field of view as the interface it controls.

 Remember -- comparisons should be made in a fixed visual field, not
 across multi-second long gulfs of time, cursor positioning, and fine
 motor control.

You didn't respond to this principle. Do you accept it or feel that it
misses some important cases?

 Finding that many kids were actually waiting for the palette to appear
 always, instead of, for instance, simply clicking on an activity icon
 to join it, encouraged us to INcrease the delay on the palettes to
 help emphasize this as a secondary mechanism for interaction. A agree
 that hovering in one place to click in another isn't great; but that's
 also not the intended primary means of interaction, and should only
 really be done when one of the secondary actions is desired.

 Understandable, but as you say, the result isn't great. This makes it
 better. Try it! Merge it! (Then come up with something better.)

We had lots of trouble with palettes obscuring other elements of the
UI even with short delays, including, potentially, the desired target.
I can't imagine that this issue has gone away in the intervening
months, and removing the delay entirely seems it would exacerbate the
issue. Do you have any experiences to report in this regard?

As I wrote to Daniel, my experience was that the overall increased
responsiveness of the UI more than made up for any annoyance that I
experienced as a result of its occasionally poor layout choices. 

Re: [Sugar-devel] Assorted Debian+Sugar bugs

[Michael Stone]

 On Mon, Oct 12, 2009 at 07:52:11PM -0400, Michael Stone wrote:
 Jonas  co:
 
 I just wanted to report a couple of regressions that I found today
 while trying out sugar-0.84 on Sid. In no particular order:

Thanks for reporting this.

You're very welcome; thanks again for your hard work packaging sugar!

 Even better, however, is if you file issues like this as proper
 bugreports.

I haven't diagnosed the causes of these issues so I don't actually know what
packages are at fault yet; I'm just reporting behavioral regressions.
Consequently, I don't know what packages to file the bugs against. :)

 I will respond here, cross-posted to both list, to respect your choice
 of communication platform.  But there is a higher risk that your
 information will not get tracked and the issues not solved by doing it
 this way.

By all means, feel free to enter the information into the tracker of your
choice. I will be happy to follow your lead. I simply do not wish to file
reports with faulty information.

  4. Lastly, it seems surprising to me that installing
 education-desktop-sugar and sugar-0.84 results in fewer activities
 installed on Sid than it does on Squeeze. In my testing today, Pippy was
 the only activity visible in the List View.
 
 Yes, I currently package all parts of Sugar currently officially
 packaged for Debian, and yes, I am involved in the Skolelinux project
 too.  But no, I am *not* involved in that education-desktop-sugar
 package and it is poorly maintained as far as I am aware.  I recommend
 that you remove that package to not confuse yourself and others about
 what is Sugar in Debian.

Thanks for this clarification; I shall improve my test cases. Thanks also
working to narrow dependencies -- this is always appreciated. You may, however,
be interested to know that, as of yesterday, sugar-0.86 depends on
substantially more material than sugar-0.84. (To the tune of 300 MB more, I
think.)

 P.S. - Please also find attached the output of dpkg -l run from inside my
 testing chroot. This chroot was constructed by the code in the sugar
 branch of
 
  http://dev.laptop.org/git/users/mstone/puritan
 
 with conf/distro == debian and conf/debian/distro == sid.

 Ahem, does this mean that you did not in fact use a Debian system but
 some homecooked lookalike?

I test sugar in chroots so as to be able to efficiently generate reproducible
results across multiple distros. My debian chroots are constructed with
debootstrap, as is apparent in the debian.mk Makefile in source code that I
mentioned. 

I find that this leads to an excellent and rewarding testing workflow because
it is very low-frustration, because it permits me to test both stable and
unstable versions of the code, because it permits me to control for differences
in packaging, and because it permits me to work up system changes across
package boundaries by editing in vivo before worrying about how to present
those changes to the rest of the world.

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.86 Branching - Activity

[Michael Stone]

Wade wrote:

On Thu, Oct 1, 2009 at 5:20 AM, Simon Schampijer si...@schampijer.dewrote:

 *Activity versions*
 As we use integers for activity versions (this really has to change for
 0.88 with introducing minor versions), we need to cope for the famous:
 stable/unstable version issue. I would say to leave at least 3 version
 numbers open when doing a new unstable release. An example:

 Walter has submitted TurtleArt 69 for 0.86. He reserves the numbers 70,
 71, 72 for bug fix releases. When he is doing a release from the
 unstable master branch (0.88 development) he is using numbers  72.


I'm still against this plan.  Does anyone else feel like the integer numbers
are a good thing?

Insofar as I think that version numbers are a good thing, I think that integer
version numbers are just fine. I'm just surprised that people are so timid
about using larger integers. 

(That being said, lexicographically-ordered major-minor-patch tuples would work
just as well (or as badly) for me as ordered integers because they reflect just
as little of the actual history of its authorship, its test status, its
stability, its platform-compatibility, and its bit-for-bit identity (as is
needed for cryptographic operations).)

We have been striving to keep activity releases backwards compatible as far
as possible; there should be no need to branch activities for sucrose
releases.  If a bug is found, sucrose can be updated to the latest version.

Perhaps you meant that the activity can be updated to the latest version?

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar

[Michael Stone]

Dear Sugar folks,

I have avoided wading into this discussion for some time because I wanted to
see where it went without my interference. Therefore, before I say anything
else, thanks for the entertaining show. :)

Next, here are some thoughts for you, based on my own work, uses of Sugar, and
past conversations with other principals.

Regards,

Michael



Dan wrote:

 It will affect packaging and distribution. My suggested model (as
 employed all over the open source world) is that the developers would
 release source distributions and let distributions do the packaging
 and distribution.

My suggested model, employed all over the real open source world, is that
people write web pages (the most popular kind of open source software!),
publish them at URLs, and feed those URLs to interpreters. 

Only people with unusual quality or distribution requirements release or
package their web pages. Most people just write them and fix problems that
people yell about.

Consequently, I want to make using activities more like web pages. That's why I
work on rainbow and on networking design.

NB: ZeroInstall, which was mentioned earlier in this thread by Ben, sure seems
to me like it comes from the kind of world that I want to live in, even if
Bernie isn't so sure because the page he tried to visit contained an broken
link. Remember, the web used to be that way too!

 Even though a Sugar system with distro-installed packages is crippled
 (activities cannot be erased or updated through any realistic means),

Then we should not rely on distros for dealing with activities. (They're
absolutely a great thing to build Sugar Platforms out of; they're just not so
useful for this other crazy thing we want to do. This is fine. Browsers are
also an absolutely great thing which is not right tool, today, for the
activities problem.)

 But we also have activity authors that don't want to go through the
 hassle of learning git :/

 This is getting completely ridiculous. So how do they manage the
 versions and releases of their packages?

They don't. In my opinion, ideally, they click a URL and the software they
clicked runs most of the time. They don't care what version is underneath. If
they want to change it, they hit view source and edit. If they want to share
it, they share the URL, however they like.

If they want to merge their changes with those of other people or if they want
their software to run on the computers of people with wildly different setups,
then, eventually, they learn more about the art of building portable software.

The point is that none of version control, packaging, releases, and so on are
necessary for having fun writing software or for learning; they're just useful
for engineering.

 Do these get put on a.sl.o?

Probably not. Many of the people doing the work won't even have internet
access, though they will have local networks. Take Peru as a simple example.

 If so how do we verify the source code and whether it can be
 distributed?

We don't and we can't. But other people can and will anyway.

 How do we verify any binary content they might include?

We don't and we can't. But people will happily use it anyway.

 What they do privately is their own business but if it appears on
 a.sl.o it needs to be verify able and trackable. 

Sure. Ben's point is that supporting this personal hacking is A PRIMARY USE
CASE. If we're not doing it, we should give up and go home.

However, take heart: there is a DIFFERENT primary use case; namely, supporting
distro-based engineering efforts useful to deployments, which is quite amenable
to the sort of solution you're comfortable with.

I believe that these are compatible points of view as soon as we admit that
different mechanisms are needed for the differing use cases. What's the problem
here?

 There needs to be a minimum set of requirements.

Your set of minimum requirements is a good set of requirements for
engineering a great distro like Fedora, but that's not the only thing we're
doing here. In particular, your minimum requirements violates Sugar's design
goal of low floor, high ceiling. Them's the breaks.

 And even worse, we want people who are not yet able to create
 activities from scratch to do simple modifications to existing
 activities and redistribute them.

 That's fine. Its open source and it then becomes their problem but it
 shouldn't be a central issue what they want to do with modified
 activities. 

It's a central issue because, as Ben explained, supporting it is a fundamental
principle of our work. Consequently, we're allowed to solve other parts of our
problem in different ways, but not in ways that are incompatible with it.

 The activities hosted on a.sl.o should meet a minimum
 requirement. Otherwise we get into a situation where there's no
 guarantee of the Activity whether that been the source or the
 stability of it.

Please read Stuart Cheshire's law of 

Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar

[Michael Stone]

Ben wrote: 
 Michael Stone wrote:
 Consequently, I want to make using activities more like web pages. That's
 why I work on rainbow and on networking design.
...
 In my opinion, ideally, they click a URL and the software they
 clicked runs most of the time. They don't care what version is underneath.
 If they want to change it, they hit view source and edit. If they want to
 share it, they share the URL, however they like.

 Thank you for this perspective.  I think this is a very helpful way to
 think about our software behavior goals, especially if we imagine our URLs
 as being a bit content-addressable.

I'm glad that you find it helpful and would be curious to know whether other
people feel the same way or differently.

 Lastly, about the idea of shipping everything in Python, or Java, or
 Smalltalk: Give up -- this works for mobile phones, not for things to think
 with! Programming languages are prime examples of things to think with.
 We're trying to provide people with lots of these, and with the best ones
 that we can find, remember?

 Hmm... but surely web pages are the prime example of a medium that
 contains an extremely limited variety of languages?

Not really. On the client side, there's HTML, CSS, Flash, PDF, Javascript,
various video formats, various image formats, various sound formats, Java
Applets, ActiveX controls, integration with mail and news clients, and more. On
the server side, there is even greater diversity.

We can argue about whether this collection is a small or large number of
languages. I don't really care. It suffices for my argument that the web does
not contain One Language To Rule Them All and that there are extremely
well-known conformance problems in the interpreters for these languages and yet
things basically work out anyway because there are so many redundant ways of
accomplishing the goal, which is learning.

 I have come to accept that we should provide people with lots of
 languages, but I think we can, and should, choose our interpreters to
 retain independence of platform, and isolation from distro issues.  Even
 x86 assembler can be such a language, given an appropriate interpreter.
 
 For a particularly strange glimpse into the future:
 
 http://www.codebase.es/jsgb/
 
 [1] http://www.qemu.org/qemu-doc.html#SEC69

Neat examples. I'm glad that we agree that more languages is basically good.
As for interpreters -- I absolutely agree that they should be chosen carefully.
I just think that the interpreter that we choose carefully should be the one
that prepares to run a program (e.g.  by fetching and installing it, or by
caching it, etc) rather than the one that runs it.

Does this distinction make sense?

Kind regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Friends view UI affordances?

[Michael Stone]

Folks,

Before you know how Friends work, the Friends view it is completely barren
except for the central XO-person and, as a result, is rather unusable. What are
some ways that we could make the function of this screen more discoverable?

So far, I've thought of a couple of things which might do the trick, but I'm
interested in your feedback too. My ideas include:

 1. Putting up a label when you have no friends telling you how to go get some.

 2. Putting up a combobox listing people who you might add as friends.

 3. Putting up a display like the journal empty display to try to tell you
why you aren't seeing anything.

 4. Putting up a button to move you to the neighborhood view, perhaps with a
notification event to inform you of what to do.

Thoughts?

Michael


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)

[Michael Stone]

0install looks quite promising to me and 

  http://www.osnews.com/story/16956/Decentralised_Installation_Systems

is good reading about the general issues involved.

Has anyone here experimented with it?

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)

[Michael Stone]

(Regarding 0install):

 It is interesting, but fails horribly badly in the case of no, or low  
 bandwidth Internet. 

I'm not convinced, for three reasons.

First, there is 0share

   http://0install.net/0share.html

which seems to me to be remarkably similar to our long-stated goal of
horizontal distribution of code and translations.

Second, there is 0export

   http://0install.net/0export.html

which makes setup.sh install scripts which integrate with the rest of the
tools, including 0share, mentioned above. (This sounds rather similar to me to
the fancy customization stick that we've previously thought about building.)

Third, everything that I've seen in 0install so far is HTTP-based. This means
that it should play reasonably well with any XS-based HTTP caching that we wind
up organizing and with my work on http://wiki.laptop.org/go/Network2, should
that ever amount to anything.

 Just imagine the mess when some school on a low bandwidth high cost satellite
 link downloads Wibble Activity.xo and  pops it on there local server, or
 perhaps kids themselves start to  share the bundle, or distribute it on a USB
 stick from one to another.  

See above.

 Think of all those extra nasty yes/no/are your sure dialogues

I think that this is a matter of programming and integration, not of
fundamental design.

 subsequent download failures and support calls, and the
 school or districts bandwidth budget...

I'm not sure I follow your argument here. Can you elaborate on how this is any
better or worse than the other large things people might try to download?

 No insult or disrespect to the original developer, or those trying to  
 make it an activity, but the latest example 
 http://code.google.com/p/sarynpaint/ 
 is an extremely simple/basic bitmap paint program written in Java,  
 that would take less than a day for me (and I am certainly no expert)  
 to duplicate from scratch in Python. Imagine the huge amount of  
 bandwidth, and install failures if this just got uploaded in ignorance  
 of all the duplicate dependancy downloads this would impose on remote  
 communities.

Let's see here:

   * I'm not sure I understand your point about install failures, so you'll need
 to clarify that one for me.

   * As far as the bandwidth goes... I'm actually more concerned about disk
 space, myself, due to my previous arguments about caching, horizontal
 distribution, and self-determination.

   * Finally, doesn't it seem to you that the ease of decentralized software
 distribution with dependencies and space sharing afforded by this
 technology might make it a lot easier for you (or for our friends on
 sugar-desarrollo@) to collaboratively develop and distribute your lean and
 mean replacement?

 Do you want a hand full of activity developers to bare the time effort  
 and cost of producing a quality, efficient, well thought through and  
 designed activity? Or put that cost on to 100,000+ children and their  
 country school systems? 


 How many ebooks could you distribute (and store) for the bandwidth (and nand
 space) taken up by downloading the required dependancies for Java. 

When possible, I'd rather just provide easy access to both and see which our
Learners prefer and I am coming to believe that this sort of decentralized
distribution technology might be a good way to achieve this goal.

 And once such a download system is in place, what will be the next
 unsupported language someone will try to ship an activity in?

Languages will be less expensive to support.

 Apologies for the rant.

No apology needed. I'm not trying to push something over on you; just trying to
point out some interesting technology that seems surprisingly well aligned with
my understanding of our goals. 

(And which we could learn a lot about documentation and technical writing
from!) :)

Regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] erasing the journal and config

[Michael Stone]

 Luke Faraone wrote:
 James Cameron qu...@laptop.org wrote:

 I've tested this method only on unlocked laptops.  For locked laptops
 some similar method might be used.

 For locked laptops you would *need* to get a developer key, or have OLPC
 sign the file. The latter won't happen.

OFW's recently-added multi-key support:

   http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support

has been used by several deployments (including Uruguay and Paraguay) who might
be interested in producing a wipe power.

A scheme similar to the activation lease generation scheme could also be used
to rate-limit how quickly such a power could be invoked.

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] A security vs. functionality question

[Michael Stone]

Lucian, Ben:

Here are a bunch of reactions. Apologies for the delay. :)

Michael




Lucian Branescu wrote:
 A chroot because afaik rainbow doesn't really work outside the XO
 distro My impression may be wrong, though.

Would you mind taking a look at 

   http://wiki.laptop.org/go/Rainbow

for me and letting me know what questions you are left with?





Ben Schwartz wrote:
Rainbow is not currently used much outside of the XO, but it should be,
and it can be.  Michael Stone, who developed it, no longer works for OLPC,
but he has continued to update it.  It can be packaged for any distro.
There has been some bitrot; Sugar needs to be tweaked to regain
compatibility. Someone will have to be bold enough to write the patches.

Sascha and I actually wrote the most important patches several months ago and
Tomeu merged them last weekend in response to #593. (Thanks, Tomeu and Sascha!)

(That being said, there's more fun to be had -- check out the next steps
Rainbow page!)





Lucian Branescu wrote:
 I had assumed everyone has root access, it is such a basic need for a
 machine you own.

The most notable existing Sugar users I know of who lack easy root access are
the kids using Sugar in Uruguay and Ethiopia. It's an unfortunate situation.






Ben Schwartz wrote:
 To educators:
 How concerned are you about a feature that allows one student to invite
 others to play on their computer?  Remote access is only granted if the
 user chooses to share a specific activity.  The effect is similar to
 letting someone walk over and type on your keyboard.

With current technology, it's a bit more like letting any stranger with a
nametag that reads Jimmy walk over and type on your keyboard when you
actually meant to invite your friend Jimmy over to help you. 

(Also, do note that your simile also describes the current security properties
of activity installation, web browsing, Adobe-Flash playing, and perhaps of
plugging in USB sticks -- that is: non-existent.)





Ben Schwartz wrote:
 To engineers:
 Is sharing an activity a sufficient indication of intent from the user to
 execute a potentially dangerous action, such as sharing Terminal on a
 public collaboration server?  

Let's start with a more basic question: 

   what mental model(s) of software do we want to share with our learners?





Ben Schwartz wrote:
 An Activity can easily be stopped by a single click at any time.

Pff. On Sugar today, an activity can probably reformat your hard disk, reflash
your BIOS, or make toast on your IPv6-enabled toaster. (Such, by the way, is
the general state of desktop security.) Your only hope of stopping a malicious
activity is to cut the power.






Ben Schwartz wrote:
 One possibility that has occurred to me is to permit unsafe sharing only
 with users who have already been designated as Buddies.  Instead of Share
 with My Neighborhood, the toolbar would only offer Share with My Friends.

A good design exercise that I think might shed some light on your situation
would be to analyze your SharedTerm system, in both its current and in this
proposed form, in terms of Ka-Ping Yee's design principles for usable security:

   http://zesty.ca/sid/

(Also, do let me know if you would like to pursue this course -- I would enjoy
practicing with you.)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] code review (was Re: buddy tags)

[Michael Stone]

Tomeu,

I like your response but I'm surprised that you're confused about why your
review process is getting bogged down, so I'll share my perspective in the
hopes that you will find it helpful.

In short, expecting the submitter to do all the work listed in your review
process condemns many perfectly reasonable patches to oblivion and discourages
contributors from submitting. [1] 

What you should do instead is to build community around each patch *by directly
asking specific individuals* to step in. [2]

(Bernie, Sascha, Chris Ball, and I would all seem like good victims for code
review work.) [3]

This way, you get more people involved in each patch, familiar with its ideas,
and comfortable supporting one another. That's how you ramp up the volume of
contribution. [4]

Regards,

Michael



Notes:

[1]: Drucker famously wrote that 

   Management is about human beings. Its task is to make people capable of 
   joint performance, to make their strengths effective and their weaknesses
   irrelevant.

We aren't doing that very well here, which is why your process is failing. 

(He also had some good advice on how to do it: see, e.g., The Essential
Drucker, ISBN 978-0066210872).

[2]: The individuals can obviously say no, but I have found that we're all
/far/ more likely to do things when someone we respect asks us, personally,
to do them.

[3]: We're just good guinea pigs because we're all friends of yours who are
familiar with the Sugar code base, who like making lots of different small
technical contributions, and who I know to be capable of giving a decent code
review.

[4]: People like to feel good and helping your friends out in small ways often
feels really good. You should take more advantage of this phenomenon. :)



Other notes:

  * This strategy also works well for testing and deployment feedback; c.f.
Friends in Testing, NZ-testing, and the relationships that Greg formed with
people he worked with, like Pablo Flores.

  * Another good name for this strategy is providing good customer service.
You just have to realize that SL coders are customers of SL who are trading
time and frustration for satisfaction and experience.

  * Does anyone need more examples, clarifications, or advice?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] A Fine Tradition...

[Michael Stone]

Carrying on a fine tradition of July-based Sugar reflections [1, 2], I'm going
to offer some mostly unsolicited advice. (Sorry, Tomeu, but you asked me to
write. :^)

   Dear Sugar Labs,

   In the past year, you succeeded in removing two important barriers to entry
   for new developers: you have created a distinctive brand and you freed Sugar
   from the XO. 
   
   What's next? Here's a four-part RFC:

   1. Could we embrace POSIX and the RESTful Web throughout our software [3]? 

 POSIX and HTTP are the mother tongues of our ecosystem and developer base.
 By embracing them, we make our software much cheaper to explore and to
 modify.

   2. Could we live more within our packaging?

 This way, our packaging gets tested more quickly, we become more
 expert /at/ packaging, we make friends in our distros, we get better
 packaging, and our releases become easier!

   3. Could we make ourselves more interesting to be around, for example by
   saying maybe we could... or I have... (and you can too...!) more
   frequently than we say I can't.?

 Our strengths lie in our big, sexy, /powerful/ ideas. We can't shrink from
 these ideas; they sparked our desire to contribute and they will do so for
 others. (Otherwise, we will fade.)
 
   4. We could do more to help one another to develop as may be necessary to
   advance those big, sexy ideas.

 (Anecdote: I don't think any of us here today started off understanding
 much about communities, UI design, networking, release management, quality
 assurance, or large-scale coding; I just see lots of people who looked for
 people who were smarter and more knowledgable than they were and who worked
 really hard to catch up. We should do more of that.)

   xoxoxo,

   Michael
 
   P.S. - In the spirit of walking the walk, I'll also share one of my own
   recent puny efforts in the direction outlined above:

 http://wiki.laptop.org/go/Network2

Regards,

Michael

[1]: http://lists.laptop.org/pipermail/sugar/2008-July/007304.html
[2]: http://lists.laptop.org/pipermail/sugar/2008-July/007390.html
[3]: (With suitable hacks under the covers of FUSE and DNS.)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] updating from aslo

[Michael Stone]

David,

Could you please point me to an explanation of why it's hard to get ASLO to
generate the microformat that is already understood by the tens of thousands of
sugar-0.82 machines in Uruguay, the US, and elsewhere so that I can form a more
solid opinion of your work?

Thanks,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] DNS Mischief

[Michael Stone]

On Sun, Jul 5, 2009 at 8:36 PM, Michael Stonemich...@laptop.org wrote:
 d) rewrite as an NSS module?
 e) rewrite in an external DNS resolver?
 
 Either of these would make it much easier to play with your patch,
 eliminating the whole now recompile your C library from scratch
 step. ;-)  

Pff. It got us this far. :)

 (d) would be the cleanest, and the code involved ought to
 be quite short.  With (e) you could make the names available to other
 machines our your local network, which could be cute (or awful, as you
 like).

The real advantage of (e) is that you can make it work on many platforms. The
problem with (e) is that it seems to take more than 80 lines of code.

 Network-disconnection issues also bear thinking about -- if you use a
 local IPv6 address for a local resource, can you handle its migration
 to the real network later as it roams off the mesh?  (It might be
 easiest to handle this as a clean disconnect/reconnect rather than
 going down the mobile IP path.)

I've thought a bit about this and, for the time-being, my cost/benefit analysis
(and recent professional experience) argues in favor of making apps better at
tolerating address changes in preference to going down the mobility road.

 Thanks for running with this idea, Michael!

My pleasure; thanks for taking the time to reply to me.

 (Although wearing my security hat I'd have to caution that MD5 has been
 deprecated for 13 years now, and even SHA1 is not recommended for new use.
 Use http://www.ouah.org/ogay/sha2/ -- it's just two files to add, tomcrypt
 not required.)

I agree that MD5 and SHA1 are deprecated as /cryptographic/ hash functions,
but I don't think that we care. Here's why:

Cryptographic hash functions are characterized by three notable properties: 

1. preimage resistance

for a fixed result R, how hard is to it to find a message M such that
H(M) == R?

2. second-preimage resistance 

for a fixed message M, how hard is it to find M' != M such that 
H(M) == H(M')?

3. collision resistance

how hard is it to find two distinct messages M, M' such that H(M) ==
H(M')?

My claim is that we only care about second-preimage resistance against a random
attacker (as opposed to an optimal malicious attacker). 

I believe that this is true because I think that second-preimage attacks by
random attackers accurately model the risk that a user types in a domain name
which, /by chance, rather than by malice/, happens to hash to an address that
collides with an address already being provided by a different service on the
network, or, equivalently, the risk that a user randomly chooses a name the
hash of which collides with the hash of an already present name. 

(In my present view, plain DNS was never meant to handle the threats posed by
malicious adversaries and it should not be relied upon to do so. Those risks
are, in my view, more adequately controlled by other tools like petnames,
reputation systems, PGP, SSH, and TLS.)

Am I just plain wrong?

 (Ob code review: I think you just want to fabricate a new link-local
 address entry based on the hash, rather than cloning and altering the
 existing LL address.  Link-local addresses have the prefix fe80::/64,
 with the lower 64 bits constructed from the first 64 bits of
 SHA256(hostname).  

I chose to clone existing addresses because I thought it was a convenient way
to get the addresses' zone ids (called sin6_scope_id in the sockaddr_in6 
struct)
right. Have you got a better way to do this part?

 You also should probably make sure that the hostname you're hashing is the
 full canonical host name, ie cscott.skiffserv.dyndns.org. (note trailing
 dot) not cscott or cscott.skiffserv or some other abbreviation.  

Hmm. I can see why you might want that from a network principles standpoint,
but I'm not sure that I'm convinced by your argument.

I guess: patches welcome. :)

--

The design issue that I find myself most interested in after having gotten this
far is: 

My current design is not in any way integrated into the recursive name
resolution process. This means that people who want to bind multiple names must
do so by adding an address to all their interfaces/zones for each name they
want to bind.

On the other hand, if I made something that were integrated into the name
resolution process, they could just run a nameserver for their domain and then
everything else should just work. (I think.)

Thoughts?



Kind regards,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Questions about GConf and ORBit.

[Michael Stone]

Tomeu,

I dug through the gconf, libbonobo, and orbit2 source code and discovered some
interesting things. Most relevant for this discussion:

* ORBit2, on Linux, defaults to sending messages over unix sockets in 
directories
like /tmp/orbit-$USER* which it carefully creates with mode 0700. There are no
configuration options for changing these permissions.

* it's easy to get orbit2 to use other transports with either per-user or
system-wide configuration.

Just run something like

cat  $CHROOT/etc/orbitrc EOF# resp. ~/.orbitrc
ORBIIOPIPv4=1
ORBLocalOnly=1
ORBIIOPUSock=0
EOF

and you'll be good to go. (With the obvious authentication consequences.)

Regards,

Michael

P.S. - I also pushed patches into

   http://dev.laptop.org/git/users/mstone/security 

which cause rainbow-sugarize to configure the activity root well enough to
launch Browse, Chat, Pippy, and Calculate and which comment out its $XAUTHORITY
processing since that logic isn't correct for unauth'd Xephyrs like the one
that I'm testing in.

This means that you can now test rainbow+sugar-0.84 in squeeze chroots and
perhaps in other settings well enough to launch several activities and to
collect interesting tracebacks. (Baby steps.)

P.P.S. - Packaging, anyone?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] DNS Mischief

[Michael Stone]

As many of you know, I've been fascinated for some time by Scott's Network
Principles [1]. 


Several weeks ago, I outlined in a lightly-circulated patch how one might hack
up libc's getaddrinfo() implementation to do the DNS resolution work described
in Scott's paper.

Here is a second copy of that patch, which I have improved to the point where I
am willing to recommend it for further testing, adaptation, and exploration.

(This new version uses libcrypt's MD5 implementation in favor of pulling in
chunks of libtomcrypt and it includes the minimum knowledge of gaih_service
structs necessary to work with ssh, wget, etc.)

To build it, grab your distro's libc6 packaging, apply the patch to
sysdeps/posix/getaddrinfo.c, and make sure that you define 

  crypt-in-libc = yes 
  
in an appropriate configuration file. Then build normally. Some tests for

getaddrinfo() will fail but you should wind up with a fully functional
libc.so.6 which you may install or use via LD_PRELOAD like so:

  # calculate an address for sonipes
  LD_PRELOAD=/path/to/libc.so.6 python -c 'import socket; print 
socket.getaddrinfo(sonipes, None)'

  # suppose we get fe80::b3da:e0e7:3bd7:278d%eth0

  # on sonipes:
  sudo ip addr add fe80::b3da:e0e7:3bd7:278d%eth0 dev eth0

  # elsewhere, on another computer on the same link as sonipes
  sudo env LD_PRELOAD=/path/to/libc.so.6 ping6 sonipes
  LD_PRELOAD=/path/to/libc.so.6 ssh sonipes
  (rsync, wget, nc6, ...)

Enjoy,

Michael

[1]: http://wiki.laptop.org/go/Network_principles

P.S. - Improvements are definitely welcome -- I found the code very satisfying
to use on a local wireless network.

  a) provide a cute one-liner for assigning appropriate addresses to interfaces
 based on the machine's desired hostnames

  b) check the code for endian-neutrality

  c) figure out how to fully build and package the result for easier testing

  d) rewrite as an NSS module?

  e) rewrite in an external DNS resolver?
diff -u eglibc-2.9/debian/changelog eglibc-2.9/debian/changelog
--- eglibc-2.9/debian/changelog
+++ eglibc-2.9/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.9-13.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/rules.d/build.mk: build libcrypt into libc
+  * debian/patches/any/hack-up-getaddrinfo.diff: install getaddrinfo hack.
+
+ -- Michael Stone mich...@laptop.org  Sat, 04 Jul 2009 19:06:59 -0400
+
 eglibc (2.9-13) unstable; urgency=low
 
   * debian/debhelper.in/nscd.init: fix return code when querying status
diff -u eglibc-2.9/debian/rules.d/build.mk eglibc-2.9/debian/rules.d/build.mk
--- eglibc-2.9/debian/rules.d/build.mk
+++ eglibc-2.9/debian/rules.d/build.mk
@@ -52,6 +52,7 @@
 	rtlddir=$(call xx,rtlddir) ; if test -n $$rtlddir ; then \
 		echo rtlddir = $$rtlddir  $(DEB_BUILDDIR)/configparms ; \
 	fi
+	echo crypt-in-libc = yes  $(DEB_BUILDDIR)/configparms
 
 	# Prevent autoconf from running unexpectedly by setting it to false.
 	# Also explicitly pass CC down - this is needed to get -m64 on
diff -u eglibc-2.9/debian/patches/series eglibc-2.9/debian/patches/series
--- eglibc-2.9/debian/patches/series
+++ eglibc-2.9/debian/patches/series
@@ -210,0 +211 @@
+any/hack-up-getaddrinfo.diff
only in patch2:
unchanged:
--- eglibc-2.9.orig/debian/patches/any/hack-up-getaddrinfo.diff
+++ eglibc-2.9/debian/patches/any/hack-up-getaddrinfo.diff
@@ -0,0 +1,111 @@
+From 55208c43bbd9ce5e21b7c9b77db6526e688ce612 Mon Sep 17 00:00:00 2001
+From: Michael Stone mich...@laptop.org
+Date: Thu, 11 Jun 2009 21:04:18 -0400
+Subject: [PATCH] Hack up getaddrinfo().
+
+---
+ sysdeps/posix/getaddrinfo.c |   74 ++
+ 1 files changed, 74 insertions(+), 0 deletions(-)
+
+Index: eglibc-2.9/sysdeps/posix/getaddrinfo.c
+===
+--- eglibc-2.9.orig/sysdeps/posix/getaddrinfo.c	2009-07-04 19:14:10.0 -0400
 eglibc-2.9/sysdeps/posix/getaddrinfo.c	2009-07-05 13:52:29.0 -0400
+@@ -62,6 +62,7 @@
+ #include nscd/nscd-client.h
+ #include nscd/nscd_proto.h
+ #include resolv/res_hconf.h
++#include crypt/md5.h
+ 
+ #ifdef HAVE_LIBIDN
+ extern int __idna_to_ascii_lz (const char *input, char **output, int flags);
+@@ -251,6 +252,81 @@
+ }	  \
+  }
+ 
++static void
++hack_dns  (const char *name, const struct gaih_service *service,
++	   const struct addrinfo *req, struct addrinfo **pai,
++	   unsigned int *naddrs, int *ret)
++{
++  /* XXX: Service processing! MS */
++  if (name == NULL
++   || (service != NULL  service-num  0)
++   || ( req-ai_family != AF_INET6
++  req-ai_family != AF_UNSPEC))
++  return;
++
++  char buf[16];
++
++  __md5_buffer(name, strlen(name), buf);
++
++  struct ifaddrs *ifaddr, *ifa;
++
++  if (getifaddrs(ifaddr) == -1)
++return; /* Should we set *ret? MS */
++
++  unsigned int old_naddrs = *naddrs;
++
++  for (ifa = ifaddr; ifa != NULL; ifa = ifa-ifa_next)
++{
++  if (ifa-ifa_addr-sa_family != AF_INET6)
++continue;
++
++  struct

Re: [Sugar-devel] Questions about GConf and ORBit.

[Michael Stone]

Tomeu,

Thanks for the prompt reply. 

 Do you know anything about such an assumption?

 No, but I don't see that in the logs. 

True.

 What I see is one process trying and failing to access GConf. 

Agreed. Do you have any advice on how I might extract a better error message
from it?

(Or on what symbols I should breakpoint in gdb so that I can see what's
happening?)

 Is there a GConf daemon running? 

Yes, but it's running under the credentials of the owning user (sugar) rather
than the requesting user. (Hence my suspicions.)

 Either using Orbit or D-Bus?

How can I tell?

 If so, what's the mechanism used by clients to contact the daemon? 

Again, how can I tell?

 Maybe an env var is missing?

Seems eminently plausible. Do you know of any env-vars that gconf-and-deps pay
specific attention to?

 2. Are more bleeding-edge versions of Sugar still using gconf-over-orbit?

 Sugar is a normal GConf client in this regard. My understanding is
 that if it links to the D-Bus client library, it will use D-Bus. Orbit
 otherwise.

Okay, thanks. I guess I'll just have to dig out the source code.

Thanks,

Michael
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel