Re: [Sugar-devel] Abandoned or orphaned activities

[Martin Dengler]

First, what are the numbers: extrapolating from this N=1 sample, how many 
activities can be maintained by a very experienced python and Sugar developer? 

Regards
Martin

> On Jan 23, 2019, at 07:27, Dave Crossland  wrote:
> 
> James, are you soliciting SL pay you as a contractor to fix Activities not on 
> the list?
> 
>> On Wed, Jan 23, 2019, 1:15 AM James Cameron > Nice idea, but hasn't happened yet, and I don't expect it to ever
>> happen without scaling up the number of testers and fixers.
>> 
>> We just don't have enough people paying attention.
>> 
>> How would you propose that attention be purchased?  Sugar Labs has
>> $95k we could spend.  You've seen from the list what my time can
>> accomplish each year, and that's not 100% of my time.
>> 
>> On Wed, Jan 23, 2019 at 08:03:16AM +0200, Tony Anderson wrote:
>> > My original point was that as a community we should view the activities on
>> > ASLO as a corpus to be treasured and protected. No activity can be either
>> > abandoned or orphaned. It is the responsibility of the community. When a
>> > change 'upstream' breaks an activity or set of activities, the problem
>> > should be resolved as soon as possible.
>> > 
>> > Tony
>> > 
>> > On 1/23/19 6:07 AM, James Cameron wrote:
>> > >On Tue, Jan 22, 2019 at 09:54:08PM -0500, Walter Bender wrote:
>> > >>On Tue, Jan 22, 2019 at 9:13 PM James Cameron <[1]qu...@laptop.org> 
>> > >>wrote:
>> > >>
>> > >> On Tue, Jan 22, 2019 at 01:29:56PM -0500, Devin Ulibarri wrote:
>> > >> > Hi,
>> > >> >
>> > >> > This was my experience:
>> > >> >
>> > >> >   • I came into SugarLabs community at the time that this 
>> > >> migration was
>> > >> > beginning to happen.
>> > >> >   • I started a GH account because that is where I was told the 
>> > >> software
>> > >> was
>> > >> > being maintained.
>> > >> >   • I have continued to "go with the flow" and work via GH 
>> > >> although I
>> > >> have come
>> > >> > to understand more of the history and context of this matter.
>> > >> >
>> > >> > These are my thoughts and opinions:
>> > >> >
>> > >> >   • I remember an argument that one reason to move to GH is "that 
>> > >> is
>> > >> where all
>> > >> > the developers are", but since our migration I have seen so 
>> > >> many kids
>> > >> > (usually GCI) set up new accounts with GH in order to 
>> > >> contribute to
>> > >> SL (and
>> > >> > to participate in GCI). This makes me think that many people 
>> > >> are
>> > >> willing to
>> > >> > join our development regardless of whatever tools/services we 
>> > >> use,
>> > >> and
>> > >> > whatever tool/services we use, if they are not yet setup with 
>> > >> them,
>> > >> they
>> > >> > are willing to get setup in order to join development.
>> > >> >   • Another argument seems to boil down to "we will be more 
>> > >> productive
>> > >> using GH
>> > >> > because we need not worry about the hassle of maintaining our 
>> > >> own
>> > >> code
>> > >> > hosting service". Is there evidence that we are more 
>> > >> productive now
>> > >> than
>> > >> > before? Not having the opportunity to learn/use the other 
>> > >> systems, I
>> > >> would
>> > >> > only be guessing.
>> > >>
>> > >> Not much evidence, it's about the same.  Like any tooling, you get
>> > >> good at it with time.  More productive now through the pull request
>> > >> and issue integration, but less productive through loss of 
>> > >> situational
>> > >> awareness; changes are hidden in GitHub rather than being posted to
>> > >> sugar-devel@, and new developers fixate on their favourite
>> > >> repositories.
>> > >>
>> > >> >   • In theory, SL running its own version control, seems to me 
>> > >> like it
>> > >> would be
>> > >> > a) more fun for someone interested in this kind of work, b) a
>> > >> learning
>> > >> > opportunity, and c) gives maximum freedom/flexibility to the 
>> > >> ways in
>> > >> which
>> > >> > we would like to do development.
>> > >>
>> > >> [2]git.sugarlabs.org hasn't needed any significant maintenance, and 
>> > >> is
>> > >> probably insecure now because of vulnerabilities that haven't been
>> > >> patched.
>> > >>
>> > >> [3]bugs.sugarlabs.org has needed updates, but they have generally 
>> > >> worked
>> > >> well.
>> > >>
>> > >>The spam issue made it almost unusable.
>> > >>
>> > >> >   • I would rather be using software that is licensed under a 
>> > >> FLOSS
>> > >> license
>> > >> > than a proprietary license. [4]gnu.org came up with some 
>> > >> criteria to
>> > >> evaluate
>> > >> > "code hosting services" such as GH: [1][5]https://www.gnu.org/
>> > >> software/
>> > >> > repo-criteria.html (which, btw, gets an "F", the lowest 
>> > >> grade) The
>> > >>

Re: [Sugar-devel] [SLOBS] [IAEP] [SLOB] Motion regarding xo-computer icon

[Martin Dengler]

> On 15 Sep 2017, at 14:13, Lionel Laské  wrote:
> 
> 
> +1 for the motion.
> 
> @Martin, thanks to wait for all votes or at least the end of voting delay.

Sure Lionel - what is the voting delay? I actually was waiting but the wiki had 
been updated already (not by me) so I figured as the wiki had been updated and 
the outcome was not in doubt it was ok to summarize it in an email. I agree the 
delay should govern in the future.

>   Lionel.

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

Re: [Sugar-devel] [IAEP] [SLOB] Motion regarding xo-computer icon

[Martin Dengler]

On Fri, Sep 15, 2017 at 10:12:28AM -0400, Walter Bender wrote:

Motion: To answer the questions posed by the SFC regarding the xo-computer
icon as follows:
(Q1) Why is the XO logo included in the sugar-artwork repo now -- and does
the SLOBs want to keep it there?
(A1) The xo-computer icon has been part of Sugar since we first designed
and built Sugar (beginning in 2006) and we would like to keep it there
until such time as the design team decides there is a reason to change it.
(Q2) Assuming the SLOBs want to keep the XO logo in sugar-artwork: what
outcome would the SLOBs *prefer* to see happen?  E.g.,
- Does Sugar want downstream users to be able to redistribute and modify
Sugar's codebase with or without the XO trademark file included in the
program?
- Does the SLOBs want downstream users to be able to modify and
redistribute the XO trademark image itself, or is that less important to
Sugar?
(A2) Sugar Artwork, including the xo-computer icon, is currently licensed
under the GPL and we would like our downstream users to be able to use all
of our artwork under the terms of that license. As far as the use of any
trademark image outside of the context of Sugar, we have no opinion.

[...]

regards.

-walter


I believe the motion has passed.  
https://wiki.sugarlabs.org/go/Oversight_Board/Decisions#2017-09-15

Martin


Motion 2017-09-15 "Motion regarding xo-computer icon"
=

URL: https://wiki.sugarlabs.org/go/Oversight_Board/Decisions#2017-09-15
Motion: 
http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054648.html
Second: 
http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054710.html

Votes and SLOB members (in order listed on
https://wiki.sugarlabs.org/go/Oversight_Board )

+1 Walter Bender [1]
+1 Lionel Laské  [2]
+1 Sameer Verma  [3]
  Adam Holt [4]
+1 Samson Goddy  [5]
+1 Ignacio Rodríguez [6]
-1 Laura Vargas  [7]
== =
+4 Total to-date
+3 Minimum
+5 Maximum

1. http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054648.html
2. http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054667.html
3. http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054713.html
4. Nothing found as of 2017-09-15 19:11 GMT on 
http://lists.sugarlabs.org/archive/sugar-devel/2017-September/thread.html
5. http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054710.html
6. http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054716.html
7. http://lists.sugarlabs.org/archive/sugar-devel/2017-September/054711.html


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

Re: [Sugar-devel] L-earning

[Martin Dengler]

On Tue, Jun 13, 2017 at 11:45:23AM +1000, James Cameron wrote:

On Mon, Jun 12, 2017 at 07:08:46PM -0600, Charles Cossé wrote:

Motivation: I've discovered that using internet access as a currency
results in effective learning.


This will benefit inattentive or time-poor parents who would rather
use hardware and software to control their children's social
behaviours.

Attentive or time-rich parents will be sufficiently involved in their
children that they can exert control socially, and won't need paid
service.


In the limit, yes, but a lot of parents are in between the time-poor and
time-rich extremes you mention; they may often have to prioritise what they
devote their attention to or exercise control over.

Also, a third credit-earning category of "build up enough credit and the
internet becomes accessible [until parents say it's time to stop / dinner /
etc.]" maps almost exactly to your "do your homework before you play on the
internet" use case, and strikes a different balance between parental and
automated supervision.


So your best bet will be to target this service at inattentive and
time-poor parents.

But only those parents living in houses sufficiently spread apart that
WiFi can be controlled.  Remote, rural, and suburban.


WiFi in urban areas is often not very open, so even in many urban areas this
WiFi-metering can be effective.


And only those parents who can recognise when an uncontrolled WiFi
access point appears; like a prepaid phone hotspot loaned by a friend.


True, but that's probably part of a "threat model" most parents/buyers would
understand to be not covered by their internet-metering service.


-Charles


--
James Cameron
http://quozl.netrek.org/


Martin


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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

Hi Tony

On Tue, Jul 12, 2016 at 11:29:16AM +0200, Tony Anderson wrote:

Hi Martin

Certainly we can move on and consider how the design of Sugar can be 
improved.


The keep button was valuable, but was somehow 'deprecated' as modern 
jargon has it.


This was the reasoning (from
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023439.html ):


I'd lean toward [removing "Keep"]. ["Keep"'s] intended purpose was always to
be a convenience on top of auto-save, that simply forced a new version.


There is a GSOC project to add version support to the Journal, and check out
the next sentence:


Once Sugar has full version support, and a Journal updated to take advantage
of it, restoring the Keep functionality as it exists probably wouldn't cause
problems anymore.



And lo and behold:


Until [the Journal has full version support], I think the auto-save is much
friendlier than the usual prompt-on-quit, with the possibility for lost work.




It had the function of saving the working document while allowing the user to
continue working. Apparently, the designers thought this should be done
automatically, so a button was not needed.


It *is* done automatically, right?


'Save as' is used to allow the user to open a document and then give it a new
name (or in most systems, a location).


Yes, and I understand that we want to help users give a good name to their
work.  Right now the user can give a document a new name in two ways: 1) go to
Journal and change the name; and 2) go to the activity palette and change the
name.  Note that this is very much the same modus operandi that many Google docs
users will be familiar with, although it's "the new way" for people that grew
up with the UIs I did.


Calling them 'Write.activity' is misleading at best.  The item is not a
Write.activity, it is a document created by the Write.activity which should
have a meaningful and relevant title.


I agree with you.  Would you (separate to this whole GSOC PR discussion)
support a patch to change the default activity name to "'s  work" or something similar?


Tony


Martin


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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

On Tue, Jul 12, 2016 at 11:52:10AM +0200, Tony Anderson wrote:
Regardless of the wording, the alert does not save a document until 
the user gives it a name. If the user does not care about the document 
enough to give it a name, there is probably a reason. For example, if 
I were to launch Paint to show selecting a color for a brush, I would 
have no reason to save the scribble.


To repeat, we need to consider this from the viewpoint of the user. 
The user click on the Stop button to quit the activity. The alert 
should result in terminating the activity whether the document is 
saved or not.


I think the 

This logic is used in the 'fiddler' implementation. It takes a moment 
to move the cursor to the entry, type an entry, and click save.


Have you watched a six year-old wonder why their activity isn't closing fast
enough on an XO-1 (which doesn't even have the enforced stop of a modal
dialog)?  Have you watched a child look away when talking to their friend, then
look back and not notice that a small part of the the screen changed and just
notice that they pressed quit and it hasn't?  Have you watched a small child
read some text that appears when they didn't ask it to, and then decide what to
do, then look down at the mouse pad, look back up, look back down to move, look
back up, move, miss the target button, look back down, move the mouse pointer
to the correct button, and press the mouse button?  Have you watched a small
child complete this multi-second reading-and-decision-required task without
distraction when they have already decided they want to be doing another Sugar
activity?  This "getting in the way of users" has been done to the death -- for
example, see https://blogs.msdn.microsoft.com/oldnewthing/20030901-00/?p=42723
-- and we have good bugs with good alternatives.

The children I have observed using Sugar would for sure spend longer 
closing and switching between activities without any benefit from this 
modal alert."


The alert only appears when the activity is closed not when switching 
between activities.


By "switching" I meant "closing one and opening another".  It would not appear
every time Sugar decides the journal object should be saved, right?


The modal alert gives the user a chance to give his project a title - I
consider that very beneficial.


Titles are beneficial, for sure.  Are they worth a modal dialog?  No.

How about this alternative: similar to how Browse notifies you that a download
has completed, let the activity exit *without* a modal dialog, but when the
activity closes and the sugar shell is in focus again, show the user the "name
or delete or whatever your journal entry" dialog in a non-modal way.  That way,
users that are prone to notice and care and name their work can divert from the
"quit this activity" process and name it, but users that don't notice or don't
care will not be interrupted.


The alternative is for the user to open the
activity palette and change the name there. The other alternative is for the
user to switch to the Journal and change 'Write.activity' to 'Bolivar report'.


The journal might even put the focus or highlight the latest entry and suggest
"Rename 'Write.activity' to 'Bolivar report'?".


Currently [the modal on-quit-ask-to-name-journal-entry dialog] is needed for
all activities


That sounds suboptimal :(.


Tony


Martin


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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

Hi Sam,

On Tue, Jul 12, 2016 at 08:59:55AM +1000, Sam Parkinson wrote:
I think that the current implementation of the "Choose a name" alert 
is fine.  It serves as a gentle reminder.


If it were optional, that'd be fine. But then it would not achieve its goal of
ensuring all Journal entries had an actively-chosen name.  I don't think this
goal is worth the cost.


Thanks,
Sam


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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

On Mon, Jul 11, 2016 at 07:19:26PM +0200, Tony Anderson wrote:

Hi, Dave
On 07/11/2016 06:49 PM, Dave Crossland wrote:


On 11 July 2016 at 11:55, Tony Anderson > wrote:


   Name this project. Entry is computerize, refers to the widget.


I was thinking of 'entry' like 'journal entry' - what are items in 
the journal called?


However, since the dialog already says "Please provide a name for 
your project" then I think "Project Name" is better than "Untitled" 
and my previous suggestion


Officially, I think they are called Journal objects. I tend to call 
them items. How about Utkarsh' strategy - to leave it blank. Saves 
translation and surely means that something should be entered. I don't 
know if we have the greyed entry option, if so a greyed (low opacity) 
Project Name would be completely appropriate.


"'s  Activity" was suggested by the designer of Sugar's UI and
one of its main programmers:

http://dev.laptop.org/ticket/3900
http://dev.laptop.org/ticket/3225

There is also a simple way activities could override this for a more
appropriate default than "Activity", like "Martin's Maze" (for Maze) or
"Martin's Write document" (for Write).  See ticket #3900 for the (old?) Browse
code.

Martin


Tony


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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

On Mon, Jul 11, 2016 at 05:18:00PM +0200, Tony Anderson wrote:

Hi Martin,

It seems to be nostalgia week. The goal is to have the user supply a 
name. Whether the text says untitled, Write.activity, execrable, or is 
left blank. The user will not be able to save until a title is 
supplied. There would be literally no 'untitled' or 'Write.activity' 
documents in the Journal.


This design decision of not forcing the user to name an activity has literally
been consciously made since the first deployment of Sugar:

http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009151.html
http://dev.laptop.org/ticket/3225
http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009157.html
("Sugar default naming scheme")
http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009152.html

The has many nuances, so I don't want to be the penut gallery too much, but it
seems to me that forcing kids to name activity instances upon closing[1] would
seriously change (for the worse, IMO) the Sugar user experience.  The children
I have observed using Sugar would for sure spend longer closing and switching
between activities without any benefit from this modal alert. Is it only going
to be some activities, like Write, that require (or default to) this?  Are you
sure you want to undo/change these very old design decisions?

Martin

1. My interpretation of the hypothetical proposals in "Sugar Journal save
option" on https://wiki.sugarlabs.org/go/Summer_of_Code/2016 and the video on
the "Save As" patch at https://www.youtube.com/watch?v=xcvBH7zzFBo .




Tony

On 07/11/2016 04:56 PM, Martin Dengler wrote:


On 11 Jul 2016, at 15:44, Dave Crossland <mailto:d...@lab6.com>> wrote:




On 11 July 2016 at 10:40, Tony Anderson <mailto:tony_ander...@usa.net>> wrote:


   I prefer 'Untitled' as it supports the intent of the alert - to
   request the user to supply a title.


I also prefer Untitled, although I'm curious to hear why "xxx 
Activity" would be better.


Actually, 500 "Untitled"s are so much worse than 5 sets of 100 
"Foo.activity", because (in my limited experience) kids who can read 
know that "Speak activity" is different than "Write activity".


There are literally over a hundred emails about this design decision 
years back - it was not done lightly. I didn't even participate and 
I was exhausted by the debate.


Martin


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





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




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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

On Mon, Jul 11, 2016 at 11:10:13AM -0400, Dave Crossland wrote:

On 11 July 2016 at 10:56, Martin Dengler  wrote:

On 11 Jul 2016, at 15:44, Dave Crossland  wrote:

On 11 July 2016 at 10:40, Tony Anderson  wrote:
I prefer 'Untitled' as it supports the intent of the alert - to request
the user to supply a title.


I also prefer Untitled, although I'm curious to hear why "xxx Activity"
would be better.

Actually, 500 "Untitled"s are so much worse than 5 sets of 100
"Foo.activity", because (in my limited experience) kids who can read know
that "Speak activity" is different than "Write activity".


Hopefully this point is clear.


There are literally over a hundred emails about this design decision years
back - it was not done lightly. I didn't even participate and I was
exhausted by the debate.



I'm totally confused :) I thought this has only been discussed since June,
for this year's GSOC?


I don't want to derial the GSOC projec.  If people are aware of all the
previous discussions and designs about save as / keep, sorry for the noise.  It
didn't sound like that to me.  Keep and something akin to "save as" has been
thought about and designed in to Sugar since [the original Human Interface
Guide](http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal):
the principles deprecating "save" and "save as" replaced it with "Keep", the
"keep button", or the idea of "keeping".  I will be flamed for suggesting
"Keep" is the same as "save as", but it's darn close.  Some design documents
and discussions, including the ones with the original sugar designers about
*removing* "Keep" and/or "Keep As" buttons, include:

http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/The_Journal#The_Notion_of_.22Keeping.22
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023401.html
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023404.html
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023406.html
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023441.html
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023439.html
http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023480.html
http://lists.sugarlabs.org/archive/sugar-devel/2010-September/026474.html
http://lists.sugarlabs.org/archive/sugar-devel/2011-May/031316.html
http://lists.sugarlabs.org/archive/sugar-devel/2011-July/032438.html
http://lists.sugarlabs.org/archive/sugar-devel/2011-July/032486.html

etc.

Martin


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

Re: [Sugar-devel] [DESIGN] Re: PR comments on 'Save as

[Martin Dengler]

> On 11 Jul 2016, at 15:44, Dave Crossland  wrote:
> 
> 
>> On 11 July 2016 at 10:40, Tony Anderson  wrote:
>> I prefer 'Untitled' as it supports the intent of the alert - to request the 
>> user to supply a title.
> 
> I also prefer Untitled, although I'm curious to hear why "xxx Activity" would 
> be better. 

Actually, 500 "Untitled"s are so much worse than 5 sets of 100 "Foo.activity", 
because (in my limited experience) kids who can read know that "Speak activity" 
is different than "Write activity".

There are literally over a hundred emails about this design decision years back 
- it was not done lightly. I didn't even participate and I was exhausted by the 
debate.

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

Re: [Sugar-devel] [IAEP] Save as

[Martin Dengler]

Tony,

> On 10 Jul 2016, at 16:34, Tony Anderson  wrote:
> 
> It is hard to describe 'Untitled' as an innovation since it is used by major 
> applications everywhere. 

There are many things that Sugar does differently than major applications 
everywhere. It was painful to re-think assumptions based on "major 
applications", but usually worthwhile.

> Tony

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

Re: [Sugar-devel] The future of Sugar on XO-1s

[Martin Dengler]

On Tue, Apr 05, 2016 at 08:46:15PM -0400, Dave Crossland wrote:

Sugar is basically a 10 year old technology.


Sugar is not a technology.  And the Sugar desktop's age is less than git,
javascript, C, HTML, DNS, IPv6, and lots of other things.  If there is one
thing I'd wish for pedagogical technology, it's that the Sugar UI design
principle[1] of "Low floor, no ceiling" continued to be worked on and enhanced.

If you have ever put a UI in front of kids you know how powerful and unique
Sugar's UI is.  Python is a key part of the current realization, and throwing
that away because it's "10 year[s] old" is madness[2,3].  Especially in the
face of its current[4] and future direction[5].

Martin

1. 
https://wiki.sugarlabs.org/go/Human_Interface_Guidelines/Design_Fundamentals/Key_Design_Principles
2. http://www.tiobe.com/tiobe_index
3. http://www.joelonsoftware.com/articles/fog69.html
4. https://www.jwz.org/doc/cadt.html
5. 
http://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-us-universities/fulltext


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

Re: [Sugar-devel] Community XO software builds

[Martin Dengler]

On Wed, May 06, 2015 at 11:21:35PM -0400, Samuel Greenfeld wrote:
> OLPC already appears to be going the Ubuntu LTS route

When/where can I read more about what OLPC is doing with Ubuntu LTS?  Apologies
for the lazyweb request.

Martin


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

Re: [Sugar-devel] Community XO software builds

[Martin Dengler]

On Thu, May 07, 2015 at 10:16:42AM +0100, Peter Robinson wrote:
> On Thu, May 7, 2015 at 12:10 AM, James Cameron  wrote:
> > 2.  there are missing desktop packages, which means we are taking on
> > maintenance of those packages on CentOS,
> 
> Having tried and failed to do this back when EL6 was new I believe
> this is a dead end. It turned out to be _WAY_ more effort than
> actually keeping Fedora up to date. The upstream RHEL releases are
> every 6 months but if you need a fix for a package in the core 2500
> odd packages and it's not easy you might be waiting a lot longer for a
> fix.
> 
> In Fedora if you know the right people (like me) you can get a fix
> into update-testing in a day. Also there's a much much wider QA group
> across the packages we use and care about.

I'm sure core people get it, but I think it's hard to over-emphasize to
everyone else that there are two places where you get the most bang for your
buck: 1) you stay with the latest (Fedora); or 2) you *never* change anything,
ever.  Everything in-between seems like it might be a better tradeoff, but
really all that's happening is you're giving your paid devops staff time to
work around their holidays and internally-driven priorities.

Have no paid devops staff or worldwide priority list?  You need to be on Fedora
or *never* ever change.

SugarLabs being in that place, with people like you to take forward Sugar
packages on the popular, RHEL-upstream (in practice) Fedora, there is no good
reason to accept a slower security fix process and a much more time-expensive
release process.

> And I've been trying as hard with Fedora as possible. The core Sugar
> stack is in pretty good shape. There's some work needed on some
> Activies but most of the work it to update them to the latest upstream
> bits.

This rings true to me too.

> Peter

Martin


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

Re: [Sugar-devel] [IAEP] Sugar future

[Martin Dengler]

On Sat, Apr 13, 2013 at 11:25:46AM +0800, Martin Dengler wrote:
> I bet someone (cscott?) has already investigated [porting Sugar to
> Android]

Answering myself: 
http://www.google-melange.com/gci/work/download/google/gci2012/7972209?id=17001

> Martin

Martin


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

Re: [Sugar-devel] Sugar future

[Martin Dengler]

On Sat, Apr 13, 2013 at 11:21:26AM +1000, fors...@ozonline.com.au wrote:
> Thanks to everybody who has contributed to the discussion so far,
> particularly to Sean for his well researched post on Android
> developments.
> 
> The choices as I understand:
> 0) Do not have an Android transition plan

I read the SLOBS minutes of 2013-01-14 [1] as not agreeing to a
"transition" plan but a "compatibility" plan.  This is a huge
distinction.  If I have misunderstood, it'd be interesting to know
where the "transition" or similar language is minuted.

The minutes indicate that no detailed plan has been agreed; there is
no information about what technically is planned, just what technical
directions are possible[2]

> Tony

Martin

1. http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-01-14
2. 
http://www.google-melange.com/gci/work/download/google/gci2012/7972209?id=17001



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

Re: [Sugar-devel] [IAEP] Sugar future

[Martin Dengler]

On Fri, Apr 12, 2013 at 03:48:00PM -0700, Bert Freudenberg wrote:
> [...] the individual activities are *not* what makes Sugar such a
> compelling proposition. Sure, having some of them as apps on other
> platforms would be nice. But isn't collaborating and sharing at the
> heart of Sugar? The Journal as central UI? The effortless discovery
> of your peers in the neighborhood view? Etc? *That* experience would
> have to be ported to another platform first, and then the activities
> can follow. Otherwise, it's just a bunch of random apps, of which
> there are plenty already in the various app stores.

This.  Bert has nailed the fact that Sugar is more than the sum of its
parts, because the parts are coherent.

We can still port individual activities.  But having the sugar shell
running on android is a major step up in what a collection of
coherently-designed activities provide.  Noone's doing that work,
AFAIK.  I bet someone (cscott?) has already investigated its
feasibility, though...

> - Bert -

Martin


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

Re: [Sugar-devel] Sugar future (was Re: Re: [DESIGN] Single instance activities)

[Martin Dengler]

On Fri, Apr 12, 2013 at 07:06:22AM -0500, David Farning wrote:
> It is the lack of transparency that causes people to become
> disillusioned and leave the project.

Sounds more like there aren't enough people writing code convincingly
enough for the other people writing code.

(Says the peanut gallery, I know)

> Dave

Martin


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

Re: [Sugar-devel] [PATCH Help v3] Migrated to Gtk3 and WebKit.WebView SL #3466

[Martin Dengler]

On Wed, Apr 25, 2012 at 03:15:22PM -0300, Manuel Quiñones wrote:
> El día 25 de abril de 2012 12:43, Manuel Kaufmann  
> escribió:
> > 2012/4/25 Manuel Quiñones :
> >> Both forms pass PEP8, but we use one import per line in Sugar.  Is a
> >> matter of style, that's all.
> >
> > Do you have the reasons of this decision? (link to a discussion or
> > something like that)
> 
> Main reason: consistency (as already said).

Another reason: readability of the import list.  If you're pulling a
binding in with a "from" import, you are gaining readability of the
code at the cost of tracability of the name bindings.  This makes it
easier to forget where that binding came from.  Putting the "from x
import y" imports separate to the "import x" highlights to the reader
that they need to remember where that name came from when they read
the code, and putting all the "from" imports on one line diminishes
this effect.

Given the code already did one from import per line and most of Sugar
is written this way (or to avoid "from" imports, as usual with python
code), I see even less reason to change it than to do multiple "from"
imports in the first place.

Martin


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

Re: [Sugar-devel] [IAEP] Article on "Why files need to die"

[Martin Dengler]

On Fri, Jul 15, 2011 at 11:54:40AM +0200, Christoph Derndorfer wrote:
> Please also see this article (
> http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one
> of the early Sugar developers) just shared on Google+, well worth a
> read!

The article offers no solution that avoids the problem of naming and
organising documents[1].  It ends with "other people are setting up
clouds, where's ours?", which doesn't seem very relevant to
educational software in an intermittently connected world[2] like the one
I think we're targeting.

The words privacy, security, or control do not appear in the article.

The article is good insofar as it lays out one avenue of improvement:
we need to take advantage of new connectivity options and improve the
user interfaces for the information which is often or hard to manage
right now.

But would our computers be useful for learning, writing, reading, or
playing if the only user interface was like Facebook or iTunes?

> Christoph

Martin

PS:

We (this audience, and others like GNOME) are in danger of being
distracted by the current limitations of moving audio-visual data
around into thinking that our conversations, thoughts, and stories
don't deserve designers' time, or can be managed in the same simple
ways.  At their essence this information is neither audio nor visual;
it is textual (for practical, useful definitions of "essence").  And
their labels (meta-data) are the same.

Sure, these things can be compressed or expressed in different forms.
But they cannot be easily used, or separated easily from context (what
the original article's author found so terrible), without the control
that the cloud takes away or the simplicity of the written word.

We are at risk of sacrificing clarity and simplicity of expression so
that Facebook or Apple or Google can sell us ads for the Kabbalah,
mormonism, or DVDs.  That is, if what what google.com and bing.com
suggest when I search for 'the meaning of life' is any indication.
Speaking of which, I'll finish this postscript after I watch the
Meaning of Life... 


1. Even after the author has narrowed the scope of the "file problem"
three times to Document, then to MS-Office-type document, then to
document one never needs to move outside of the cloud, he still
doesn't say anything about how this fixes "file management" (which I
infer he thinks of as naming, organising, and sharing.

2. One of the commenters basically said the author and other are
getting distracted into re-creating "appliances" rather than designing
for "general purpose computers"; rather than helping people manage the
information they generate or manage mostly unconsciously now, it seems
a big inferiority complex is being fed, since Facebook is so good and
iCloud will make sure your documents (whose naming is never discussed)
can appear on all your devices.  Which is almost never useful unless
you a) have always-on, low latency connections; and b) have a large
amount of bandwidth; and c) never need to do anything with the
information except look at it onscreen or what the cloud provider lets
you do with it.


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

Re: [Sugar-devel] [PATCH] Display build number at Name Page

[Martin Dengler]

On Fri, Jul 08, 2011 at 01:26:40PM +0100, Daniel Drake wrote:
> On 15 June 2011 16:01, Esteban Bordón  wrote:
> > This patch show the build number in the name page for first boot (see
> > attached file). It's very useful to test the correct massive flashing for
> > technical team.
> 
> It may sound excessive and a little unbelievable, but this first step
> really is a very challenging and stressful experience for everyone
> involved. This screen must be kept as simple as possible.
> [...]
> [P]erhaps it could be temporarily shown on the Sugar naming screen
> while Ctrl+Shift are held down, or something like that.

+1.

Ctrl + Shift or flash the mic LED or spew it on the wireless interface
as a spurious ICMP packet's target IPv4 address, but the visible UI
should be geared toward the people using the laptops.

Having the build number there disrupts the UX of the vast majority to
the benefit of a tiny minority of people.

> Daniel

Martin


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

Re: [Sugar-devel] FUSE for Journal?

[Martin Dengler]

On Fri, Jun 17, 2011 at 09:58:33PM +0200, Sascha Silbe wrote:
> Please give datastore-fuse [1] a try. Besides Sugar it needs just
> python-fuse >= 0.2. I've mentioned this project both on sugar-devel and
> on IRC several times, but got no feedback from anyone who tried it.

datastore-fuse is great.  I tried it and liked it.

> Sascha
Martin

> [1] http://git.sugarlabs.org/datastore-fuse/


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

Re: [Sugar-devel] A better participation

[Martin Dengler]

On Wed, Feb 09, 2011 at 03:07:31AM -0600, Yader Velásquez wrote:
> I would like to involve with more participation into the
> community. I'm just a teenager student, but I can learn. What do you
> suggest me to do?

Just what you did: introduce yourself, maybe write some code, let
people know you're around, read sugar-devel mailing list.  I'm sure
others will have more detailed suggestions, but you have already done
more than many.  Welcome.

Martin


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

[Sugar-devel] Eliminate Glucose co-maintainers

[Martin Dengler]

I propose we eliminate "co-maintainers" from Glucose[1] because they
reduce the responsibility and pressure of a sole maintainer.

Recall that the role of maintainer is:

a) accept features [2]
b) accept patches [3]
c) make releases [4]

Having more than one person making these decisions risks reducing the
responsibility of the sole maintainer to maintain a quality release.
Essentially, it's too easy to leave maintainer work if you think
someone else could be helping you.

Thoughts?

Martin

Footnotes: 
[1]  http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Glucose

[2]  http://wiki.sugarlabs.org/go/Features/Policy#Roles

[3]  "accepting patches is a maintainer matter" 
http://wiki.sugarlabs.org/go/Oversight_Board/Meeting_Log-2009-11-20

[4]  http://wiki.sugarlabs.org/go/Development_Team/Release#Module_release


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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

On Sat, Nov 20, 2010 at 10:49:40PM +, Gary C Martin wrote:
> Hi Martin,
> 
> On 20 Nov 2010, at 09:32, Martin Dengler wrote:
> > Gary, can you add / correct anything from our conversation?
> 
> Summary: A two prong attack.
> 
>   1) HIG cleanup and polishing effort (one ring to rule them all)
>   2) Focus on keeping a core of HIG compliant quality activities to
>   act as our ambassadors

I like it, especially as I can certainly help with 2).

> Regards,
> -Gary

Martin


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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

On Sat, Nov 20, 2010 at 06:33:52PM -0500, Walter Bender wrote:
> On Sat, Nov 20, 2010 at 5:55 PM, Michael Stone  wrote:
> > On Sat, 20 Nov 2010 at 08:42:42 -0500, Walter Bender wrote:
> >> 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.
> 
> Even on your short list, I see people who are not designers...

> there is a call to add more non-designers.

I'm not sure if you thought I was calling for non-designers to join,
but I don't see such a call.  I just see a call for people that can
contribute to the design team.  I'd be hesitant to say the
"non-designers" on that list can add nothing to a design discussion.
I think in the absence of real designers, as long as we try not to
overreach ourselves (perhaps you or just our good sense keeping us
from this), there is something that can be accomplished...

> I don't want to divert non-designers into making design decisions

I hope we don't have to get into an "is no decision better than
decision that might be sub-optimal", because I'm not sure where I
stand on that.  I think that Gary and you can keep anyone from
overstepping themselves well enough to risk it until you/we get more
proper designers.

> I am also actively recruiting [for the Design Team]

Good to know.  If this is going to get in the way of that (I'm not
saying you said that), please let us know and I'll move on to other
things.

> -walter

Martin


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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

On Sat, Nov 20, 2010 at 08:42:42AM -0500, Walter Bender wrote:
> But adding a bunch of developers to the design team will not help it
> accomplish its design goals.

It might not.  But it will a) help the lack of designers from impeding
development progress; and b) help do no harm to the HIG / design goals
already espoused (assuming the non-designer members keep an eye on
their limitations).

> And we need to stay focused on Sugar's core design principles.

Completely agree.

> 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.

I couldn't agree more - which is why I'm scared to touch the HIG,
since I know it's best left to designers with Sugar's core design
principles squarely in the fore.

> -walter

Martin


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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

On Sat, Nov 20, 2010 at 05:55:14PM -0500, Michael Stone wrote:
> On Sat, 20 Nov 2010 at 09:32:53 +0000, 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.

I see your point.  Can we get Bernie to confirm the distinction?
Perhaps you or he could provide an example of a UI-related decision
that is not HIG-related[1]?

> >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.

Sorry for being (in retrospect) a bit flippant.  I did not mean to be
dismissive of the additional clarity (and empowerment and
seeking-concrete-committments-ness) of your proposal.  By
"re-invented" I meant (keeping in mind I saw the committee as both UI
maintainer and UI arbiter, as well as HIG maintainer) "constructed a
group with similar goals and responsibilities".  I see now how your
proposal does indeed narrow the scope, membership, and committments
vis-a-vis the Design Team.  Do you think there is space for two
groups?  Would an active Design Team vitiate the need for an organised
group like the UI committee?[2]

> >With that in mind, I think we should just have more people actively
> >participate in the design team.
[...]
> >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?

I think it does.

> Michael

Martin

Footnotes: 
[1]  Am I oversimplifying to see a continuum of code <--- UI ---> HIG
decision-making here, and your committee as designed to stay out of
the code (UI maintainer) and HIG areas, and focus on the middle ground
of "UI"?  If so, I'm trying to get a better understanding of the
boundary between not-UI and UI as you see it.

[2]  An academic point, I hear you saying, as we don't have one.  Just
trying to understand.



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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote:
> Martin and I talked for bit this evening and I believe that I managed to
> persuade him to support my [UI Dictator team] proposal.

I do, for the reasons mentioned in Michael's "key arguments".

> 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.
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.

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? 

Martin

[1]  http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html



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

Re: [Sugar-devel] Engineering Team

[Martin Dengler]

On Sat, Nov 20, 2010 at 02:53:06AM +, Aleksey Lim wrote:
> Hi all,
> 
> (Just trying to summarize previous discussions, including recent one
> on #sugar with some kind of motion)
> 
> 
> = The problem =
[...]
> = Engineering Team [the solution] =
[...]

I'm not opposed to the discussion.  While we (continue to) have it, am
I wrong in thinking the de factor situation is that:

- anyone who is allowed push to sugar* repos is allowed to approve and
  / or push a patch or other code (and is trusted to not push
  contentious things)

- people who are not allowed to push to sugar should do this to get
  code in: http://wiki.sugarlabs.org/go/Development_Team/Code_Review

I ask because I want to understand what the the "current situation"
is:

> Current situation with stuck patches queue is dangerous

Martin


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

Re: [Sugar-devel] [DESIGN] Messages notification

[Martin Dengler]

On Wed, Nov 17, 2010 at 02:44:16PM -0200, Daniel Castelo wrote:
> Maybe we could group all the notifications that are repeated.
> Journal is Full... (X 3)
> Other Warning..
> Other Warning (X2).

Definitely.

> Could be useful show the date of the problem in the case of historical
> warnings.

sort of like:

Nov 18 16:28:53 solaris.machine.some.com automountd[18246]: [ID 834250 
daemon.error] Mount of /xxx on /yyy: No such file or directory
Nov 18 16:40:54 solaris.machine.some.com last message repeated 2 times

syslogd does...?

What happens when the user clicks on a notification?  Perhaps Log
should be launched showing the file / line in question?


Martin


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

Re: [Sugar-devel] [DESIGN] Messages notification

[Martin Dengler]

On Wed, Nov 17, 2010 at 12:10:23PM -0600, David Farning wrote:
> On Wed, Nov 17, 2010 at 11:15 AM, Martin Langhoff
>  wrote:
> > On Sat, Nov 6, 2010 at 2:07 AM, Martin Abente
> >  wrote:
> >> * Why the user should start an activity to know what is happening?
> >
> > Why/when does the user want to know "what's happening"? Users are busy
> > doing something interesting...
> >
> > We should interrupt/hassle the user never. Or extremely seldom.
> >
> MartinL
> 
> I think this is one of the times where we need to agree to disagree.
> There is a very good chance that this patch set will never make it
> into Sugar.Main. What you are saying is 100% true from an end users
> point of view.
> 
> This patch has a place in Dextrose.  Dextrose is looking at the
> question, "How can we provide support staff the necessary information
> to effectively fix and/or report problems to a higher level of service
> and support?"
>
> [description of a "support staff"]

You forgot to explain why you think answering that question using such
a "support staff" is usefully done using for or so messages of ~60 or
fewer English characters[1] and while not telling them about the Log
Activity.

tch's proposal is more than the point you've responded to, and
looks[1] promising (IMO, as long as it doesn't interrupt / hassle the
user more than we already do), but I don't understand why you think
the notifications will make a big difference for you in the field.

I agree it doesn't have a place in Sugar.  I guess you'll discuss the
Dextrose-specific bits on the desxtrose mailing list.  I'm interested
to hear what you find out.

> david

Martin

1. 
http://wiki.sugarlabs.org/go/File:Corner_notification_message_only_history.png


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

Re: [Sugar-devel] [Dextrose] [PATCH] Feature Request added : Kill the Mute function by clicking on the speaker icon.

[Martin Dengler]

On Mon, Nov 15, 2010 at 04:48:13PM +, Martin Dengler wrote:
> 4. run pylint / pep08 /tools on patch - Shanjit, please do this as in [1]

Sorry, that should be [4], as I guess you figured out:

> 4.
> http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines#Tools

...and please put the output, if any, in a comment on the bug report.

Martin




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



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

Re: [Sugar-devel] [Dextrose] [PATCH] Feature Request added : Kill the Mute function by clicking on the speaker icon.

[Martin Dengler]

On Mon, Nov 15, 2010 at 11:09:08AM -0500, Bernie Innocenti wrote:
> On Mon, 2010-11-15 at 15:19 +0000, Martin Dengler wrote:
> > On Sat, Nov 13, 2010 at 05:38:14PM +0530, shan...@seeta.in wrote:
> > > From: Shanjit Singh Jajmann 
> > > 
> > > Muting by clicking on the icon is killed.
> > 
> > NAK.  This functionality was requested by a deployment[1], AFAICS.
> 
> I just spoke on IRC with the original requester, Raul.
> 
> He says that the feature seemed cool, but it was developed before the
> roll-out so it could not be tested on actual users.
[...]
> So my proposal is: let's just remove this feature until someone comes up
> with a better way to implement it and justification for its usefulness.

I'm ok with this.  Let's do it properly:

0. figure out if this is intended behaviour and why - Shanjit, please
   include this information in a pre- or post- patch email next time
   so we don't have to waste time and you can demonstrate you know
   what you're changing.

1. bug report - Shanjit, please do this like [1] and include the
   information from 0.  Please remove
   
http://wiki.sugarlabs.org/go/Kill_the_mute_function_in_the_volume_icon_of_the_frame
   as a) the page doesn't tell me any information from point 0 above;
   b) the page doesn't tell me who requested it; c) requires much less
   discussion than a "feature"; d) is much smaller in scope (code
   changes, UI effects, difficulty to revert) than a "feature"; and e)
   has no relation to a "feature"
   http://wiki.sugarlabs.org/go/Features/Policy#What_is_a_feature.3F
   as we usually use the term.

2. ...that includes which deployment, why, and HIG changes - Shanjit,
   please do this like [2]

3. test cases - Shanjit, please do this like [3]

4. run pylint / pep08 /tools on patch - Shanjit, please do this as in [1]

Shanjit, please read
http://wiki.sugarlabs.org/go/Development_Team/Code_Review#Proposal for
next time.

Martin

1. http://dev.laptop.org/ticket/7730

2. https://dev.laptop.org/ticket/7248

3. https://dev.laptop.org/ticket/7248#comment:7

4.  http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines#Tools



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

Re: [Sugar-devel] [PATCH] Feature Request added : Kill the Mute function by clicking on the speaker icon.

[Martin Dengler]

On Sat, Nov 13, 2010 at 05:38:14PM +0530, shan...@seeta.in wrote:
> From: Shanjit Singh Jajmann 
> 
> Muting by clicking on the icon is killed.

NAK.  This functionality was requested by a deployment[1], AFAICS.

Martin

1. http://dev.laptop.org/ticket/7730#comment:16


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

Re: [Sugar-devel] Coding style: line continuations

[Martin Dengler]

On Thu, Nov 11, 2010 at 05:39:50PM +0100, Sascha Silbe wrote:
> Excerpts from Sugar Labs Bugs's message of Wed Oct 27 11:11:49 UTC 2010:
> 
> >  {{{
> >  249 self._shared_activity.connect('buddy-joined',
> >  250 self._buddy_joined_cb)
> >  }}}
> >  In emacs I just use tab for that, the next line then gets aligned under
> >  the buddy joined. Same below:
> >  {{{
> >  290 logger.debug('Tube address: %s', \
> >  291
> >  self.tubes_chan[telepathy.CHANNEL_TYPE_TUBES].GetDBusTubeAddress(id))
> >  }}}
> 
> We should agree on a continuation style, otherwise we'll confuse new
> contributors.

Agreed - but like your example, anyone who's using "\" inside
parentheses is almost certainly already confused.

> In cases where using four spaces would make the code harder to read
> because the block following it uses the same indentation width I add
> four more spaces (i.e. eight total):
> 
> if (really_really_long_variable_name > another_long_variable_name and
> long_variable_name[another_long_variable_name] == 'bar'):
> print "whatever"
> 
> 
> I applied this style for the clean-up patch series.

That style can be questioned, but even I can't be bothered to quibble
on such a point, so I agree with you; want if you haven't already
documented it that way, I will.

> Sascha

Martin


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

Re: [Sugar-devel] Coding style: line continuations

[Martin Dengler]

On Fri, Nov 12, 2010 at 03:27:15AM +0800, C. Scott Ananian wrote:
> On Fri, Nov 12, 2010 at 2:09 AM, Simon Schampijer 
> wrote:
> > In general I would do what the spec says if there is no good reason not to
> > [1]. The example they have does not really handle all the cases, though.
> > Neither pep8 nor pylint does favor any formatting. So I guess we are a bit
> > free here.
> 
> I belive PEP8's example is rather definitive:
> 
> "... Make sure to indent the continued line appropriately.  The preferred
> place to break around a binary operator is *after* the operator, not before
> it.[" ...]
> I don't think there's any ambiguity there, actually.

Indeed, so I think we should accept that: it's written down that way
and the issue is otherwise open to legitimate argument (I think it's a
overly prescriptive, though[1]).

>   --scott

Martin

[1] When the boolean logic joining the tests are quite important
relative to the tests themselves, the boolean operators benefit from
emphasis:

if (width == 0
and height == 0
and color == 'red'
and emphasis == 'strong'
or highlight > 100):

...rather than:

if (width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight > 100):

But we can argue about this point for a while.  That example really
sucks, since it uses implicit precedence in ways that are quite liable
to require people to refer to the documentation[2]:

if w and h and c and e or hi:

...if I saw that in code I'd want it changed to:

if (w and h and c and e) or hi:

...which is what it means, not:

if w and h and c and (e or hi):

I had to convince myself:
 
w = False
h = True
c = True
e = True
hi = True

print w and h and c and e or hi
print (w and h and c and e) or hi
print w and h and c and (e or hi)

...yields:
True
True
False

[2]  http://docs.python.org/reference/expressions.html#summary




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

Re: [Sugar-devel] [Dextrose] [PATCH] Copying files multiple times results in bogus names. (SL#2060)

[Martin Dengler]

On Wed, Nov 10, 2010 at 05:57:18PM -0300, Gonzalo Odiard wrote:
> Mhh, is sufficient with doing the split out of the while

looks good

> Gonzalo

Martin



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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

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.  I think both, however, require more administration than we're
liable to get :(.

I think the implicit, current situation is:

1. All patches have to satisfy any committer that notices...
2. unless overruled by the Design Team

And that's not too bad, given there are a large number of sugar
committers and not too many members of the Design Team and neither
group changes very often.

The bad part is that it was implicit, and that we could do better
(like what you proposed).

Martin

1. http://lists.sugarlabs.org/archive/sugar-devel/2010-November/028615.html

2. Proposal #2, Concerning UX patches:

0 - any patch is a UX patch if a committer says it is

1 - The UX patch acceptance criteria will be as follows:
1a - UX patches have to be accompanied by HIG change patches (in any
 reviewable form), or a statement as to why none is required
1b - UX patches with non-trivial HIG changes should be accompanied by
 appropriate supporting material (non-anecdotal user feedback, for
 example)

2 - accepting UX patches will be done by the following people:
2a - any committer can commit a UX patch as long as it complies with
 the criteria above
2b - any committer can revert a UX patch
2c - the Design Team will adjudicate any disagreements amongst
 committers

Issues:

a) my intent is that the main difference between Michael's proposal[1]
and mine be the degree of formality of the acceptance "committee".

b) social considerations will be used keep any disagreements to a
minimum; amicable differences of opinion may persist.

c) it is intentional that anyone who can commit code can affect the UX
as long as the design team isn't sufficiently angered: the bias is
towards people willing to do the work, as that selects for the
momentum and contributors that Sugar needs.

d) I haven't thought about this enough, but this will have to do.


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

Re: [Sugar-devel] Sugar UI Dictator

[Martin Dengler]

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.

Martin


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

Re: [Sugar-devel] [DESIGN] Messages notification

[Martin Dengler]

On Sat, Nov 06, 2010 at 03:07:29AM -0300, Martin Abente wrote:
> On Sat, Nov 6, 2010 at 1:44 AM, Martin Dengler 
> wrote:
> 
> > On Fri, Nov 05, 2010 at 06:02:28PM -0300, Martin Abente wrote:
> > > Hello amigos,
> > >
> > > Recently I encountered many situations where a system-wide
> > > notification-messages system is required as a basis for many bug fixes or
> > > enhancements.
> > [...]
> > > Currently, Sugar does not have a mechanism to communicate to users
> > > different kind of information about sugar itself.
> >
> > What about the notification system?  The Log activity?  The Journal
> > Full warning?  The Frame?  There are a lot of communication
> > mechanisms, but they dn't seem to do what you wnat:
> >
> >
> 
> * The notification system only shows an icon floating, and if you want to
> show a message you have to implement a palette manually, not so DRY
> considering all the use cases.

I'm not sure what you mean by "DRY".  The reason - I guess - for only
the icon is because text requires translation and literacy (a point
you make later).  I prefer text (obviously, since we developers work
with text as much as possible) but this requires a change to the HIG.
We should think hard about why, and justify it.

> * Why the user should start an activity to know what is happening?

I know, this is odd for developers/computer people.  I personally
don't like it (I really liked the "quake terminal"[1] approach), or
having four activities to read e-books. But a) it's what the HIG[2]
says, for some good reasons (it's not better to have text flashing by
all the time -- have you seen how many exceptions are in shell.log!?);
and b) it's not a new approach: OSX has the "Console" log viewer,
Windows has the Event Viewer.

> Even if they do, do you think all that pile of text is really
> helpful? (for a developer, sure.. for a 7 years kid probably not,
> and if you want him to understand you would have to translate the
> log messages anyway).

Wait, that's my argument you just stole :).

If you're saying the error messages should be better, I don't think
anyone would disagree.

> * The journal full warning is actually a problem to be solved, #630.

Wow, I can't believe it's taken 20 months to fix it.  I guess it's not
that critical :(.

> * What about the frame?, currently it
> does nothing about this issue. (except for the floating pulsing
> icon)

That's exactly what you wanted, but with icons instead of text: a list
of the messages from Sugar, without starting an activity.

> Again, why should we force users to start an activity to know what is
> happening.

To summarise:

1) Because the HIG tells us to, and nobody's proposing changing the
HIG
2) Because Sugar UI should strive for simplicity, not tons of alerts
that only a developer would understand
3) Because it's not clear what advantage over the existing
notifications + Log activity you think will exist.

> > > I invite everyone to share their ideas on how this feature could
> > > work and look.

Well, those were my ideas.  When you have something more I'm sure we
could have a more constructive discussion.

> We need sugar to tell the users what is happening otherwise they will never
> guess it, that is exactly problem in the first place. I can't imagine a kid
> having to check the log activity every 10 minutes to see if the automatic
> backup has started recently.

I can't imagine any more than a few kids at each deployment (so,
that's say 100 of 1.5 million laptops) ever wanting to see if the
automatic backup has started recently.

> Anyway, if someone does not like the messages and wants just wants to read
> the log every N minutes they could be disable it :):):)

In my experience, every time you show some information to the user
that isn't actionable, they hate it.

> > Saludos
> > > Martin (tch) Abente
> >
> > Martin

Martin

1. http://wiki.laptop.org/go/Quake_Terminal

2. http://wiki.sugarlabs.org/go/Human_Interface_Guidelines#Simplicity


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

Re: [Sugar-devel] [DESIGN] Messages notification

[Martin Dengler]

On Fri, Nov 05, 2010 at 06:02:28PM -0300, Martin Abente wrote:
> Hello amigos,
> 
> Recently I encountered many situations where a system-wide
> notification-messages system is required as a basis for many bug fixes or
> enhancements.
[...]
> Currently, Sugar does not have a mechanism to communicate to users
> different kind of information about sugar itself.

What about the notification system?  The Log activity?  The Journal
Full warning?  The Frame?  There are a lot of communication
mechanisms, but they dn't seem to do what you wnat:

> 1. Simple text messages display.

Where do you think this would best be shown?  Text is limited in the
UI to avoid literacy and translation burdens.

> 2. Messages manager, this would help the user to see what messages have been
> delivered in the current session, so they could react to those events (for
> example, reporting bugs).

Peraps Log could be changed to show this?  Or the Frame (doesn't it
already show the last few notifications?)? 

> Saludos
> Martin (tch) Abente

Martin


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

Re: [Sugar-devel] [Dextrose] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Martin Dengler]

On Fri, Nov 05, 2010 at 10:59:05PM +0530, Anurag Chowdhury wrote:
> Then I may have misinterpreted Gary's comment.I apologize in that case.
> 
> But when I tested Martin's patch on my XO-1.5 , 0.88.1 build  , upon
> starting an activity the pulsing icon animation was replaced by a
> static grayscale svg icon of the activity ,whose screenshots I have
> placed at http://wiki.sugarlabs.org/go/Pulsing_icon_delayed_by_5_seconds.
> 
> To reach to the above results I applied the changes suggested at
> http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-set-new-colors-in-one-go-to-avoid-multiple-calls-to-SVG-rendering.patch
> 
> Please let me know if I needed to add any more changes to get the
> patch working because the sole application of this patch doesn't
> produce the said changes at my end.

I just tried it on 0.88-1 in the emulator and it worked fine.  At
least one other person tried it on HEAD (as I did before) and it
worked fine.  Can you try it again please, or let me know how you're
applying the patch?

Martin


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

Re: [Sugar-devel] [Dextrose] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Martin Dengler]

On Fri, Nov 05, 2010 at 01:46:27PM -0300, Gonzalo Odiard wrote:
> > Hmmm, no, with Martin's below linked patch pulse colour animation is good.
> >
> > The only extra thing I noted in my email was that the 1sec zoom effect is
> > still not showing for anything by very simple icons (Log icon is simple
> > enough, Distance is not), however the zoom effect is not showing with your
> > 'skip the first update' approach either. Fixing zoom efficiency should be
> > looked at as a separate issue.
> >
> >
> Is really needed the zoom?
> If we can't do it in a efficient way, may be we can use another metaphor.
> What about moving the icon from the position in the home view to the screen
> center?
> I think we must do all we can to start quickly the activities.

I agree - I don't see any point in a zoom that's not shown.  It seems
like we might be able to get it quick enough before the next freeze,
though.  If not I wouldn't object to removing it.

> Gonzalo

Martin


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

Re: [Sugar-devel] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Martin Dengler]

On Fri, Nov 05, 2010 at 09:49:01PM +0530, Anurag Chowdhury wrote:
> On Fri, Nov 5, 2010 at 6:53 PM, Martin Dengler  
> wrote:
> > On Fri, Nov 05, 2010 at 06:05:16PM +0530, Anurag Chowdhury wrote:
> >> Sure , we can work to get a combined patch but your patch still
> >> disables the animation in most of the icons
> >
> > I think you're talking about something else than my patch.  No
> > animation is disabled.  Not sure what's wrong but the patch you linked
> > to[1] in your wiki page clearly does nothing like disabling any
> > animation.
> Well, I actually didn't meant that. I was talking about the change
> noticed by Gary (and me too) i.e. after the application of the patch
> we don't get to see the pulsing icon animation in most of the icons ,
> all we see is only the grayscale svg icon , this anomaly is also
> linked with the complexity of the icons i.e. more complex icons don't
> show up the animation while the simpler ones do.

Are you talking about the pulsing from greyscale to color, or the
zooming?  Gary was talking about the zooming[1] IIUC, and that is
obviously not changed by my patch.  I understood his comment to mean
that there was already a zooming issue in the build he was referring
to, and that my patch did not change that.

Can you please help me understand a bit more why you think my patch
causes the pulsing icon to not show in color?  I don't see that in my
sugar-jhbuild before or after my patch.

Martin

1. http://lists.sugarlabs.org/archive/sugar-devel/2010-October/028444.html


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

Re: [Sugar-devel] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Martin Dengler]

On Fri, Nov 05, 2010 at 09:28:23AM -0400, Martin Langhoff wrote:
> On Fri, Nov 5, 2010 at 6:35 AM, Martin Dengler  
> wrote:
> > Again, thanks for this summary.  I think the thing to do is merge my
> > patch for #2080 and then address the other issues.  I'll do that
soon.

If I call this change #1...

> would it make sense to change (in toolkit) jarabe/view/icon.py to
> optionally return the cairo object, instead of paint()ing it?
> 
> Then you can render the SVG once or twice (for zoom effect?), keep
> those raster images cached in the pulsingicon object, and use Cairo's
> paint_with_alpha() instead of straight paint().
> 
> Which will be fast. (Load/render your sprites only once, get creative
> in how you blit them... )
> 
> The pulsing color combinations change (get simpler) with this.

...and this change #2...

> To get back to what we have now (or an approximation) you could render
> to black&white (and a reverse) and use them as masks, painting with
> masked full color fills. A bit more work.

...and this change #3, I'll have a go at implementing #2 and #3 soon.
Since #1 is separate and an improvement from what we have now, it can
be merged earlier9 Unless there are issues, which I haven't seen yet).

> I'm following this tutorial -- mask() and paint_with_alpha() should be
> enough. I am disappointed that I cannot see more advanced blitting
> opts.
> 
> http://www.tortall.net/mu/wiki/CairoTutorial

Thanks for the link - I've seen it before but it's always good to come
back to absorb a bit more.

> m

Martin


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

Re: [Sugar-devel] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Martin Dengler]

On Fri, Nov 05, 2010 at 06:05:16PM +0530, Anurag Chowdhury wrote:
> Sure , we can work to get a combined patch but your patch still
> disables the animation in most of the icons

I think you're talking about something else than my patch.  No
animation is disabled.  Not sure what's wrong but the patch you linked
to[1] in your wiki page clearly does nothing like disabling any
animation.

> Regards
> Anurag

Martin

1. 
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-set-new-colors-in-one-go-to-avoid-multiple-calls-to-SVG-rendering.patch


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

Re: [Sugar-devel] Report on Sl# 2080 , Pulsing icon delayed by 5 seconds or so.

[Martin Dengler]

On Fri, Nov 05, 2010 at 02:24:58PM +0530, Anurag Chowdhury wrote:
> Hello
> 
> I have prepared a detailed report on the issue SL # 2080, Pulsing icon
> delayed by 5 seconds or so , and have made it online at
> http://wiki.sugarlabs.org/go/Pulsing_icon_delayed_by_5_seconds .

Thanks for that.  Next time, could you link to the SL bug in the wiki
page and the wiki page in the SL bug?  I have done this for you.

> Any feedback is appreciated.

Again, thanks for this summary.  I think the thing to do is merge my
patch for #2080 and then address the other issues.  I'll do that soon.

> Regards,
> 
> --Anurag

Martin


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

Re: [Sugar-devel] Appearance Customization

[Martin Dengler]

On Tue, Nov 02, 2010 at 09:48:15PM +0430, Mike Dawson wrote:
> Hi,
> 
> I guess the crux of the issue is the link between the developers (of
> whom some are working on deployments and dealing with features that
> are important to them) and the ground out in places like here.
> 
> If we want to create something more inclusive I'm sure a lot of
> deployments would like to help out - but not everyone is able to deal
> with FOSS style systems.

I think I understand your request and issue and I sympathize (see
below for some concrete suggestions).  I think you've just used a
"FOSS-style system": convince people that can help with the current
problem to help you.  When you say "more inclusive", how do you mean?

>  Would it be possible that someone could create a survey that could
> be given to deployments?  We could translate it and carry it out
> here and ask educators, learners etc.  what they want and about
> their priorities.  That could then be fed to developers who could do
> work with their priorities and those of the outside world known.

I think if somebody tried that, they'd get criticised for telling the
deployments what they could have :).  I don't say it's a bad idea -
just that it's hard to create a survey when you don't know the
problems (or the problems would take a few pages of very small font to
list).

> In the meantime I still know our kids want their pretty colours!

To change some colors, edit /usr/share/themes/sugar-72/gtk-2.0/gtkrc.
You can edit the entries in the file, then start a new activity to
test your changes.

The entries you might like to edit include:

style "button"
{

fg[NORMAL] = "#00"   affects the text color
fg[ACTIVE] = "#00"   affects the text color

color["bg_color"] = "#00"   affects the background color

}

...and


style "checkbutton"
{
fg[NORMAL] = "#FF"   affects color of text
fg[PRELIGHT] = "#00FF00"   affects color of text
fg[ACTIVE] = "#00FF00"   affects color of text
}

...and

style "entry"
{
base[NORMAL] = "#FF"   affects background of text input
areas
text[NORMAL] = "#00FF00"   affects text color of text input
areas
}

The documentation includes:

http://library.gnome.org/devel/gtk/2.11/gtk-Resource-Files.html#id2851866

> I guess I would have to try and formalize an exact deliverable for the
> bounty

That'd be a really good.

> Regards,
> 
> -Mike

Martin


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

Re: [Sugar-devel] Appearance Customization

[Martin Dengler]

On Tue, Nov 02, 2010 at 04:17:12PM +0800, C. Scott Ananian wrote:
> I think we should let the kids customize their machines easily --
> certainly to change the colors.

Changing the colors is just editing
/usr/share/themes/sugar-72/gtk-2.0/gtkrc in a safe and reasonably
upgrade-friendly way, right?  A decent UI wouldn't be trivial but it's
not the end of the world, I guess.

I wonder how hard it would be to allow people to drag items from the
Frame-clipboard to the Home view...

>  But this discussion is an old one.
>  I wonder how it will turn out this time, maybe we've finally moved
> past some of the old bugbears.

I think you just helped by summarising how things evolved.

>   --scott


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

Re: [Sugar-devel] Appearance Customization

[Martin Dengler]

On Tue, Nov 02, 2010 at 12:40:13PM +, Aleksey Lim wrote:
> On Tue, Nov 02, 2010 at 04:17:12PM +0800, C. Scott Ananian wrote:
> >  I wonder how it will turn out this time, maybe we've finally moved
> > past some of the old bugbears.
> 
> This is exactly the core[one of not many, at least] problem of current
> situation around sugar core development. After forming SL, nothing
> principally was changed, the same vertical organizational system
> was just moved (dunno how it was in OLPC, created otherwise) to another
> conditions.

I'm not sure I understand the problem you see: is it that when you say
"vertical organization" you are saying that SL can't change because
the people with access to the code won't commit the necessary changes?
Or that they don't (for whatever reason) make the changes people want?
Or something else...?

> In my mind core issue is that no one are willing to take
> responsibility because people who might take this responsibility are
> the same developers and that there is always a chance to get "Are
> you have the full picture of needs to make such invasive decision?".

Can you clarify this problem?  I don't think I understand what you see
as the problem (I'm not saying they're aren't any).  Are you saying
that there are too few developers and none (of those developers) want
to propose changes because they get shot down by non-developers?

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:49:24PM +0100, Gary Martin wrote:
> To be frank, as we move towards a touch UI Sugar, most of this left
> click vs. right click, mouse hover pop-up timing will go out the
> window any way. ;)

True.  What do you think the time frame for that is?

> Regards,
> --Gary

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:51:35PM -0400, Martin Langhoff wrote:
> The same (potentially complex) SVG is being rendered in 2 tones, many
> times. This is nonsense.
> 
> Render it once to a B/W grayscale raster. Then use/abuse whatever
> cairo bitblit blend operators.
[...]
> Maybe I am making wild assumptions about the bitblt ops you have available...

You've exceeded my knowledge of cairo :).  Sounds like a promising
thing to investigate

> m

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:18:05PM +0100, Gary Martin wrote:
> On 29 Oct 2010, at 09:12, Martin Dengler  wrote:
> 
> > On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
> >> I think the problem is the code is rendering the svg icon every time
> >> the color is changed.
> > 
> > Indeed.  As James Cameron pointed out, we're setting the stroke and
> > fill in rapid succession, resulting in two calls to render().
[...]
> > I'd love any feedback.
> 
> I've been testing this patch on an XO-1 F14 0.90 build today and can
> confirm the svg icon appears in the launcher about one second after
> starting/resuming an activity from the home view. Fab! :)

Cool.

> It's worth a note that the zoom in effect is still lost for most svg icons, 
> only for the very simple icons is the effect visible (Log icon is simple 
> enough to show it, Distance icon is not quick enough). The zoom animation is 
> defaulting to 20 fps which can't be helping, but lowering it to 10fps doesn't 
> seem to help enough to make much of a visible improvement. I only reliably 
> started to see the zoom when I also increased the length of the zoom effect 
> from 1sec to 2sec by modifying launcher.py #116:
> 
> self._animator = animator.Animator(2.0, fps=10)
> 
> ...so I guess that first second of launching is still rather swamped
> so the first second of zoom is usually skipped. Hmmm, maybe the zoom
> start should be triggered only once the first update has hit.

Interesting.  I'll have a look at that.  I'm also interested in why
the zoom effect moves the icon around on the screen so much - using my
profile-pulsingicon.py test on my low-to-mid end laptop, I can clearly
see the icon, when "zooming", wobbling around the center
significantly.

> Regards,
> --Gary

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Sat, Oct 30, 2010 at 12:09:53AM +0530, Anurag Chowdhury wrote:
> Uptill now what we have gathered from this issue is:
> 
> 1) We can improve this issue by using a cache system or cairo operation:
> 
>   >" I think the problem is the code is rendering the svg icon every time
>   >  the color is changed.
>   >  There are not cache or cairo operation used to avoid this.
>   >
>   >  Gonzalo"
> 
>  -- I think that we all seem to agree upon this point that using a
> cache to store the once rendered frames and then reuse them later
>in the animation to improve the performance of the system.

This is already done.

>  3) We can try some tweaks to the animation and related aspects of the
> issue to make the animation smoother and lighter on
> system:
> 
>   >  "We did play around with a few ideas when Wade last worked on
> the pulse optimisation/enhancements. He landed
>   >  improvements for speed by minimising the area being redrawn, and
> landed the addition of the "failed to launch" check and
>   >  button/message. He also found a few extra cpu seconds worth of
> improvement that didn't land in time. The trick was to fade
>   >  in, _hold_, fade out, _hold_, the effect is still of pulsing
> activity but you can get away with less frames as you don't need to
>   >  redraw anything during the hold.
> 
>   >  This doesn't effect the initial start-up however, which I
> believe was the original ticket... FWIW I think F14 builds have
>   >  regressed for some other reason here, perhaps it's the window
> manager being laggy (I occasionally see window bezels before
>   >  things go full screen).
> 
>   >  Regards,
>   >  --Gary"
> 
> --But we realised that any changes made to improve the animation were
> not affecting the initial starting time , which is our main
>  point of concern.

This is not a correct summary of what Gary said - he didn't say "any
changes...".  I think you menat something else, because it also
doesn't agree with how you started point 3#.

> 4) Prerendering the pulsing icon and maintaining a cache (As said
> earlier in point #1 also) type scenario for the different frames of
>the animation also looks like a plausible option:
[...]
> --We can certainly try this option as it can possibly solve the
> problem to a large extent and improve the system performance.

Again, this is already done.

> Regards,
> 
> --Anurag

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)

[Martin Dengler]

On Thu, Oct 28, 2010 at 10:19:37PM -0400, Bernie Innocenti wrote:
> [cc += fgrose,m_stone]
> 
> On Wed, 2010-10-27 at 06:19 +0100, Martin Dengler wrote: 
> > On Wed, Oct 27, 2010 at 06:05:58AM +0530, Manusheel Gupta wrote:
> > > Are we ready to commit this patch?
> > 
> > Well, it's only a year after there were some quite significant
> > discussions about it:
> > http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020141.html
> > 
> > There were many concerns.  Have they all been addressed?  Perhaps just
> > nobody can be bothered to object again?
> 
> Well, a big change since last year is that now we've actually tested
> this UI change for several months with a large number of real users.
> The last adjustments proposed by Frederick Grose weren't actually
> tested in a classroom, but it was well justified and lays somewhere
> between the old and the new timings.

I agree this is the best we can do with the resources we have, and
that it's enough to justify applying the patch (not that it's my
decision).

> In order to test this change, we had to actually apply the patch to a
> release build before we knew whether or not it was an improvement.
> There's no other way! Very few developers have this luxury, so the
> requirement to test each UI change beforehand should be dropped unless
> we want to halt development.

There is no such requirement - that's a straw man.  Based on the
amount of debate last year, I think it's justified to ask how the
concerns raised have been addressed.  "We tried it for a year in a
deployment" seems a very good answer.  It's not the answer that I
guess would justify inclusion, but I don't think we should thus move
too close to the other extremem, which is accepting very little
justification for contentious, significant UI changes.

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.

> For the future, I'd like to propose that we review UI changes using the
> same criteria of any other code change. That is, by applying the
> maintainer's best judgment upfront and testing the best we can
> afterwards.

I don't disagree with this wording, but hope that the "maintainer's
best judgement" will apply different standards for a UI change that
would break documentation and training everywhere than for a PEP008
patch.

> Establishing a tighter feedback loop with users is a problem that can be
> solved separately with the help of deployments.

Making UI changes without feedback and that break documentation /
training should be done very carefully, if at all.

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 10:56:25AM +1100, James Cameron wrote:
> On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
> > I think the problem is the code is rendering the svg icon every time
> > the color is changed.  There are not cache or cairo operation used to
> > avoid this.
> 
> I agree.  Martin Dengler's stats graph confirms it.
> 
> Anurag is proposing skipping the paint after the first rendering.  It
> remains a puzzle to me why the first frame rendering takes so much
> longer than the remaining frames.
> 
> In Netrek when I faced this kind of problem, I solved it by
> pre-rendering a reduced number of frames, or at least caching the
> rendered frames.
> 
> The frame rate is 10 Hz.  The _phase is continually incremented, and the
> level is set using:
> 
>   self._level = (math.sin(self._phase) + 1) / 2
> 
> The first two seconds uses these levels:
> 
> 0.50
> 0.920735
> 0.954649
> 0.570560
> 0.121599
> 0.020538
> 0.360292
> 0.828493
> 0.994679
> 0.706059
> 0.227989
> 0.05
> 0.231714
> 0.710084
> 0.995304
> 0.825144
> 0.356048
> 0.019301
> 0.124506
> 0.574939
> 
> Now if these were filtered to a reduced set of levels, the rendered
> images could be cached and re-used.
> 
>   N = 10
>   self._level = int(math.sin(self._phase) + 1) / 2 * N) / N

I'm interested in what you mean here.  I applied this patch:

$ diff -u ./source/sugar/src/jarabe/view/pulsingicon.py 
./install/lib/python2.6/site-packages/jarabe/view/pulsingicon.py 
--- ./source/sugar/src/jarabe/view/pulsingicon.py   2010-09-14 
11:02:24.566582134 +0800
+++ ./install/lib/python2.6/site-packages/jarabe/view/pulsingicon.py 2010-10-29 
16:42:40.156372299 +0800
@@ -78,7 +78,8 @@
 
 def __pulse_cb(self):
 self._phase += _STEP
-self._level = (math.sin(self._phase) + 1) / 2
+N = 10.0
+self._level = round((math.sin(self._phase) + 1) / 2, 3)
 self.update()
 
 return True

...and I didn't see much change with my test program[1]:

$ for i in $(seq 1 10) ; do ./profile-pulsingicon.py >> 
./profiling_results-before.txt 2>&1; done \
  patch ./install/lib/python2.6/site-packages/jarabe/view/pulsingicon.py  
~/tmp/pulsingicon.py-filter-_level_to_ten.patch \
  for i in $(seq 1 10) ; do ./profile-pulsingicon.py >> 
./profiling_results-after-filtering.txt 2>&1; done 

$ grep render_cairo profiling_results-before.txt | sed -e 
's/{.*render_cairo.*}/render_cairo/'
[  ncalls  tottime  percall  cumtime  percall   function  ]
   600.4380.0070.4380.007 render_cairo
   700.5010.0070.5010.007 render_cairo
   680.4980.0070.4980.007 render_cairo
   690.5110.0070.5110.007 render_cairo
   670.4960.0070.4960.007 render_cairo
   660.4730.0070.4730.007 render_cairo
   680.4910.0070.4910.007 render_cairo
   720.5300.0070.5300.007 render_cairo
   690.4960.0070.4960.007 render_cairo
   670.4880.0070.4880.007 render_cairo

$ grep render_cairo profiling_results-after-filtering.txt | sed -e 
's/{.*render_cairo.*}/render_cairo/'
[  ncalls  tottime  percall  cumtime  percall   function  ]
   640.4910.0080.4910.008 render_cairo
   640.4750.0070.4750.007 render_cairo
   640.4580.0070.4580.007 render_cairo
   640.4630.0070.4630.007 render_cairo
   640.4380.0070.4380.007 render_cairo
   640.4590.0070.4590.007 render_cairo
   640.4550.0070.4550.007 render_cairo
   640.4670.0070.4670.007 render_cairo
   640.4790.0070.4790.007 render_cairo
   640.4730.0070.4730.007 render_cairo


Can you suggest some corrections to what I've done?

Martin

1. http://www.martindenglerm.com/tmp/sl.o-2080/profile-pulsingicon.py



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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Thu, Oct 28, 2010 at 03:44:37PM -0300, Gonzalo Odiard wrote:
> I think the problem is the code is rendering the svg icon every time
> the color is changed.

Indeed.  As James Cameron pointed out, we're setting the stroke and
fill in rapid succession, resulting in two calls to render().

> There are not cache or cairo operation used to avoid this.

Perhaps CanvasIcon's _emit_paint_needed_icon_area can check some
dirty flag that gets reset upon paint()?  I'm not an expert, and it
sounds like there might be lots of races to worry about.

However it's easier just to replace the calls to set_stroke_color() and
set_fill_color() with set_xo_color(), which does both and then calls
_emit_paint_needed_icon_area().

So I did that[1], and using a small script[2] to just launch the
pulsing icon window using the sugar emulator, we can compare before[3]
and after[4]: The code change halves the number of times we call
_emit_paint_needed_icon_area, and that is borne out by the experiment:
_emit_paint_needed_icon_area is called 196 times in 10 seconds before
the patch, and 99 times afterwards.  Correspondingly, render_cairo()
is called half as much.

I'd love any feedback.

> Gonzalo

Martin

1. 
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-set-new-colors-in-one-go-to-avoid-multiple-calls-to-SVG-rendering.patch

2. http://www.martindengler.com/tmp/sl.o-2080/profile-pulsingicon.py

3. 
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph-before.png

4. 
http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph-after.png


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 11:05:45AM +1100, James Cameron wrote:
> On Thu, Oct 28, 2010 at 06:42:53PM +0100, Martin Dengler wrote:
> > http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png
> 
> Nice.  A question on interpretation ... is the number of renderings
> consistent with the number of __pulse_cb callbacks?

Yes...

> Looking at the bright green costly part of the graph, only the call
> counts:
> 
> __pulse_cb 80x
> __update 84x
> {
> __set_stroke_color 40x (implies get_pulsing is false half the time)
> __set_fill_color 40x
> }
> _emit_paint_needed_icon_area 83x
> get_surface 199x
> render_cairo 90x
> 
> I'm puzzled as to why (a) set_stroke_color is only being called 40
> times, yet (b) render_cairo is being called 90 times.  As if there is a
> doubling.

...because both set of 40x calls to __set_stroke_color and
__set_fill_color are causing _emit_paint_needed_icon_area to be
called[1,2], which call get_surface, which call render_cairo.  That
seems like doubling to me :).  Perhaps (OTTOMH) a flag in icon.py
_emit_paint_needed_icon_area which prevents it from actually emitting
if, well, it hasn't been paint()ed yet?

I'm also not sure why the icon is set as "sensitive", or whether "if
sensitive:"[3] is the right test.

Martin

1. 
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/graphics/icon.py#n654
2. 
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/graphics/icon.py#n685
3. 
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/graphics/icon.py#n296


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:26:33AM +0530, Anurag Chowdhury wrote:
> On Fri, Oct 29, 2010 at 12:14 AM, Gonzalo Odiard  wrote:
> > I think the problem is the code is rendering the svg icon every time
> > the color is changed.
> > There are not cache or cairo operation used to avoid this.
> >
> > Gonzalo
>
> Certainly that seems to me as a possible reason behind this issue ,
> but in the present state we need to decide exactly on what future we
> want for this pulsing icon i.e. keep it , improve it or replace it.

I guess that's why Gonzalo raised the point.  It's usually better to
fix the problem than to fix a symptom.

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Fri, Oct 29, 2010 at 05:26:40AM +0530, Anurag Chowdhury wrote:
> On Thu, Oct 28, 2010 at 11:12 PM, Martin Dengler
>  wrote:
> >  to test the time taken by update function everytime
> >> it is called.
> >> I used the time.time() function to measure the time taken to process
> >> the update step.
> >
> > There is a better way: use cProfile and gprof2dot.py.  You will get
> > graphs (and of course the raw data) like this:
> >
> Thanks and I appreciate the pointers., but I did it this way as I
> wanted it simple and to the point. :)

Well, it's simple, but it's not very useful or convincing.

> >> And If you may compare the odd steps of both logs i.e the numbers in
> >> the lines having "seconds taken to update frame" appearing at the odd
> >> steps
> >> (3rd ,5th ,7th.entries) and similarily compare  the even steps
> >> you may find the average time taken on XO-1.5 to run the update
> >> function was nearly 50% faster.
> >
> > Odd steps?  Even steps?  Sounds scary.  Why?
> >
> Sorry for the confusion. What  I meant to say by frames renders at odd
> steps was 1st frame, 3rd frame , 5th frame.so on, similarily
> for even frames.

I understood that.  The question is: Why?

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

I'm sorry to harp on this, but I hope you can see it actually takes
quite some effort to communicate this stuff well...

On Thu, Oct 28, 2010 at 09:27:18PM +0530, Anurag Chowdhury wrote:
> I have attached the pulsingicon.py file

Thanks - very useful to understand what you're timing.

> in which I placed the benchmark script

which benchmark script?!  Another file you should include.

 to test the time taken by update function everytime
> it is called.
> I used the time.time() function to measure the time taken to process
> the update step.

There is a better way: use cProfile and gprof2dot.py.  You will get
graphs (and of course the raw data) like this:

http://www.martindengler.com/tmp/sl.o-2080/pulsingicon.py-stats-graph.png

...and then you could show us before and after your change on the XO
1.0 and XO 1.5.  Normally the relative time is most interesting, but
since we are also interested in the absolute running time I patched
gprof2dot.py to show that, and you can see the total time (in seconds)
consumed by each graph node and its subtree as the second-to-last
number shown in the node.

You can find the pulsingicon.py changes and the instructions I used to
make that in:
http://www.martindengler.com/tmp/sl.o-2080/README.txt

> And If you may compare the odd steps of both logs i.e the numbers in
> the lines having "seconds taken to update frame" appearing at the odd
> steps
> (3rd ,5th ,7th.entries) and similarily compare  the even steps
> you may find the average time taken on XO-1.5 to run the update
> function was nearly 50% faster.

Odd steps?  Even steps?  Sounds scary.  Why?

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote:
> I carried out the same benchmark test, which I earlier conducted on an
> XO-1.5 , on a X0-1 .

Please tell us what the test is/was.  How many times did you run it?
How did you make sure nothing else interfered with the system cpu and
memory while you were running it?

> And I have attached the log files obtained in both the cases. [...]
> the consecutive times taken for the rendering of the frames on the
> XO-1 were much larger as compared to that on a XO-1.5.

I compared the means and standard deviations for the numbers in the
lines having "seconds taken to update frame" and I don't understand
how you came to that "very much larger" conclusion:

$ (~/src/stddev.py < ~/tmp/xo15  ; ~/src/stddev.py < ~/tmp/xo10) | \
~/tmp/compare_means.py
for 'seconds taken to update frame':
XO 1.0 mean was 0.021002, XO 1.5 mean was 0.014994
...change in speed was -28.605292%

You can find the data from your logs (I had to remove some numbers
that were split across the stderr output that was mixed in with your
logging) and the scripts mentioned at:

http://www.martindengler.com/tmp/sl.o-2080

Please, can you do more than wave your hands to help us understand the
effect of what you've done?  You want to affect a key part of the
system for a lot of people.  It's a bit frustrating to hear talk of
"very much larger" speed without actually knowing how and what you're
measuring.

> Regards,
> --Anurag

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)

[Martin Dengler]

On Wed, Oct 27, 2010 at 06:05:58AM +0530, Manusheel Gupta wrote:
> Are we ready to commit this patch?

Well, it's only a year after there were some quite significant
discussions about it:
http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020141.html

There were many concerns.  Have they all been addressed?  Perhaps just
nobody can be bothered to object again?

> Manu

Martin


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

Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080

[Martin Dengler]

On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote:
> The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1 could
> be verified by comparing their hardware specifications.
> at http://en.wikipedia.org/wiki/OLPC_XO-1  (For XO-1) and
> http://wiki.laptop.org/go/Hardware_specification_1.5 (For XO-1.5) .Also we
> can see the test results of James'(quozl) at
> http://bugs.sugarlabs.org/ticket/245 which suggests that XO-1.5 is atleast
> twice as fast as XO-1.

Those conclusions are oversimplified - in general they might be useful
but you are talking about a very specific, very large and subtle set
of operations with a very specific set of interacting hardware and
software components, the software ones of which change a lot from
release to release.

Much more compelling for a problem that has been with us for a while,
has been a moving target in software terms, and many people have
looked at, would be just to test your change on an XO-1 and report
back.  If you don't have one - and even if you do - others will be
interested in testing your changes on an XO-1, too.

Please can you provide an easy way for people with an XO-1 and a
well-supported release to objectively gather the speedup of your
patch?  Or at least some numbers of your own?

Martin


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

Re: [Sugar-devel] Development Meetings

[Martin Dengler]

On Mon, Oct 25, 2010 at 01:45:21PM +, Aleksey Lim wrote:
> For me, default time is ok
> 
> Wednesday
> 2010-10-27, 14:00 UTC
> irc://irc.freenode.net#sugar-meeting
> 
> How about other possible attenders?

+1


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

Re: [Sugar-devel] #1169 NORM: Drop down menus give no indication of their existence, also are too slow to load.

[Martin Dengler]

On Tue, Oct 05, 2010 at 10:14:58AM +0200, Tomeu Vizoso wrote:
> On Sat, Oct 2, 2010 at 09:46, Shanjit Singh Jajmann
>  wrote:
> > Hi,
> >
> > Appropriate changes have now been made to the issue and the patches have
> > also been uploaded. Changes have been made as suggested by FGrose in his
> > comment.
> 
> I see lots of related information in the bug tracker about this and
> other proposals.
> 
> Can you make explicit why you have chosen to implement this particular 
> solution?
> 
> Also, would be good to have a ticket for each issue that needs to be
> addressed.
[...]
> For the others, please chime into this thread if you have any
> insight

For major / broad UI changes like this I'd like to see 1) summaries of
the opposing views by the patch author (so they know what they're
doing and its import, and can help others have a useful discussion on
it); and 2) manifest consensus for the change.  I see neither in this
patch.

> Thanks,
> 
> Tomeu

Martin


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

Re: [Sugar-devel] Home view activities layout

[Martin Dengler]

On Fri, Jul 30, 2010 at 11:32:34PM -0400, Walter Bender wrote:
> On Fri, Jul 30, 2010 at 8:25 PM, Chris Ball  wrote:
> > Hi Christian,
> >
> >   > Hi Chris--to address scalability we have a list view from which
> >   > you can select favorite activities to go in the ring. This is a
> >   > similar technique to the OSX dock or Windows taskbar.
> >
> > I don't think this is working out.  For OLPC (and perhaps SoaS as
> > well?) we're shipping with every activity other than Log and Terminal
> > favorited by default, after receiving reports that kids didn't
> > understand how to launch activities otherwise.
> 
> Here is a tighter spiral of 74 icons for the home view (running in the
> Sugar emulator at 800x600).
>
> http://wiki.sugarlabs.org/images/f/f0/Spiral-home-view.png

+1

> > Thanks,
> >
> > - Chris.
>
> -walter

Martin


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

Re: [Sugar-devel] A Tale of Sugar and Pippy

[Martin Dengler]

On Tue, Jun 22, 2010 at 02:41:04PM +0100, Martin Dengler wrote:
> On Tue, Jun 22, 2010 at 02:36:42PM +0100, Lucian Branescu wrote:
> > I think all activities should have "Report bug" on the toolbar
> > somewhere. And of course a system in place on the other end, perhaps
> > email-to-trac?
> 
> Good idea, but why make every activity implement this?  I think a
> bikeshed icon in the frame would be better.  I plan to release one on
> April 1, 2011.

HHOS.  And I'm not sure what colour the icon should be.




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

Re: [Sugar-devel] A Tale of Sugar and Pippy

[Martin Dengler]

On Tue, Jun 22, 2010 at 02:36:42PM +0100, Lucian Branescu wrote:
> I think all activities should have "Report bug" on the toolbar
> somewhere. And of course a system in place on the other end, perhaps
> email-to-trac?

Good idea, but why make every activity implement this?  I think a
bikeshed icon in the frame would be better.  I plan to release one on
April 1, 2011.

Martin


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

Re: [Sugar-devel] A Tale of Sugar and Pippy

[Martin Dengler]

On Tue, Jun 22, 2010 at 06:07:50PM +1000, James Cameron wrote:
> On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote:
> > 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?
>
> We might not be able to depend on an e-mail path.  So I envisage a
> small web application on sugarlabs.org

Both an email and a POST request could be tried - saving the entry to
the journal might be good, which then opens up a whole other set of
routes (and confusions) for submission/sharing (and its resultant UI
challenges).

To bikeshed a bit, perhaps "share via email" and/or "share via web"
could become part of Activities' sharing options.

Martin


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

Re: [Sugar-devel] R&D vs Product Support

[Martin Dengler]

On Mon, Jun 21, 2010 at 10:06:48AM -0400, Martin Langhoff wrote:
> we're too small to split people into clubs

+1

> cheers,
> 
> 
> m

Martin


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

Re: [Sugar-devel] core maintainers

[Martin Dengler]

[we're just arguing for fun now, I guess]

On Mon, Jun 21, 2010 at 12:59:01PM -0500, David Farning wrote:
> On Mon, Jun 21, 2010 at 6:57 AM, Martin Dengler
>  wrote:
> > David,
> >
> > When you have the time, some clarity here would be appreciated.
> >
> > Martin
> >
> > On Sat, Jun 12, 2010 at 12:49:33AM +0100, Martin Dengler wrote:
> >> On Fri, Jun 11, 2010 at 01:58:32PM -0500, David Farning wrote:
> >> > Over the past couple of months, Activity Central has been establishing
> >> > a network of developers to provide service and support for
> >> > deployments.
> >>
> >> I assume they're paid, otherwise why would you (Activity Central) not
> >> just "establish" such people into the normal SugarLabs network.
> 
> Some developers receive a salary from AC, some are paid by
> deployments, and some are paid by third parties.  The significant
> difference is that Sugar Labs is entirely voluntary (as it should be.)

It seems like you're setting up some kind of dichotomy between people
that are volunteers (in some way) and people that (in some way) are
paid to work on Sugar.  That seems both odd and beside the point.

> The developers for the deployment support network work on particular
> task and bugs which _someone_ is willing to pay to be fixed.
> 
> It is the standard upstream downstream division of labor.

I'm not sure what you're getting at.  The only reason for such a
division is if the needs diverge.  Plenty of "downstream" people are
"upstream" as well.  Again, I think this is a useless and false
dichotomy.

> >> > On Fri, Jun 11, 2010 at 12:04 PM, Walter Bender 
> >> >  wrote:
> >> > > What is "Deployment Support Network"?
> >> >
> >> > Sugar Labs has expressed the importance of more code contributions
> >> > from deployments.  Deployments have expressed an interest in fixing
> >> > their own bugs.  The Deployment Support Network fills that gap.
> >>
> >> What gap?  The gap between getting code from deployments and...
> >> deployments who want to write code?
> 
> Many deployments would like to participate in the upstream process but
> for some reason don't.  The biggest hurdle is that it takes time,
> money and effort to push things upstream.  As such many deployments
> are sitting on local patches... or worse just not bothering to fix
> issues.

It seems like now you've got an organisation that has as a for-fee
service the act of getting code from downstream to upstream.  I can
see that being either constructive or destructive.

> >> What is "Deployment Support Network"?  In particular, who are they and
> >> how/why are they distict from Sugar Labs "members" (basically anyone
> >> who wants to submit a patch or write an email to sugar-devel@)?
> 
> The Deployment Support Network is a subset of Sugar Labs members who
> work on tasks requested and paid for by some body interested in having
> those task accomplished.

Literally, if someone you don't know about is paid by somebody to work
on Sugar they're automatically part of the DSN?  Or is the DSN trying
to be the _only_ group of paid people working on Sugar?  The first
sounds overly broad and the second sounds a bit odd.  I guess AC is
just trying to present the DSN as a service to people who want to pay
for help with Sugar, but I can see paranoid people bleating on about
"DSN competes with SL for attention of deployments' coders' time".
Let's not feed such speculation with sloppy descriptions of DSN.

> >> > Initial, I had reservations about the maintainship roles these
> >> > developers would hold at Sugar Labs.  In light of the current backlog
> >> > of patches and the heavy burden a few core developers are holding, I
> >> > would like  work with the Sugar Labs development team to determine the
> >> > process for experienced developers to become maintainers.
> >>
> >> You've totally avoided Walter's question (AFAICS) and then gingerly
> >> formulated an missive that, despite some mysterious reservations,
> >> seems to imply that you think the "[SL] development team" will resist
> >> having "experienced developers [...become] maintainers".  Why would
> >> you think that?
> 
> Because change is disruptive.  The Sugar Labs code base development is
> premised on individuals "Scratching their own itch" by writing code
> which is reviewed and committed.

SL developers have constantly lamented the lack of feedback from
deployments.  Again, paranoid people could easily read your statements
as indicating that AC has an incentive to poison deployments' coders'
opinions about how receptive SL will be to their code unless it goes
through paid gatekeepers like AC.  Please don't characterise SL
development as 'premised on individuals "Scratching their own itch"'.

> david

Martin


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

Re: [Sugar-devel] core maintainers

[Martin Dengler]

On Mon, Jun 14, 2010 at 02:02:57PM -0500, David Farning wrote:
> On Mon, Jun 14, 2010 at 12:36 PM, Tomeu Vizoso  wrote:
> > On Fri, Jun 11, 2010 at 18:39, David Farning  wrote:
> >> Over the past couple of months it has appeared that the ramp up of
> >> deployment submitted patches has stretched the core maintainers rather
> >> short.
> >>
> >> I would like to consider having Deployment Support Network developers
> >> start accepting additional maintainership responsibility and
> >> authority.  Specifically, I am interested in which core activities are
> >> in need of a maintainer and which core modules are up for adoption.
> >>
> >> With this information, I can start identifying and recruiting
> >> potential maintainers.
> >
> > From my POV, in order of need/suitability:
> >
> > - Read
> > - Write
> 
> AC will accept responsibility for  Read and Write.

Please update
http://wiki.sugarlabs.org/go/Development_Team/Release/Modules then.
It'd also be nice to know who the people are and why they are
qualified (code patches seem a good way to do this, as implied by
http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024616.html
).

> david

Martin


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

Re: [Sugar-devel] core maintainers

[Martin Dengler]

David,

When you have the time, some clarity here would be appreciated.

Martin

On Sat, Jun 12, 2010 at 12:49:33AM +0100, Martin Dengler wrote:
> On Fri, Jun 11, 2010 at 01:58:32PM -0500, David Farning wrote:
> > Over the past couple of months, Activity Central has been establishing
> > a network of developers to provide service and support for
> > deployments.
> 
> I assume they're paid, otherwise why would you (Activity Central) not
> just "establish" such people into the normal SugarLabs network.
> 
> > On Fri, Jun 11, 2010 at 12:04 PM, Walter Bender  
> > wrote:
> > > What is "Deployment Support Network"?
> >
> > Sugar Labs has expressed the importance of more code contributions
> > from deployments.  Deployments have expressed an interest in fixing
> > their own bugs.  The Deployment Support Network fills that gap.
> 
> What gap?  The gap between getting code from deployments and...
> deployments who want to write code?
> 
> What is "Deployment Support Network"?  In particular, who are they and
> how/why are they distict from Sugar Labs "members" (basically anyone
> who wants to submit a patch or write an email to sugar-devel@)?
> 
> > Initial, I had reservations about the maintainship roles these
> > developers would hold at Sugar Labs.  In light of the current backlog
> > of patches and the heavy burden a few core developers are holding, I
> > would like  work with the Sugar Labs development team to determine the
> > process for experienced developers to become maintainers.
> 
> You've totally avoided Walter's question (AFAICS) and then gingerly
> formulated an missive that, despite some mysterious reservations,
> seems to imply that you think the "[SL] development team" will resist
> having "experienced developers [...become] maintainers".  Why would
> you think that?
> 
> > david
> 
> Martin




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

Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)

[Martin Dengler]

On Wed, Jun 16, 2010 at 09:17:37AM +1000, fors...@ozonline.com.au wrote:
> > Furthermore, what all system parameters should be made available
> > through such a means (such as free memory, and cpu load)?
> > Suggestions and opinions welcome!
> 
> Time and date would be good.

We've been there:

http://wiki.laptop.org/go/User:MartinDengler#Add_a_clock_.28to_the_frame.29
http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014270.html

> Tony

Martin


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

Re: [Sugar-devel] core maintainers

[Martin Dengler]

On Fri, Jun 11, 2010 at 01:58:32PM -0500, David Farning wrote:
> Over the past couple of months, Activity Central has been establishing
> a network of developers to provide service and support for
> deployments.

I assume they're paid, otherwise why would you (Activity Central) not
just "establish" such people into the normal SugarLabs network.

> On Fri, Jun 11, 2010 at 12:04 PM, Walter Bender  
> wrote:
> > What is "Deployment Support Network"?
>
> Sugar Labs has expressed the importance of more code contributions
> from deployments.  Deployments have expressed an interest in fixing
> their own bugs.  The Deployment Support Network fills that gap.

What gap?  The gap between getting code from deployments and...
deployments who want to write code?

What is "Deployment Support Network"?  In particular, who are they and
how/why are they distict from Sugar Labs "members" (basically anyone
who wants to submit a patch or write an email to sugar-devel@)?

> Initial, I had reservations about the maintainship roles these
> developers would hold at Sugar Labs.  In light of the current backlog
> of patches and the heavy burden a few core developers are holding, I
> would like  work with the Sugar Labs development team to determine the
> process for experienced developers to become maintainers.

You've totally avoided Walter's question (AFAICS) and then gingerly
formulated an missive that, despite some mysterious reservations,
seems to imply that you think the "[SL] development team" will resist
having "experienced developers [...become] maintainers".  Why would
you think that?

> david

Martin


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

Re: [Sugar-devel] [SoaS] Heads-up: POSSE folks hacking in Fedora/Sugar thisweek and next

[Martin Dengler]

[In light of sense and recent conversations, please can we not
cross-post to five mailing lists in the future unless there is clear
information that all lists can benefit from]

On Wed, Jun 09, 2010 at 03:37:19PM -0400, Walter Bender wrote:
> On Wed, Jun 9, 2010 at 3:26 PM, Peter Robinson  wrote:
> > On Wed, Jun 9, 2010 at 7:50 PM, Art Hunkins  wrote:
> >> I've noticed that neither the SoaS CD Boot Helper nor the SoaS Floppy Disk
> >> Boot Helper manage to boot SoaS Mirabelle (Fedora 13).
> >
> > [Please tell me specific devices that don't boot using boot helper CD]
> >
> 
> [Helper CD is fine, think Windows 2000-era PCs as most benefited]

This conversation is about as useful as emailing a car designer's
mailing list and saying "I bought some diesel but I can't get to the
supermarket".

We need:

1) Specific machines (BIOS + motherboard model #s) that don't work
2) Precise symptoms - "doesn't work", "doesn't boot",
"crashes", "hangs", are all useless and frustrating for everyone.

Otherwise please don't waste anyone's time.

> >> Art Hunkins
> >
> > Peter
> >
> -walter

Martin


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

Re: [Sugar-devel] [record] Fixes to the UI

[Martin Dengler]

On Tue, Jun 08, 2010 at 11:04:44AM -0400, Bernie Innocenti wrote:
> El Mon, 07-06-2010 a las 03:02 +0100, Martin Dengler escribió:
> > On Mon, Jun 07, 2010 at 12:04:18AM +0530, anishmangal2...@gmail.com wrote:
> > [...]
> > great variable name that you inherited, there...might as well rename
> > it to something more standard like "buttonBox" while you're at it.
> 
> Or maybe "button_box". CamelCase does not seem to be very fashionable
> among Python developers.

Totally right - I stand corrected.

> > > @@ -884,6 +939,10 @@ class UI:
> > >  kids[i].setButtClickedId(BUTT_CLICKED_ID)

Loads of unfortunate areas there, too.

Martin


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

Re: [Sugar-devel] [record] Fixes to the UI

[Martin Dengler]

On Mon, Jun 07, 2010 at 01:12:38PM +0530, Anish Mangal wrote:
> > Why don't you just fix hideAllWindows()?
> 
> Because it has a specific purpose.

Specific purpose (distinct from what your other method has) or just
different implementation?

> [implementation] If instead of moving them off-screen, I actually
> hide the widgets, I won't be able to resize or move them.

Ok - I haven't read the code enough to see why that's a problem.

> That said, I could probably give better names to the methods in
> question.

That'd be nice...that way it doesn't just look like you have two
methods that do the same thing, one correctly and one badly.

Martin


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

Re: [Sugar-devel] initial commit to git?

[Martin Dengler]

Glad you sorted it out.

On Sun, Jun 06, 2010 at 11:00:43PM -0400, Art Hunkins wrote:
> Simple enough: just add "master" to the end of your first git push
> command. (I believe it's only necessary for the initial commit.)

Yes, because there is no "master" ref in the remote repo - it's empty
of commit objects and refs that might name them.

> I had not run across this requirement before anywhere in the git
> repository itself.

Which requirement?  If you see 'just add[ing] "master"' as "a
requirement" you're missing the point of what "git push" does.  One
always is telling git to push _to_ a *ref* (e.g., "master") - it just
was implied / defaulted sensibly before so you may not have realised
what ref git was choosing for you.  Try to push from a branch named
one thing in your local repo but a different thing on the remote repo
without understanding what "git push origin master" means - you'll be
hopelessly confused :).

> One of the problems I've encountered is that it's difficult to find
> specific info in the wiki - especially when you don't know your
> precise problem.

That's why I suggested re-reading your favorite git tutorial and
asking oneself "what could I be overlooking?".  The git man pages
reward educated study - not easy when one is frustrated at a
distracting problem, I admint.

> Art Hunkins

Martin


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

Re: [Sugar-devel] On sugar-0.90.

[Martin Dengler]

On Sat, Jun 05, 2010 at 03:06:34PM -0400, Michael Stone wrote:
> [Sugar 0.90 release management discussion]

Could you or someone with similar standing merge this thread with
http://lists.sugarlabs.org/archive/iaep/2010-June/011033.html ?  It
seems they're talking about the same thing.

> Michael 

Martin


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

Re: [Sugar-devel] [record] Fixes to the UI

[Martin Dengler]

On Mon, Jun 07, 2010 at 12:04:18AM +0530, anishmangal2...@gmail.com wrote:
[...]
> @@ -884,6 +939,10 @@ class UI:
>  kids[i].setButtClickedId(BUTT_CLICKED_ID)
>  
>  
> +def actuallyHideAllWindows( self ):
> +for i in range (0, len(self.windowStack)):
> +self.windowStack[i].hide_all()
> +
>  def hideAllWindows( self ):
>  for i in range (0, len(self.windowStack)):
>  self.moveWinOffscreen( self.windowStack[i] )

Why don't you just fix hideAllWindows()?

> @@ -1913,22 +2036,22 @@ class ScrubberWindow(gtk.Window):
>  self.add( self.hbox )
>  
>  self.button = gtk.Button()
> -buttBox = gtk.EventBox()
> -buttBox.add(self.button)
> -buttBox.modify_bg( gtk.STATE_NORMAL, Constants.colorBlack.gColor )
> +self.buttBox = gtk.EventBox()
> +self.buttBox.add(self.button)
> +self.buttBox.modify_bg( gtk.STATE_NORMAL, 
> Constants.colorBlack.gColor )

great variable name that you inherited, there...might as well rename
it to something more standard like "buttonBox" while you're at it.


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

Re: [Sugar-devel] initial commit to git?

[Martin Dengler]

On Sun, Jun 06, 2010 at 07:16:55PM -0400, Art Hunkins wrote:
> $ git push  gitori...@git.sugarlabs.org:sun-moon-music/mainline.git
[...]
> No refs in common and none specified; doing nothing.
> Perhaps you should specify a branch such as 'master'.

> The line:
> Perhaps you should specify a branch such as 'master'.
> keeps showing up in these dialogs.

Git is telling you exactly what to do, and this time it's right.

try

 git push origin master

(like you have tried before, when origin wasn't set to gitorious) or

 git push gitori...@git.sugarlabs.org:sun-moon-music/mainline.git master

(like you almost tried before but with the fatally omitted "master")

> To my knowledge there is *nothing but* a "master."

There can be many.  "master" is a ref.  A ref names a commit object
(roughly).  You push a ref to another repo's ref.  "git push origin
master" means:

take the commit object named by (among other things) the ref "master"
in the current directory's repo and transfer (push) it to the remote
(other) repo named by "origin" (this is defined by you in the config
file), and change the ref "master" (this is defaulted for you in your
command) in that remote repo to point to that commit, and transfer any
commits leading up to my local master that are necessary to that
remote repo, too.

> Further ideas most appreciated.

It has helped me to re-read the git tutorials I have found useful in
the past when I have to come to grips with something in git that's
giving me trouble.  It usually means I haven't understood something
fully.

> Art Hunkins

Martin


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

Re: [Sugar-devel] Change default Neighborhood network settings for greater security

[Martin Dengler]

On Wed, May 26, 2010 at 10:34:04AM -0700, Frederick Grose wrote:
> We simply have no way of knowing who the other users are with whom a
> child can "make friends."

How is this different from the lack of knowledge one has about the
people one's children could meet at a city park?

> All it would take is for one bad thing to happen for the Sugar
> project to suffer.

This is an unsubstantiated and dangerous assumption to make, and as a
parent I would not support such a change to the default.

From a learning environment wher "collaboration is first class" to
cripple it for the average downloader by default is silly.  We must
resist this "only one bad thing" line of reasoning, which reducto ad
absurdum leads to paralysing madness (shall we change the branding in
case "one bad thing" happens like a child misinterpreting "Sugar is
good" and gorging themselves on sugar?).


> While we love the idea of children from all over the world collaborating
> on-line, perhaps pragmatic concerns about the security of all children
> should lead us, at the very least, to have the default setting on the Mesh
> entry as a blank. Parents and teachers will then be responsible for enabling
> this feature, if they so wish.

Parents and teachers giving their child a computer with a learning
environment that "promotes collaborative learning" (first sentence of
the first text on www.sugarlabs.org) have chosen to take
responsibility for the nature of their child's learning, including the
collaborative part that is so promoted (rightly so).

Please don't try to convince me that someone who's downloaded an .iso,
installed it on a usb stick, and handed it, or a computer with it, to
a child hasn't assumed that responsibility.

> pragmatic concerns about the security of all children

We need to not assume responsibility for "the security of all
children".

> [...] at the very least [the default collaboration setting should be
> effectively "off for the individual SoaS user"]

I cannot imagine what might be meant by "the very least" here.

Martin


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

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

[Martin Dengler]

On Wed, May 26, 2010 at 10:57:55AM -0400, Michael Stone wrote:

> Additionally, having a mixed-language codebase may be
> off-putting to some potential contributors. 

It's also going to decrease consistency[1] and increase the bar to
contribution to (ad absurdum) working knowledge of each language of
each patch contributor.

> [D]oes 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[?]

It doesn't seem likely since an understanding of existing English code
would seem a prerequisite for any patches to exist in the first
place.

> (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?)

Oh wait, are you supporting *reviewing* patches in any language but
*committing* only translated patches?  That seems much less
consistency-hostile.

> Regards,
> 
> Michael

Martin

1. I don't think the second section of PEP-8 diminishes this objection


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

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

[Martin Dengler]

On Wed, May 26, 2010 at 11:14:37AM +0200, Bert Freudenberg wrote:
> IMHO the whole code base should be in English. This is the language
> we use for collaborating. 

+1 FWIW

Martin


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

Re: [Sugar-devel] Sugar 0.88 in F11-XO1

[Martin Dengler]

On Mon, Feb 22, 2010 at 07:43:33PM -0300, Bernie Innocenti wrote:
> >From today's #sugar-meeting:
> 
>  bernie: I think a big problem to recruit 0.88 testers, is that there 
> are no xo images
>  bernie: scratch builds, like tomeu said, sounds good
>  bernie: and then create a repo
>  bernie: maybe mtd is interested in that, too
> 
> Ok, I'll create some custom F11-XO1 builds with the latest Sugar
> packages retrofitted for testing purposes.

Sorry if it's been answered already: I wonder why you prefer 0.88 on
F11 for XO-1 builds, rather than 0.88 (or latest) on F12 (or latest)
for XO-1 builds?

Martin


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

Re: [Sugar-devel] Soas03/04 Font Size?

[Martin Dengler]

On Sun, Nov 08, 2009 at 06:29:15PM -0500, Art Hunkins wrote:
> I've run into a major unexpected problem with both, however: the default 
> font sizes have been increased so that my activities, nicely sized for both 
> XO-1 and Strawberry, now considerably overflow the same screens.
> 
> So I need to add code to compensate.

Didn't Daniel Drake suggest an algorithm to deal with this?

Martin


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

Re: [Sugar-devel] OOM conditions

[Martin Dengler]

On Sun, Nov 08, 2009 at 12:07:58PM +, Lucian Branescu wrote:
> Slightly off-topic, has anyone tried compcache
> (http://code.google.com/p/compcache/) on an XO-1? I might if I can get
> it to work.

Yes.  It works very well.

http://www.google.com/search?q=compcache+xo

Martin


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

Re: [Sugar-devel] OOM conditions

[Martin Dengler]

On Fri, Nov 06, 2009 at 04:50:53PM +, Tomeu Vizoso wrote:
> On Wed, Nov 4, 2009 at 14:16, Martin Dengler  wrote:
> > On Fri, Oct 30, 2009 at 11:22:13PM +0100, Tomeu Vizoso wrote:
> >> On Fri, Oct 30, 2009 at 16:58, Richard A. Smith  wrote:
> >> > Working the table at the Boston book festival I was reminded how
> >> > painful the OOM stuff is on a gen 1. The demo machines were in
> >> > this state a lot as each visitor would open up a new
> >> > program.  Basically you have to just turn the unit off and restart
> >> > as trying to recover is futile.
> >>
> >> What if activities had a higher oom_score? Would that protect enough
> >> the processes that once killed require a system restart (X, shell,
> >> etc)?
> >
> > See patch vs sugar-toolkit HEAD below[1] (I can backport to 0.82 if
> > wanted).
> 
> Maybe would be better to have the shell do that? So it works for
> non-python activities.

Patch inline below.

> >> Regards,
> >>
> >> Tomeu
> >
> > Martin
> >
> Thanks,
> 
> Tomeu

Martin


(untested) patch against
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/activity/activityfactory.py
:

From 4bd6fb9f7f245c2aed92d6964746627d0c96cbec Mon Sep 17 00:00:00 2001
From: Martin Dengler 
Date: Sat, 7 Nov 2009 10:55:16 +
Subject: [PATCH] sacrifice activities to the OOM killer first

change the OOM-killer score of launched activities to be the maximum.
See discussion at http://linux-mm.org/OOM_Killer
---
 src/sugar/activity/activityfactory.py |   35 +
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/src/sugar/activity/activityfactory.py 
b/src/sugar/activity/activityfactory.py
index ee0fd92..5deee6e 100644
--- a/src/sugar/activity/activityfactory.py
+++ b/src/sugar/activity/activityfactory.py
@@ -65,6 +65,39 @@ def _close_fds():
 pass
 
 
+def __oom_adj_pid(pid, omm_adj_value=None):
+""" Change a process' OOM likelihood to oom_adj_value.
+
+By default, use the value of gconf path
+"/desktop/sugar/performance/oom_adj_default"; if none exists, make
+this process most likely to be killed (oom_adj_value=15).
+
+Linux-specific.  See http://linux-mm.org/OOM_Killer for details.
+"""
+oom_adj_fullpath = "/proc/%s/oom_adj" % pid
+if os.path.exists(oom_adj_fullpath):
+try:
+
+# get values/defaults from gconf
+import gconf
+gconf_dir = "/desktop/sugar/performance"
+gconf_key = "oom_adj_default"
+client = gconf.client_get_default()
+if not client.dir_exists(gconf_dir):
+client.add_dir(gconf_dir, gconf.CLIENT_PRELOAD_NONE)
+if oom_adj_value is None:
+oom_adj_value = client.get_int(gconf_dir + "/" + gconf_key)
+if oom_adj_value is None:
+oom_adj_value = 15
+client.set_int(gconf_dir + "/" + gconf_key,
+   oom_adj_value)
+
+file(oom_adj_fullpath).write(oom_adj_value)
+
+except:
+pass
+
+
 def create_activity_id():
 """Generate a new, unique ID for this activity"""
 pservice = presenceservice.get_instance()
@@ -276,6 +309,8 @@ class ActivityCreationHandler(gobject.GObject):
 stdout=log_file.fileno(),
 stderr=log_file.fileno())
 
+__oom_adj_pid(child.pid)
+
 gobject.child_watch_add(child.pid,
 _child_watch_cb,
 (environment_dir, log_file))
-- 
1.6.2.5



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

Re: [Sugar-devel] Terminal.xo patch: do not die if the cwd is gone

[Martin Dengler]

On Tue, Nov 03, 2009 at 12:08:20PM -0500, paul fox wrote:
> On Tue, Nov 3, 2009 at 11:04 AM, Martin Langhoff
>  wrote:
> > Attached is a trivial patch that handles gracefully the situation
> > where cwd does not exist anymore or is no longer accessible to the
> > olpc user.
> >
> 
> frankly, i think the whole state-saving notion in Terminal (and other
> terminal emulators i've seen) is flawed, and a bad idea

I agree.  I don't see the point of Terminal's journal entries, either.

> (i understand the desire for restoring scrollback -- that's useful
> history).

Perhaps.  I don't find its place on the confusion/benefit curve
interesting, though.

> paul

Martin


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

Re: [Sugar-devel] OOM conditions

[Martin Dengler]

On Fri, Oct 30, 2009 at 11:22:13PM +0100, Tomeu Vizoso wrote:
> On Fri, Oct 30, 2009 at 16:58, Richard A. Smith  wrote:
> > Working the table at the Boston book festival I was reminded how
> > painful the OOM stuff is on a gen 1. The demo machines were in
> > this state a lot as each visitor would open up a new
> > program.  Basically you have to just turn the unit off and restart
> > as trying to recover is futile.
> 
> What if activities had a higher oom_score? Would that protect enough
> the processes that once killed require a system restart (X, shell,
> etc)?

See patch vs sugar-toolkit HEAD below[1] (I can backport to 0.82 if
wanted).

> Maybe even have the background activities have a higher
> oom_score than the one in the foreground?

Interesting.  Another approach I'd love feedback on would be to set
the allowed number of simultaneous running activities to be 2 (1 +
Journal) and writing a simple control panel extension that would allow
tweaking that, this oom_adj, and other related gconf values.
 
> Regards,
> 
> Tomeu

Martin


1. patch against
http://cgit.sugarlabs.org/sugar-toolkit/mainline/tree/src/sugar/activity/main.py
 :

diff --git a/src/sugar/activity/main.py b/src/sugar/activity/main.py
index 93f34e6..c868e11 100644
--- a/src/sugar/activity/main.py
+++ b/src/sugar/activity/main.py
@@ -31,7 +31,40 @@ from sugar.bundle.activitybundle import ActivityBundle
 from sugar import logger
 
 
+def __oom_adj_self(omm_adj_value=None):
+""" Change this process' OOM likelihood to oom_adj_value.
+
+By default, use the value of gconf path
+"/desktop/sugar/performance/oom_adj_default"; if none exists, make
+this process most likely to be killed (oom_adj_value=15).
+
+Linux-specific.  See http://linux-mm.org/OOM_Killer for details.
+"""
+oom_adj_fullpath = "/proc/self/oom_adj"
+if os.path.exists(oom_adj_fullpath):
+try:
+
+# get values/defaults from gconf
+import gconf
+gconf_dir = "/desktop/sugar/performance"
+gconf_key = "oom_adj_default"
+client = gconf.client_get_default()
+if not client.dir_exists(gconf_dir):
+client.add_dir(gconf_dir, gconf.CLIENT_PRELOAD_NONE)
+if oom_adj_value is None:
+oom_adj_value = client.get_int(gconf_dir + "/" + gconf_key)
+if oom_adj_value is None:
+oom_adj_value = 15
+client.set_int(gconf_dir + "/" + gconf_key,
+   oom_adj_value)
+
+file(oom_adj_fullpath).write(oom_adj_value)
+
+except:
+pass
+
 def create_activity_instance(constructor, handle):
+__oom_adj_self()
 activity = constructor(handle)
 activity.show()
 


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

Re: [Sugar-devel] [SoaS] New SoaS Snapshot ready!

[Martin Dengler]

On Tue, Nov 03, 2009 at 08:08:54AM -0500, Wade Brainerd wrote:
> Can we renamed soas04.zip to soas04virtualbox.zip in future builds?
> It's confusing to me because .zip does not have any connection to
> virtual machines.

Due to a typo in the Makefile the file that was supposed to be called
soas*.vmdk.zip has been called soas*.zip.  I chose .vmdk.zip because
the file-that-is-zipped is soas*.vmdk.

I have fixed the typo.

Do you think soas*.vmdk.zip is sensible?

> -Wade

Martin


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

Re: [Sugar-devel] Latest school-ready image for XOs?

[Martin Dengler]

On Mon, Nov 02, 2009 at 12:21:10PM +0100, Christoph Derndorfer wrote:
> Hi everyone,
> 
> I'll be spending an afternoon at the Austria OLPC / Sugar pilot project
> school on Thursday and was now wondering what the latest "school-ready"
> software image for use on the XO-1s there was.

I think it has to be 802[1].  SoaS-on-XO1 and F11-on-XO1 still have a
broken Record (pun, err, whatever), which is a blocker IMO.

> Thanks,
> Christoph

Martin


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

Re: [Sugar-devel] Submitting New Activities

[Martin Dengler]

On Sat, Oct 31, 2009 at 08:32:49PM -0400, Art Hunkins wrote:
> Attached is a zip archive that contains both Activities - 
> OurMusic.activity and OurMusicMC.activity.

As David asked you for a copy of what you're uploading, I assume you
are trying to upload two activities in one .zip file.  The link at
http://activities.sugarlabs.org/en-US/developers/addon/submit talks
about "Submit New Activity", singular.  Try uploading each activity as
its own zip file.

> Art Hunkins

Martin


pgprjRZIdDwI4.pgp
Description: PGP signature
___
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

[Martin Dengler]

On Thu, Oct 15, 2009 at 06:48:31PM +1100, James Cameron wrote:
> I'm adding it to my list of patches that improve performance
> perceptions.

Is this list available online somewhere?

Martin


pgpJVkW3DRSoD.pgp
Description: PGP signature
___
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

[Martin Dengler]

On Wed, Oct 14, 2009 at 12:14:57PM +0100, Tomeu Vizoso wrote:
> On Tue, Oct 13, 2009 at 03:40, Bernie Innocenti  wrote:
> > El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió:
> >> 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. Please,
> >> test it yourself and report back. If we like this change, I think we
> >> should go on and also kill the code that this patch makes redundant.
>
> I'm more concerned about developers proposing big user experience
> changes because they feel it's better. 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?

From [1]:

"Also the context menu, that appears when hovering for a moment over
an icon, providing some settings or features, irritated at least five
children more than it was supportive. Only two children used the
context menu of the home screen-icons to identify the activity,
because the name of the activity is displayed on top of the menu."

"[The children] were partially bothered [by the context menu-function]
and one girl even groaned every time the menu appears, because she did
not want it to."

Eben's justification of popup-menus[2] (which I alway re-buy into
everytime I read it) is perhaps not being absorbed by Activity
developers?  Perhaps with a bit of developer elbow-grease we can
eliminate the crutch of the popup-menu from every (Fructose) Activity?

> Thanks,
> 
> Tomeu

Martin

1. 
http://dimeb.informatik.uni-bremen.de/documents/Sugar-Not_necessarily_unhealthy.pdf

My favourite "use out of context for bashing-the-UI-design" quote is:
"Every-time the Frame appeared, which happened mostly unintentional,
the children were irritated and one girl even [got] a little bit angry
and started to swear."

2. http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020209.html


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

Re: [Sugar-devel] [SoaS] Where should we put our mixture of bugs, feature requests and misunderstandings as we develop curriculum

[Martin Dengler]

On Wed, Sep 30, 2009 at 08:27:46PM -0400, Caroline Meeks wrote:
> As I work with educators to create and write up curriculum we will discover
> problems.  They will be a mixture of Sugar, Activities, SoaS and confusion.
> There are a bunch of ways we could deal with it.
[...]
> 2. Everything is first posted to IAEP

Please please don't do this - IAEP gets enough SoaS/distro noise as
is.

> 3. Everyone tells me everything and I try to decide where to put it which
> has obvious problems

This is it.  If you imagine you're the deployment, you have to
communicate "upstream".  I don't think, realistically, it's scalable
for every deployment to do anything else.

> 4. Everything is put into Trac

No, then trac (Sugar) becomes a dumping ground that includes a lot of
"downstream" (SoaS, etc.) issues.


Triage suggestions (but I'm not the expert):

> For example todays issues
>
>- Record is not recording audio - probably hardware SoaS issue.

SoaS bug tracker.

>- Colors journal entries are not showing up as an image so I can't import
>it into another program like Cartoon Builder.

Activity author / mailing list.

>- Cartoon builder is cool, I want to make my own characters but it seems
>really hard in Sugar to draw a bit, save, draw a bit more, save under a new
>name, how can I do that more easily.

Activity author / mailing list.

>- I'd like to save a figure out of FlipSticks and put him into cartoon
>builder. Is there a way to save a flipstick image?

Activity author / mailing list.

> Thanks,
> Caroline

Martin


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