Re: [Sugar-devel] MIME type?

[Gary Martin]

> On 21 Jun 2016, at 19:48, Sebastian Silva  wrote:
> 
> El 21/06/16 a las 13:32, Gonzalo Odiard escribió:
> 
>> (btw, would be good have this information in a official place)
> +1 in fact the Sugar Toolkit API docs are not online. Aleksey used to
> maintain a website for them. Also, recently Tony complained that there's
> no toolkit docs.
> 
> I don't know how those were generated (epydocs?). They were not pretty
> but worked.

Sorry, it’s been a while (don’t have a machine quickly to hand to test). Can 
you not just run pydoc from the Terminal or console on an install of Sugar and 
point your web browser at it to navigate? Pretty sure I accessed all the docs 
this way for python Sugar development.

pydoc -p 8080

—Gary

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Physics-26 on Sugar 0.104 on XO-1

[Gary Martin]

Hi James,

 On 13 May 2015, at 23:13, James Cameron qu...@laptop.org wrote:
 
 On Wed, May 13, 2015 at 06:51:02AM -0400, Adam Holt wrote:
 A [...] XO-1 has issues with Physics on 13.2.4 -- I don't have
 details yet (I hope [n] can report more what happened) but has
 anybody else had recent problems with the Physics activity in
 general?
 
 OLPC OS 13.2.4 has Physics-26 on Sugar 0.104.  Physics was not in any
 previous XO-1 release.
 
 For me, it tests out fine.
 For some people, it may seem slow.
 
 On an XO-1 the CPU is pushed very hard by Physics.  This will cause:
 
 1.  every other activity to perform badly, if Physics is not stopped
 before moving to another activity; so make sure you stop Physics
 carefully,

It’s been a while since I was working on the activity code, but I did spend 
quite some time detecting and debugging when Physics was not the activity in 
current focus, and minimise its cpu usage (stops all physics calculations and 
any buffer redrawing). It does still continue to consume a little cpu (pygame 
run loop), along with perhaps memory it was using. I was certainly 
testing/developing on XO-1 as the primary use case, so if it is really making 
other activities perform badly while it is in the background then there may be 
some environment regression related to events being passed/triggered (it 
watches _focus_event and _window_event to help spot if it is in_focus).

Regards,
—Gary

 2.  sudden power down if the battery is near flat, or damaged; so make
 sure you have plugged in the laptop, and watch out for age related
 battery failures, which should have hit the XO-1 population by now,
 
 3.  massive slow down if the heat spreader has come loose; so get the
 laptop serviced and check the heat spreader is properly screwed down.
 
 See http://wiki.laptop.org/go/Reuse_checklist
 
 Comparing XO-1.5 and XO-1, the performance of Physics is consistent
 with the CPU speed and bandwidth of the graphics drivers.
 
 Learners will rapidly figure out that the flickering cursor correlates
 to too many objects on screen.  ;-)
 
 Rainbow pooing unicorns are extra.  Pay up.
 
 --
 James Cameron
 http://quozl.linux.org.au/
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Sugar for smart devices

[Gary Martin]

Hi Christian,

On 18 Sep 2014, at 10:10, Christian Stroetmann stroetm...@ontolab.com wrote:

 Aloha
 
 Maybe somebody mentioned the following solution already on an other channel.
 If not, then I would like to show two images of the activity screen as 
 examples. The Graphical User Interface (GUI) works like the home screen of a 
 well known smart device, which might be of use for adaptions of Sugar that 
 run on small devices with small screens (e.g. Sugarizer and Sugarfox).
 
 The first image [1] shows a common desktop as displayed on a laptop for 
 children or a tablet computer.
 The second image [2] shows a screen of a smartphone or a phone tablet 
 (phablet) for example.
 The GUI could also be scaled in such a way that it fits on the screen of a 
 smartwatch, on which I am working with iRaiment as well since a year or so.
 
 For sure, the icons have to be arranged in a more dense way, but these images 
 are just sketches.

Nice, I like the mockups. There have been similar layouts in the past using a 
range of patterns – the layout code was originally designed so that it was 
(fairly) easy to go in and add your own, or enable some of the other hidden 
ones. Your layout would need tweaks to the code to support variable icon sizes, 
the code currently selects a single size to layout all icons.

From a very small screen point of view, this layout only starts to make sense 
if the user can dynamically scroll around the view, bringing the wanted icon 
nearer the centre where it is scaled larger and is easier to interact with. In 
the past Sugar UI has unfortunately had to be very frugal with any animations 
due to the (low power) devices it's been designed for (and often limited 
support of hardware graphics acceleration in the open source stack).

Regards,
--Gary

 
 By the way: Who has already recognized the original GUI?
 
 
 
 Have fun in the sun
 Christian Stroetmann
 
 [1] www.ontomax.com/images/multimedia/sugar-activity-smart_devices-01.jpg
 [2] www.ontomax.com/images/multimedia/sugar-activity-smart_devices-03.jpg
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Open Street Map

[Gary Martin]

On 2 Mar 2014, at 18:00, Christian Stroetmann stroetm...@ontolab.com wrote:

 Aloha
 
 Today, I wondered if there is already an activity that is related with the 
 Open Street Map (OSM; [1]).
 I search the Wiki of Sugar Labs and the Activities, but got no results for 
 the search terms open street, openstreet and osm.
 Has anybody informations about this?
 If there is not such an activity I would like to propose such an activity as 
 well, because IMO it is definitely a most have.
 I even would like to propose it as a feature of Sugar.

The Map [1] activity supports OSM data (and others), not sure how stable it is 
under current Sugar builds as it was worked on some time ago.

[1] http://wiki.sugarlabs.org/go/Activities/Map

--Gary

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] A protototype of SugarWeb / SugarAndroid ?

[Gary Martin]

Hi Lionel,

On 13 Nov 2013, at 22:26, Lionel Laské lio...@olpc-france.org wrote:

 
 Hi Sugar lover,
  
 I must confess that like other here, recent discussions on this list don't 
 inspired me a lot :-( Governance strategy or strategy of governance of the 
 future of Sugar and SugarLabs is not my cup of tea. Worse: I'm afraid that 
 this transparency could scare some guys here and so don't serve our global 
 objective…
 My session at OLPC SF on Sugar HTML5 work convince me also that not everyone 
 put the same words on what Sugar Android, Sugar HTML5, … The same things 
 could sometimes means very different features.
  
 So all of this stimulate me to hack instead of talking !
 It's why I've decided to prototype a bit what could be (or could not be) 
 Sugar Web/Android. I've packaged all existing Sugar Web Activities (that you 
 could run of Sugar 0.100) and created a launcher that mimic the current Sugar 
 desktop. I've used also HTML5 storage to reproduce a sort of data storage. 
 Finally, Suraj is working on a way to simulate Presence using webRTC API that 
 I hope we could add it shortly to this prototype.
  
 Here is the result as a Web Site:
  
 http://olpc-france.org/tmp/sugarwebui (Chrome browser need)

Fantastic! :)

Really great to see this, and for what its worth it ran well in Safari on my 
Mac (and would be trivial to make a standalone, fullscreen Mac app that wrapped 
this in an html view if desired). I'm thinking this – at the very least – may 
be a great path forward for writing Sugar Web apps and having somewhere to 
quickly and easily test them.

Regards,
--Gary

  Or as an Android app:
  
 http://olpc-france.org/download/org.olpc-france.sugarweb.apk (To be use on a 
 tablet)
  
 An image is viewable here: 
 http://olpc-france.org/download/sugarwebui_capture.png.
 This work has no vocation to become the Sugar Web/Sugar Android, it's just 
 here to explore technically and functionally this subject: a prototype is 
 often better than lot of words ! Hope it could help the discussion on the 
 list and talks to the Malaysia base camp.
  
 Best regards from France.
  
 Lionel
  
 P.S.: Source code is available here: https://github.com/llaske/SugarWebUI
 
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4

[Gary Martin]

On 8 Nov 2013, at 14:24, Chris Leonard cjlhomeaddr...@gmail.com wrote:

 What about a virtual touch keyboard layout?  Just wondering?

FWIW: I'm pretty sure (check [1]  [2]) that Nepali layouts were not part of 
the Maliit set I was asked to work on for the XO-4 touch keyboard layouts. It's 
been over a year ago, and a lot of things were going on, so my memory is a 
little rusty.

If the XO-4's in question do have the touch screen hardware support, creating a 
layout file is not too difficult (as long as the required fonts glyphs are 
already installed). That is a beauty of touch screen keyboards, they may not be 
as good as tactile keyboards, but you can have almost any language layout you 
want with no hardware changes.

[1] http://wiki.sugarlabs.org/go/User:Garycmartin/Maliit_Layouts
[2] 
http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit#Currently_available_language_layouts

Regards,
--Gary

 On Fri, Nov 8, 2013 at 8:46 AM, Basanta Shrestha
 basanta.shres...@olenepal.org wrote:
 Hi Walter
 We don't have plans to use stickers at the moment. The stickers won't last
 long in the hands of kids. But we need to have some mechanism to input
 Nepali characters. For now we can give them a printout of the keyboard
 layout.
 Regards,
 Basanta
 
 
 
 On Fri, Nov 8, 2013 at 5:58 PM, Walter Bender walter.ben...@gmail.com
 wrote:
 
 A bit tricky because we don't have that key anymore (but we could come
 up with some other key combination to enable it). Also, are you
 planning to use stickers or some other way to add the proper glyths to
 the keyboard?
 
 Happy to explore this with you further.
 
 regards.
 
 -walter
 
 On Fri, Nov 8, 2013 at 12:23 AM, Basanta Shrestha
 basanta.shres...@olenepal.org wrote:
 Hi,
 
 I am writing this mail seeking a clue on where to start looking to
 enable
 Nepali input in XO4. For XO-1 we had nepali keyboard and there was a
 button
 just below the enter button which would switch input between English
 and
 Nepali. And that was very convenient.
 
 But for XO-4 we will just be getting ones with English layout. I was
 wondering how we can enable nepali keyboard input on it. I can see that
 the
 key maping file for nepali is already there under
 /usr/share/X11/xkb/symbols/
 
 Thank you .
 
 --
 Basanta Shrestha
 OLE Nepal
 
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 
 
 
 
 --
 Basanta Shrestha
 Network Engineer
 Open Learning Exchange (OLE) Nepal
 Tel: +977.1.551, 5520075 Ext. 303
 Cell: +977.9818 605110
 http://www.olenepal.org
 
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar 0.99.1 (unstable)

[Gary Martin]

Thanks Daniel,

That's a great feature list, looking forward to giving this all a spin!

Regards,
--Gary

On 31 Jul 2013, at 18:52, Daniel Narvaez dwnarv...@gmail.com wrote:

 Hello,
 
 this is the first feature frozen release. We landed all the features that we 
 initially planned and a few more. Thanks to everyone involved!
 
 Highlights:
 
 * Multi selection in the journal
 * Service providers selection in the modem configuration
 * Previews in the object chooser
 * Multiple home views
 * Microformat activity updater
 * Automatic activity updates
 
 Sources:
 
 http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.99.1.tar.xz
 http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.99.1.tar.xz
 http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.99.1.tar.xz
 http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.99.1.tar.xz
 http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.99.3.tar.xz
 
 -- 
 Daniel Narvaez
 ___
 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

Re: [Sugar-devel] Multi selection in the Journal feature

[Gary Martin]

On 19 Jul 2013, at 16:02, Gonzalo Odiard gonz...@laptop.org wrote:

 Thanks to all the reviews.
 New pull request is available
 
 https://github.com/sugarlabs/sugar/pull/64

Cool, I'm looking forward to giving this a try (I don't have an active dev 
build at the moment so will need to wait for it to land in an image). Great to 
see this long requested feature finally make it in! Thanks to all involved, and 
Gonzalo for getting his hands dirty with the final effort to land the feature.

Regards,
--Gary

 
 Gonzalo
 
 
 On Wed, Jul 17, 2013 at 6:42 PM, Gonzalo Odiard gonz...@laptop.org wrote:
 A initial version to review of the feature is available to test and review.
 
 The pull requests are:
 
 sugar-datastore: https://github.com/sugarlabs/sugar-datastore/pull/2
 sugar-artwork: https://github.com/sugarlabs/sugar-artwork/pull/7
 sugar: https://github.com/sugarlabs/sugar/pull/62
 
 This work is based on previous implementations, but is different in many ways.
 
 In particular, the previous implementation had a performance problem,
 when the user wanted to select all the ellements in the journal.
 As the datastore is designed to return the data paginated, 
 the journal needed to do several queries to get all the uids needed
 to create the list of selected items.
 This problem is solved adding a method to the datastore to get the uids
 belonging to a query. As the datastore get that information from the index,
 the query is really fast. 
 
 Other visible change is the use of real checkboxes in the listview, instead 
 of icons
 with a checkbox drawn. In a desktop, the checkbox is not displayed right, 
 but in the xo is ok.
 Surely something we need solve in the theme.
 
 Another difference in behavior is now the user can interrupt a operation 
 while is running.
 If you realize you started to delete all the objects in a pen drive, you can 
 stop it,
 and at least part will be saved.
 
 Gonzalo
 
 
 ___
 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

Re: [Sugar-devel] multi-homeview feature

[Gary Martin]

Hi Walter,

On 21 Jun 2013, at 13:18, Walter Bender walter.ben...@gmail.com wrote:

 I did a clean [1] up of Daniel Francis's Multi Home View feature [2]
 yesterday and in the process tried to address two issues:
 
 (1) The original code had many redundancies. The new version is
 reasonably tight (although I am certain to get push back in the review
 process).
 
 (2) There was some concern that this feature would cause confusion
 among our users (despite its being written in response to several
 requests from the field).
 
 To address #2, I made the number of home views configurable. By
 default, there is just one home view, as is currently the case. A
 gconf settting is used to add additional home views. (In gconf, I
 maintain a list of icons to use for the view toolbar and to use for
 marking favorites in the list view.) A view is generated for each icon
 in the list.
 
 I posit that this is a reasonable compromise: the default behavior
 does not change, but deployments that want to exploit this feature can
 use gconftool to set custom icons and views. (And since it is in user
 space, enterprising users can also customize the number of views.)
 
 Reactions?

Great – yes that sounds like a good compromise while still supporting requests 
from the field for this new feature.

Regards,
--Gary

 -walter
 
 [1] https://github.com/sugarlabs/sugar/pull/38
 [2] http://wiki.sugarlabs.org/go/Features/Multiple_home_views
 
 
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 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

Re: [Sugar-devel] 0.100 features update

[Gary Martin]

On 12 Jun 2013, at 21:55, Walter Bender walter.ben...@gmail.com wrote:

 On Wed, Jun 12, 2013 at 4:50 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 On 12 June 2013 22:47, Walter Bender walter.ben...@gmail.com wrote:
 
 On Wed, Jun 12, 2013 at 4:28 PM, Daniel Narvaez dwnarv...@gmail.com
 wrote:
 Hello,
 
 as we are approaching 0.99.0, I would like to update the features
 status.
 Here is a summary of what I know about the features status, I would
 appreciate if Walter and Ajay in particular could expand on it.
 
 * HTML5 based toolkit for activities
 
 Work seems to be progressing pretty smoothly here. It won't be completed
 for
 0.100 but we will do as much as possible.
 
 * Icon customization
 
 No patch submitted yet. Are we still planning to land the feature?
 
 * Integration with web services
 
 Actively developed. Seems like it will make it.
 
 * Multiple home views
 
 There seem to be no agreement on the design. Not sure how to move
 forward,
 especially since it seem a bit of a sensitive topic :)
 
 This is actually pretty important to at least one deployment. We
 should try to come to consensus here. (I am agnostic about the
 technical approach, but pretty fanatic about the pedagogical impact.)
 
 
 Maybe someone summarizes the points of agreement and disagreement and we try
 to restart from there?
 
 There was some disagreement about the implementation since I tried to
 tiptoe around the existing code to minimize changes, so there was more
 redundancy than necessary. Easy to address.
 
 There was dissatisfaction expressed about the UI design, but never any
 alternative suggestions put forward.

My concern is that we don't confuse people even more in the main Sugar UI, 
especially at the younger end of our users. Favourite/List view and 
Journal/Detail view already cause some confusion when returned to from else 
where when they are in an unexpected state. Do we have any mockups/sketches of 
what has been proposed to land?

Regards,
--Gary

 -walter
 
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 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

Re: [Sugar-devel] Web activity example that uses html5 canvas

[Gary Martin]

Hey Manuel,

On 11 May 2013, at 00:47, Manuel Quiñones ma...@laptop.org wrote:

 Oh, we should release it then.  Can you, Gary?

Yes but need to fix the 'drag hands' bugs – can't have it reading out 
occasional incorrect times to kids due to lack of precision/rounding errors ;) 
Lets see if I can make progress this weekend and make a release.

Regards,
--Gary

 2013/5/10 James Cameron qu...@laptop.org:
 On Wed, May 01, 2013 at 10:55:51AM +1000, James Cameron wrote:
 Summary: this Clock activity consumes significantly less CPU on XO-4
 and XO-1 when implemented in Javascript.
 
 Myth busted.  See new results in context below.
 
 On Tue, Apr 30, 2013 at 08:42:18PM -0300, Manuel Qui?ones wrote:
 2013/4/30 James Cameron qu...@laptop.org:
 On Tue, Apr 30, 2013 at 08:58:50AM -0300, Manuel Qui?ones wrote:
 Should work on other browsers now:
 
 http://manuq.github.io/clockjs/
 
 Agreed, works well, reasonably low CPU utilisation.  Thanks.
 
 Excellent.  Thanks for checking the CPU consumption.
 
 Here's a more detailed check.  Method is to run only the activity
 under test, and use the serial port to run the Linux top command
 configured for a 30 second sample time.
 
 --
 
 On XO-4 using 13.1.0:
 
 - using Javascript, the Browse-149 process consumes 7.5% CPU, and the
  X process 3.2% CPU.  Total of 10.7% CPU.
 
 - not using Javascript, the Clock-12 process consumes 2.7% CPU, and
  the X process 13.2% CPU.  Total of 15.9% CPU.
 
 Clock-12.5 process consumes 0.6%, and the X process 2.0%, a total of
 2.6%.
 
 --
 
 On XO-1 using 13.2.0, build 32004o0,
 
 - using Javascript, the Browse-149.2 process consumes 9.8%, the X
  process 7.4%, a total of 17.2%,
 
 - not using Javascript, the Clock-12 process consumes 10.4% and X
  process consumes 18.4%, a total of 30.8%.
 
 Clock-12.5 process consumes 1.5%, and the X process 3.6%, a total of
 5.1%.
 
 
 --
 
 On XO-1 using 11.3.0, build 883,
 
 - using Javascript, the Browse 129.1 does not render the script,
 
 - not using Javascript, the Clock-6 consumes 7.0%, and X consumed
  9.0%, a total of 16%.
 
 Test not repeated.
 
 --
 James Cameron
 http://quozl.linux.org.au/
 
 
 
 -- 
 .. manuq ..

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

Re: [Sugar-devel] [IAEP] wiki.sugarlabs.org ongoing maintenance

[Gary Martin]

On 16 Apr 2013, at 06:03, Bernie Innocenti ber...@sugarlabs.org wrote:

 Today a serious security hole was announced for MediaWiki, so I started
 a long overdue upgrade of our main wiki.

Thanks Bernie!

 Our wiki has grown quite large and the upgrade from Mediawiki 1.19 to
 1.20 required several slow steps, so unfortunately I had to leave before
 fixing up the local wikis.
 
 Meanwhile, please test login and editing and report any problems.

No problems logging back in here.

Regards,
--Gary

 Tomorrow I'll try to find some time to cleanup any remaining fallout.
 
 -- 
 Bernie Innocenti
 Sugar Labs Infrastructure Team
 http://wiki.sugarlabs.org/go/Infrastructure_Team
 ___
 IAEP -- It's An Education Project (not a laptop project!)
 i...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/iaep

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

Re: [Sugar-devel] [DESIGN] Journal Details view - Re: Sugar 0.100 status report - April 2

[Gary Martin]

On 2 Apr 2013, at 23:59, Manuel Quiñones ma...@laptop.org wrote:

 Some UI feedback for the recently added comment box:
 
 2013/4/2 Daniel Narvaez dwnarv...@gmail.com:
 5. Walter Bender landed several patches to add a comment box to journal
 entries. It will be populated both by the Portfolio activity and by the web
 services integration which is being worked on. The obligatory screenshot
 
 http://wiki.sugarlabs.org/images/4/4a/FB-comments.png
 
 Great!  I think it is better to have the header of the box like the
 others, as a label outside the box, followed by a colon.

+1

 On the same page, why not change the tags text box to a one line
 entry?  That will favour vertical space for the comments.

Also worth considering auto folding of empty fields (perhaps down to '(+) add 
Description/Tags/Comment' one liners for each empty field type?). FWIW: One of 
the GSOC projects listed [1] already proposes removing the Details view screen 
and integrating its content, inline, with the Journal so that it keeps context 
(+1 from me!).

Regards,
--Gary

[1] http://wiki.sugarlabs.org/go/Summer_of_Code/2013#Unified_journal_view

 The thing
 to consider is backwards compatibility... can we convert newlines to
 whitespaces in that case?
 
 --
 .. manuq ..
 ___
 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

Re: [Sugar-devel] We have a problem: activity._shared_activity

[Gary Martin]

Hi Gonzalo,

Thanks for the reminders :)

On 26 Feb 2013, at 19:08, Gonzalo Odiard gonz...@laptop.org wrote:

 After reading the information about Write ticket sl#4436 Making 
 collaboration work again 
 (Thanks Ajay!) I decided check what other activities use 
 activity._shared_activity,
 and this is the list:
 
 [gonzalo@localhost honey]$ grep -r \._shared_activity * --include=*.py
 
 calculate: (shareable_activity.py)

Currently GTK2, but a nearly ready GTK3 version is simmering in master, so I'll 
need to remember to test/check (Calculate has good collaboration support we 
don't want to break).

 physics: (mesh.py)

Again GTK2, but it doesn't have any collaboration feature (yet), so you're 
likely just grepping something out of the old olpcgames module that is not 
being used (there is work done to migrate to sugargame but that's on the 
back-burner just now).

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

Re: [Sugar-devel] Is it possible to hack the rotate key?

[Gary Martin]

Hi Ajay,

On 18 Feb 2013, at 11:12, Ajay Garg a...@activitycentral.com wrote:

 Hi all.
 
 Is it possible to hack the rotate key in XO?
 
 I wish to have the following working ::
 
  * Press the rotate key. This will rotate the window.
  * Just after that, have a callback function being called in sugar 
 (this of course being possible  only if the rotate key could be hacked).
 
 
 
 I will be thankful for any pointers.

This is a little out of my league, but I think you'll need to take a look at 
olpc-kbdshim [1] so see how things are currently triggered, in particular the 
olpc-rotate script. If you want to pickup aspect ration changes on the Sugar 
side, perhaps hook a gtk.gdk.screen_get_default().connect('size-changed', do 
something interesting) callback intp the sugar toolkit. I've implemented 
something simple like this in the Moon activity, so that it uses different 
layouts for landscape and portrait screen orientations [3].

Regards,
--Gary

[1] http://dev.laptop.org/git/users/pgf/olpc-kbdshim/
[2] http://dev.laptop.org/git/users/pgf/olpc-kbdshim/tree/olpc-rotate
[3] http://git.sugarlabs.org/moon/mainline/blobs/master/moon.py

 Regards,
 
 Ajay Garg
 Dextrose Developer
 Activity Central: http://activitycentral.com 
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

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

Re: [Sugar-devel] HTML activities

[Gary Martin]

Hi Daniel,

On 30 Jan 2013, at 15:14, Daniel Narvaez dwnarv...@gmail.com wrote:

 On Wednesday, 30 January 2013, Manuel Quiñones wrote:
 2013/1/29 Daniel Narvaez dwnarv...@gmail.com:
  On 28 January 2013 18:47,  lio...@olpc-france.org wrote:
 
  * Should we be using existing js frameworks like jquery in the toolkit ot
  limit ourselves to plain javascript.
 
  There is plenty of JavaScript frameworks. We should allow to use any
  framework to avoid losing a part of the JavaScript community.
  My current work is based on the Enyo framework but could be adapted easily
  to jQuery or to pure JavaScript.
 
 I hope I don't start a frameworks war..
 
 Being accustomed to Python, I really like CoffeScript.  And is not
 just syntactic sugar, go have a look at Classes and inheritance:
 
 http://coffeescript.org/#classes
 
 I think for JS Sugar and Toolkit would be nice to investigate.  As the
 website states, they try to expose the goodness of JS in a simple way.
 
 Heh, I'm so tempted now... I was noticing yesterday how painful it is to 
 write JS code when you are used to python.

Sorry for the aside to another tec, but any here played with brython much 
(browser python), it allows Python to be used as the browsers scripting 
language (basically anywhere you'd use javascript):

http://www.brython.info

Works in Browse on the XO's just fine :)

Regards,
--Gary

 Most essential coffee feature is the lack of semicolon :) But seriously it 
 could make our life easier and ease the transition from python activities to 
 HTML.
 
 
 -- 
 Daniel Narvaez
 
 ___
 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

Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK

[Gary Martin]

On 23 Jan 2013, at 15:29, Walter Bender walter.ben...@gmail.com wrote:

 On Wed, Jan 23, 2013 at 1:20 AM, Ajay Garg a...@activitycentral.com wrote:
 Hi all.
 
 I wish to fix the bug, where some activities (Chat, Terminal, Speak for
 instance) are rendered unusable in the ebook-mode, due to the OSK covering
 the area of text-input.
 I have figured out a generic working solution for this - the idea is to
 minimize the activity windows when the OSK appears, and move back to the
 normal size when the OSK disappears.
 
 I thought we had a different approach under development: to scroll the
 window up in the case of the text view being occluded by the OSK?

Yes, there are patches in GTK3 and Sugar for this, though with some issues 
still needing worked through. One activity that we managed to push hard to get 
polished was Write, it needed to be a special case as it doesn't use normal gtk 
widgets. My (rough) understanding of the implementation is that GTK first looks 
for a scrolled view and tries to scroll it so that the cursor/focus rect is 
kept in view [1], if no scrolled view is found it scrolls the canvas [2].

[1] the Write behaviour here is not ideal as the abiword widget implementation 
for the text area didn't allow for extra padding at the bottom of the view, so 
the text being edited is hard up next to the OSK rather than with some extra 
space so the text selection handles stay visible.

[2] I think there were patches in GTK3 Sugar so that the activity canvas area 
was automatically placed in a scroll view, so the toolbars are guaranteed to 
stay in view, but not sure if this landed. 

 This
 should be doable for activities that have scrolling windows, such as
 terminal and chat. Speak, which doesn't scroll could be refactored to
 put the textview on the top instead of the bottom of the screen. (I
 suspect that whatever solution we have will involve some intervention
 in some activities.)

Yes some intervention in activities will still be needed, and the first thing 
to do if you want any of this auto scrolling support is make sure your activity 
is ported to GTK3! ;) FOr activities like Speak I'd posted mockup images to a 
previous mail list thread showing how moving the text input area to the top of 
the UI would work well (the eyes will just peek over the top of the keyboard 
and the OSK can be hidden when the text is submitted for speaking).

 
 I have tested the re-sizing the windows; however, to make the fix  work
 everywhere, I was thinking of the following algorithm ::
 
 What does resizing the window do? What other activities have you tested it on?

Some activities will become quite unusable if auto shrunk, scrolling I think is 
better, we're lucky if the original developer planned for landscape and 
portrait aspect ratios...

Regards,
--Gary

 
 
 a)
 Just before/after the OSK appears, make the current window smaller.
 
 b)
 Just after/before the OSK disappears, revert the current  window to its
 original size (if not already).
 
 
 This requires a way to know when and how the appeareance/disappearance of
 the OSK is triggered.
 
 How can this be done? I am sure there must be some gobject-signal for this -
 I just can't seem to figure it  out by manually browsing the code, since I
 don't personally  have a  XO4-Touch with me :-(
 
 
 
 Regards,
 
 Ajay Garg
 Dextrose Developer
 Activity Central: http://activitycentral.com
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 regards.
 
 -walter
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

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

Re: [Sugar-devel] [PROPOSAL] Inform the user when an activity is being installed and more

[Gary Martin]

Hi folks,

On 21 Jan 2013, at 20:04, Ignacio Rodríguez nachoe...@gmail.com wrote:

 Option 1, and I am 100% agree with what you said Gonzalo.

So just to be clear on this... This means when someone downloads a new activity 
from ASLO, or some other location, you will not find it in the home screen 
favourites or list views. Only if you go to the Journal, find it, and click the 
bundle will it install and subsequently be visible elsewhere. What if you 
download a new version from ASLO, will you have to remember to open the bundle 
first in the Journal before the existing version is replaced?

Regards,
--Gary

 
 
 2013/1/21 fors...@ozonline.com.au
 I am for option 1.
 
 Tony
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 -- 
 Saludos
 Juan Ignacio Rodríguez
 CeibalJAM!
 Somos Azucar
 ___
 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

Re: [Sugar-devel] [PATCH] SDXO#2620 Add ability to save unfinished games in Memorize.

[Gary Martin]

On 12 Jan 2013, at 10:16, Hal Murray hmur...@megapathdsl.net wrote:

 
 walter.ben...@gmail.com said:
 Or may be ask the user  (while exiting), that whether the user
 wishes to save the game?
 
 Not a very Sugary approach.
 
 What is the right way for Sugar to handle that problem?

It should auto save as much state as possible so a resume is as seamless as 
possible.

 I get annoyed when I start an activity and it pops up in some strange state 
 rather than the new-game I expect.  

That is a different and long standing design issue. We were hoping to land an 
improvement for build 13.1.0, Sugar 0.98, but time was too tight with all the 
other GTK3 and touch UI work needed. The enhancement was to make start 
new/resume an explicit choice for the user when pressing an icon in the home 
view. An intermediate, full screen 
UI would open prior to the activity launch pulse icon with large thumbnails for 
either start new, some resume choices, or cancel. It would contain similar 
functionality as per the right click activity palette (that it would be 
replacing) but we have the full screen available for thumbnails, titles, a 
clear layout, and large button hit targets for novice trackpad or touch screen 
users.

Regards,
Gary

 On the other hand, if I was working on 
 something when the system shut down due to battery running low or such, 
 starting over where I left off might be a wonderful idea.
 
 I think Sugar needs either/both of:
  Exit/Discard vs Exit/Save
  Start/New vs Start/Resume
 
 
 
 -- 
 These are my opinions.  I hate spam.
 
 
 
 ___
 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

Re: [Sugar-devel] Stepping down as Sugar maintainer

[Gary Martin]

Hi Sascha,

On 6 Jan 2013, at 20:19, Sascha Silbe si...@sugarlabs.org wrote:

 Hello everyone,
 
 I am stepping down as maintainer for Sugar and some related
 services. This is mostly due to lack of time, but even if I had more of
 that to spare for Sugar, the way I work is sufficiently different from
 that of the most active contributors that I'd do more harm than good.
 
 For some time now, my business didn't have any Sugar-related contract,
 so as an entrepreneur I can't afford investing time, effort or money
 into Sugar. My spare time is pretty limited these days and I tend to
 spend what's left of it on reflecting, relaxing and some minor non-Sugar
 projects, so even as a volunteer I can't spend much on Sugar.
 
 However, I will continue using an XO as my primary laptop, so I may
 contribute to some of the lower-level parts of the stack (powerd,
 kernel, etc.) from time to time. I'll also continue working on some data
 store stuff (gdatastore, datastore-fuse, etc.), but strictly outside of
 Sugar as I wouldn't be able to hold your pace.
 
 It's been exciting times working with you and I've learned a lot. But
 now it's time to move on and let younger folks take over. That seems to
 have worked fine the past few months; hopefully it'll work out in the
 long run as well. This side of the ocean, my current customers have come
 to appreciate the way I work. And taking Sundays off for relaxing and
 reflecting, I'm much more at ease. So everyone is better off now.
 
 So long and thanks for all the fish,

Just wanted to say many thanks for all your efforts ant contributions over the 
years, and especially for your thorough and detailed patch reviews! I know I 
picked up many hints and insights reading through them along the way.

Best of success for your future projects and please do keep in contact from 
time to time!

Best Regards,
--Gary

 Sascha
 ___
 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

[Sugar-devel] [Release] Physics-11

[Gary Martin]

== Source ==

http://download.sugarlabs.org/sources/honey/Physics/Physics-11.tar.bz2

== Bundle ==

http://activities.sugarlabs.org/en-US/sugar/downloads/file/28396/physics-11.xo

== News ==

- Fix toolbar activity title input so it does not stop the physics simulation 
from running (affected pre-release 13.1.0 build) SL#4193
- Included latest text translations from pootle

Note: Physics version 11 is for Sugar 0.98 and should not be installed on 
earlier releases (and the ASLO upload has been marked as such)

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

[Sugar-devel] [Release] Clock-12

[Gary Martin]

Hi folks,

This is a release of Clock-12 to fix #4079 (broken speech) for landing in the 
13.1.0 release (thanks go to Humitos for the patch).

It's been tested on two XO-4s, and an XO-1.75 running 13.1.0 build 18, also 
tested with the long distant 802 release (Sugar 0.82.1) on an XO-1. Tested both 
English and Spanish spoken time translations.

== Source ==

http://download.sugarlabs.org/sources/honey/Clock/Clock-12.tar.bz2

== Bundle ==

http://activities.sugarlabs.org/en-US/sugar/downloads/file/28395/clock-12.xo

== News ==

- Includes latest translations from pootle
- Fix for 'Clock does not speak in pre-release 13.1.0' #4079
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Automated testing

[Gary Martin]

Hi Daniel,

On 7 Dec 2012, at 18:48, Daniel Narvaez dwnarv...@gmail.com wrote:

 Hello,
 
 I made a lot progress in the last few days on automated testing, so I
 thought I would give a quick update to the list. Hopefully this will
 also provide an higher level description of the many patches I sent.
 I'm working on a few cases which I consider paradigmatic but of course
 we will need everyone to buy into it for this to really work. After
 all, if you worked with a unit tested code base before you know it
 takes less time to write code with tests than without!
 
 Case 1. Non-UI component.
 
 http://git.sugarlabs.org/~dnarvaez/sugar-toolkit-gtk3/dnarvaez/blobs/master/tests/test_bundlebuilder.py
 
 Nothing special here. We are setting up a git repository with a sample
 activity and running all the bundlebuilder commands on it, both
 in-source and out-of-source.
 
 Case 2. UI component, functional testing.
 
 http://git.sugarlabs.org/~dnarvaez/sugar/dnarvaez/blobs/master/tests/test_activitieslist.py
 
 This is more interesting. We are using at-spi (the gtk accessibility
 framework) to get a tree of the UI. We can check if certain widgets
 exists, click on them etc. At the moment it looks like for a palette
 for the activities list palette for example
 
  [test_activitieslist.py | application]
[ | frame]
  [ | filler]
[ | filler]
  [ | filler]
[ | panel]
  [ | icon]
  [ | panel]
[ | filler]
  [mock | accelerator label]
  [ | label]
[ | filler]
  [ | separator]
  [ | filler]
[ | filler]
  [ | panel]
[ | filler]
  [ | filler]
[ | filler]
  [ | icon]
  [ | panel]
[Make favorite | label]
  [ | panel]
[ | filler]
  [ | filler]
[ | filler]
  [ | icon]
  [ | panel]
[Erase | label]
  [ | panel]
[ | filler]
  [ | filler]
[ | filler]
  [ | icon]
  [ | panel]
[Start new | label]
  [ | filler]
 
 
 Case 3. UI component, visual testing.
 
 No code to share here yet. The idea is to take a screenshot of the UI
 and compare with it at testing time. It should be pretty easy to
 update it when styles and sizes changes. I never experimented with it
 yet, so I will have to play and see if it really works. I'm probably
 going to use one of the sugar3.graphics widget to start with.
 
 Case 4. Full UI, functional testing.
 
 http://git.sugarlabs.org/sugar-build/sugar-build/blobs/master/tests/sugar/tree.py
 
 In sugar-build we are starting all the activities from the activities
 list view and the close them. Timing is tricky but I think we can make
 it work reliably. Of course we will need to write more and more
 complex tests.
 
 Case 5. Full UI, visual testing.
 
 I have not thought too much about this. I think a combination of
 at-spi and screenshots could work. But I hear humitos is doing some
 research on it :)
 
 I will keep the list updated as I make progress on this.

Thanks for all the effort on this! It really looks like your work is pulling 
together as a great test suite for us folk working further up the stack at the 
Activity end of development. :)

Regards,
--Gary

 
 -- 
 Daniel Narvaez
 ___
 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

Re: [Sugar-devel] (no subject)

[Gary Martin]

Hi Ariel,

On 4 Dec 2012, at 16:02, Ariel Calzada ar...@activitycentral.com wrote:

 Hello!
 
 We’re working in the GTK3 porting and HIG adjustments of Speak and other 
 activities we have observations in both fields.
 
 HIG/Touchscreen
 
 The main concern is that the OSK hides the interface and doesn’t let the 
 textbox be visible for the user. We think that a possible solution should be 
 making OSK has an inputbox above that which displays the inserted text, and 
 thus the speak interface should be shrinked. But this has to be analyzed 
 because should be fixed upstream. As this is transversal to all the 
 activities that could have input text.

So a quick and simple solution that I think will work well in this case, is to 
just move the text input area from the bottom to the top of the canvas area. 
See images [1] and [2] for mockups of what this could look like, both with and 
without the on screen keyboard (OSK). One thing to make sure, is that the input 
text are be un-focused when the user presses return and the speaking starts, 
this will make the OSK hide so that the user can watch the mouth moving. I do 
quite like that the eyes are peeking over the top of the keyboard when the OSK 
is open, so I don't think we need to shrink down the whole face.

Regards,
--Gary

[1] http://wiki.sugarlabs.org/go/File:Mockup_of_Speak_text_input_at_top.png
[2] 
http://wiki.sugarlabs.org/go/File:Mockup_of_Speak_text_input_at_top_with_OSK.png

 GTK3
 
 We have been working in a GTK3 porting of Speak which basically implies usage 
 of Gstreamer 1.0
 
 We already have a release version of this porting but it  has many issues. 
 One of them is that the activity runs very very slow and the eyes don’t move 
 correctly when the mouse is moved. So we have to analyse code performance in 
 light of gstreamer and cairo. 
 
 We would like to get some ideas of what’s happening and if gstreamer 1.0 is 
 failing in XO with other activities.
 
 Regards,
 
 -- 
 Ariel Calzada and Rafael Ortíz
 Activity Central: http://www.activitycentral.com
 
 Facebook: https://activitycentral.com/facebook
 Google+: https://activitycentral.com/googleplus
 Twitter: https://activitycentral.com/twitter
 ___
 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

Re: [Sugar-devel] About speak and other activities GTK3/HIG

[Gary Martin]

On 4 Dec 2012, at 16:07, Walter Bender walter.ben...@gmail.com wrote:

 On Tue, Dec 4, 2012 at 11:03 AM, Ariel Calzada ariel.calz...@gmail.com 
 wrote:
 Hello!
 
 We’re working in the GTK3 porting and HIG adjustments of Speak and other
 activities we have observations in both fields.
 
 Thanks for working on this.
 
 
 HIG/Touchscreen
 
 The main concern is that the OSK hides the interface and doesn’t let the
 textbox be visible for the user. We think that a possible solution should be
 making OSK has an inputbox above that which displays the inserted text, and
 thus the speak interface should be shrinked. But this has to be analyzed
 because should be fixed upstream. As this is transversal to all the
 activities that could have input text.
 
 I thought the plan of record was (at the Sugar toolkit level) to have
 the activity window scroll up. It would be good to come up with a
 general solution in any case.

Yes good point, if/when it is ported to GTK3 it should automatically inherit 
this auto scrolling behaviour as seen in the newer builds (working but still 
needs some tuning).

 GTK3
 
 We have been working in a GTK3 porting of Speak which basically implies
 usage of Gstreamer 1.0
 
 We already have a release version of this porting but it  has many issues.
 One of them is that the activity runs very very slow and the eyes don’t move
 correctly when the mouse is moved. So we have to analyse code performance in
 light of gstreamer and cairo.

Not sure which rep your working from, but make sure all the eye drawing code is 
correctly drawing in radians, _not_ degrees, for Cairo (easy mistake to make):

http://bugs.sugarlabs.org/ticket/3901

Regards,
--Gary

 Hmm. I've been playing with GST 1 in Turtle and haven't notice a
 performance hit.
 
 
 We would like to get some ideas of what’s happening and if gstreamer 1.0 is
 failing in XO with other activities.
 
 Regards,
 
 --
 La Salvaje Esperanza
 
 Éramos dioses y nos volvieron esclavos.
 Éramos hijos del sol y nos consolaron
 con medallas de lata.
 Éramos poetas y nos pusieron a recitar
 oraciones pordioseras.
 Éramos felices y nos civilizaron.
 Quién refrescará la memoria de la tribu.
 Quién revivirá nuestros dioses.
 Que la salvaje esperanza siempre sea tuya, querida alma inamansable.
 
 -Gonzalo Arango-
 
 
 
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 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

Re: [Sugar-devel] FR: Feature for a.sl.o: global filter by Sugar version

[Gary Martin]

HiBastien,On 26 Nov 2012, at 07:32, Bastien b...@laptop.org wrote:Alan Jhonn Aguiar Schwyn alan...@hotmail.com writes:supposedly.. when you navigate from Browse Activity, the searchs onASLO returns the latest for your sugar version..Good if it is really so. Can someone confirm?Yes, http://activities.sugarlabs.org (ASLO) picks up the browser client string from Browse that varies from Sugar release to Sugar release, and shows the latest Activity versions for that release of Sugar. It does assume some steps are correctly taken when a developer uploads a new version, they have to set which Sugar versions their activity is compatible with, or an editor/reviewer needs to be on the ball with re-testing the activity later. ASLO is also not just for longterm Sugar developers to distribute activities, but also to allow other third party developers to share their work as well, so the quality/robustness of activity code/design can vary.The area we most often get caught out in Sugar is that we don't have good architecture variation support – XO hardware was x86 based (XO-1 XO 1.5) and more recent models are now ARM based (XO-1.75, XO-4), if an activity developer decides to include binary code/libraries within an activity, it is down to them to make sure they include support for differentarchitectures. This is why we try and encourage developers to develop Python activities, built for the agreed Sugar platform dependancies, as this avoids hardware architecture issues.Then maybe the compatibility info for each activity is often wrong.If you have found one, please do let me know the activity name, version, the version of Sugar you tested, and what hardware type you were trying to get it to run on and I'll take a look and update the compatibility flags.If you are downloading from a browser/device other than the Browse running on the XO you finally want to install the activity on, you can use the 'Advanced' search button on the main ASLO:Regards,--GaryDoes any other users have problems with compatibility?--  Bastien___Sugar-devel mailing listSugar-devel@lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] FR: Feature for a.sl.o: global filter by Sugar version

[Gary Martin]

Hi Bastien,

On 26 Nov 2012, at 14:58, Bastien b...@laptop.org wrote:

 Hi Gary,
 
 thanks for your answer.
 
 Gary Martin garycmar...@googlemail.com writes:
 
 Yes, http://activities.sugarlabs.org (ASLO) picks up the browser
 client string from Browse that varies from Sugar release to Sugar
 release, and shows the latest Activity versions for that release of
 Sugar.  It does assume some steps are correctly taken when a
 developer uploads a new version, they have to set which Sugar
 versions their activity is compatible with, or an editor/reviewer
 needs to be on the ball with re-testing the activity later. ASLO is
 also not just for longterm Sugar developers to distribute activities,
 but also to allow other third party developers to share their work as
 well, so the quality/robustness of activity code/design can vary.
 
 Yes.
 
 The area we most often get caught out in Sugar is that we don't have
 good architecture variation support – XO hardware was x86 based (XO-1
 XO 1.5) and more recent models are now ARM based (XO-1.75, XO-4), if
 an activity developer decides to include binary code/libraries within
 an activity, it is down to them to make sure they include support for
 different architectures. This is why we try and encourage developers
 to develop Python activities, built for the agreed Sugar platform
 dependancies, as this avoids hardware architecture issues.
 
 Yes.  This is a bit of a problem.  For example, I encouraged the Kiwix
 developer to make Kiwix available for Sugar, which they did, and I now
 have to ask them to port it to the ARM architecture (as they had too few
 feedback on Kiwix, I doubt porting Kiwix on ARM is a high priority task.)
 
 If you have found one, please do let me know the activity name,
 version, the version of Sugar you tested, and what hardware type you
 were trying to get it to run on and I'll take a look and update the
 compatibility flags.
 
 Using VirtualBox and Sugar on a Stick (Fedora-17-i686-Live-SoaS.iso),
 the Sugar File Manager does not launch.

Aha, OK. So my first guess would be that the SOAS image is probably missing 
some dependency shipped in an OLPC build (or in a deployments customised build) 
that this activity depends on. I've not used this particular activity before (I 
try to use Sugar with the tools we ship by default so have a better idea what 
our users have access to), but if you wanted to help debug a little further (it 
might be something _really_ simple), start the Log activity and look in the log 
file called:

org.ceibaljam.SugarFileManager

Send me or copy/paste the log file if you wanted me to have a quick look.

Regards,
--Gary

 
 If you are downloading from a browser/device other than the Browse
 running on the XO you finally want to install the activity on, you
 can use the 'Advanced' search button on the main ASLO:
 
 [cid] 
 
 Very useful, thanks!
 
 -- 
 Bastien

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

Re: [Sugar-devel] Renaming the Telescope activity to Scope

[Gary Martin]

Hi Jv,

On 23 Nov 2012, at 11:57, RJV jv.ravichand...@gmail.com wrote:

 Hi,
 
 This looks like a great activity to me. I am unable to find what kind of 
 telescopes (in India) can be used and help to this effect on the downloads 
 page as a Readme would be very helpful.
 
 Has anybody used a physical telescope with this activity and what type? 
 Thanks for any response.

Have a look at the learning resources pdf at:

http://wiki.sugarlabs.org/go/Activities/Moon#Learning_Resources

This covers research into a low cost monocular project that Telescope activity 
was originally aimed at. For Moon observing I have had fair success using a 
Brunton 10-30x21 monocular. It can be carefully held against the XO bezel over 
the camera, but that's quite hard work to keep everything still and pointed at 
the correct location ;) The above project uses a mounting bracket that attaches 
the monocular firmly to the XO so it is easier to aim. For imaging planets (e.g 
Jupiter/Saturn with moons) that monocular does not quite get enough light into 
the camera to show the moons, though I do have a light polluted sky here so you 
might manage better.

You might also like this shot Sameer Verma tweeted recently:

https://twitter.com/sameerverma/status/271428793476980736/photo/1

Regards,
--Gary

P.S. I have a collection of Moon test images I should really go upload to the 
wiki soon...

 Jv
 
 
 On Tue, Nov 20, 2012 at 12:08 PM, Simon Schampijer si...@schampijer.de 
 wrote:
 
 
 Am 20.11.2012 um 06:23 schrieb Martin Langhoff martin.langh...@gmail.com:
 
  On Mon, Nov 19, 2012 at 11:58 PM, Chris Leonard
  cjlhomeaddr...@gmail.com wrote:
  As I recall, this activity was already renamed once from xoscope after
  it became clear it was colliding in name space with an oscilloscpe
  activity.
 
  Renames are a pain in infrastructure, and in upgrade handling for users.
 
  I would say prefer to retain the current name until there's an
  overwhelming case for change.
 
 
 Agreed. A rename should be well thought through. If you do it, agreed with 
 what Chris said, please use a cerb.
 
 Thanks,
Simon
 
 
  cheers,
 
 
 
  m
  --
  martin.langh...@gmail.com
  mar...@laptop.org -- Software Architect - OLPC
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
  ___
  Devel mailing list
  de...@lists.laptop.org
  http://lists.laptop.org/listinfo/devel
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel
 
 
 
 -- 
 Regards,
 
 Ravichandran Jv
 http://ravichandranjv.blogspot.com
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

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

[Sugar-devel] [Release] Moon-16

[Gary Martin]

== Source ==

http://download.sugarlabs.org/sources/honey/Moon/Moon-16.tar.bz2

== Bundle ==

http://activities.sugarlabs.org/en-US/sugar/downloads/file/28334/moon-16.xo

== News ==

- Release including latest available translations
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Release] Clock-11

[Gary Martin]

== Source ==

http://download.sugarlabs.org/sources/honey/Clock/Clock-11.tar.bz2

== Bundle ==

http://activities.sugarlabs.org/en-US/sugar/downloads/file/28335/clock-11.xo

== News ==

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

Re: [Sugar-devel] Maliit 0.93.0 OSK language layout cycle key testing

[Gary Martin]

Hi Simon,

On 30 Oct 2012, at 12:00, Simon (erikos) Schampijer si...@laptop.org wrote:

 Excellent work everyone!!!
 
 On 10/30/2012 04:36 AM, Gary C Martin wrote:
 Hi Peter,
 
 I wasn't having much luck with yum upgrade seeing the arm versions on the XOs
 here for testing yet, but I managed to find your arm build tonight at [1], 
 and
 installed the below rpms on an XO-4 for some quick testing of the new 
 language
 layout cycle key support:
 
 maliit-framework-0.93.0-1.fc18.armv7hl.rpm
 maliit-framework-gtk2-0.93.0-1.fc18.armv7hl.rpm
 maliit-framework-gtk3-0.93.0-1.fc18.armv7hl.rpm
 maliit-plugins-0.93.0-1.fc18.armv7hl.rpm
 
 Wanted to quickly confirm that all is working well :) The language layout key
 icon is rendering correctly on the keyboard (world map icon [3]); that the 
 key
 is cycling through the enabled layouts on each press; and once it reaches the
 last enabled layout it loops back to the first layout.
 
 I can also confirm that the extended key fix [2] is correctly included.
 
 I am considering one small design change on these layouts, to swap the 
 language
 layout key with the ?123 key to the left, so that the language key is in the 
 far
 left keyboard corner. This will keep its position stable as you cycle through
 different keyboard layouts allowing you can tap in the same location without
 needing to visually check it might have shifted a little (the ?123 size can 
 vary
 on some layouts due to additional keys).
 
 I will re-test the OSK tomorrow on an XO-1.75 for checking portrait 
 orientation
 layouts (XO-4s don't yet have gfx support for screen rotation).
 
 Many (!) thanks must go to Michael (mikhas) for his Sunday maliit coding, 
 patch,
 and release, this was almost a lost feature for the 13.1.0 target!!
 
 Daniel: If possible we should try to enable two, perhaps three layouts in the
 next test build so the feature can be more widely used/demoed/tested – 
 keeping
 in mind there is no existing way to hide this key if only one layout is 
 enabled
 (the key has no effect if only one language layout is enabled).
 
 Gary, the easiest for testing is to edit 
 /home/olpc/.config/maliit.org/server.conf

Yes thanks for the reminder that this is the easiest place to tweak. I was 
previously using the maliit settings python example to enable all the layout's 
I've been working with.

 Here is an example I did you try as working fine: 
 http://dev.laptop.org/attachment/ticket/12166/server.conf
 
 But maybe having by default (en, es, fr might be a good bet or going with 
 more fancy ones to show off) is a good idea.

en_us, es and fr sound like fair candidates to enable to get the ball rolling 
:) It would also place enough config in ~/.config/maliit.org/server.conf so 
folks can more easily enable more layouts if needed.

Regards,
--Gary

 Cheers,
   Simon

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

Re: [Sugar-devel] Bridge activity

[Gary Martin]

Hi Alan,

Just a quick update.

On 20 Oct 2012, at 10:24, Alan Jhonn Aguiar Schwyn alan...@hotmail.com wrote:

 Hi Gary,
 
 Yesterday, I see that Bridge activity appears in ASLO as Experimental.
 I clone: http://git.sugarlabs.org/bridge
 and check it, and found some things to fix.
 I attach a patch that makes a few changes to the activity backs to live :-)
 Only the important changes, for example: olpcgames - sugargame
 
 I test it, and works good!

Many thanks, yes the olpcgame - sugargame port looked good and has landed in 
mainline along with your other cleanup items. I've also now updated Bridge to 
use a more recent version of Box2d and elements (similar to Physics), and some 
other fixes so that it will now run on ARM (or other architectures) devices to 
support XO-1.75 and XO-4 hardware. I have a few more hardware tests to make and 
I want to add a toolbar icon for at least the 'start/pause' feature, so that 
Bridge will also be usable with a touch screen device. Hopefully I'll get a new 
release out later tomorrow, but the version in git [1] should be working as it 
just now if you wanted to have a quick test/check of the commits.

Regards,
--Gary

[1] http://git.sugarlabs.org/bridge/mainline/commits/master

 Regards!
 
 Alan
 0001-some-changes-to-back-to-life.patch

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

Re: [Sugar-devel] Bridge activity

[Gary Martin]

On 21 Oct 2012, at 17:26, Chris Leonard cjlhomeaddr...@gmail.com wrote:

 On Sat, Oct 20, 2012 at 5:16 PM, Alan Jhonn Aguiar Schwyn
 alan...@hotmail.com wrote:
 The activity haves the strings with i18n...
 
 The ticket:
 
 http://bugs.sugarlabs.org/ticket/4072
 
 
 Thanks Alan.
 
 Gary, please give gituser: pootle commit on the repo , everything else
 is all set up for L10n.

Done,  ticket closed.

--G

 cjl

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

Re: [Sugar-devel] Purpose for Help Activity

[Gary Martin]

Hi Tony,

On 16 Oct 2012, at 14:34, Tony Anderson tony_ander...@usa.net wrote:

 Hi,
 
 What is the purpose of help? In Windows, help is a method to find out how to 
 accomplish a particular task using an application. It is not a means to learn 
 how to use the computer or Windows.
 
 The Help activity is a specialized reader for the Floss (pdf) manuals.
 Unfortunately, the text in the Floss manuals was written for experienced 
 computer users who were new to the XO and the Sugar.
 
 I believe we need a Sugar activity to introduce the XO and Sugar to those who 
 have no prior computing experience. Further, we need to use the 'learn to 
 learn' approach we advocate for the XO, i.e. these materials should be 
 designed for experimentation (trial and error) and collaborative learning. 
 The beauty of the computer is that it provides instant feedback on whether 
 you did something 'right' or not.

Yes an initial version of this landed in the last release cycle, it was the 
Welcome Activity. It's just really a basic slideshow, that has a simple folder 
structure that is intended to be customised by deployments to add their own 
material. It's success will be down to what quality of content it contains. 
Currently it just supports images, not animations or sound, though that was a 
future 'like to have' on the feature list. The activity also used by a matching 
first boot behaviour that displays that same content on first boot before the 
user is asked to type their name or choose a colour. The current default 
content is almost all visual/cartoony, no text reading expected (though there 
are some screenshots of the UI as part of the cartoons), one issue is that if 
it dose need to be locale customised, good image content does not seem to be 
easy for many to create, and can make the activity larger than otherwise ideal.

Gonzalo: Is it worth uploading the Welcome activity to ASLO (I just looked and 
couldn't find it), or will this cause some issues for deployments (e.g. a user 
'upgrading' at ASLO might wipe local generated content)? Though it would 
provide all existing users/deployments the chance to see the content (and 
suggest/provide improvements)

Regards,
--Gary

 I also believe that use of screenshots, screencasts and icons can reduce the 
 dependency of these materials on text. Another underutilized tool is audio. 
 If the text instructions were spoken, any deployment would be able to provide 
 the same instructions in the native language (the skill needed would be a 
 speaker of the native language who also knows English). Incidentally, in 
 deployments where English is a medium of instruction, using both versions can 
 help children learn English.
 
 Tony
 
 
 
 
 
  Message: 3
  Date: Tue, 16 Oct 2012 09:05:08 -0300
  From: Gonzalo Odiard gonz...@laptop.org
  To: S. Daniel Francis fran...@sugarlabs.org
  Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org
  Subject: Re: [Sugar-devel] Purpose for Help Activity
  Message-ID:
  caj+ipvrgke8qenkjc3dqv8dufybjczesdtg8qvrxv8hzfqv...@mail.gmail.com
  Content-Type: text/plain; charset=iso-8859-1
 
  Help issues are known and we need solve it,
  but I don't agree with the proposed solution.
 
  The style can be changed with css, that is not a problem.
 
  The biggest problem we have today, is found people to write the help.
  If we impose to a potential writer the work of learn docbook,
  will be worst. And writing a docbook editor is not a trivial task.
 
  About having help content inside the activities,
  probably is a good idea. We need think about:
  * how enable the translation of that content (and how much disk space
  will use if we have all the translations inside the activity)
  * where put the content related to sugar (not activities)
 
  Gonzalo
 
  On Mon, Oct 15, 2012 at 10:03 PM, S. Daniel Francis
  fran...@sugarlabs.orgwrote:
 
  Hi,
 
  Looking at the Help activity, I see the following issues:
  - It looks very orange. A more integrated style is needed.
  - Activities should be documented independently of the help activity.
 
  (Not very related with my purpose but important for deploy a solution)
  - The documentation needs to be updated and Gonzalo told me about
  there were efforts to update it. ?Where are them?
 
  Now I purpose some solutions:
  - Using docbook.
  Docbook is used by the GNOME documentation team and can be styled
  easily with CSS.
  - Save the documentation in each activity.
  With that way, Help could scan each activity for documentation, that
  documentation could depend of the installed version of each activity.
  And documentation for non-core activities could be seen from the Help
  activity.
 
  Knowing that the Help isn't up to date, I only migrated the first
  chapter for give you a preview of my purpose.
 
  A screenshot:
  http://wiki.sugarlabs.org/go/File:Help-docbook-purpose.png
 
  On the git repository:
  http://git.sugarlabs.org/~danielf/help/help-docbook
 
  For generate the HTML files I used the 

Re: [Sugar-devel] Purpose for Help Activity

[Gary Martin]

Hi Tony,

On 16 Oct 2012, at 15:47, Tony Anderson tony_ander...@usa.net wrote:

 Hi,
 
 The ShowNTell activity provides both slide show and sound capability. The 
 slides are images at present.

Hmmm, seems like some amount of overlapping activity effort and target use 
cases going on. You might like to also take a quick look at Portfolio [1] 
(already part of the default OLPC builds), and Bulletin Board [2] (more aimed 
at documenting the work group projects, and has some support for audio 
recording and playback). Though I think the Welcome activity still has somewhat 
separate goals from ShowNTell/Portfolio/Bulletin Board (e.g. first time user 
introduction to Sugar and XO).

 Slide shows based on screenshots are easy to create.

FWIW: Most screenshots are a pain for translation/localisation (UI text), it 
pretty much ties down any content generated to one locale.

Regards,
--Gary

[1] http://activities.sugarlabs.org/en-US/sugar/addon/4437
[2] http://activities.sugarlabs.org/en-US/sugar/addon/4588

 I am trying to port it to use webkit so the slides can be html. This is a 
 problem at present because use of webkit now requires a port to gtk3.
 
 Tony
 
 On 10/16/2012 10:22 AM, Gary Martin wrote:
 Hi Tony,
 
 On 16 Oct 2012, at 14:34, Tony Anderson tony_ander...@usa.net wrote:
 
 Hi,
 
 What is the purpose of help? In Windows, help is a method to find out how 
 to accomplish a particular task using an application. It is not a means to 
 learn how to use the computer or Windows.
 
 The Help activity is a specialized reader for the Floss (pdf) manuals.
 Unfortunately, the text in the Floss manuals was written for experienced 
 computer users who were new to the XO and the Sugar.
 
 I believe we need a Sugar activity to introduce the XO and Sugar to those 
 who have no prior computing experience. Further, we need to use the 'learn 
 to learn' approach we advocate for the XO, i.e. these materials should be 
 designed for experimentation (trial and error) and collaborative learning. 
 The beauty of the computer is that it provides instant feedback on whether 
 you did something 'right' or not.
 
 Yes an initial version of this landed in the last release cycle, it was the 
 Welcome Activity. It's just really a basic slideshow, that has a simple 
 folder structure that is intended to be customised by deployments to add 
 their own material. It's success will be down to what quality of content it 
 contains. Currently it just supports images, not animations or sound, though 
 that was a future 'like to have' on the feature list. The activity also used 
 by a matching first boot behaviour that displays that same content on first 
 boot before the user is asked to type their name or choose a colour. The 
 current default content is almost all visual/cartoony, no text reading 
 expected (though there are some screenshots of the UI as part of the 
 cartoons), one issue is that if it dose need to be locale customised, good 
 image content does not seem to be easy for many to create, and can make the 
 activity larger than otherwise ideal.
 
 Gonzalo: Is it worth uploading the Welcome activity to ASLO (I just looked 
 and couldn't find it), or will this cause some issues for deployments (e.g. 
 a user 'upgrading' at ASLO might wipe local generated content)? Though it 
 would provide all existing users/deployments the chance to see the content 
 (and suggest/provide improvements)
 
 Regards,
 --Gary
 
 I also believe that use of screenshots, screencasts and icons can reduce 
 the dependency of these materials on text. Another underutilized tool is 
 audio. If the text instructions were spoken, any deployment would be able 
 to provide the same instructions in the native language (the skill needed 
 would be a speaker of the native language who also knows English). 
 Incidentally, in deployments where English is a medium of instruction, 
 using both versions can help children learn English.
 
 Tony
 
 
 
 
 
 Message: 3
 Date: Tue, 16 Oct 2012 09:05:08 -0300
 From: Gonzalo Odiard gonz...@laptop.org
 To: S. Daniel Francis fran...@sugarlabs.org
 Cc: Sugar-dev Devel sugar-devel@lists.sugarlabs.org
 Subject: Re: [Sugar-devel] Purpose for Help Activity
 Message-ID:
caj+ipvrgke8qenkjc3dqv8dufybjczesdtg8qvrxv8hzfqv...@mail.gmail.com
 Content-Type: text/plain; charset=iso-8859-1
 
 Help issues are known and we need solve it,
 but I don't agree with the proposed solution.
 
 The style can be changed with css, that is not a problem.
 
 The biggest problem we have today, is found people to write the help.
 If we impose to a potential writer the work of learn docbook,
 will be worst. And writing a docbook editor is not a trivial task.
 
 About having help content inside the activities,
 probably is a good idea. We need think about:
 * how enable the translation of that content (and how much disk space
 will use if we have all the translations inside the activity)
 * where put the content related to sugar (not activities

Re: [Sugar-devel] NPR story on OLPC in Peru

[Gary Martin]

On 13 Oct 2012, at 20:10, Alexandro Colorado j...@oooes.org wrote:

 On 10/13/12, Chris Leonard cjlhomeaddr...@gmail.com wrote:
 2012/10/13 Alexandro Colorado j...@oooes.org:
 
 
 Los trabajos que venimos realizando en forma coordinada entre SugarLabs
 +
 SomosAzucar + Ministerio de educación es en brindar una plataforma capaz
 de
 mantener a la comunidad educativa CONECTADA, con o sin internet, y esto
 por
 que nuestra realidad así lo requiere.
 
 Is there any 'intermediary projects' or setups that allow people to
 keep connected? Giving 2 minute thought, I would think that a RAID
 SERVER on the school could provide a school with the lastest
 information sources like wikipedia, mailing list archieves, ebooks,
 ezines, website pull downs, and other required service that people
 could order to be delivered at the school. Then switch the info
 harddisk from the general system harddisk.
 
 Yes, you should read up on Sugar Network which is part of the
 SomosAxucar effort Hernan references.
 
 http://wiki.sugarlabs.org/go/Sugar_Network
 
 You should also know that off-line Wikipedia versions are available in
 a variety of languages (English, Spanish, French, Polish, Quechua,
 more easily created).
 
 cjl
 
 
 Ah Links, thanks.

http://activities.sugarlabs.org/en-US/sugar/search?q=wikipediacat=1%2C104

Regards,
--Gary

 -- 
 Alexandro Colorado
 PPMC Apache OpenOffice
 http://es.openoffice.org
 ___
 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

Re: [Sugar-devel] [ASLO] Release Terminal-41

[Gary Martin]

Hey Guys,

Thanks for the new release, very happy to have the great Tabs now in Terminal!! 
:)

Could you make sure and push the source code changes back up to the main git 
repository (git.sugarlabs.org)? I've just been looking there to see what 
changed between v40 and v41 as Terminal-41 is failing [1] on XO-4 hardware, 
though it works fine on the XO-1.75 and I'm trying to diagnose the problem. The 
previous Terminal-40 release works fine on the XO-4 – so I'm currently trying 
to dig my way through the .xo bundles to see what changed ;)

Regards,
--Gary

[1] http://bugs.sugarlabs.org/ticket/4020

On 10 Oct 2012, at 03:13, Rafael Ortiz raf...@activitycentral.com wrote:

 
 
 On Tue, Oct 9, 2012 at 6:45 PM, Agustin Zubiaga Sanchez a...@sugarlabs.org 
 wrote:
 Yes Rafa, thanks for releasing it...
 
 El 09/10/2012 20:03, S. Daniel Francis fran...@sugarlabs.org escribió:
 2012/10/9 Rafael Ortiz raf...@activitycentral.com:
  Release notes:
 
  * Initial GTK3 release (Port by S. Daniel Francis
  fran...@sugarlabs.org,Agustin Zubiaga Sanchez a...@sugarlabs.org).
  * Adding summary, Rafael Ortiz raf...@activitycentral.com
  * Testing by Flavio Danesse fdane...@activitycentral.com
 * Same tabs as Browse. (Also fill all the allowed space correctly.)
 
 Thanks for releasing it, Rafael.
 
 Thanks to you guys-.
 
 
  
 ___
 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

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

Re: [Sugar-devel] [RELEASE] Clock-10

[Gary Martin]

Hi Gonzalo,

On 5 Oct 2012, at 13:27, Gonzalo Odiard gonz...@laptop.org wrote:

 Beautiful!
 Any chance to have the code to move the hands landed?

Hey give me a chance! ;) That was next on my Clock todo list, but from memory I 
think that patch needed a little more work/testing before it can land.

Regards,
--G

 Gonzalo 
 
 On Fri, Oct 5, 2012 at 4:57 AM, Gary C Martin garycmar...@googlemail.com 
 wrote:
 == Bundle ==
 
 http://activities.sugarlabs.org/en-US/sugar/downloads/file/28260/clock-10.xo
 
 == Source ==
 
 http://download.sugarlabs.org/sources/honey/Clock/Clock-10.tar.bz2
 
 == News ==
 
 * Includes latest translations from the translation team
 * Updated graphics rendering to use Cairo for improved drawing quality 
 (thanks go to Manuq)
 * Improvements to the simple clock face design
 * Nice Clock rendering optimisations (thanks go to Gonzalo)
 ___
 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

Re: [Sugar-devel] [PATCH] Sort the activities in the home in alphabetic order

[Gary Martin]

On 4 Oct 2012, at 16:48, Manuel Quiñones ma...@laptop.org wrote:

 2012/10/4 Gonzalo Odiard godi...@sugarlabs.org:
 
 
 On Thu, Oct 4, 2012 at 12:00 PM, Martin Langhoff martin.langh...@gmail.com
 wrote:
 
 On Thu, Oct 4, 2012 at 10:33 AM, Gonzalo Odiard godi...@sugarlabs.org
 wrote:
 We are sorting by localized name.
 It's true than the order will be different if you use a different
 language,
 but we think is better for the users.
 
 Less consistency in icon location better? How?
 
 
 You have less consistency only if you change the language.
 99.9% of our users will not do it,
 and will prefer have a consistent order = alphabetic.
 
 Navegar is after Medir, does not have sense have it sorted as Browse
 
 Have sense use the same order in the listview and in the favorites view too.
 
 In internal discussions with Gary and Simon I gave +1 for alphabetic
 ordering in list view, and -1 for favs view.  My cons were: 1.
 inconsistency between languages for first boot layout, 2. icons
 displacement while switching language 3. I like how new added
 activities appear right at the top of the buddy icon head.  I think
 alpha ordering have no sense in only-icons views.

I'm still +1 for localised alphabetical ordering.

Installation date ordering (e.g. modification date of Activity) is rather 
arbitrary and unstable, you have no idea where anything will be, and they keep 
changing over time. Alphabetical sorting on the localised names provides a 
stable, understandable sort order for both list and favourite views (unless you 
are frequently switching between locales, a minority edge case). For newly 
added activities, they will first appear as grey stroke icons, so unless you've 
not been not using your favourite Activities, the new one should be reasonably 
obvious, and we have a nice search feature if you have a large number installed.

Regarding screenshots for documentation (mentioned by Martin), I would argue 
this is a relatively minor case, less than the previous date sort case where 
documentation screen shots, over time, have icons in seemingly arbitrary 
positions as the documentation authors update to different activity versions. 
Martin, could you clarify this example a little more, did you have some 
specific documentation task in mind?

Regards,
--Gary

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

Re: [Sugar-devel] [DESIGN] List View of Activities (hovering stars)

[Gary Martin]

Hi Manuel,

On 29 Sep 2012, at 19:37, Manuel Kaufmann humi...@gmail.com wrote:

 Hello,
 
 I've just realize that there is no feedback on clicking on the star in
 the List View to make it Favorite.

Yes we have a ticket for this, there has been additional discussion in the mail 
list and irc that should be added to this ticket:

   http://bugs.sugarlabs.org/ticket/3147

I think my last suggestion was that we should be using the round grey rectangle 
outline to show hover, press visual feedback (as we do in the Home view for 
Activity icons, though this is currently broken after the GTK3 shell port and 
theming), this sounds like a similar fix as to the UI you linked to in 
wikipedia.

Regards,
--Gary

 
 1. Go to Home View
 2. Click on List View
 3. Hover one the star of one no-favorite Activity
 4. The star gets colorized
 5. Click on it
 6. Did I click?
 
 Maybe we can use a 0.5 alpha star when the user is hovering the star
 of a no-favorite Activity to highlight it but showing that it's not
 activated and 1.0 after a click.
 
 Wikipedia on its rating feature uses a circle to show what star you
 are hovering. Here is an example at the bottom of the page:
 
 * http://es.wikipedia.org/wiki/New_X-Men
 
 What do you think?
 
 -- 
 Kaufmann Manuel
 Blog: http://humitos.wordpress.com/
 Porfolio: http://fotos.mkaufmann.com.ar/
 PyAr: http://www.python.com.ar/
 ___
 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

Re: [Sugar-devel] [DESIGN] List View of Activities (hovering stars)

[Gary Martin]

Hi Manuel,

On 29 Sep 2012, at 20:02, Manuel Kaufmann humi...@gmail.com wrote:

 On Sat, Sep 29, 2012 at 3:52 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 I think my last suggestion was that we should be using the round grey 
 rectangle outline to show hover, press visual feedback (as we do in the Home 
 view for Activity icons, though this is currently broken after the GTK3 
 shell port and theming), this sounds like a similar fix as to the UI you 
 linked to in wikipedia.
 
 So, we will have 4 states:
 
 1. Pressed and un hovered: colorized star without grey rectangle
 2. Pressed and hovered: colorized star with grey rectangle
 3. Unpressed and un hovered: uncolorized star without grey rectangle
 4. Unpressed and hovered: uncolorized star withtout grey rectangle
 So, if I click on the star in the 4) state I will get 2) immediately, right?

Let me reword this, I think 'pressed' has two possible meanings (enabled and 
button down):

  hovering || button down: show grey rectangle outline
  button down  enabled (colorized star): immediately change to disabled 
(uncolorized star)
  button down  disabled (uncolorized star): immediately change to enabled 
(colorized star)

So if the star is currently enabled (colorized) and you hover over it, you'll 
first see the grey rounded rectangle outline, then if you click/press it you 
will still see the grey rectangle outline and the star will change immediately 
to disabled (uncolorized star), as you release and move the mouse away the grey 
rounded rectangle outline will disappear.

If the star is currently disabled (uncolorized) and you hover over it, you'll 
first see the grey rounded rectangle outline, then if you click/press it you 
will still see the grey rectangle outline and the star will change immediately 
to enabled (colorized star), as you release and move the mouse away the grey 
rounded rectangle outline will disappear.

--Gary

 I like this way.
 
 -- 
 Kaufmann Manuel
 Blog: http://humitos.wordpress.com/
 Porfolio: http://fotos.mkaufmann.com.ar/
 PyAr: http://www.python.com.ar/

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

Re: [Sugar-devel] [PATCH Browse] Display only the URL in the URL entry SL #3553

[Gary Martin]

Hi Martin,

On 27 Sep 2012, at 15:35, Martin Langhoff martin.langh...@gmail.com wrote:

 If there is concensus that it's better, then it's ok. It was one of
 those things where I liked Browse more than Chrome, but perhaps it's a
 personal quirk.

I don't think I'd explicitly noted the +/- reasons, just tried to make a quick 
call on the patch/ticket to move things along. So...

Some '+' for the change:

+ editing URLs via touch. Using a mouse cursor, the title reverts to a URL on 
hover, so you can more easily know where to click to make an edit [1]
+ exposing URLs for touch users. The cursor hover is the only way to expose 
URLs when browsing (unless tap to editing them)
+ why show the same text twice on the screen (in tab and in the URL location 
entry), URL plus Title would make better use of the available space
+ seems to be a standard in other Browsers (Chrome, Safari, Firefox, Explorer9) 
– probably partly a choice for some security reasons

Some '-' against:

- removes some visual re-enforcement of which tab you may currently be looking 
at (the Tab and location input area won't have the identical text)
- less elegant to see, and less comprehensible. The case that makes me a little 
uncomfortable is the default, first thing you see OLPC Library case, 
file:///home/olpc/.library_pages/index.html.
- exposes some 'inner workings' of the web, dns, file structure – this one 
could also be in the '+' section ;)
- a change in behaviour

I'm still a +1, just wish the change was more designer 'pretty' ;)

Regards,
--Gary

[1] The touch editing case could be mitigated by having a touch focus initially 
select the whole URL rather than placing the insertion point as what will at 
that point be an arbitrary location.

 m
 
 On Thu, Sep 27, 2012 at 10:33 AM, Gonzalo Odiard gonz...@laptop.org wrote:
 This change was discussed with Manuq and Gary.
 I can't find the discussion now.
 CC both
 
 Gonzalo
 
 On Thu, Sep 27, 2012 at 11:25 AM, Martin Langhoff
 martin.langh...@gmail.com wrote:
 
 Is this really an improvement in behaviour?
 
 - The tabs are often too small to show the title.
 - The title is more important for the user than the URL. No?
 
 cheers,
 
 
 m
 
 On Mon, Sep 24, 2012 at 5:09 PM, Manuel Kaufmann humi...@gmail.com
 wrote:
 The Title of the current page is no longer shown in the URL
 entry. Now, it's only shown in the tab and the current URL is visible
 all the time in the URL entry.
 
 Signed-off-by: Manuel Kaufmann humi...@gmail.com
 ---
 browser.py| 13 +
 webtoolbar.py | 53
 +
 2 files changed, 18 insertions(+), 48 deletions(-)
 
 diff --git a/browser.py b/browser.py
 index de546f2..1c67beb 100644
 --- a/browser.py
 +++ b/browser.py
 @@ -453,6 +453,10 @@ class Browser(WebKit.WebView):
 # Scale text and graphics:
 self.set_full_content_zoom(True)
 
 +# This property is used to set the title immediatly the user
 +# presses Enter on the URL Entry
 +self._loading_uri = None
 +
 # Reference to the global history and callbacks to handle it:
 self._global_history = globalhistory.get_global_history()
 self.connect('notify::load-status',
 self.__load_status_changed_cb)
 @@ -542,6 +546,15 @@ class Browser(WebKit.WebView):
 def open_new_tab(self, url):
 self.emit('new-tab', url)
 
 +def _set_loading_uri(self, uri):
 +self._loading_uri = uri
 +
 +def _get_loading_uri(self):
 +return self._loading_uri
 +
 +loading_uri = GObject.property(type=str, setter=_set_loading_uri,
 +   getter=_get_loading_uri)
 +
 def __run_file_chooser(self, browser, request):
 picker = FilePicker(self)
 chosen = picker.run()
 diff --git a/webtoolbar.py b/webtoolbar.py
 index 28bc015..1d531bc 100644
 --- a/webtoolbar.py
 +++ b/webtoolbar.py
 @@ -47,7 +47,6 @@ class WebEntry(iconentry.IconEntry):
 GObject.GObject.__init__(self)
 
 self._address = None
 -self._title = None
 self._search_view = self._search_create_view()
 
 self._search_window = Gtk.Window(type=Gtk.WindowType.POPUP)
 @@ -57,8 +56,6 @@ class WebEntry(iconentry.IconEntry):
 self.connect('focus-in-event', self.__focus_in_event_cb)
 self.connect('populate-popup', self.__populate_popup_cb)
 self.connect('key-press-event', self.__key_press_event_cb)
 -self.connect('enter-notify-event',
 self.__enter_notify_event_cb)
 -self.connect('leave-notify-event',
 self.__leave_notify_event_cb)
 self._focus_out_hid = self.connect(
 'focus-out-event', self.__focus_out_event_cb)
 self._change_hid = self.connect('changed', self.__changed_cb)
 @@ -79,18 +76,11 @@ class WebEntry(iconentry.IconEntry):
 
 def _set_address(self, address):
 self._address = address
 -if address is not None and self.props.has_focus:
 +if address is not 

Re: [Sugar-devel] Performace in os3

[Gary Martin]

Hi Manuel,

On 27 Sep 2012, at 15:40, Manuel Kaufmann humi...@gmail.com wrote:

 Hello,
 
 I'm working on my 1.75 XO with os3 and I feel it really slow. There
 are some examples:

Yes, does feel a little slower here generally (especially any Activities ported 
to Cairo just now). Performance work/polish where time permits is need.

 - Hover in Favourite and List view
 
 1. Hover in Favourite view
 2. Move the mouse directly to List view and hover it
 3. It shows the palette after the timeout but the palette square
 appears first and then the text
 
 (test this many times because sometimes does not happen)

Can't trigger this one just yet (I will key an eye out for it).

 - Show and Hide the frame
 
 1. Go to the edge of the screen
 2. The frame appears
 3. Go again to the edge of the screen (to make the frame hides) --
 comment: this works different than before, it was no needed to go
 again to the edge of the screen to make it disappears.

Yes this is a feature change, landed by Simon at least a build or two ago. I 
can dig up the discussion thread for you if you need but it's about interaction 
with multiple ways to open the Frame, the old behaviour you had to use either 
_just_ the keyboard frame button, or _just_ the mouse in the corner. Now that 
it is a toggle you can raise the Frame with the keyboard and then use the mouse 
cursor to hide it when you are done. Also helps the situation for folks with 
jumpy mouse trackpads or poor motor control as you do not have to keep the 
cursor inside the frame area while you try to click on something. This also is 
needed so that current Frame interaction methods (keyboard and corners) will 
work well with the new touch Frame interactions (touch swipe gestures, and a 
top left corner hot spot touch/click for raising  hiding the Frame).

 4. The frame disappears but it leaves the same frame (width and hight)
 in gray color for a while

Yes, there is a SL ticket open about this, pretty sure there is some regression 
work to fix after the gtk3 port effort.

 Besides, I noticed that when you hover on Home Icons they are no
 longer highlighted as it was gtk2 version of Sugar. Is this a desired
 behaviour?

Yes, it's GTK3 theme related I think, Manuq was going to take a look.

FWIW: I'm using an XO-1.75 for all my end of the maliit OSK and touch selection 
handle work, and the speed of interaction with these has not been causing 
problems me. It's more the graphic redraw and blanking glitches (as things pop 
up and close again) that has a negative impact on user experience. I'm sure 
enabling compositing in the WM would help perceived performance, but at the 
cost of memory usage (less Activities open at once, perhaps more memory related 
issues), and actual performance.

Regards,
--Gary

 See you,
 
 
 -- 
 Kaufmann Manuel
 Blog: http://humitos.wordpress.com/
 Porfolio: http://fotos.mkaufmann.com.ar/
 PyAr: http://www.python.com.ar/
 ___
 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

Re: [Sugar-devel] [PATCH shell] Views: defocus the search entry by default

[Gary Martin]

Hi Simon,

On 26 Sep 2012, at 08:40, Simon Schampijer si...@schampijer.de wrote:

 From: Simon Schampijer si...@laptop.org
 
 This patch does implement the following behavior:
 
 - the search entry in all the views (Home (Favorites and Activity list),
  Group and Neighborhood) is unfocused by default
 
 - the search entry can be focused by clicking in the entry or by
  starting to type
 
 - the search entry contains a hint when unfocused and no search has been
  entered, the hint is dependent on the View you are in and matches the
  labels in the View Palettes (Frame), the existing translations have
  been reused
 
 - the learner can defocus the entry by clicking outside somewhere in
  the view (toolbar or canvas), if no search has been entered the hint
  will be displayed again if there is a search entered it will remain
  in effect and the entry will only be unfocused, the latter will help
  to hide the OSK and see the matches for a particular search
 
 - clicking on the clear icon in the entry ('x') the entry will be
  unfocused again

Tested there here on an XO (with OSK and without) and it's working very nicely. 
Thanks for the patch! :)

For the others reviewing this, there are a couple more behaviours on the radar 
as part of this search focus treatment, but their omission here should not 
block getting this patch landed as it's already a really good improvement (and 
especially for OSK user interaction):

 - the enter/return key (to defocus and leave query intact)
 - the escape key (clear query and defocus)

Regards,
--Gary

 Signed-off-by: Simon Schampijer si...@laptop.org
 ---
 src/jarabe/desktop/activitieslist.py |  4 
 src/jarabe/desktop/favoritesview.py  |  4 
 src/jarabe/desktop/groupbox.py   |  6 +-
 src/jarabe/desktop/homebox.py| 15 +++
 src/jarabe/desktop/homewindow.py | 23 +++
 src/jarabe/desktop/meshbox.py|  5 +
 src/jarabe/desktop/viewcontainer.py  |  1 +
 src/jarabe/desktop/viewtoolbar.py|  6 +-
 8 files changed, 58 insertions(+), 6 deletions(-)
 
 diff --git a/src/jarabe/desktop/activitieslist.py 
 b/src/jarabe/desktop/activitieslist.py
 index b830526..1b5ddd7 100644
 --- a/src/jarabe/desktop/activitieslist.py
 +++ b/src/jarabe/desktop/activitieslist.py
 @@ -375,6 +375,10 @@ class ActivitiesList(Gtk.VBox):
 self._alert = None
 self._clear_message_box = None
 
 +def grab_focus(self):
 +# overwrite grab focus in order to grab focus from the parent
 +self._tree_view.grab_focus()
 +
 def set_filter(self, query):
 matches = self._tree_view.set_filter(query)
 if matches == 0:
 diff --git a/src/jarabe/desktop/favoritesview.py 
 b/src/jarabe/desktop/favoritesview.py
 index b73d016..26a89e6 100644
 --- a/src/jarabe/desktop/favoritesview.py
 +++ b/src/jarabe/desktop/favoritesview.py
 @@ -85,6 +85,10 @@ class FavoritesBox(Gtk.VBox):
 def set_resume_mode(self, resume_mode):
 self._view.set_resume_mode(resume_mode)
 
 +def grab_focus(self):
 +# overwrite grab focus in order to grab focus from the parent
 +self._view.grab_focus()
 +
 def add_alert(self, alert):
 if self._alert is not None:
 self.remove_alert()
 diff --git a/src/jarabe/desktop/groupbox.py b/src/jarabe/desktop/groupbox.py
 index 3d7c0f3..f916f62 100644
 --- a/src/jarabe/desktop/groupbox.py
 +++ b/src/jarabe/desktop/groupbox.py
 @@ -41,7 +41,8 @@ class GroupBox(ViewContainer):
 
 self._query = ''
 toolbar.connect('query-changed', self._toolbar_query_changed_cb)
 -
 +toolbar.search_entry.connect('icon-press',
 + self.__clear_icon_pressed_cb)
 self._friends = {}
 
 friends_model = friends.get_model()
 @@ -72,3 +73,6 @@ class GroupBox(ViewContainer):
 for icon in self.get_children():
 if hasattr(icon, 'set_filter'):
 icon.set_filter(self._query)
 +
 +def __clear_icon_pressed_cb(self, entry, icon_pos, event):
 +self.grab_focus()
 diff --git a/src/jarabe/desktop/homebox.py b/src/jarabe/desktop/homebox.py
 index 8eda213..ed5144b 100644
 --- a/src/jarabe/desktop/homebox.py
 +++ b/src/jarabe/desktop/homebox.py
 @@ -45,6 +45,8 @@ class HomeBox(Gtk.VBox):
 
 toolbar.connect('query-changed', self.__toolbar_query_changed_cb)
 toolbar.connect('view-changed', self.__toolbar_view_changed_cb)
 +toolbar.search_entry.connect('icon-press',
 + self.__clear_icon_pressed_cb)
 self._list_view.connect('clear-clicked',
 self.__activitylist_clear_clicked_cb, toolbar)
 
 @@ -108,6 +110,17 @@ class HomeBox(Gtk.VBox):
 def __activitylist_clear_clicked_cb(self, widget, toolbar):
 toolbar.clear_query()
 
 +def __clear_icon_pressed_cb(self, entry, icon_pos, event):
 +self.grab_focus()
 +
 +def grab_focus(self):
 +# 

Re: [Sugar-devel] [DESIGN] Chage in filter in home view

[Gary Martin]

Hi Gonzalo,

On 26 Sep 2012, at 14:55, Gonzalo Odiard gonz...@laptop.org wrote:

 The Search in the home, used to search activities, 
 in the favorites or in the list view, is cleaned after one activity starts 
 and is closed.
 Is a recent change, and is very annoying, why is the reason behind this 
 change? 
 Should I fill a ticket or is a design decision?

We did discuss it in the mailing list here [1], and then was re confirmed by 
Manuq after the OLPC-A team meeting in the separate mail thread (between us and 
Martin) where we were checking off tasks (should be in you inbox dated 
September 14th, Subject: Design meeting).

There were three choices if I remember:

 1) make the search query 'sticky' between views so that a search would be 
active from one view to the next
 2) make each view's search query cache a copy of the search (this is the 
behaviour we had before)
 3) start with a clear search query when you expose/switch views (this is the 
change that just landed)

Behaviour (1) was rejected, as a search query doesn't often make sense in all 
views (searching for an AP or Buddy in Neighbourhood is not much use when you 
switch to the Home Favourites view). Option (2) has given us some mischief when 
users enter a query (on-purpose, accidentally, or unknowingly) and later return 
to a view and wonder why icons are greyed out, or even missing in the case of 
the Home list view. Option (3) seemed to provide the more consistent behaviour 
for users later returning to a view after having left it in a search query.

Can you describe how it is annoying, what were you trying to do with search, 
was it a complicated search string you needed to preserve, or a result state 
you particularly wanted to keep? UI freeze is not for another couple of weeks, 
reports/feedback on feature chenges is most wanted! :)

Regards,
--Gary

[1] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039342.html

 
 Gonzalo

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

Re: [Sugar-devel] [DESIGN] Chage in filter in home view

[Gary Martin]

Hey Daniel,

On 26 Sep 2012, at 18:50, S. Daniel Francis fran...@sugarlabs.org wrote:

 2012/9/26 Gary Martin garycmar...@googlemail.com:
 Behaviour (1) was rejected, as a search query doesn't often make sense in
 all views (searching for an AP or Buddy in Neighbourhood is not much use
 when you switch to the Home Favourites view).
 
 And when you open an activity and return to the home view?

So yes, the new behaviour would clear the search when you returned later.

 Developing and testing, when I use the home list view and use the
 filter to find my activity, I have to write the activity name all the
 times I need to run it...

Yes that is a fair use case, especially if you have lots of activities 
installed, and I do wish we had more active developers like you! :) Can I ask, 
do you spend more time working in Sugar's home list view, or the home favourite 
view? Would making your test activity a Favourite be a practical option? Again, 
this depends how many Activities you already have favourited ;)

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

Re: [Sugar-devel] Programming language

[Gary Martin]

Hi Tony,

On 24 Sep 2012, at 15:33, Tony Anderson tony_ander...@usa.net wrote:

 Hi,
 
 An important concept is 'language of instruction'. For example, in Nepal the 
 language of instruction is Nepali; however, there are many native languages 
 other than Nepali.
 
 In Haiti, the language of instruction is French. This is different than 
 requiring a course in French. All of the textbooks are written in French.
 
 In Rwanda, until last year, the language of instruction was English. Now, it 
 is Kinyarwanda until grade 4, and then English.
 
 The implication is that we could concentrate on supporting the language of 
 instruction in the deployments: English, Spanish, and French. We should also 
 help deployments with support for initial literacy in the student's mother 
 tongue.
 
 One concern is that Sugar becomes more text-based with every release. Open 
 Browse for example. Use of icons was a very practical way to help students 
 learn to use the computer regardless of their mother tongue.

Sugar becoming more text-based? Could you be a little more specific as to where 
in Sugar and Activities you're seeing this?

From a design point of view I try very hard to keep with, and extend the icon 
focused Sugar designs e.g. the switch away from Activity toolbar tabs allowed 
us to make Activities much more icon driven. Just the other day I was working 
with humitos to provide him with a mockup for a simpler, more friendly page 
load error message (less text and a visual).

Regards,
--Gary

[1] 
http://bugs.sugarlabs.org/attachment/ticket/3500/Browse_unable_to_load_page.png

 yours,
 
 Tony
 
 On 09/24/2012 04:35 AM, sugar-devel-requ...@lists.sugarlabs.org wrote:
 Send Sugar-devel mailing list submissions to
  sugar-devel@lists.sugarlabs.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
  http://lists.sugarlabs.org/listinfo/sugar-devel
 or, via email, send a message with subject or body 'help' to
  sugar-devel-requ...@lists.sugarlabs.org
 
 You can reach the person managing the list at
  sugar-devel-ow...@lists.sugarlabs.org
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Sugar-devel digest...
 
 
 Today's Topics:
 
1. Re: [IAEP] Sugar Digest 2012-09-18 (Kevin Mark)
2. Re: [IAEP] Sugar Digest 2012-09-18 (Kevin Mark)
3. Re: [IAEP] Sugar Digest 2012-09-18 (James Cameron)
4. Re: [IAEP] Sugar Digest 2012-09-18 (Alan Jhonn Aguiar Schwyn)
5. Re: [IAEP] Sugar Digest 2012-09-18 (Kevin Mark)
6. Re: [IAEP] Sugar Digest 2012-09-18 (Hal Murray)
 
 
 --
 
 Message: 1
 Date: Sun, 23 Sep 2012 22:17:25 -0700 (PDT)
 From: Kevin Markkevin.m...@verizon.net
 To: Flavio Danessefdane...@gmail.com
 Cc: sugar-devel@lists.sugarlabs.org, James Cameronqu...@laptop.org,
  S. Daniel Francisfran...@sugarlabs.org
 Subject: Re: [Sugar-devel] [IAEP] Sugar Digest 2012-09-18
 Message-ID:
  1348463845.49692.yahoomailclas...@web84509.mail.ne1.yahoo.com
 Content-Type: text/plain; charset=iso-8859-1
 
 Hola Flavio, I think you gave many?excellent? reasons for using Spanish, 
 which is what i was saying. So I agree. I was recalling something about the 
 OLPC project in Haiti. ?They have 2 'officlal' languages: Kreyol and French. 
 99% of the country learns Kreyol but the upper class/government know French. 
 So the kids learn French for some reason in their early years along with 
 Kreyol and I was confused by this. Why learn something that they will use 
 very little and confuse learning while trying to learn it in a little used 
 language, French. That may not be 100% correct, so any correction welcome. 
 So I understand the idea of having kids try to learn Python and English at 
 the same time as being difficult and not always useful.-K
 -- next part --
 An HTML attachment was scrubbed...
 URL:http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120923/e9887e05/attachment-0001.html
 
 --
 
 Message: 2
 Date: Sun, 23 Sep 2012 22:24:25 -0700 (PDT)
 From: Kevin Markkevin.m...@verizon.net
 To: Flavio Danessefdane...@gmail.com, Gonzalo Odiard
  gonz...@laptop.org
 Cc: sugar-devel@lists.sugarlabs.org, James Cameronqu...@laptop.org,
  S. Daniel Francisfran...@sugarlabs.org
 Subject: Re: [Sugar-devel] [IAEP] Sugar Digest 2012-09-18
 Message-ID:
  1348464265.12572.yahoomailclas...@web84510.mail.ne1.yahoo.com
 Content-Type: text/plain; charset=iso-8859-1
 
 
 
 --- On Mon, 9/24/12, Gonzalo Odiardgonz...@laptop.org  wrote:
 
 From: Gonzalo Odiardgonz...@laptop.org
 Subject: Re: [Sugar-devel] [IAEP] Sugar Digest 2012-09-18
 To: Flavio Danessefdane...@gmail.com
 Cc: Kevin Markkevin.m...@verizon.net, sugar-devel@lists.sugarlabs.org, 
 James Cameronqu...@laptop.org, S. Daniel Francisfran...@sugarlabs.org
 Date: Monday, September 24, 2012, 1:08 AM
 
 Flavio,Estoy de acuerdo que para ense?ar programaci?n, agregar la 
 

Re: [Sugar-devel] [sugar] Show summary information in the activities list view

[Gary Martin]

Hi Simon,

Here's my original mockup for the summary text spacing/layout, should give a 
fair idea for the column proportions and white space between:

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

Regards,
--Gary

On 20 Sep 2012, at 09:01, Simon Schampijer si...@schampijer.de wrote:

 Thanks Gonzalo for your patch!
 
 Gary, Manuel, how should we best represent this visually? Attached is a 
 screenshot of the Activity listview after Gonzalo's changes.
 
 Regards,
   Simon
 
 
 On 09/19/2012 11:47 PM, godi...@sugarlabs.org wrote:
 From: Gonzalo Odiard godi...@gmail.com
 
 Signed-off-by: Gonzalo Odiard gonz...@laptop.org
 ---
  src/jarabe/desktop/activitieslist.py | 27 ---
  1 file changed, 12 insertions(+), 15 deletions(-)
 
 diff --git a/src/jarabe/desktop/activitieslist.py 
 b/src/jarabe/desktop/activitieslist.py
 index fc05594..58e285c 100644
 --- a/src/jarabe/desktop/activitieslist.py
 +++ b/src/jarabe/desktop/activitieslist.py
 @@ -25,7 +25,6 @@ from gi.repository import GConf
  from gi.repository import Gtk
  from gi.repository import Gdk
 
 -from sugar3 import util
  from sugar3.graphics import style
  from sugar3.graphics.icon import Icon, CellRendererIcon
  from sugar3.graphics.xocolor import XoColor
 @@ -77,12 +76,9 @@ class ActivitiesTreeView(Gtk.TreeView):
  self.append_column(column)
 
  cell_text = Gtk.CellRendererText()
 -cell_text.props.ellipsize = Pango.EllipsizeMode.MIDDLE
 -cell_text.props.ellipsize_set = True
 
  column = Gtk.TreeViewColumn()
  column.props.sizing = Gtk.TreeViewColumnSizing.GROW_ONLY
 -column.props.expand = True
  column.set_sort_column_id(ListModel.COLUMN_TITLE)
  column.pack_start(cell_text, True)
  column.add_attribute(cell_text, 'markup', ListModel.COLUMN_TITLE)
 @@ -96,24 +92,26 @@ class ActivitiesTreeView(Gtk.TreeView):
  column.props.sizing = Gtk.TreeViewColumnSizing.GROW_ONLY
  column.props.resizable = True
  column.props.reorderable = True
 -column.props.expand = True
  column.set_sort_column_id(ListModel.COLUMN_VERSION)
  column.pack_start(cell_text, True)
  column.add_attribute(cell_text, 'text', 
 ListModel.COLUMN_VERSION_TEXT)
  self.append_column(column)
 
  cell_text = Gtk.CellRendererText()
 -cell_text.props.xalign = 1
 +cell_text.props.xalign = 0
 +cell_text.props.wrap_width = int(Gdk.Screen.width() / 3)
 +cell_text.props.wrap_mode = Pango.WrapMode.WORD
 
  column = Gtk.TreeViewColumn()
 -column.set_alignment(1)
  column.props.sizing = Gtk.TreeViewColumnSizing.GROW_ONLY
  column.props.resizable = True
  column.props.reorderable = True
  column.props.expand = True
 -column.set_sort_column_id(ListModel.COLUMN_DATE)
 +column.props.max_width = int(Gdk.Screen.width() / 3)
 +column.props.spacing = 5
 +column.set_sort_column_id(ListModel.COLUMN_SUMMARY)
  column.pack_start(cell_text, True)
 -column.add_attribute(cell_text, 'text', ListModel.COLUMN_DATE_TEXT)
 +column.add_attribute(cell_text, 'text', ListModel.COLUMN_SUMMARY)
  self.append_column(column)
 
  self.set_search_column(ListModel.COLUMN_TITLE)
 @@ -164,11 +162,10 @@ class ListModel(Gtk.TreeModelSort):
  COLUMN_TITLE = 3
  COLUMN_VERSION = 4
  COLUMN_VERSION_TEXT = 5
 -COLUMN_DATE = 6
 -COLUMN_DATE_TEXT = 7
 +COLUMN_SUMMARY = 6
 
  def __init__(self):
 -self._model = Gtk.ListStore(str, bool, str, str, str, str, int, str)
 +self._model = Gtk.ListStore(str, bool, str, str, str, str, str)
  self._model_filter = self._model.filter_new()
  Gtk.TreeModelSort.__init__(self, model=self._model_filter)
 
 @@ -208,7 +205,6 @@ class ListModel(Gtk.TreeModelSort):
  if activity_info.get_bundle_id() == 'org.laptop.JournalActivity':
  return
 
 -timestamp = activity_info.get_installation_time()
  version = activity_info.get_activity_version()
 
  registry = bundleregistry.get_registry()
 @@ -224,14 +220,15 @@ class ListModel(Gtk.TreeModelSort):
  'span style=italic weight=light%s/span' % \
  (activity_info.get_name(), tags)
 
 +summary = activity_info.get_summary()
 +
  self._model.append([activity_info.get_bundle_id(),
  favorite,
  activity_info.get_icon(),
  title,
  version,
  _('Version %s') % version,
 -int(timestamp),
 -util.timestamp_to_elapsed_string(timestamp)])
 +summary])
 
  def set_visible_func(self, func):
  self._model_filter.set_visible_func(func)
 

Re: [Sugar-devel] [DESIGN] Messages to Browse when checking free space

[Gary Martin]

On 17 Sep 2012, at 22:14, Walter Bender walter.ben...@gmail.com wrote:

 On Mon, Sep 17, 2012 at 4:57 PM, Gonzalo Odiard gonz...@laptop.org wrote:
 If Browse check before start to download the space available [1]
 and there are not enough space to do a safe download,
 what should be a good message to show to the user?
 
 May be:
 Can't download the file X 
 
 Not specific enough
 
 You need NN MB, delete files in the Journal and try again
 
 Maybe too specific?
 
 How about:
 
 Not enough space available to download  (file size: NN MB; free
 space: NN MB).

How about:

Title: Not enough space to download
Text: Download X requires XX MB of free space, only XX MB is available

Regards,
--Gary

 -walter
 
 
 Gonzalo
 
 [1] http://bugs.sugarlabs.org/ticket/394
 
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 
 -- 
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org

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

Re: [Sugar-devel] Issues i have found in os2

[Gary Martin]

On 14 Sep 2012, at 17:45, Gonzalo Odiard gonz...@laptop.org wrote:

 First, congrats by the port, is a huge mass of work.
 
 I know is early, but I report here a few issues I have found, just if is 
 useful to you:
 
 * Palettes in speak and speech don't show.
 * Palette in central kid icon in the home does not show at times.

It (and others) work the first time, but not subsequently, UNLESS you raise a 
different palette, or close the palette by moving the mouse cursor into and 
then out of the open palette (so looks like it's not releasing/closing a 
palette correctly when interacting with touch).

 * In the control panel,  Power, Keyboard, Network and Software Update panel 
 does not work.

Yep, for now I'm using sudo touch /var/run/powerd-inhibit-suspend/1 to make 
sure my remote ssh sessions into my test XO-1.75 don't get dropped every 15 
seconds.

 * In the control panel,  Language,Switch Desktop panel reset sugar!

Aaaahhh! So that's why Sugar sugar crashed and restarted one me, I though I was 
just hogging too much memory with my yum install. :)

--Gary

 * In the control panel,  Modem panel is bigger than expected
 * The home is unresponsive at times, in the log there are many errors: 
 favoritesview.py line 210: Expected Gtk.TargetList, but got list
 
 Touch stop working in my system at times, and I need restart the XO,
 was happening with the last images, anybody else see this issue?
 
 Gonzalo
 ___
 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

Re: [Sugar-devel] [FEATURE] [DESIGN] Display Device

[Gary Martin]

Hi Simon,

Just going through my sketches and raising a few older threads:

On 21 Aug 2012, at 13:44, Simon Schampijer si...@schampijer.de wrote:

 Hi Gary,
 
 thanks for having a look!
 
 On 08/21/2012 02:34 PM, Gary Martin wrote:
 Hi Simon,
 
 On 21 Aug 2012, at 12:18, Simon Schampijer si...@schampijer.de wrote:
 
 Hi,
 
 this Feature Display Device [1] has been proposed for 0.96 inclusion 
 already but did not make it in due to time constraints. With touch the need 
 to expose the 'take-screenshot' and 'adjust-brightness' options in the UI 
 gets more prominent, that is why I want to propose this again for 0.98.
 
 The part for the screenshot taking was already done, that part of the patch 
 just needs to be re-based.
 
 I'm not happy the design is ready yet for inclusion, some quick comments:
 
  - Use of the camera icon (especially in the device frame) suggests it 
 involves camera hardware.
 
 The icon is a placeholder. It should be an icon for the display.

Have a look at [1] for some variations on the theme.

 
  - Is taking a screenshot really a feature that should be in the device 
 section of the frame?
 
 See below. I am happy to hear about other suggestions. At the moment I have 
 no other one :/ Previous discussions did not bring something up neither [1].

So... two possible suggestions:

A) I might be able to trigger a screen shot from a maliit extended key, I'm 
thinking a long press of the 1 key could raise an extended palette (as used 
by accents) and include a 'take screen shot' trigger key (it would just send a 
regular key event up the chain to be caught further up). The current the screen 
shot mechanism already hides the OSK so this could work pretty much as the 
physical keyboard alt-1 does, taking a screenshot of whatever you had on screen 
minus the OSK. OT: This could also be a route to use for some other shortcuts 
where we have limited space to expose UI buttons (e.g. long press of space 
could have a view source cog option). The one hurdle is that maliit visible key 
labels == the character they trigger (except for special key actions that need 
hard coded into maliit, aka the language switch key that we need added at some 
point).

B) The current screen shot feature is already something you need to be shown or 
read about in the documentation i.e. not discoverable without external help, so 
we would not be regressing if we made the touch screen shot trigger something 
equally hidden like a long-press of the Display device icon... this is also 
quite similar to how Android have it in their UI (and better than iOS that have 
no visible UI for it at all, there you have to press the physical home and off 
buttons simultaneously).

  - The device frame is filling up fast and furious in this cycle, we already 
 need to add an icon for raising the OSK, and an icon for controlling the 
 hardware display brightness/monochrome mode.
  - The palette shown in the screen shot is named Display.
 
 The Palette should contain as well the options for the brightness. At least 
 that is what we discussed at one point. The Palette would be named something 
 like 'Display', have an option for brightness and one for taking a screenshot.

Brightness is certainly the primary Display device feature needing a visible UI 
(especially for touch input). I've made some mockup/sketches around how the 
icon and palette could look as per the discussion so far [1], [2], [3], [4].

Regards,
--Gary

[1] http://wiki.sugarlabs.org/go/File:Display_device_icons.jpg
[2] http://wiki.sugarlabs.org/go/File:Display_device_location.png
[3] http://wiki.sugarlabs.org/go/File:Candidate_Display_icon.jpg
[4] http://wiki.sugarlabs.org/go/File:Mockup_Display_device_palette.jpg

 Regards,
   Simon
 
 [1] http://lists.sugarlabs.org/archive/sugar-devel/2011-November/034372.html

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

Re: [Sugar-devel] [DESIGN] set zoom to initial value in Browse

[Gary Martin]

Hi Manuel,

On 10 Sep 2012, at 12:35, Manuel Quiñones ma...@laptop.org wrote:

 Hello,
 
 any comments, concerns about this enhacement contributed by humitos?
 
 http://bugs.sugarlabs.org/ticket/3540
 
 Is the wording for the tooltip Zoom equal ok?

Actual size is perhaps the more common name for this, some alternatives are 
Zoom 100%, Zoom reset, Normal size, Original size.

Regards,
--Gary

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

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Gary Martin]

Hi Martin,

On 4 Sep 2012, at 03:05, Martin Abente martin.abente.lah...@gmail.com wrote:

 @gonzalo: Regarding gtk2-gtk3, no problem, I wil do it ASAP.
 
 @gonzalo  bert: I would go for the simpler solution. But is really important 
 that we can agree on this.
 
 @gonzalo: regarding the icon, I think the activity icon works fine, but maybe 
 someone else can give us more feedback to see which one is better to choose 
 (maybe @gary?).

Yes need to look at this, the activity icon gets used in many places these days 
for slightly different meanings, we will wear them out if we are not careful! 
;) /me wonders if we can badge the Activity icon with a small box/collection 
icon.

 @gonzalo: setting the examples option as first is no big deal.
 
 Before doing anything I think we should agree on these changes. Maybe at 
 tomorrow's design meeting? If these is one, at least informal.

Apologies, I know we missed last weeks official meeting as well, but the first 
13.0 build triage meeting is today (due to a US holiday yesterday). I at least 
will not manage a design meeting today.

Regards,
--Gary

 Thank you guys for the feedback :) Lets keep pushing this!
 
 On Fri, Aug 31, 2012 at 4:42 PM, Gonzalo Odiard godi...@gmail.com wrote:
 Another note:
 
 Thinking in the use case of a developer adding the ObjectChoser with the 
 intention
 of show to the users the examples directory content,
 like TurtleArt today use a FileChooser, 
 probably would be good have a option to set the examples directory as the 
 first displayed
 instead of displaying the content of the Journal, and then the user need 
 change to 
 the examples directory.
 I don't know how difficult is implement it, but have sense from the point of 
 view 
 of the usability.
 
 Gonzalo
 
 On Fri, Aug 31, 2012 at 4:54 PM, Gonzalo Odiard godi...@gmail.com wrote:
 Sorry, we are so busy, these days...
 
 I have tested it, and works as expected.
 
 A few comments:
 
 * gtk2 branch is in maintenance mode now, probably is better port this to the 
 gtk3 branch.
 (Anyway need opinion of sugar maintainers)
 
 * IMHO the code added to enable configure the examples directory is so 
 complicate,
 and do not add too much value. I think is better use a fixed examples or 
 samples
 (as in TurtleArt). If the maintainer want use it, should follow the 
 convention.
 We do the same, by example with the icons directory.
 
 * Finally, I think the button in the ObjectChooser deserve a special icon, 
 and not use the activity icon.
 Probably using the box metaphor. 
 
 Thanks by the work and patience :)
 Keep pushing! (my new motto)
 
 Gonzalo
 
 
 On Fri, Aug 31, 2012 at 3:23 PM, Martin Abente 
 martin.abente.lah...@gmail.com wrote:
 Its been too quiet recently.
 
 Apart from Bert I have not received any feedback from the current functional 
 design concept.
 
 Anyone still interested? :)
 
 
 On Wed, Aug 22, 2012 at 10:13 PM, Martin Abente 
 martin.abente.lah...@gmail.com wrote:
 Nice! Please also give it a try :)
 
 @Gary, Gonzalo, ping ;) both patches are here: 
 http://www.sugarlabs.org/~tch/patches/examples/
 
 
 On Wed, Aug 22, 2012 at 10:24 AM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 On 2012-08-22, at 04:27, Martin Abente wrote:
 
  Hello everyone:
 
  From the meeting notes and Bert suggestion I have what could be called the 
  version 2 of this feature, greatly simplified and complies with everyones 
  rightful suggestions.
 
  To avoid spaming (for some time) the sugar-devel ML I will post the patches 
  just here:
 
  sugar: 
  http://www.sugarlabs.org/~tch/patches/examples/sugar/0001-Examples-objects-support-V2.patch
  sugar-toolkit: 
  http://www.sugarlabs.org/~tch/patches/examples/sugar-toolkit/0001-Examples_path-activity-info.patch
 
  Feedback is welcome!
  tch
 
 I have not tried it, but by eyeballing the code looks fine :)
 
 - Bert -
 
 
  On Tue, Aug 21, 2012 at 3:42 PM, Martin Abente 
  martin.abente.lah...@gmail.com wrote:
  I don't see why not, we can achieve both things :). Maybe someone have 
  another opinion regarding this?
 
 
  On Tue, Aug 21, 2012 at 3:07 PM, Bert Freudenberg b...@freudenbergs.de 
  wrote:
  On 2012-08-21, at 20:17, Martin Abente wrote:
 
   The design I implemented works like this:
  
   a. activity developers or deployments add a new examples folder inside 
   the activity bundle with their examples objects.
   b. when the activity starts, the example folder will be accessible 
   through the journal as new volume option, and also from __any__ 
   ObjectChooser.
   c. Only one volume button will be shown, even when many instances of the 
   activity are running.
   d. The example folder will disappear from the journal when the last 
   instance is closed.
   [...]
   Waiting for more feedback... :)
 
  And in another thread:
 
   instead of a magic directory name, couldn't the activity.info file have 
   a new entry giving the examples path?
  
 
   What I tried, or I am trying, to do is to make this feature available as 
  

Re: [Sugar-devel] [Design] Accelerometer icon

[Gary Martin]

Hi Agustin,

Early in the current development cycle there were/are plans to enable system 
wide auto screen rotation using the accelerometer when in ebook mode (there was 
a chance we might loose the physical rotate button on the display). Using the 
accelerometer to rotate the image inside Image Viewer would likely prove 
frustrating if the system was also auto rotating the screen. If we enable 
system wide auto rotate (in ebook mode) this does raise the case for allowing 
Activities the option of blocking accelerometer auto rotation if they are the 
front most activity so they can customise the experience.

Walter, this probably affects you more than others at the moment, what are your 
thought on auto rotate an activity accelerometer use?

Regards,
--Gary

On 2 Sep 2012, at 21:31, Agustin Zubiaga Sanchez a...@sugarlabs.org wrote:

 Hi everybody, 
 Some days ago I sent a patch for ImageViewer, that adds the use of the 
 accelerometer to rotate images in this activity. 
 I am maintainer then I can apply this patch, but I want to know your opinion.
 
 Regards, 
 aguz
 
 
 2012/8/31 Gary Martin garycmar...@googlemail.com
 On 31 Aug 2012, at 13:44, Manuel Kaufmann humi...@gmail.com wrote:
 
  On Thu, Aug 30, 2012 at 7:21 AM, Walter Bender walter.ben...@gmail.com 
  wrote:
  I use the accelerometer if it
  available. If not, I fall; back to the keyboard. I think that would be
  a reasonable approach for Maze as well.
 
  I think in Maze would be good to have the option to use the
  accelerometer or not because Maze can be played with more that one
  player, and in that case you need the keyboard. It could be really
  difficult to play a multiplayer Maze Game if one of them is using the
  accelerometer :)
 
 +1, Maze and Physics both need to provide a toggle option, although sometimes 
 fun, accelerometer input is often impractical, inaccurate, and non obvious in 
 many cases *, though the default state should be up to the activity author.
 
 * phone size devices are more practicle, but tablet size and up are only good 
 for limited use or in special use cases of the sensor (landscape/portrait 
 detection, movement monitoring, how bumpy is your journey to school, 
 pedometer counting activity/game).
 
 Regards,
 --Gary
 
  --
  Kaufmann Manuel
  Blog: http://humitos.wordpress.com/
  Porfolio: http://fotos.mkaufmann.com.ar/
  PyAr: http://www.python.com.ar/
 ___
 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

Re: [Sugar-devel] [Design] Accelerometer icon

[Gary Martin]

On 31 Aug 2012, at 13:44, Manuel Kaufmann humi...@gmail.com wrote:

 On Thu, Aug 30, 2012 at 7:21 AM, Walter Bender walter.ben...@gmail.com 
 wrote:
 I use the accelerometer if it
 available. If not, I fall; back to the keyboard. I think that would be
 a reasonable approach for Maze as well.
 
 I think in Maze would be good to have the option to use the
 accelerometer or not because Maze can be played with more that one
 player, and in that case you need the keyboard. It could be really
 difficult to play a multiplayer Maze Game if one of them is using the
 accelerometer :)

+1, Maze and Physics both need to provide a toggle option, although sometimes 
fun, accelerometer input is often impractical, inaccurate, and non obvious in 
many cases *, though the default state should be up to the activity author.

* phone size devices are more practicle, but tablet size and up are only good 
for limited use or in special use cases of the sensor (landscape/portrait 
detection, movement monitoring, how bumpy is your journey to school, pedometer 
counting activity/game).

Regards,
--Gary

 -- 
 Kaufmann Manuel
 Blog: http://humitos.wordpress.com/
 Porfolio: http://fotos.mkaufmann.com.ar/
 PyAr: http://www.python.com.ar/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)

[Gary Martin]

Hi Gonzalo,

On 29 Aug 2012, at 13:51, Gonzalo Odiard gonz...@laptop.org wrote:

 
 Btw, re Activity list view. We said at one point that the date displayed in 
 the list has not much meaning (at least at the moment). Did we have an idea 
 for a replacement?
 
 +1
 
 I know is not a trivial change, but IMHO, would be great have a short 
 description here.
 We can add it in the activity.info file, and get it translated as the 
 activity name today.

+1

FWIW I'm sure I saw this working in an alpha build once (I remember being 
surprised when I looked in list view, just a few activities had text extra 
minimal descriptions showing). I don't remember who was responsible but I did 
have a little dig and found the below existing strings in some activity.info 
files:

Garys-Computer:All Activities archive gary$ grep -r summary 
*/activity/activity.info
CartoonBuilder.activity/activity/activity.info:summary   = Make a cartoon by 
creating a sequence of poses inside a filmstrip
Chat.activity/activity/activity.info:summary   = Text chat
FlipSticks.activity/activity/activity.info:summary   = Using keyframes, program 
a stick figure to twist and dance
ImageViewer.activity/activity/activity.info:summary   = The Image Viewer 
activity is a simple and fast image viewer tool
Speak.activity/activity/activity.info:summary   = An animated face that speaks 
whatever you type
TamTamEdit.activity/activity/activity.info:summary = A music and sound 
exploration application for Sugar
TamTamJam.activity/activity/activity.info:summary = A music and sound 
exploration application for Sugar
TamTamMini.activity/activity/activity.info:summary = A music and sound 
exploration application for Sugar
TamTamSynthLab.activity/activity/activity.info:summary = A music and sound 
exploration application for Sugar
TuxPaint.activity/activity/activity.info:summary   = Drawing program designed 
for young children

Perhaps we could officially adopt the summary keyword if we go this route? I 
put together a quick mockup [1] using some of the above strings and close to 
the descriptions as found on ASLO to give an idea for what type of strings misc 
developers would probably fill this with. Note that an ellipsis ... is used for 
clipping overly long strings. We would want to provide a style guide for that 
text, so it is a short, friendly, and as succinct as possible (i.e. say what it 
does, or what you can do with it in less than 7-10 words).

Regards,
--Gary

[1] http://wiki.sugarlabs.org/go/File:Home_list_view_comment_summary_mockup.png

 
  Gonzalo

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

Re: [Sugar-devel] activity sandbox

[Gary Martin]

On 28 Aug 2012, at 14:49, blekros sugar blekros.su...@gmail.com wrote:

 I'd like to use Eclipse with PyDev on Windows to try to build activities.
 
 Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a 
 chrome / firefox plugin so that I can use my existing environments without 
 VMWare or VirtualBox?
 
 I can't find anything resembling an object model, or class diagram that shows 
 the architectural breakdown of Sugar.   Where to look?

Here's another couple places [1] [2], to start at, though they don't go into 
great depth and are somewhat dated now. I also had a quick, somewhat gaudy, 
stab at this some years back [3] but it doesn't add much useful vs. the ascii 
art:

Regards,
--Gary

[1] http://wiki.sugarlabs.org/go/Sugar_System_Stack
[2] http://wiki.sugarlabs.org/go/Development_Team/Architecture
[3] http://youtu.be/xVV_OnBS6O4

 
 Thanks,
 
 Brad
 ___
 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

Re: [Sugar-devel] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)

[Gary Martin]

On 29 Aug 2012, at 18:19, Gonzalo Odiard gonz...@laptop.org wrote:

 I am pretty sure Aleksey knows who was involved :)
 
 There are more info here [1] and here [2]
 
 Solve the packaging issues (specially the dependencies required) 
 is another different beast, but we can add the following without problem:
 
 summary (will be translated)
 license
 homepage
 
 And at the risk of starting a never ending thread, I propose:
 
 authors (we see the need of recognition to the work volunteers do)
 repository (will enable improve development process in the future)
 
 Right now, this information will not be visible, but in the future,
 we can add a tab in the show source window, or find another place to show it.
 
 Should be good agree at least in the proposed info, and start to add to the 
 activities,
 if not is ever a chicken and egg problem, do not add the info because is not 
 useful,
 and not show the info because is not available...

Hmmm... You really want others now as well? Not busy enough ;)

Summary is the one I'd focus on if we are moving forward with this and show 
them in the list view. If there is no direct exposure/need the rest will all 
just bit rot and go stale, like much of the rest of the 'standard' activity 
file spam that tries to have much of the same information repeated yet again – 
HACKING, AUTHORS, NEWS, README, TODO – I gave up looking, changing them some 
time back.

Regards,
--Gary

 Gonzalo
 
 [1] http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging
 [2] http://wiki.sugarlabs.org/go/Features/Feature_ActivityInfo
 
 
 On Wed, Aug 29, 2012 at 11:45 AM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Gonzalo,
 
 On 29 Aug 2012, at 13:51, Gonzalo Odiard gonz...@laptop.org wrote:
 
 
  Btw, re Activity list view. We said at one point that the date displayed in 
  the list has not much meaning (at least at the moment). Did we have an idea 
  for a replacement?
 
  +1
 
  I know is not a trivial change, but IMHO, would be great have a short 
  description here.
  We can add it in the activity.info file, and get it translated as the 
  activity name today.
 
 +1
 
 FWIW I'm sure I saw this working in an alpha build once (I remember being 
 surprised when I looked in list view, just a few activities had text extra 
 minimal descriptions showing). I don't remember who was responsible but I did 
 have a little dig and found the below existing strings in some activity.info 
 files:
 
 Garys-Computer:All Activities archive gary$ grep -r summary 
 */activity/activity.info
 CartoonBuilder.activity/activity/activity.info:summary   = Make a cartoon by 
 creating a sequence of poses inside a filmstrip
 Chat.activity/activity/activity.info:summary   = Text chat
 FlipSticks.activity/activity/activity.info:summary   = Using keyframes, 
 program a stick figure to twist and dance
 ImageViewer.activity/activity/activity.info:summary   = The Image Viewer 
 activity is a simple and fast image viewer tool
 Speak.activity/activity/activity.info:summary   = An animated face that 
 speaks whatever you type
 TamTamEdit.activity/activity/activity.info:summary = A music and sound 
 exploration application for Sugar
 TamTamJam.activity/activity/activity.info:summary = A music and sound 
 exploration application for Sugar
 TamTamMini.activity/activity/activity.info:summary = A music and sound 
 exploration application for Sugar
 TamTamSynthLab.activity/activity/activity.info:summary = A music and sound 
 exploration application for Sugar
 TuxPaint.activity/activity/activity.info:summary   = Drawing program designed 
 for young children
 
 Perhaps we could officially adopt the summary keyword if we go this route? 
 I put together a quick mockup [1] using some of the above strings and close 
 to the descriptions as found on ASLO to give an idea for what type of strings 
 misc developers would probably fill this with. Note that an ellipsis ... is 
 used for clipping overly long strings. We would want to provide a style guide 
 for that text, so it is a short, friendly, and as succinct as possible (i.e. 
 say what it does, or what you can do with it in less than 7-10 words).
 
 Regards,
 --Gary
 
 [1] 
 http://wiki.sugarlabs.org/go/File:Home_list_view_comment_summary_mockup.png
 
 
   Gonzalo
 
 

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

Re: [Sugar-devel] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)

[Gary Martin]

Hi Simon,

On 29 Aug 2012, at 12:41, Simon Schampijer si...@schampijer.de wrote:

 On 08/28/2012 05:53 PM, Gary Martin wrote:
 Hi Simon,
 
 On 28 Aug 2012, at 14:12, Simon Schampijer si...@schampijer.de wrote:
 
 On 08/28/2012 02:14 PM, Manuel Quiñones wrote:
 So now the filtering is shared between the three views.  I think this
 is worth noting in the commit message.
 
 Thanks for the review and catching this! I did note it in the commit 
 message before pushing.
 
 Gary, we did discuss the following:
 
 There seem to be three options how the search now that we have a search 
 entry in each view could work:
 
 - if you did a search in View A and then switch to View B the entry will be 
 cleared leaving you with no search applied in B
 
 - if you did a search in View A and then switch to View B the search from A 
 will be applied to B (behavior which landed in 0.97.2)
 
 - if you did a search in View A and then switch to View B the search from A 
 will not be applied in B, if you switch back to A the search you did before 
 in A has been cached and is still applied (behavior before 0.97.2)
 
 Thanks for raising this change! I'll need to give it some more though and 
 test the patches.
 
 My gut reaction so far would be for the clearing behaviour,
 
 You can use the attached patch to test that behavior. I think I like that 
 behavior as well. Preferred over caching, as you say it may lead to 
 unexpected behaviors.
 
 second choice would be the caching behaviour. My reasons against the 0.97.2 
 behaviour change would be that different views contain dissimilar enough 
 objects that a search in one is not often useful in another (e.g. searching 
 for a buddy or access point, and switching to home), and that will drop the 
 user in an unexpected UI state. A reason for clearing the search when 
 switching views is that it prevents issues for novice users who leave a query 
 in place unintentionally, and return to find a view in an unexpected state 
 without realising they need to clear the old search query manually. Though so 
 far, caching previous search queries in a view is just what we've been doing 
 in the shell. FWIW: home list view is the worst offender as it shows a blank 
 white canvas when a query has no matches, should really behave like the 
 Journal with the 'No matching entries' UI. The 0.97.2 change may well lead to 
 an increase in my icons are all grey/gone type support reports, especially 
 from young users who may randomly press keys and generate a shel query 
 without realising it.
 
 
 Thanks Gary, good catch about the needed feedback in the list view, filed as 
 [1] (feel free to add there wordings/icon to use etc). Once the shell port is 
 done, it should be straight forward to add.

Fab. Done. Have added a mockup screen shot and comment to the ticket.

Regards,
--Gary

 Btw, re Activity list view. We said at one point that the date displayed in 
 the list has not much meaning (at least at the moment). Did we have an idea 
 for a replacement?
 
 Thanks,
   Simon
 
 [1] http://bugs.sugarlabs.org/ticket/3838
 view_toolbar_search_behavior.patch

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

Re: [Sugar-devel] long-press touch actions in Sugar

[Gary Martin]

Hi Sridhar,

On 28 Aug 2012, at 03:41, Sridhar Dhanapalan srid...@laptop.org.au wrote:

 It appears [1] that long-press is becoming part of the Sugar user
 experience on touchscreens:
 
 Touch and hold _should_ trigger full display of palette content (like
 a right click, no extra delay)
 
 I have some reservations [2] about long-press actions.

Thanks, I'd seen your comments on the wiki.

 They don't seem
 to be very intuitive or discoverable.
 
 How are the Sugar Design Team managing this problem?

So yes, I agree long press is not immediately discoverable/obvious (a similar 
situation as we have had with right click), though I'd disagree with you about 
long press intuitiveness as a gesture. Once it is discovered, I'd say it is 
more intuitive to use than a right click. Here are some of the UI/UX changes we 
are undertaking to improve on previous right click interactions, and upcoming 
touch support (Note: we need to support both trackpad and touch based UI 
interactions).

 - Amendment of various widgets in Sugar that only responded to right click or 
cursor hover (left click or a tap now raises their palettes).
 - Modification of a number of, but not all, Sugar widgets that have overloaded 
functionality (e.g. widgets with a primary action and a palette full of sub 
actions), so that the primary action is removed and replaced with an action to 
immediately expose the palette on left click or tap (provides safer UI 
exploration and removes need for some right click , hover, long touch 
interactions).
 - Exploratory mockup work and discussion looking at the possibilities of 
visually marking widgets that contain long press features (not sure if we'll 
land this cycle).
 - Long press gesture on widgets that support it will show a timed animation 
while you hold to provide visual feedback.

You should find many of the working patches already on this mail list (if you 
have the chance to test any and provide feedback), and the links [1], [2], [3], 
[4] should help provide more background on touch related items being worked on. 
Feedback/review/suggestions welcome!

Regards,
--Gary

[1] http://wiki.sugarlabs.org/go/Features/Touch/Development
[2] http://wiki.sugarlabs.org/go/Design_Team/Sugar_Shell_Touch_Input
[3] http://wiki.sugarlabs.org/go/Talk:Design_Team/Sugar_Shell_Touch_Input
[4] http://wiki.sugarlabs.org/go/Design_Team/Activity_Touch_Input

 [1] http://wiki.sugarlabs.org/go/Design_Team/Sugar_Shell_Touch_Input
 [2] 
 http://ux.stackexchange.com/questions/24460/press-and-hold-or-long-press-gestures-unintuitive
 
 
 
 Sridhar Dhanapalan
 Engineering Manager
 One Laptop per Child Australia
 ___
 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

Re: [Sugar-devel] [DESIGN] Frame, new behavior for revealing/hiding the Frame with the mouse

[Gary Martin]

Hi Simon,

On 28 Aug 2012, at 12:36, Simon Schampijer si...@schampijer.de wrote:

 Hi,
 
 in 238338d4b5d6a065eb81bd118a8c0b7ca83717bf (will be in 0.97.2) we modified 
 the Frame hide/show with a mouse behavior to some extent:
 
- you can reveal the Frame by going with the cursor in one of the
  hot corners
 
- you can hide the Frame by going with the cursor in one of the
  hot corners (and the Frame is visible)
 
- the Frame is not hidden on mouse out (leaving the Frame)
 
- (as before) you can hide/reveal the Frame with the designated keys
 
- the Frame is hidden when you switch between activities
  (todo: hide as well when resume in the Palette is clicked)
 
- the Frame is hidden when a zoom level is selected
 
- (as before) you can use 'alt-tab' to cycle through the
  running activities
 
- drag  drop is currently not working, SL #3811
 
 
 One item I was looking at is the resume option in the Palette in the activity 
 tray in the Frame (patch attached). At current if I click on one of those 
 icons in the upper Frame it will do the primary action and the Frame is 
 hidden. Should then do the 'resume' option in the Activity Palette do the 
 same, when clicked resume and hide the Frame (like in the patch)?

+1 for resume menu item behaviour hiding the frame.

Regards,
--Gary

 Regards,
  Simon
 frame_activitytray_resume_hide_palette.patch___
 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

Re: [Sugar-devel] [DESIGN] Views: search behavior (was Re: [PATCH sugar] Views: move the ViewToolbar to the HomeWindow instead of having one in each View)

[Gary Martin]

Hi Simon,

On 28 Aug 2012, at 14:12, Simon Schampijer si...@schampijer.de wrote:

 On 08/28/2012 02:14 PM, Manuel Quiñones wrote:
 So now the filtering is shared between the three views.  I think this
 is worth noting in the commit message.
 
 Thanks for the review and catching this! I did note it in the commit message 
 before pushing.
 
 Gary, we did discuss the following:
 
 There seem to be three options how the search now that we have a search entry 
 in each view could work:
 
 - if you did a search in View A and then switch to View B the entry will be 
 cleared leaving you with no search applied in B
 
 - if you did a search in View A and then switch to View B the search from A 
 will be applied to B (behavior which landed in 0.97.2)
 
 - if you did a search in View A and then switch to View B the search from A 
 will not be applied in B, if you switch back to A the search you did before 
 in A has been cached and is still applied (behavior before 0.97.2)

Thanks for raising this change! I'll need to give it some more though and test 
the patches.

My gut reaction so far would be for the clearing behaviour, second choice would 
be the caching behaviour. My reasons against the 0.97.2 behaviour change would 
be that different views contain dissimilar enough objects that a search in one 
is not often useful in another (e.g. searching for a buddy or access point, and 
switching to home), and that will drop the user in an unexpected UI state. A 
reason for clearing the search when switching views is that it prevents issues 
for novice users who leave a query in place unintentionally, and return to find 
a view in an unexpected state without realising they need to clear the old 
search query manually. Though so far, caching previous search queries in a view 
is just what we've been doing in the shell. FWIW: home list view is the worst 
offender as it shows a blank white canvas when a query has no matches, should 
really behave like the Journal with the 'No matching entries' UI. The 0.97.2 
change may well lead to an increase in my icons are all grey/gone type 
support reports, especially from young users who may randomly press keys and 
generate a shel query without realising it.

Regards,
--Gary

 Regards,
   Simon

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

Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set

[Gary Martin]

Hi Chris,

On 23 Aug 2012, at 19:45, Chris Leonard cjlhomeaddr...@gmail.com wrote:

 On Thu, Aug 23, 2012 at 11:10 AM, Gary Martin
 garycmar...@googlemail.com wrote:
 
 I like the most recent version well enough,
 
 http://wiki.sugarlabs.org/go/File:Maliit_Sugar_theme_work_13.png
 
 High praise ;) Improvements/changes?
 
 Sorry, I did not mean to damn with faint praise, it is really good
 work under very tight restrictions.  I personally find the XO physical
 kb limiting, so I bought a rollable rubber USB kb :-)
 
 I am sincerely excited about the potential for an OSK in the realm of
 limitless i18n/L10n freed from the shackles of silkscreening.
 
 I'm a little concerned that the absence of the
 Home/Friends/Neighborhood/World quartet of XO specific keys will be
 missed, but I understand that it is tough to collapse 6 rows of XO
 keys into 4 rows for Maliit.
 
 Yes space is at a premium using an OSK [1], however as the OSK is only 
 visible when a text input widget has focus, we need to make sure 
 Neighborhood/Group/Home/Activity/Journal are accessible at all other times 
 as well, primarily by improving touch access to the Frame (and improving 
 Frame discovery, though unlikely for this cycle).
 
 Yes, the ergonomics of frame invocation/dismissal and switching focus
 from kb to other touch input needs deep thought, but I have confidence
 in the people smarter in UI design than I am that will be working on
 it. :-).  I don't expect it to be tuned to re-training fossils like
 me, but at the agile minds and fingers of kids.
 
 I've got lots of other questions, but they are more i18n related, so
 I'll forego inserting them into this design thread,
 
 No, bring them up here if they are OSK related!
 
 Ok, you asked for it :-)
 
 Is there currently a mechanism for re-creating the many xkb-based
 layouts already designed for OLPC that never got silkscreened?
 
 http://wiki.laptop.org/go/Keyboard_layouts
 
 No, those are physical layouts not designed for OSK. There about 40 existing 
 maliit layouts that I'll update to match our OSK design modifications. And 
 then I'd imagine we will want to closely check the OSK layouts for the 
 languages we prioritise, and make sure they cover our needs (the existing 
 OLPC layouts will be a useful reference).
 
 
 Getting the existing OLPC xkb designs recreated is going to be pretty
 important once the existing Maliit layouts are adapted.  It's also
 going to be a repetitive task (see attached spreadsheet), I'm
 wondering if there are hackerish methods for assisting in that task
 (scripts, spreadsheet templates, etc.)?  Even the list of OLPC xkb
 layouts in my spreadsheet is incomplete, for example, I know of a
 layout for an Inuktitut variant that Walter helped some Canadians
 design.
 
 Generating some local documentation on de novo Maliit keyboard design
 is going to pretty important as I can easily imagine getting asked a
 lot of questions about this that can no longer be put off with, well,
 first you make a silkscreen in a factory in China. . . 
 
 I'd love to be able to do more for new languages than say go look at
 https://wiki.maliit.org/Documentation and let me know when you've
 figured out their process.  Sugar Labs is, by it's nature, an entry
 point for languages under-represented in ICT and we already do a lot
 of stuff (like glibc locale design assistance) in support of  these
 language communities.
 
 
 Language switching:
 So, with the language switch key you can toggle through a stack of
 keyboards that you've configured in the Control Panel (in advance).
 All by itself, that would be awesome and really enhance multilingual /
 multi-script input.
 
 This more-or-less implements the Language key already found on Arabic
 and Thai OLPC keyboards, but does so for all keyboards.
 
 http://wiki.laptop.org/go/Keyboard#Special_Keys
 
 http://wiki.laptop.org/go/OLPC_Arabic_Keyboard
 http://wiki.laptop.org/go/File:Key_arabic.jpg
 
 http://wiki.laptop.org/go/OLPC_Thai_Keyboard
 http://wiki.laptop.org/go/File:Key_thai.jpg
 
 This also seems to be necessary, but not sufficient, for the utopian
 ideal of toggling through UI languages / glibc locales on-the-fly
 (without going to Control Panel and rebooting).  How far away is such
 a promised land once we have keyboard switching?

FWIW, I've added the output to the discussion page from Maliit listing the 
language files in a little more detail. I'll put up screenshots of the layouts 
once I'm a little further along with the style/layout changes (I need to do 
this as part of my layout change testing anyway):

http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit

Regards,
--Gary

 cjl
 OLPC_kbs.ods

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

Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set

[Gary Martin]

On 26 Aug 2012, at 18:02, Chris Leonard cjlhomeaddr...@gmail.com wrote:

 On Sun, Aug 26, 2012 at 8:04 AM, Gary Martin garycmar...@googlemail.com 
 wrote:
 FWIW, I've added the output to the discussion page from Maliit listing the 
 language files in a little more detail. I'll put up screenshots of the 
 layouts once I'm a little further along with the style/layout changes (I 
 need to do this as part of my layout change testing anyway):
 
http://wiki.sugarlabs.org/go/User_talk:Garycmartin/Maliit
 
 
 Thanks Gary.  A good start.  As things stabilize I'd love to work with
 folks to document the variants in more detail on the wiki (including
 links to the XML files) in a manner similar to the way the OLPC xkb
 designs are documented on w.l.o
 
 http://wiki.laptop.org/go/Category:Keyboard_layouts
 
 There is huge i18n/L10n potential and I can imagine a lot of interest
 in developing additional keyboard XML files to capture scripts that
 are not on Maliit's radar screen yet.

One thing to keep in mind is that the Maliit keyboard layouts _are_ the 
language files, so if we make even to most trivial of changes for our desired 
keyboard layout (move a button or add a button etc) then any new language 
layouts we may later add will be of minimal use to Maliit upstream, 
unfortunately. Would be nice if the process could go both ways, but unlikely in 
the short term at least.

Regards,
--Gary

 cjl

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

Re: [Sugar-devel] [DESIGN] search toolbar in Group view

[Gary Martin]

Hi Simon,

On 26 Aug 2012, at 10:35, Simon Schampijer si...@schampijer.de wrote:

 Hi,
 
 to have the same functionality in the Views, I would like to add a search 
 toolbar to the Group View. That is trivial in the first place and code can be 
 shared from the Mesh and the Group View.
 
 One thing that is a bit tricky to handle is that we use already grey icons to 
 show that a buddy is absent at the moment. This collides a bit with the alpha 
 representation when we do search. Is there some smart way to make that more 
 distinguishable?
 
 I know we talked once about a different search mechanism all together but 
 maybe there is something we can do short term.

Yea ;)

OK so a couple of quick thoughts:

1) The current search design does _not_ grey out mis-matches, it reduces the 
alpha. So we do have two metaphors; buddy grey stroke for absent; full 
colour/faded alpha buddy icon for search. Searching for a buddy that is absent 
is the weakest visual case here, where you'd be left looking at a screen of 
faded alpha colour icons, and a grey stroke only buddy icon. I think that would 
still be a reasonable case.

2) The other option discussed was to reuse the grey rounded rect for the search 
hits, though this would clash with our mouse over/down use.

Regards,
--Gary

 Regards,
   Simon
 ___
 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

Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set

[Gary Martin]

Hi Chris,

On 23 Aug 2012, at 05:56, Chris Leonard cjlhomeaddr...@gmail.com wrote:

 On Wed, Aug 22, 2012 at 9:09 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 
 The key layout is a more complicated affair as it requires modification of 
 XML files for each language layout [1], so I'd rather lock down an agreed 
 layout before I start trying to apply them to 40+ different languages – and 
 yes I plan to script the edits as far as I can ;) FWIW, looks like this will 
 be a patch set we need to apply to out builds as although maliit supports 
 custom styles (olpc-xo is the one they added for us), their layouts are 
 shared between all styles, so they would be unlikely to accept patches from 
 us wanting to modify them all for Sugar's needs.
 
 [1] 
 https://gitorious.org/maliit/maliit-plugins/trees/master/maliit-keyboard/data/languages
 
 I like the most recent version well enough,
 
 http://wiki.sugarlabs.org/go/File:Maliit_Sugar_theme_work_13.png

High praise ;) Improvements/changes?

 I'm a little concerned that the absence of the
 Home/Friends/Neighborhood/World quartet of XO specific keys will be
 missed, but I understand that it is tough to collapse 6 rows of XO
 keys into 4 rows for Maliit.

Yes space is at a premium using an OSK [1], however as the OSK is only visible 
when a text input widget has focus, we need to make sure 
Neighborhood/Group/Home/Activity/Journal are accessible at all other times as 
well, primarily by improving touch access to the Frame (and improving Frame 
discovery, though unlkely for this cycle).

 I've got lots of other questions, but they are more i18n related, so
 I'll forego inserting them into this design thread,

No, bring them up here if they are OSK related!

 but I can't resist
 throwing one out there.
 
 Is there currently a mechanism for re-creating the many xkb-based
 layouts already designed for OLPC that never got silkscreened?
 
 http://wiki.laptop.org/go/Keyboard_layouts

No, those are physical layouts not designed for OSK. There about 40 existing 
maliit layouts that I'll update to match our OSK design modifications. And then 
I'd imagine we will want to closely check the OSK layouts for the languages we 
prioritise, and make sure they cover our needs (the existing OLPC layouts will 
be a useful reference).

Thanks for the feedback!

Regards,
--Gary

[1] 8-10mm per touch target is about as small as you want to go for key hit 
targets, and we are at 9.5mm in portrait for the v13 layout example (assuming 
the current XO screen dimensions).

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

Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set

[Gary Martin]

Hi Gonzalo,

On 23 Aug 2012, at 16:20, Gonzalo Odiard gonz...@laptop.org wrote:

 
 [1] 8-10mm per touch target is about as small as you want to go for key hit 
 targets, and we are at 9.5mm in portrait for the v13 layout example (assuming 
 the current XO screen dimensions).
 
 
 Do you know how much is this in pixels or better in style.zoom() units?
 Should be good have this information available for activity developers.

Well I can tell you that our standard toolbar button size is already pretty 
much spot on :) this is part of the reason I was happy that Sugar designs 
already had a very good basis for touch support vs. other desktop operating 
systems.

Regards,
--Gary

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

Re: [Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set

[Gary Martin]

On 22 Aug 2012, at 20:58, Manuel Quiñones ma...@laptop.org wrote:

 2012/8/22 Gary C Martin garycmar...@googlemail.com:
 Hi all,
 
 I've pulled together most of the design mockups onto a wiki page [1] for the 
 ongoing work on the Maliit based on screen keyboard (OSK). This is part of 
 the feature set [2] to get the Sugar UI/UX touch ready, as raised by Simon 
 on the mail-list already. Please feel free to use the wiki discussion page, 
 or reply to this email thread if you have any OSK design related feedback!
 
 Excellent!  For the definitive one, what's the highlight color of the keys?

By definitive, do you mean the final selected one? I was hoping to see what the 
reaction was to these mockups first, but the highlight (on key press) certainly 
wont be the blue gradient used in the existing maliit olpc-xo theme.  Expect a 
key press will be a simple monochrome darkening of a key fill (if we go for a 
light default key fill style), or a brightening of a key fill (if we go for a 
dark default key fill style). These parts of the style definition are simple 
png images, so easy to tweak.

The key layout is a more complicated affair as it requires modification of XML 
files for each language layout [1], so I'd rather lock down an agreed layout 
before I start trying to apply them to 40+ different languages – and yes I plan 
to script the edits as far as I can ;) FWIW, looks like this will be a patch 
set we need to apply to out builds as although maliit supports custom styles 
(olpc-xo is the one they added for us), their layouts are shared between all 
styles, so they would be unlikely to accept patches from us wanting to modify 
them all for Sugar's needs.

Regards,
--Gary

[1] 
https://gitorious.org/maliit/maliit-plugins/trees/master/maliit-keyboard/data/languages

 -- 
 .. manuq ..

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

Re: [Sugar-devel] [DESIGN] Journal: confirmation before erasing/duplicating an entry

[Gary Martin]

Hi Simon,

On 21 Aug 2012, at 05:17, Simon Schampijer si...@schampijer.de wrote:

 On 08/20/2012 11:21 PM, Manuel Quiñones wrote:
 2012/8/19 Simon Schampijer si...@schampijer.de:
 Hi,
 
 I have been working on the confirmation alert for the Journal, submitted a
 patch [1].
 
 Erasing an entry in the Journal does not ask for confirmation
 before doing the erase. This patch adds an alert to the ListView
 and the DetailView that asks for confirmation before doing the
 erase. This is part of the touch interaction work [2].
 
 I think the need is clear, I just want to confirm the wording of the message
 and title.
 
 This will erase the object... can also work, but I think This will
 erase the entry... works better.
 
 About the alert for the duplication. I am not 100% convinced it is needed.
 
 +1 to not add an alert in duplication too.
 
 There is not much harm in duplicating an entry (unless it is really big). I
 try to avoid confirmation alerts when possible. I think the only thing which
 is critical is feedback in that case. In the ListView the feedback is given.
 Duplicating an entry in the DetailView lacks a bit the feedback what has
 happened. Long term an animation would be nice here. Short term options that
 would help giving feedback here (please not an alert:)?
 
 What about a message duplicating entry... that dissapears in a few
 seconds?  Yes, is an alert :) but without Accept/Cancel buttons.
 
 Yes, I thought about that as well, actually. In the ListView I think feedback 
 is great, in the DetailView not so much, so the alert would be only in the 
 DetailView?

Apologies not to be clear enough, but for both cases (Erase and Duplicate), the 
confirmation dialogues were intended only for the detail view where the toolbar 
button icon functions may not be immediately obvious and their resulting action 
not clear (Duplicate) or undoable (Erase). No need for the dialogues in the 
main Journal list view as you have to explicitly raise an entries palette and 
then select the Erase or Duplicate item from those options presented (text and 
small icon).

Regards,
--Gary

 Simon
 
 
 
 
 ___
 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

Re: [Sugar-devel] [FEATURE] [DESIGN] Display Device

[Gary Martin]

Hi Simon,

On 21 Aug 2012, at 12:18, Simon Schampijer si...@schampijer.de wrote:

 Hi,
 
 this Feature Display Device [1] has been proposed for 0.96 inclusion 
 already but did not make it in due to time constraints. With touch the need 
 to expose the 'take-screenshot' and 'adjust-brightness' options in the UI 
 gets more prominent, that is why I want to propose this again for 0.98.
 
 The part for the screenshot taking was already done, that part of the patch 
 just needs to be re-based.

I'm not happy the design is ready yet for inclusion, some quick comments:

 - Use of the camera icon (especially in the device frame) suggests it involves 
camera hardware.
 - Is taking a screenshot really a feature that should be in the device section 
of the frame?
 - The device frame is filling up fast and furious in this cycle, we already 
need to add an icon for raising the OSK, and an icon for controlling the 
hardware display brightness/monochrome mode.
 - The palette shown in the screen shot is named Display.

Regards,
--Gary

 Regards,
   Simon
 
 [1] http://wiki.sugarlabs.org/go/Features/Display_Device
 ___
 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

Re: [Sugar-devel] [DESIGN] Journal: confirmation before erasing/duplicating an entry

[Gary Martin]

On 21 Aug 2012, at 13:34, Simon Schampijer si...@schampijer.de wrote:

 On 08/21/2012 01:57 PM, Gary Martin wrote:
 Hi Simon,
 
 On 21 Aug 2012, at 05:17, Simon Schampijer si...@schampijer.de wrote:
 
 On 08/20/2012 11:21 PM, Manuel Quiñones wrote:
 2012/8/19 Simon Schampijer si...@schampijer.de:
 Hi,
 
 I have been working on the confirmation alert for the Journal, submitted a
 patch [1].
 
 Erasing an entry in the Journal does not ask for confirmation
 before doing the erase. This patch adds an alert to the ListView
 and the DetailView that asks for confirmation before doing the
 erase. This is part of the touch interaction work [2].
 
 I think the need is clear, I just want to confirm the wording of the 
 message
 and title.
 
 This will erase the object... can also work, but I think This will
 erase the entry... works better.
 
 About the alert for the duplication. I am not 100% convinced it is needed.
 
 +1 to not add an alert in duplication too.
 
 There is not much harm in duplicating an entry (unless it is really big). 
 I
 try to avoid confirmation alerts when possible. I think the only thing 
 which
 is critical is feedback in that case. In the ListView the feedback is 
 given.
 Duplicating an entry in the DetailView lacks a bit the feedback what has
 happened. Long term an animation would be nice here. Short term options 
 that
 would help giving feedback here (please not an alert:)?
 
 What about a message duplicating entry... that dissapears in a few
 seconds?  Yes, is an alert :) but without Accept/Cancel buttons.
 
 Yes, I thought about that as well, actually. In the ListView I think 
 feedback is great, in the DetailView not so much, so the alert would be 
 only in the DetailView?
 
 Apologies not to be clear enough, but for both cases (Erase and Duplicate), 
 the confirmation dialogues were intended only for the detail view where the 
 toolbar button icon functions may not be immediately obvious and their 
 resulting action not clear (Duplicate) or undoable (Erase). No need for the 
 dialogues in the main Journal list view as you have to explicitly raise an 
 entries palette and then select the Erase or Duplicate item from those 
 options presented (text and small icon).
 
 Regards,
 --Gary
 
 Controversial part: Ok, maybe I did misunderstand or maybe did want to :) It 
 is true that the erase option is in a Palette, so revealing the Palette is 
 not as easy to be triggered by mistake. But maybe you have fat fingers and 
 'while wanting choose the option to show the details of that entry' you hit 
 erase by accident - I think I would still play safe here and have a 
 confirmation alert before erasing an item in the ListView.

OK. With the intention to land the multi-select Journal batch feature that 
covers the case where you might need to tidy up and remove more than a few 
entries in an efficient manor (just one Dialogue to get past).

 Clear part: Ok, so let's do the alerts in the detail view. Can you set on the 
 wording for both. We need a title and a message.

So for reference, the Activity home list view has a (in my opinion a rather 
wordy) Erase confirmation dialogue:

 Confirm erase
 Confirm erase: Do you want to
 permanently erase activity_name?  ((x) Keep  ((√) Erase)

And Ajay, in his multi-select Journal batch patch, currently has:

 Erase
 Do you want to erase N entries? ((x) Stop)  ((√) Continue)

I'd propose for both the Journal list  detail views:

 Erase
 Do you want to permanently erase entry name?  ((x) Cancel  ((√) Erase)

For the Journal detail view:

 Duplicate
 Do you want to duplicate entry name? ((x) Cancel  ((√) 
Duplicate)

Ajay, if folks are happy with the above, could we tweak the dialogue strings in 
your multi-select patch to match:

 Erase
 Do you want to permanently erase N entries?   ((x) Cancel  ((√) 
Erase)

 Copy
 Do you want to copy N entries to target?((x) Cancel  
((√) Copy)

Simon, if (!) folks agree with above, the Activity home list view dialogue text 
could be tided up to for consistency ;)

 Erase
 Do you want to permanently erase activity_name?((x) Cancel  ((√) Erase)

So you wish you'd never asked, right? ;)

Regards,
--Gary

 Thanks,
   Simon
 

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

Re: [Sugar-devel] [FEATURE] [DESIGN] Display Device

[Gary Martin]

Hi Simon,

On 21 Aug 2012, at 13:44, Simon Schampijer si...@schampijer.de wrote:

 Hi Gary,
 
 thanks for having a look!
 
 On 08/21/2012 02:34 PM, Gary Martin wrote:
 Hi Simon,
 
 On 21 Aug 2012, at 12:18, Simon Schampijer si...@schampijer.de wrote:
 
 Hi,
 
 this Feature Display Device [1] has been proposed for 0.96 inclusion 
 already but did not make it in due to time constraints. With touch the need 
 to expose the 'take-screenshot' and 'adjust-brightness' options in the UI 
 gets more prominent, that is why I want to propose this again for 0.98.
 
 The part for the screenshot taking was already done, that part of the patch 
 just needs to be re-based.
 
 I'm not happy the design is ready yet for inclusion, some quick comments:

One more quick comment. How does the screenshot taking interact with the 
exposed frame and open palette. I frequently need to take screen grabs of 
frames and palettes for documentation/design work, though I expect 
teachers/kids may often want clean, chrome free, shots of their activities. 
Perhaps a delayed countdown after the menu is triggered? Four audio beeps and a 
camera click (or longer duration beep, e.g. blip, blip, blip, blip, beep) 
as 5 sec count down to allow getting the UI in the state you want an image of?

  - Use of the camera icon (especially in the device frame) suggests it 
 involves camera hardware.
 
 The icon is a placeholder. It should be an icon for the display.

OK, understood. My immediate reaction is an icon that looks like the brightness 
sun icon on the keyboard, but that's explicitly brightness rather than the 
more encompassing term display.

  - Is taking a screenshot really a feature that should be in the device 
 section of the frame?
 
 See below. I am happy to hear about other suggestions. At the moment I have 
 no other one :/ Previous discussions did not bring something up neither [1].

Thanks for the link, yea pretty much a dead end there as well :/

  - The device frame is filling up fast and furious in this cycle, we already 
 need to add an icon for raising the OSK, and an icon for controlling the 
 hardware display brightness/monochrome mode.
  - The palette shown in the screen shot is named Display.
 
 The Palette should contain as well the options for the brightness. At least 
 that is what we discussed at one point. The Palette would be named something 
 like 'Display', have an option for brightness and one for taking a screenshot.

Yea, still not a great fit for taking a screenshot, but I've nothing better to 
suggest other than another undiscoverable hidden shortcut, long hold of the 
physical rotate screen button (interestingly both Android and iOS have equally 
funky hidden ninja shortcuts for taking arbitrary screenshots, suggesting it is 
an awkward design issue).

Regards,
--Gary

 Regards,
   Simon
 
 [1] http://lists.sugarlabs.org/archive/sugar-devel/2011-November/034372.html
 
 

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

Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal

[Gary Martin]

Hi Simon,

On 20 Aug 2012, at 12:56, Simon Schampijer si...@schampijer.de wrote:

 Hi,
 
 I have been thinking a bit about how we can enhance the interaction with the 
 search entries in the Shell so they will work well in touch as well [1].
 
 When you have a touchscreen device focusing an entry will automatically bring 
 up the onscreen keyboard (OSK). We are currently doing this in the Home 
 View/Neighborhood View and in the Journal. For keyboard devices this makes 
 absolute sense, having first to move the pointer towards the entry, click on 
 it before you can type in the search is a too long interaction. With a touch 
 interface however it is ok to touch the search field to bring up the OSK in 
 most of the cases. Otherwise the OSK might cover parts of the screen without 
 need.
 
 I would suggest the following new behavior:
 
 - the entry is unfocused by default, the canvas is focused

+1

 - the entry contains a hint (e.g. Search in your Journal...), adding a 
 placeholder text is available in GTK+3.2 [2]

Nice find. The place holder text would need to vary from place to place e.g. 
Search journal, Search neighbourhood, Search group [1], Search favourite 
activities, Search all activities.

 - when the user starts typing the entry is focused automatically (listening 
 on the canvas and switching focus)

+1

 I think this will give a good behavior for both worlds.

Yes, agreed. The search placeholder text also provides additional context 
indicating which view you might be in. At one point we discussed the 
possibility of adding each zoom view icon to each view's toolbar to improve 
context, but that design wasn't complete, the search placeholder text would be 
a step in that direction.

Regards,
--Gary

[1] The Group view still doesn't have a minimal toolbar or search facilities ;)

 I have attached as well a GTK+ 3 example. Let me know what you think.
 
 Regards,
   Simon
 
 [1] 
 http://wiki.sugarlabs.org/go/Features/Touch/Development#Reveal_on_text_input_focus.2C_auto_.2A.2Adismiss.2A.2A_on_loss_of_focus
 [2] 
 http://developer.gnome.org/gtk3/3.4/GtkEntry.html#gtk-entry-set-placeholder-text
 
 focus_entry.py___
 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

Re: [Sugar-devel] Testing Rotate in sugar-jhbuild

[Gary Martin]

Hi Walter,

On 20 Aug 2012, at 00:57, Walter Bender walter.ben...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Walter,
 
 
 On 16 Aug 2012, at 16:53, Walter Bender walter.ben...@gmail.com wrote:
 
 On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard gonz...@laptop.org wrote:
 
 In anybody want test how activities work with the screen rotated in
 
 sugar-jhbuid,
 
 can do in the terminal:
 
 
 xrandr -o left
 
 
 when your neck hurts, or you have finished...
 
 
 xrandr -o normal
 
 
 Gonzalo
 
 
 ___
 
 Sugar-devel mailing list
 
 Sugar-devel@lists.sugarlabs.org
 
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 Works great. Check out
 http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support
 rotation. But I am curious why the stop button runs off the edge... it
 would appear there is plenty of room for it.
 
 
 Not sure if this is your issue (my land line has been down most of the day
 and am on GSM network), but invisible separators still take space unless you
 explicitly tell them not to:
 
separator.set_size_request(0, -1)
 
 So your separator factory might need a tweak. See Physics activity.py line
 103 for a working example.
 
 Regards,
 --Gary
 
 
 -walter
 
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 I've been thinking for quite some time that we need a new approach to
 the problem of toolbar items following off the end of the toolbar This
 problem will be greatly exacerbated by the more frequent use of screen
 rotate one would expect with more use of tablet mode on XO 4.0 Touch.
 Most activities have not taken into account the potential squeezing of
 the toolbar by 25% even of they take into consideration general
 resizing of the screen due to rotation.

I know this is a tough line to take, but we should file tickets against 
activities that overflow in portrait orientation – that includes Physics and 
Calculate ;)

It is quite an effort making a complicated multi-function Activity appear 
simple, but letting activity developers off the hook to pile on features 
without keeping their UI under control seems like a loosing direction to take. 
Max ten icons in the toolbar (that includes the Activity toolbar icon and the 
Stop toolbar icon). We've had decent sub-toolbar support in Sugar for a long 
time now, lets make sure we prioritising that primary tool bar space and 
putting the less used features into secondary toolbars.

Regards,
--Gary

 A simple solution would be to double the vertical size of the toolbar
 and wrap the icons onto a second row.
 
 comments?
 
 -walter
 -- 
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org

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

Re: [Sugar-devel] [DESIGN] Frame Device icon Volumes

[Gary Martin]

On 19 Aug 2012, at 15:54, Simon Schampijer si...@schampijer.de wrote:

 On 08/19/2012 03:45 PM, Gonzalo Odiard wrote:
 There are a convention about the position of the primary action?
 Should be the closest to the button or the first at top of the palette?

The palettes reflow based on how close to a screen edge it is, so in some cases 
it might not be easily to know which end of the palette is closest to the 
button. I'd also call out that reordering a palettes content is a worse UI 
crime for consistency. At Sugar Camp Paris 2, Simon and I did mock-up a range 
of 'put the primary action by the button' type designs, until we realised the 
issues with reflow when near screen edges.

So that's a +1 for top of the palette. I've always assumed this was the 
convention and implicit in the current implementation, but perhaps it's not 
explicitly documented (seemingly like so many other items).

 I think is important have this defined, and may be show it in a special way.
 In this particular case, the option is between the label, another action and
 the widget showing the size, and is not obvious.
 
 Gonzalo
 
 So, in this particular case, there is no primary action anymore. Left click 
 will always bring up the Palette, then it is up to the user to decide.

+1

 Let's look at another case: the Activity Palettes in the Frame (see 
 activity_palette_1.png). The primary action there is to resume the Activity. 
 When you click on the button that activity is resumed. The action is drawn 
 right below the label. That is where I would put it as well. But in this 
 case, I think the separator should then be drawn below the primary option 
 (see activity_palette_2.png).

Yes, for this case I think that's a reasonable amendment. The only other 
variation for this that came to mind would be to make the primary action text 
bold (as adding/moving separators might not always be the right treatment).

 Doing the same for the Volume Palette will look odd (volume_palette_2.png) as 
 we have also a separator below the 'Remove' option as this is the Palette 
 content (the progress bar showing how much space is left). Three horizontal 
 lines in one Palette is just too much.

Agreed, separators allow grouping/structure, putting separators between every 
item does not help, and is not a visual improvment.

 On a related note: actually we should show the 'Show content' option in the 
 Volume Palette in the Journal as well. I think it is right to leave the 
 primary action there, clicking on the icon it is to switch views. But the 
 primary action should be present in the Palette as well, same as we do in the 
 Activity Palettes in the Frame where the primary action is 'Resume' and it is 
 shown as well in the Palette.

+1

Regards,
--Gary

 Regards,
  Simon
 activity_palette_1.png
 activity_palette_2.png
 volume_palette_2.png

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

Re: [Sugar-devel] [DESIGN] Frame Device icon Volumes

[Gary Martin]

Hi Simon,

On 16 Aug 2012, at 09:44, Simon Schampijer si...@schampijer.de wrote:

 Hi,
 
 working on the 'reveal palette on left click' behavior change for the Frame 
 device icons [1] I came across the following behavior for the Volumes device 
 icons:
 
 - when you click on the icon it will resume the Journal and show the contents 
 of the volume
 
 - if you reveal the Palette (right click or hover) you get the Palette (see 
 screen-shot):
 
 [Label]
 [Remove option]
 [info about free space]
 
 
 I think there are two issues with the current behavior:
 
 - the primary action which triggers the 'show content' is not reflected in 
 the Palette, if you bring up the Palette you can not find that action in the 
 Palette, this is about discover-ability
 
 - secondly as we are currently moving to the behavior for bringing up the 
 Palette on left click for the device icons it makes sense to be consistent 
 here, so I would remove the primary action from the button, hence on left 
 click reveal the Palette containing the 'Show content' option like we have 
 for the Journal as first item in the Palette

+1 to removal of the primary action, adding 'Show content' to the palette, and 
bringing up the palette on a left click.

Regards,
--Gary

 Regards,
   Simon
 
 PS: Maybe we can adopt the touchpad device icon as well [2]
 
 [1] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/039013.html
 [2] 
 http://git.sugarlabs.org/sugar/mainline/blobs/master/extensions/deviceicon/touchpad.py#line69
 frame_device_icon_volumes.png___
 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

Re: [Sugar-devel] Testing Rotate in sugar-jhbuild

[Gary Martin]

Hi Walter,

On 16 Aug 2012, at 16:53, Walter Bender walter.ben...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard gonz...@laptop.org wrote:
 In anybody want test how activities work with the screen rotated in
 sugar-jhbuid,
 can do in the terminal:
 
 xrandr -o left
 
 when your neck hurts, or you have finished...
 
 xrandr -o normal
 
 Gonzalo
 
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 Works great. Check out
 http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support
 rotation. But I am curious why the stop button runs off the edge... it
 would appear there is plenty of room for it.

Not sure if this is your issue (my land line has been down most of the day and 
am on GSM network), but invisible separators still take space unless you 
explicitly tell them not to:

separator.set_size_request(0, -1)

So your separator factory might need a tweak. See Physics activity.py line 103 
for a working example.

Regards,
--Gary

 
 -walter
 
 -- 
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 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

Re: [Sugar-devel] [DESIGN] Zoom to width icon

[Gary Martin]

Hi Gonzalo,

On 15 Aug 2012, at 13:13, Gonzalo Odiard gonz...@laptop.org wrote:

 Gary,
 
 Here is the icon I am using in Read.
 Comments welcomed

Fab thanks. Looks good :)

Please find the attached clean up version removing all the inkscape xml junk an 
unnecessary tags. Should go into sugar-artwork with the others.

Note that I've not reviewed Daniels ML proposal yet to remove certain grey fill 
from some of the artwork icons (zoom ones specifically), so we may need revisit 
this (and others) at some point, though your icon is consistent with the 
current icons right now for landing it.

Regards,
--Gary

 Gonzalo
 zoom-to-width.svg

inline: zoom-to-width.svg___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings - About My Computer

[Gary Martin]

On 15 Aug 2012, at 20:14, Walter Bender walter.ben...@gmail.com wrote:

 On Sun, Aug 12, 2012 at 8:48 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Anish,
 
 I've uploaded a mockup image to the wiki [1] which covers most of the items 
 raised in this thread:
 
 - a new security section (that should only be shown if there is lease 
 information)
 - lease number of days remaining
 - lease absolute expiry date (date string should use correct formatting to 
 display locale date format)
 
 Did I miss anything?
 
 One nit: There is no such thing as Sugar Labs Inc. Should be: Sugar
 Labs, a member project of the Software Freedom Conservancy.

Good catch, this mockup was based on a quick screen grab of the soon to be 
released 12.1, and wasn't aware of it being updated recently. Hmmm. Not sure 
who I'd need to bother to correct the license text.

Regards,
--Gary

 
 regards.
 
 -walter
 
 Regards,
 --Gary
 
 [1] 
 http://wiki.sugarlabs.org/go/File:Settings_About_My_Computer_Security_Section_Mockup.png
 
 On 7 Aug 2012, at 17:55, Anish Mangal an...@activitycentral.com wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi Daniel,
 
 Thanks for replying!
 
 On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote:
 On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal
 an...@activitycentral.com wrote:
 One problem they were also trying to get around in Paraguay is
 that during vacations, the kids don't go to the schools and hence
 the leases expire. If the kids also know about this information,
 then they can easily make sure that they don't get 'locked out'
 
 You'd hope that the project would make provisions for long-enough
 leases to be supplied before the vacations. But I can see the use
 for this for when that doesn't happen (which is understandable
 given high workloads and so on).
 
 Talking more with the team in Nicaragua, this functionality would
 be useful for them too. Similar situations are occuring here where
 laptops were activated for a certain amount of time, with the
 strong expectation that internet connectivity would become
 available in the schools before the activations expire (so that
 they can be automatically updated/renewed). These expectations look
 like they won't turn out to be true :(
 
 So a manual activation update process will happen and the ability
 for someone less-technical to be able to quickly check whether this
 manual update process has completed OK would be of value (that
 would be the person's only contact with activations - we aren't
 expecting them to be able to solve any problems if the results are
 bad, other than report up the chain).
 
 
 This is exactly the kind of clear info that should have been in the
 feature page in the first place. Sorry for not doing it earlier.
 
 Anyway, the use cases you describe in your mail don't seem to be
 described on the feature page. Could you please extend the feature
 page to go into more detail about this? I'll then add the above
 local case if its of interest.
 
 
 +1
 
 
 Why is the proposal to show the number of days remaining?
 
 
 Yes, I remember discussing specifically this with Roberto (PyEduca
 Technical head) back in Dec 2010, and my suggestion was exactly the
 same (to display the date).
 
 However, as per them (and I know this is not a rational explanation),
 they wanted us to display no of days remaining.
 
 The Nicaraguan team have expressed a strong preference that this
 should (instead, or additionally) display the expiry date. When
 dealing with long duration activations, which is often the case
 (until good connectivity is established), having a teacher phone up
 and say there are 137 days remaining (and then having to
 calculate the day of expiry in order to put an appropriately timed
 school visit on the calendar) would be a pain.
 
 
 I agree with this, and since I cannot seem to remember exactly why
 they wanted it to display in terms of no. of days remaining, I'll ping
 them or we can go with this.
 
 Since this feature is only relevant for the XO at the moment,
 making use of the bitfrost API would be acceptable to me, but I
 don't see a lot wrong here by parsing the lease.sig directly.
 This file is supposed to be automatically generated/updated in
 normal use cases.
 
 Are you planning to parse sig02 (delegated leases) by hand as
 well? What if the lease is corrupt in some way?
 
 I can see myself objecting to any implementation of this that
 doesn't reuse bitfrost. It takes care of all of the corner cases
 and will avoid code duplication.
 
 
 Again, it seemed to solve the use case we had in Paraguay, and the
 idea behind upstreaming a feature is that it goes through this process
 of review. I am up for changing the code to use the bitfrost api. It
 should not be complex (if it's adequately documented somewhere).
 
 Daniel ___ Sugar-devel
 mailing list Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 - --
 Anish

Re: [Sugar-devel] [DESIGN] higher-resolution thumbnails

[Gary Martin]

On 13 Aug 2012, at 17:38, Walter Bender walter.ben...@gmail.com wrote:

 I have a proposal from the learning team regarding the resolution of
 the thumbnail images in the Journal. They'd like the thumbnails to be
 of a higher resolution, both for the detail view in the Journal and in
 the Portfolio activity. The motivation is that the current resolution
 (300x225) is not sufficient to see important details, such as the text
 in a Write document, the layout of a Mindmap (Labrynth), or the blocks
 in a Turtle Art project.
 
 The tradeoff is primarily one of storage space, although there maybe
 some potential workarounds, such as having a way to ask an activity to
 generate a thumbnail on the fly.

+1 though this is raises the question of what resolution would be good enough. 
Ideally we would store images at the full display resolution, and try to 
minimise the storage space tradeoff by being more aggressive on compression. 
This would also open up an option for the illusion of fast starting Activities. 
iOS relies on this quite heavily as you start and switch between images, you're 
often looking at a transition animation and the static screen shot for a number 
of seconds (maybe 4 or 5 in some cases) while the actual code is still starting 
in the background.

Regards,
--Gary

 regards.
 
 -walter
 
 -- 
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 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

Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

Hi Ajay,

On 14 Aug 2012, at 11:51, Ajay Garg a...@activitycentral.com wrote:

 Hi Gary, Anish, Gonzalo.
 
 The impatient UI-interaction bug has been fixed via ::
 http://git.sugarlabs.org/dextrose/mainline/commit/e34ba2bc5554621a7770c8f5960f257bff9787f8
 
 The latest sugar-rpm (containing the fix) can be found at ::
 http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-14th-august/sugar-0.94.1-31.dx3.noarch.rpm
 
 
 Please test on the dextrose image as usual :)

Thanks. have just been testing an bumped into this new issue with the Journal 
UI is locking during a batch operation. You can't interact with error alerts:


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

Regards,
--Gary

 
 
 Thanks and Regards,
 Ajay
 
 
 
 On Tue, Aug 14, 2012 at 8:59 AM, Gonzalo Odiard gonz...@laptop.org wrote:
 Probably have sense blocking the Journal ui (and show a clock cursor)
 when doing a slow operation.
 
 Gonzalo
 
 
 On Mon, Aug 13, 2012 at 11:27 PM, Anish Mangal an...@activitycentral.com 
 wrote:
 There seem to be many bugs where something 'ugly' happens when
 something is clicked while an operation is happening.
 
 Can't we just lock all UI actions *while* batch operations are taking
 place (and only have an abort/cancel button)? Of course, this might be
 harder said than done, and might not be the best way codewise (was
 just thinking in terms of UX)
 
 On Tue, Aug 14, 2012 at 4:34 AM, Gary Martin garycmar...@googlemail.com 
 wrote:
  Thanks Ajay,
 
  On 13 Aug 2012, at 07:05, Ajay Garg a...@activitycentral.com wrote:
 
  Hi Gary.
 
  Made the change via the patch ::
  http://git.sugarlabs.org/dextrose/mainline/commit/d9426b3b0be8249110d3073015d2514402734930
 
  That's a much smaller code change than mine ;)
 
  The latest sugar-rpm can be found at ::
  http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-13th-august/sugar-0.94.1-31.dx3.noarch.rpm
 
 
  Please test with it, on your dextrose image as usual :)
 
  Have found a new nasty bug. If, while a batch operation is in progress, you 
  uncheck some items, multi-select gets rather unhappy. My test case:
 
  1) copy ~100 items over to the Documents folder
  2) switch to view the Documents folder
  3) check an entry and the select all
  4) scroll down a few pages
  5) click Erase
  6) confirm the Erase
  7) uncheck some entries while the batch is running
  8) wait for Erase batch to complete
 
  Result: I now see the Toolbar hint that says Selected 3 of 100 (I 
  unchecked 3 items during the Erase batch operation), however all ~100 items 
  are still displayed and shown checked. I then clicked Select all and got a 
  spinning cursor and a seemingly stalled Journal stuck in multi-select mode. 
  As I moved the cursor over the list area the activity icons started to 
  redraw in black and white (no more ownership stroke and fill colour, I 
  guess due to catching up with erased metadata). Needed to reboot Sugar to 
  recover, and on checking Documents all items had been erased.
 
  You can get into similar multi-select stalls by being 'impatient' with the 
  UI:
 
  1) select ~100 items
  2) click erase
  3) confirm erase
  4) click Deselect all while the batch is still running
 
  I'll post the shell log to you in a separate email.
 
  Regards,
  --Gary
 
  Thanks and Regards,
  Ajay
 
  On Mon, Aug 13, 2012 at 5:24 AM, Gary Martin garycmar...@googlemail.com 
  wrote:
  Hi Ajay,
 
  On 12 Aug 2012, at 20:30, Gary Martin garycmar...@gmail.com wrote:
 
   Hi Ajay,
  
   On 8 Aug 2012, at 10:42, Ajay Garg a...@activitycentral.com wrote:
  
   Hi Gary.
  
   Please find the link, for the latest sugar-rpm, that contains the 
   fixes/changes, as per the 3 action-items marked for me, in 7th August's 
   design-meeting ::
   http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix-plus-3-more-7th-august-action-items/sugar-0.94.1-31.dx3.noarch.rpm
  
   For brevity, here are the action items, and the corresponding patches ::
  
   #action improve batch tick redraw-intervals (ajay)
   http://git.sugarlabs.org/dextrose/mainline/commit/cdcf2717fe4bdd42cdbb632c51b0b371e2e3352f
  
   Spotted one case here, in line 96:
  
 if (current_entry_number % twenty_percent_of_total_items) == 0:
  
   If there are only a small number of items (e.g. 11) being batched 
   operated on then it redraws too frequently (in ~2 at a time for 11 
   entries), so is quite slow. Batch operations should be in blocks of 10 
   or more at a time (unless there are less than 10 items in which case do 
   them all at once). This also means your test at line 80 isn't being 
   usefully triggered and I think can be removed (as far as I can tell, 
   please test).
  
   The test case at line 96 should be something like:
  
 if min (total_items, max (10, (current_entry_number % 
   twenty_percent_of_total_items))) == 0:
 
  Sorry that test case for line 96 made little sense! Second attempt

Re: [Sugar-devel] [DESIGN] Visual clue about secondary options

[Gary Martin]

Hi Gonzalo,

On 13 Aug 2012, at 16:38, Gonzalo Odiard gonz...@laptop.org wrote:

 Looking at the ticket SL #3752 [1] Add page-based viewing functionality
 I found again a old problem we have not solved.
 
 If one button have a menu, is displayed pressing the secondary button,
 but the user does not have any clue about the existence of this menu.
 In the toolbar, when a button have a sub-toolbar attached, a triangle is 
 displayed,
 and I think works ok.
 
 Can we implement a similar visual signal to show there are a menu available 
 if the user press the secondary button? 
 With the use of touch, will be more difficult to discover these options.

+1, though we do have to consider how many places will need that extra little 
visual e.g. every AP, Ad-Hoc, Buddy, Activity icon in all the shell views, 
Pretty much every icon on all Frame sides except for the zoom level icons. That 
is a lot of little arrows all over the UI.For the white canvas area, it could 
be not too visually messy if the canvas arrows were in a pale grey rather than 
black.

My general goal for this has been to try and convince developers NOT to 
overload icons with both primary and secondary button actions. Buttons with 
palette entries should generally always just open their palettes when clicked, 
and Buttons with primary actions should avoid having secondary actions hidden 
in palettes (with exceptions for advanced, or rarely used features where these 
users can be considered more experienced).

 May be something to talk in the next design meeting? 

Sure, I'll add it to the agenda, I have some of Simons touch related patches to 
add as well.

Regards,
--Gary

 
 Gonzalo
 
 
 [1] http://bugs.sugarlabs.org/ticket/3752
 ___
 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

Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

Thanks Ajay,

On 13 Aug 2012, at 07:05, Ajay Garg a...@activitycentral.com wrote:

 Hi Gary.
 
 Made the change via the patch ::
 http://git.sugarlabs.org/dextrose/mainline/commit/d9426b3b0be8249110d3073015d2514402734930

That's a much smaller code change than mine ;)

 The latest sugar-rpm can be found at ::
 http://people.sugarlabs.org/ajay/root/multi-select-latest-sugar-rpm-13th-august/sugar-0.94.1-31.dx3.noarch.rpm
 
 
 Please test with it, on your dextrose image as usual :)

Have found a new nasty bug. If, while a batch operation is in progress, you 
uncheck some items, multi-select gets rather unhappy. My test case:

1) copy ~100 items over to the Documents folder
2) switch to view the Documents folder
3) check an entry and the select all
4) scroll down a few pages
5) click Erase
6) confirm the Erase
7) uncheck some entries while the batch is running
8) wait for Erase batch to complete

Result: I now see the Toolbar hint that says Selected 3 of 100 (I unchecked 3 
items during the Erase batch operation), however all ~100 items are still 
displayed and shown checked. I then clicked Select all and got a spinning 
cursor and a seemingly stalled Journal stuck in multi-select mode. As I moved 
the cursor over the list area the activity icons started to redraw in black and 
white (no more ownership stroke and fill colour, I guess due to catching up 
with erased metadata). Needed to reboot Sugar to recover, and on checking 
Documents all items had been erased.

You can get into similar multi-select stalls by being 'impatient' with the UI:

1) select ~100 items
2) click erase
3) confirm erase
4) click Deselect all while the batch is still running 

I'll post the shell log to you in a separate email.

Regards,
--Gary

 Thanks and Regards,
 Ajay
 
 On Mon, Aug 13, 2012 at 5:24 AM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Ajay,
 
 On 12 Aug 2012, at 20:30, Gary Martin garycmar...@gmail.com wrote:
 
  Hi Ajay,
 
  On 8 Aug 2012, at 10:42, Ajay Garg a...@activitycentral.com wrote:
 
  Hi Gary.
 
  Please find the link, for the latest sugar-rpm, that contains the 
  fixes/changes, as per the 3 action-items marked for me, in 7th August's 
  design-meeting ::
  http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix-plus-3-more-7th-august-action-items/sugar-0.94.1-31.dx3.noarch.rpm
 
  For brevity, here are the action items, and the corresponding patches ::
 
  #action improve batch tick redraw-intervals (ajay)
  http://git.sugarlabs.org/dextrose/mainline/commit/cdcf2717fe4bdd42cdbb632c51b0b371e2e3352f
 
  Spotted one case here, in line 96:
 
if (current_entry_number % twenty_percent_of_total_items) == 0:
 
  If there are only a small number of items (e.g. 11) being batched operated 
  on then it redraws too frequently (in ~2 at a time for 11 entries), so is 
  quite slow. Batch operations should be in blocks of 10 or more at a time 
  (unless there are less than 10 items in which case do them all at once). 
  This also means your test at line 80 isn't being usefully triggered and I 
  think can be removed (as far as I can tell, please test).
 
  The test case at line 96 should be something like:
 
if min (total_items, max (10, (current_entry_number % 
  twenty_percent_of_total_items))) == 0:
 
 Sorry that test case for line 96 made little sense! Second attempt:
 
 if current_entry_number % max(10, twenty_percent_of_total_items) == 
 max(10, twenty_percent_of_total_items) - 1:
 
 So this should refresh the list no more frequently than every 10th entry 
 processed, and when there are  50 entries the 20% starts to have an effect 
 on the distance between updates so that not too much time is wasted redrawing 
 when there are many entries being batch processed.
 
 Your test case at line 80 should stay so that at least the first page of 
 entries gets a reasonably quick update if there are many entries being 
 processes, and your clause at line 86 for redrawing at the last entry covers 
 the case for when there are  10 items.
 
 Apologies,
 --Gary
 
 
  Regards,
  --Gary
 
  #action change status strings to normal case and remove braces and / for 
  friendly language (ajay)
  http://git.sugarlabs.org/dextrose/mainline/commit/767074994a0ea7f8356a1feafb7f2becae1b49f3
 
  #action make Stop aleart before batch operations really stop the batch 
  operation (ajay)
  http://git.sugarlabs.org/dextrose/mainline/commit/f4ab20a311e5090aca2e1d757c6433eb19c5522a
 
 
  Please test as usual, on the dx3ng147 image :)
 
  Also, please let know for further feedback, on the mailing-list itself. 
  The next Tuesday is still 6 days away :D :D
 
 
  Thanks and Regards,
  Ajay
 
 
  On Mon, Aug 6, 2012 at 3:13 PM, Ajay Garg a...@activitycentral.com wrote:
  Hi Gary.
 
  Finally... the checkbox-issue has been solved :)
 
  Please find the fixed rpm, containing the checkbox-fix at
  http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix/sugar-0.94.1-31.dx3.noarch.rpm
 
  For brevity

Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

 ::
 
 * Stop - This stops the batch-operation there and then.
 
 * Continue - Proceed forward with the next journal entry.
 
 
 
 g)
 As seen in f), the Ok of the error-alert has been replaced (only textually) 
 by Continue.
 
 
 
 h)
 There were exceptions of the form KeyError: 'keep' occuring in logs. 
 This was due to some cases, wherein keep property was not present in a 
 particular journal entry.
 
 So now, as a fix, we first check if keep is a valid metadata-key. If yes, 
 we read its value to gauge favorite-status.
 Else, we assume that the journal-entry is an unfavorite by default.
 
 
 
 i)
 VERY IMPORTANT NOTE ::
 
 Renaming a journal-entry (by clicking and modifying the contents of the 
 title-cell, has been disabled functionally.
 This is because, the following happens when a rename is done in the 
 Documents view ::
 
 * Initially, the UID is same as the path of the entry in Documents.
 
 * User changes the name. The change is written on the DS, and the UID 
 changed.
 
 * Now, since refresh is inhibited in multi-select view, we need to fetch 
 the new value of the title from the DS.
   This requires the UID, through which the UID could be fetched. Since 
 the name of the Documents journal-entry has
   changed, so has its UID. But in the memory, the old UID still resides. 
 Fetching the new title from the old UID does not
   work.
 
   Now, I tried disabling the renaming while rendering the listview, but 
 that could not be done, as rendering th listview requires
   knowing whether we are in multi-select mode, while multi-select mode is 
 set, after the listview is rendered. So, we are in a catch-22
   situation.
 
 So, the way it works now in multi-select mode ::
 
 * User is apparently able to edit the title, but that is all what happens.
   There is no efective change - neither in backend, nor in frontend.
 
 In the normal view, the renaming works as usual.
 
 
 ==
 
 
 PENDING CHANGES ::
 
 a)
 As explained in point i) above, the renaming will not work, while in 
 multi-select mode (however, the bug you reported wherein trying to rename in
 Documents folder renders the UI unusable, has been duly fixed (of course, 
 by not allowing the renaming to happen).
 
 If this is indeed required, this will be a major change in the way we deal 
 with UIDs for non-journal mount-points. But given that renaming is affected 
 only in multi-select mode (renaming does not work at all in multi-select; 
 while it works as usual in normal-mode), I am a bit sceptical to regarding 
 this.
 
 
 
 b)
 A solution to the following bug ::
 
 
 UNRESOLVED BUG. Tick-box slow/erratic behaviour in dx3ng143 with latest rpm 
 fixes image on XO1, still needs mouse movement to redraw. This is also an 
 issue when using the Select all toobar button, as the list view tick-boxes 
 do not update until after the Select all. You have selected N entries. (Ok) 
 dialogue is clicked.
 
 still eludes me :(
 
 This is an important issue, since (although there is no unusable UX, or any 
 such major workflow blocker), the select/deselect visual feedback is an 
 important thing, that should be conveyed as soon as possible. Though Gary's 
 feedback on adding a text-widget on the top EditToolBar, does help show the 
 number of entries selected, and thus gives a textual feedback :)
 
 I would request all sugar-devel members to please post a solution to the 
 issue, for which the discussion is going on, in the thread ::
 http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038626.html
 
 
 
 Thanks and Regards,
 Ajay
 
 
 
 
 
 
 
 
 On Sat, Aug 4, 2012 at 9:59 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Ajay,
 
 
 On 4 Aug 2012, at 10:21, Ajay Garg a...@activitycentral.com wrote:
 
 On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg a...@activitycentral.com wrote:
 Thanks a ton Gary.
 This is REALLY useful :)
 
 Fab :)
 
 Please find the comments inline.
 
 
 On Fri, Aug 3, 2012 at 6:29 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Ajay/Anish,
 
 On 18 Jul 2012, at 11:57, Anish Mangal an...@activitycentral.com wrote:
 
  I would like to propose the long-discussed-finally-implemented ;-)
  journal entry batch operation and multi selection feature for
  inclusion in sugar-0.98. All the necessary and relevant details should
  be present in the associated feature page:
 
  http://wiki.sugarlabs.org/go/Features/Multi_selection_screenshots
 
  AFAIK, This feature was initially brought up in discussions in EDUJam
  in 2011 and an initial implementation was made by Martin Abente. The
  current implementation, done by Ajay, has been derived from that
  keeping the UI experience largely the same while significantly
  speeding up operations like select/deselect.
 
  Should you have any design related questions about this, feel free to
  reply to this thread.
 
 At last Tuesday's design meeting we didn't make it back around to this 
 agenda item

Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

Hi Ajay,

On 12 Aug 2012, at 20:30, Gary Martin garycmar...@gmail.com wrote:

 Hi Ajay,
 
 On 8 Aug 2012, at 10:42, Ajay Garg a...@activitycentral.com wrote:
 
 Hi Gary.
 
 Please find the link, for the latest sugar-rpm, that contains the 
 fixes/changes, as per the 3 action-items marked for me, in 7th August's 
 design-meeting ::
 http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix-plus-3-more-7th-august-action-items/sugar-0.94.1-31.dx3.noarch.rpm
 
 For brevity, here are the action items, and the corresponding patches ::
 
 #action improve batch tick redraw-intervals (ajay)
 http://git.sugarlabs.org/dextrose/mainline/commit/cdcf2717fe4bdd42cdbb632c51b0b371e2e3352f
 
 Spotted one case here, in line 96:
 
   if (current_entry_number % twenty_percent_of_total_items) == 0:
 
 If there are only a small number of items (e.g. 11) being batched operated on 
 then it redraws too frequently (in ~2 at a time for 11 entries), so is quite 
 slow. Batch operations should be in blocks of 10 or more at a time (unless 
 there are less than 10 items in which case do them all at once). This also 
 means your test at line 80 isn't being usefully triggered and I think can be 
 removed (as far as I can tell, please test).
 
 The test case at line 96 should be something like:
 
   if min (total_items, max (10, (current_entry_number % 
 twenty_percent_of_total_items))) == 0:

Sorry that test case for line 96 made little sense! Second attempt:

if current_entry_number % max(10, twenty_percent_of_total_items) == 
max(10, twenty_percent_of_total_items) - 1:

So this should refresh the list no more frequently than every 10th entry 
processed, and when there are  50 entries the 20% starts to have an effect on 
the distance between updates so that not too much time is wasted redrawing when 
there are many entries being batch processed.

Your test case at line 80 should stay so that at least the first page of 
entries gets a reasonably quick update if there are many entries being 
processes, and your clause at line 86 for redrawing at the last entry covers 
the case for when there are  10 items.

Apologies,
--Gary

 
 Regards,
 --Gary
 
 #action change status strings to normal case and remove braces and / for 
 friendly language (ajay)
 http://git.sugarlabs.org/dextrose/mainline/commit/767074994a0ea7f8356a1feafb7f2becae1b49f3
 
 #action make Stop aleart before batch operations really stop the batch 
 operation (ajay)
 http://git.sugarlabs.org/dextrose/mainline/commit/f4ab20a311e5090aca2e1d757c6433eb19c5522a
 
 
 Please test as usual, on the dx3ng147 image :)
 
 Also, please let know for further feedback, on the mailing-list itself. The 
 next Tuesday is still 6 days away :D :D
 
 
 Thanks and Regards,
 Ajay
 
 
 On Mon, Aug 6, 2012 at 3:13 PM, Ajay Garg a...@activitycentral.com wrote:
 Hi Gary.
 
 Finally... the checkbox-issue has been solved :)
 
 Please find the fixed rpm, containing the checkbox-fix at
 http://people.sugarlabs.org/ajay/root/multi-select-with-checkbox-fix/sugar-0.94.1-31.dx3.noarch.rpm
 
 For brevity, here is the patch link ::
 http://git.sugarlabs.org/dextrose/mainline/commit/381e706de7e7309d27a44ed064794a44d50aad4a
 
 The sugar-toolkit rpm remains the same as before.
 
 
 
 So, in addition to the a) - i) points of the previous mail, I add the next 
 point ::
 
 j)
 Now there is prompt feedback of checking/unchecking the checkboxes and 
 favorite-icons.
 
 However, note that for favorite-icons, there is a logical hinderance to
 true prompt feedback, as described in http://bugs.sugarlabs.org/ticket/3147.
 
 Checkboxes' feedbacks work perfectly !!
 
 
 
 Thanks and Regards,
 Ajay
 
 
 
 On Sun, Aug 5, 2012 at 12:02 PM, Ajay Garg a...@activitycentral.com wrote:
 Hi Gary.
 
 Please find attached the links to the fixed rpms.
 Please --upgrade --force --nodeps on the dx3ng143 image, on which you have 
 been testing.
 
 http://people.sugarlabs.org/ajay/root/multi-select/sugar-0.94.1-31.dx3.noarch.rpm
 http://people.sugarlabs.org/ajay/root/multi-select/sugar-toolkit-0.94.0-20120805.dx3.fc14.i386.rpm
 
 
 For brevity, the patches are at ::
 http://git.sugarlabs.org/dextrose/mainline/commit/38a261887ed44756147bae44277642252cae628f
 http://git.sugarlabs.org/dextrose/mainline/commit/0c71cf00dfb8fe507627109748b5539e0eeba87f
 
 
 
 Following are the changes/fixes ::
 All courtesy you :)
 
 
 
 
 a)
 'Select none' renamed as 'Deselect all'.
 
 
 
 b)
 Now, a text-widget has been added to the top of EditToolBar.
 This serves the following two purposes ::
 
 
* The widget is supposed to display only one line, at ANY time.
 
* Usually, while in multi-select mode, it will display x of 97 
 selected, where x is the number of entries currently selected,
  and 97 is assumed to be the total number of entries.
 
 
  Here, as we select/deselect by single-click, or select all/deselect 
 all button,  the update happens consequently.
 
  So, as is obvious, this modification helps show

Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings - About My Computer

[Gary Martin]

Hi Anish,

I've uploaded a mockup image to the wiki [1] which covers most of the items 
raised in this thread:

 - a new security section (that should only be shown if there is lease 
information)
 - lease number of days remaining
 - lease absolute expiry date (date string should use correct formatting to 
display locale date format)

Did I miss anything?

Regards,
--Gary

[1] 
http://wiki.sugarlabs.org/go/File:Settings_About_My_Computer_Security_Section_Mockup.png

On 7 Aug 2012, at 17:55, Anish Mangal an...@activitycentral.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi Daniel,
 
 Thanks for replying!
 
 On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote:
 On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal
 an...@activitycentral.com wrote:
 One problem they were also trying to get around in Paraguay is
 that during vacations, the kids don't go to the schools and hence
 the leases expire. If the kids also know about this information,
 then they can easily make sure that they don't get 'locked out'
 
 You'd hope that the project would make provisions for long-enough 
 leases to be supplied before the vacations. But I can see the use
 for this for when that doesn't happen (which is understandable
 given high workloads and so on).
 
 Talking more with the team in Nicaragua, this functionality would
 be useful for them too. Similar situations are occuring here where 
 laptops were activated for a certain amount of time, with the
 strong expectation that internet connectivity would become
 available in the schools before the activations expire (so that
 they can be automatically updated/renewed). These expectations look
 like they won't turn out to be true :(
 
 So a manual activation update process will happen and the ability
 for someone less-technical to be able to quickly check whether this
 manual update process has completed OK would be of value (that
 would be the person's only contact with activations - we aren't
 expecting them to be able to solve any problems if the results are
 bad, other than report up the chain).
 
 
 This is exactly the kind of clear info that should have been in the
 feature page in the first place. Sorry for not doing it earlier.
 
 Anyway, the use cases you describe in your mail don't seem to be 
 described on the feature page. Could you please extend the feature 
 page to go into more detail about this? I'll then add the above
 local case if its of interest.
 
 
 +1
 
 
 Why is the proposal to show the number of days remaining?
 
 
 Yes, I remember discussing specifically this with Roberto (PyEduca
 Technical head) back in Dec 2010, and my suggestion was exactly the
 same (to display the date).
 
 However, as per them (and I know this is not a rational explanation),
 they wanted us to display no of days remaining.
 
 The Nicaraguan team have expressed a strong preference that this 
 should (instead, or additionally) display the expiry date. When 
 dealing with long duration activations, which is often the case
 (until good connectivity is established), having a teacher phone up
 and say there are 137 days remaining (and then having to
 calculate the day of expiry in order to put an appropriately timed
 school visit on the calendar) would be a pain.
 
 
 I agree with this, and since I cannot seem to remember exactly why
 they wanted it to display in terms of no. of days remaining, I'll ping
 them or we can go with this.
 
 Since this feature is only relevant for the XO at the moment,
 making use of the bitfrost API would be acceptable to me, but I
 don't see a lot wrong here by parsing the lease.sig directly.
 This file is supposed to be automatically generated/updated in
 normal use cases.
 
 Are you planning to parse sig02 (delegated leases) by hand as
 well? What if the lease is corrupt in some way?
 
 I can see myself objecting to any implementation of this that
 doesn't reuse bitfrost. It takes care of all of the corner cases
 and will avoid code duplication.
 
 
 Again, it seemed to solve the use case we had in Paraguay, and the
 idea behind upstreaming a feature is that it goes through this process
 of review. I am up for changing the code to use the bitfrost api. It
 should not be complex (if it's adequately documented somewhere).
 
 Daniel ___ Sugar-devel
 mailing list Sugar-devel@lists.sugarlabs.org 
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 - -- 
 Anish Mangal
 Dextrose Project Manager
 Activity Central
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iQEcBAEBAgAGBQJQIUh6AAoJEBoxUdDHDZVpEX8H/j5oCzGUvnfIWdy1f/awAnkf
 Trtsm4Me8r2D0ufxEyIZkUHugCQPUTdPqDEAlexr8ziQjy8mqNLrbvEWwwxxl4ho
 XstY7RZsk9gPGVYiE1bLniIZnO5e63lIyBEkM3eNgkHrO8XTPw86lBBcTcx9XDrx
 T00HW8J1UGDMo29SRcrnxnNVd6j+uArJXcaeSXhLAPb3xkaharF22AbTlWgQ+4s5
 YIzvIfmEYMpqXbCCY+IPSVxzcpdRuHhueaFKchDfzRm01Wf77laACUg6+ZFkq/Ft
 

Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

Hi Ajay,

On 4 Aug 2012, at 10:21, Ajay Garg a...@activitycentral.com wrote:

 On Fri, Aug 3, 2012 at 8:53 PM, Ajay Garg a...@activitycentral.com wrote:
 Thanks a ton Gary.
 This is REALLY useful :)

Fab :)

 Please find the comments inline.
 
 
 On Fri, Aug 3, 2012 at 6:29 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Ajay/Anish,
 
 On 18 Jul 2012, at 11:57, Anish Mangal an...@activitycentral.com wrote:
 
  I would like to propose the long-discussed-finally-implemented ;-)
  journal entry batch operation and multi selection feature for
  inclusion in sugar-0.98. All the necessary and relevant details should
  be present in the associated feature page:
 
  http://wiki.sugarlabs.org/go/Features/Multi_selection_screenshots
 
  AFAIK, This feature was initially brought up in discussions in EDUJam
  in 2011 and an initial implementation was made by Martin Abente. The
  current implementation, done by Ajay, has been derived from that
  keeping the UI experience largely the same while significantly
  speeding up operations like select/deselect.
 
  Should you have any design related questions about this, feel free to
  reply to this thread.
 
 At last Tuesday's design meeting we didn't make it back around to this agenda 
 item, so here's my feedback/notes after testing the DX3 image with the new 
 rpms:
 
 - FIXED. Once in multi-select mode, the favourite stars no longer visibly 
 updates, though changes update later once multi-select mode is exited.
 
 Great !!
 
 
  
 
 - FIXED. Auto deselection after batch operation.
 
 Great !!
 
 
  
 
 - UNRESOLVED BUG. Tick-box slow/erratic behaviour in dx3ng143 with latest rpm 
 fixes image on XO1, still needs mouse movement to redraw. This is also an 
 issue when using the Select all toobar button, as the list view tick-boxes 
 do not update until after the Select all. You have selected N entries. (Ok) 
 dialogue is clicked.
 
 Yep.. this is becoming a real pain.
 I have tried the solutions listed at 
 http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038626.html, but 
 none seem to work :-\
 Anyways, I am still trying ..
 
 [Ajay ACTION 1] : Fix this.
 
 
  
 
 - NEW BUG. Renaming an entry while in multi-select mode does not display the 
 name change, only updates the name displayed after multi-select mode is 
 exited.
 
 Thanks. Reproduced the bug at my side.
 
 [Ajay ACTION 2] : Will fix.
 
 
  
 
 - NEW BUG. If you rename while in multi-select and then try to copy, the 
 entry can't be copied and raises an error Entries without a filename cannot 
 be copied.
 
 Hmm.. I think this is a false-negative.
 I tried the following ::
 
   * Entered multi-select mode.
 
   * Selected an entry (by ticking the check-box).
 
   * Re-named the entry (however, the rename was not immediately 
 visible, due to the above bug).
 
   * Copied the entry to Documents.
 
   * Exited multi-select mode.
 
   * Clicked Documents icon.
 
   * The entry (WITH THE MODIFIED NAME) was present.
 
 I guess the error message Entries without a file cannot be copied occurred 
 on an entry, that would have anyways given this message, even if you hadn't 
 renamed the entry.
 
 [Gary ACTION 1] : Please let me know if you still face the error :)

OK, sorry I must have missed an extra step (I can't reproduce this just now). 
Will email you if I can find a reliable way to reproduce it.

However, I seem to have found a more nasty bug, while trying to test... Switch 
to the Journal Documents view; select an item; rename the selected item; the 
selected item will be deselected – though you'll still be in multi-select mode 
(but with nothing selected); click the toolbar button Select none; Journal will 
now be in a bad/unusable state, spinning busy cursor, can't escape multi select 
mode, shell log shows tracebacks IOError: Couldn't open metadata directory. I 
needed to restart Sugar to get back to normal. I'll post some shell logs in a 
separate email to you.

 - UNRESOLVED DESIGN QUESTION. Should filters continue to work once in 
 multi-select mode e.g: Filter for star favourite items in Journal; multi 
 select all stared items; un-favourite some entries while in multi-select 
 mode. Should they be removed from the multi-select view, or stay? Currently 
 they stay, but this causes a visual 'jump' when exiting multi-select mode as 
 the initial filter is re-applied to the view. Same issue if filtering the 
 Journal by title, and you rename some entries while in multi-select mode.
 
 Well, I would say not to effect the change during multi-select mode, because 
 of the following reasons ::
 
   * Currently, the code is tightly bound to having the current 
 listmodel entries in the cache. 
 A re-fresh, would cause the cached entries to be 
 re-distributed, requiring a very major code change.
 
   * The original motive of allowing the user to set/unset 
 favorite status

Re: [Sugar-devel] [DESIGN] Proposal: Multi-Selection and Batch Operations on Journal entries

[Gary Martin]

Hi Ajay/Anish,

On 18 Jul 2012, at 11:57, Anish Mangal an...@activitycentral.com wrote:

 I would like to propose the long-discussed-finally-implemented ;-)
 journal entry batch operation and multi selection feature for
 inclusion in sugar-0.98. All the necessary and relevant details should
 be present in the associated feature page:
 
 http://wiki.sugarlabs.org/go/Features/Multi_selection_screenshots
 
 AFAIK, This feature was initially brought up in discussions in EDUJam
 in 2011 and an initial implementation was made by Martin Abente. The
 current implementation, done by Ajay, has been derived from that
 keeping the UI experience largely the same while significantly
 speeding up operations like select/deselect.
 
 Should you have any design related questions about this, feel free to
 reply to this thread.

At last Tuesday's design meeting we didn't make it back around to this agenda 
item, so here's my feedback/notes after testing the DX3 image with the new rpms:

- FIXED. Once in multi-select mode, the favourite stars no longer visibly 
updates, though changes update later once multi-select mode is exited. 

- FIXED. Auto deselection after batch operation.

- UNRESOLVED BUG. Tick-box slow/erratic behaviour in dx3ng143 with latest rpm 
fixes image on XO1, still needs mouse movement to redraw. This is also an issue 
when using the Select all toobar button, as the list view tick-boxes do not 
update until after the Select all. You have selected N entries. (Ok) dialogue 
is clicked.

- NEW BUG. Renaming an entry while in multi-select mode does not display the 
name change, only updates the name displayed after multi-select mode is exited.

- NEW BUG. If you rename while in multi-select and then try to copy, the entry 
can't be copied and raises an error Entries without a filename cannot be 
copied.

- UNRESOLVED DESIGN QUESTION. Should filters continue to work once in 
multi-select mode e.g: Filter for star favourite items in Journal; multi select 
all stared items; un-favourite some entries while in multi-select mode. Should 
they be removed from the multi-select view, or stay? Currently they stay, but 
this causes a visual 'jump' when exiting multi-select mode as the initial 
filter is re-applied to the view. Same issue if filtering the Journal by title, 
and you rename some entries while in multi-select mode.

- FEEDBACK. In multi-select mode the toolbar button string 'Select none' would 
be better renamed as 'Deselect all'.

- TESTING. A loaded Journal with ~100 items, and a USB stick with 900+ items 
was tested. Selecting individual items one by one is reasonable (ignoring the 
above unresolved redraw/event bug). Batch selecting, deselecting, erasing 
operations are pretty quick (batch feedback progress is helpful especially for 
the 900+ item case). Batch copying is the slowest operation (as to be 
expected), feedback progress here is essential for even a few items.

- FEEDBACK. In the primary multi-select toolbar, add a separator and text 
widget to show how many items are selected, and how many are in the current 
multi-select view e.g. Selected 3 of 123 so the current multi-select state is 
always visible to the user. This same widget can be used for progress feedback 
during batch operations e.g. Copying 9 of 22: title, Erasing 3 of 15: 
title, Deselecting 5 of 17. This removes the need for all progress alerts 
during batch operations, see below.

- FEEDBACK. {confirmation_before, progress, confirmation_after}
... select_none {N, N, N}
... select_all {N, N, N}
... erase {Y, N, N}
... copying {Y, N, N} 

- FEEDBACK. We should allow a user to abort a batch operation when an error 
occurs. Use cases, encountering many errors during a batch operation when a 
volume runs out of space, or becomes unavailable. One solution on other 
platforms is a check box for in the error dialogues [√] Apply to all (to 
ignore future errors of this type during this batch process), and/or an 
additional button Stop. I'd suggest our batch operation errors dialogues add 
a Stop button to allow aborting the batch process, and that the current Ok 
button is renamed Continue to be more clear.

- UNRESOLVED DESIGN QUESTION. Do we want to allow a user to abort a batch 
operation while it is in progress? Use case, copying/erasing many items over a 
slow network, or usb device, and deciding if it is not worth the wait. I think, 
for now, we can avoid this extra UI work as the batch features do provide the 
option to cancel before they begin. We should revisit this if it turns out to 
be a frustration for users. The UI design would likely be to add the cancel 
icon (X) to the primary toolbar while a batch operation is in progress.

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

Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings - About My Computer

[Gary Martin]

On 2 Aug 2012, at 12:50, Gonzalo Odiard gonz...@laptop.org wrote:

 
 On this point, the code seems to not behave you describe
   above. Testing on an XO-1, the DX3 build 143 International, I see
   an item in the Identity section saying Lease: Not available. The
   wording Not available suggests something is missing from my XO
   when actually this machine does not need a lease, and is
   unsecured, this line of information should not be displayed at all
   to the user.
 
 
   
 
 
 
 Yes, that is correct. That change will be made when the code is ported over 
 to mainline.
 
 
 Maybe you can put this information in a Security section instead of 
 Identity,
 and show it only if needed?

+1, sounds like a reasonable choice. Could also be a fair place for future 
patches to add security related information on things like root access 
available/unavailable, OFW prompt enabled/disabled, signed/unsigned build.

--Gary

 Gonzalo

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

Re: [Sugar-devel] [ANNOUNCE] Design meeting Tuesday July 31st 2012 - 16:30 UTC 1hr

[Gary Martin]

Hi Martin,

On 31 Jul 2012, at 15:54, Martin Abente martin.abente.lah...@gmail.com wrote:

 Hello:
 
 One of the connections in my flight got moved so I won't be able to assist to 
 this meeting ;/
 
 Regarding the examples objects support, I would appreciate feedback on 
 possible designs for this feature i,e: if we should use an special toolbar 
 button to access this screen or not (?), how this screen should look, or 
 whatever else you guys consider important.
 
 I would also like your opinions on this idea of simply extending the current 
 objectChooser to show the activity examples folder (when opened from the 
 activity).
 
 One important thing that is missing from the design thread is to consider the 
 backward compatibility with existing version of sugar.
 
 Thank you very much in advance!

Sorry you can't make it today – yes this is the first item on the agenda, 
ideally we get some extra feedback about it and follow up back on the mail-list 
thread you've started already.

Regards,
--Gary

 tch.
 
 On Fri, Jul 27, 2012 at 1:30 PM, Gary C Martin garycmar...@googlemail.com 
 wrote:
 Hi folks,
 
 Let's try Tuesday at the slightly later time of 16:30 UTC. The plan is to 
 keep the meeting to 1 hour, or under, and use our realtime meeting to keep 
 the various design efforts ticking over and everyone who is interested up to 
 date with progress made. I'm hoping the majority of design conversation will 
 take place in mail-list design threads, wiki pages and or bug.SL.org tickets.
 
 Proposal  mail-list links for some of the below agenda items are at:
 
  http://wiki.sugarlabs.org/go/Design_Team/Meetings
 
  Provisional agenda 
 * Examples support for activities – using the ObjectChooser and/or Journal 
 volumes bar to allow access to examples folder inside activity bundles. tch
 * Lease expiry information display in My Settings - About My Computer. Anish
 * Followup on multi-selection and batch operations on Journal entries.
 * Home list view, hover highlight/click results in confusion for favourite 
 icons: See http://bugs.sugarlabs.org/ticket/3147#comment:3 Frederick
 * Your agenda item here
 
 Time: Tuesday July 31st 2012 - 16:30 UTC
 Place: #sugar-meeting
 
 Hope to see you there!
 
 Regards,
 --Gary
 
 ___
 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

Re: [Sugar-devel] [ANNOUNCE] Design meeting Tuesday July 31st 2012 - 16:30 UTC 1hr

[Gary Martin]

On 27 Jul 2012, at 18:30, Gary C Martin garycmar...@googlemail.com wrote:

 Hi folks,
 
 Let's try Tuesday at the slightly later time of 16:30 UTC. The plan is to 
 keep the meeting to 1 hour, or under, and use our realtime meeting to keep 
 the various design efforts ticking over and everyone who is interested up to 
 date with progress made. I'm hoping the majority of design conversation will 
 take place in mail-list design threads, wiki pages and or bug.SL.org tickets.
 
 Proposal  mail-list links for some of the below agenda items are at:
 
 http://wiki.sugarlabs.org/go/Design_Team/Meetings 

Thanks to those who could make it, here's the logs:

 Log: http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-07-31T16:30:26
 Minutes: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-07-31T16:30:26.html

Next meeting time will be announced later this week.

Regards,
--Gary

  Provisional agenda 
 * Examples support for activities – using the ObjectChooser and/or Journal 
 volumes bar to allow access to examples folder inside activity bundles. tch
 * Lease expiry information display in My Settings - About My Computer. Anish
 * Followup on multi-selection and batch operations on Journal entries.
 * Home list view, hover highlight/click results in confusion for favourite 
 icons: See http://bugs.sugarlabs.org/ticket/3147#comment:3 Frederick
 * Your agenda item here
 
 Time: Tuesday July 31st 2012 - 16:30 UTC
 Place: #sugar-meeting
 
 Hope to see you there!
 
 Regards,
 --Gary
 

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

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Gary Martin]

On 19 Jul 2012, at 18:40, Martin Abente wrote:

 Hello Everyone:
 
 In a recent conversation with Walter, he mentioned that it would be very 
 useful if activities could include examples objects. From my experience in 
 the field, I can tell this feature can be a really useful indeed. Therefore I 
 would like to bring this idea to the general discussion and see what others 
 think.
 
 The idea is  simple: Activities include examples objects that can be bundled 
 with and accessed from the activity.
 
 For the ones that also think this could be useful: I am sure you must have 
 your own vision of how this feature should work and look like, so please 
 share it here.
 
 In general terms and from my POV it should be something:
 
 (a) simple to access.
 (b) with a familiar interface to the users.
 (c) low-cost for activities developers to include.
 (d) Safe.
 
 One of the ideas, that meets these requirements, is to include a standard 
 Examples folder in the activities root directory that would be accessible 
 through a regular ObjetChooser. The ObjectChooser is already capable of 
 presenting any folder's contents, thanks to recent years improvement in the 
 journal to present external-media and documents-folder contents.
 
 Accessing to these objects would be as easy as just opening a ObjectChooser 
 instance, many activities already do this (but limited to journal content). 
 As I just said, the ObjectChooser interface is widely used, therefore users 
 are already familiar with it. To ease the costs for activities developers I 
 think that having this standard folder approach is crucial. One open question 
 I still have is how this ObjectChooser should  be opened from the activities 
 in a standard way (suggestions?). By safe I mean that it should guarantee 
 that it only presents this standard folder objects in read-only mode (at 
 least from the GUI POV).

Sounds good +1, we already have an icon design for activity 'collections', see 
Turtle Art for an example, but it is basically a small version of the activity 
icon, a box container with an arrow coming out of it (Walter currently raises a 
completely un-sugarised and scary GNOME file dialogue pointing inside a folder 
in the TA bundle, so it would be good to see this go ;) ).

 
 I will stop here and I would like to hear what you guys think regarding the 
 general idea first.

I've added it to the agenda for Mondays design meeting.

Regards,
--Gary

 
 Saludos.
 tincho.
 
 ___
 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

[Sugar-devel] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr

[Gary Martin]

Hi folks,

It's a quick turnaround for our next design meeting on Monday, this time 
slightly earlier at 14:30 UTC. The plan is to keep the meetings to 1 hour, or 
under, and use our realtime meeting to keep the various design efforts ticking 
over and everyone who in interested up to date with progress made. I'm hoping 
the majority of design conversation will take place in mail-list design 
threads, wiki pages and or bug.SL.org tickets.

Proposal  mail-list links for some of the below agenda items are at:

  http://wiki.sugarlabs.org/go/Design_Team/Meetings 

 Provisional agenda 
* Journal multi-select
* Touch hardware support Activities, Sugar Shell, OSK.
* Re-assessment of text-to-speech engine options, in particular think about how 
we can improve upstream voices to cover more of our languages, mail-list 
thread. cjl
* Examples support for activities – use Journal volumes strip and/or 
ObjectChooser to allow Activities to provide access to an examples folder 
inside their bundles. tch
* Lease expiry information display in My Settings - About My Computer, 
mail-list thread, wiki proposal. Anish
* your item here

Time: Monday July 23rd 2012 - 14:30 UTC 1hr
Place: #sugar-meeting

Hope to see you there!

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

Re: [Sugar-devel] [ANNOUNCE] Design meeting Wednesday July 18th 2012 - 15:00 UTC 1hr

[Gary Martin]

On 16 Jul 2012, at 14:51, Gary C Martin wrote:

 Hi folks,
 
 It's time to start reviving the IRC Design Meetings for the next Sugar 
 release cycle! The plan is to keep the meetings to 1 hour, or under, and use 
 our realtime meeting to keep the various design efforts ticking over and 
 everyone who in interested up to date with progress made. I'm hoping the 
 majority of design conversation will take place in mail-list design threads, 
 wiki pages and or bug.SL.org tickets.
 
 Links for below agenda items are on:
 
http://wiki.sugarlabs.org/go/Design_Team/Meetings 

Thanks all who could make it along today, glad we managed to keep the meeting 
close to the 1hr! Next design meeting will be on Monday 23rd July @ 1430 UTC, 
but I'll post out an announcement email with the agenda later on this week.

Minutes: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-07-18T15:00:17.html

Log: http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-07-18T15:00:17

Regards,
--Gary

  Agenda 
 * Standard Help icon and toolbar position #3746, #3721, #3720, 3759
 * Simple messages notification system
 * Database support for 3G modem configuration
 * Journal multi-select
 * Touch hardware support Activities, Sugar Shell, OSK
 * your item here
 
 Time: Wednesday July 18th 2012 - 15:00 UTC for 1hr
 Place: #sugar-meeting
 
 Hope to see you there Wednesday!
 
 Regards,
 --Gary

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

Re: [Sugar-devel] [ASLO] Problem with number of version

[Gary Martin]

Hi folks,

On 19 Jul 2012, at 00:06, Alan Jhonn Aguiar Schwyn wrote:

 
 Works. The problem is the dot in the activity version.
 Maybe all xx.x activities must will updated to xx+1

For what it's worth: Digging through git commits, dotted version number support 
was added by commit c7a80a (November 2010) and first released in Sugar 0.92.0 
(February 2011). The patch was landed as a fix for ticket Implement dotted 
activity versions to sugar #2425 [1]. The first official OLPC release with 
this change was 11.2.0 build 874 (July 20011), though not a feature I could 
find mentioned in the release notes [2].

We should not be using dotted version numbers for activities intended to be 
installed at deployments running builds older than Sugar 0.92.0.

Regards,
--Gary

[1] http://bugs.sugarlabs.org/ticket/2425
[2] http://wiki.laptop.org/go/Release_notes/11.2.0

 Regards!
 
 Alan
 
  Date: Wed, 18 Jul 2012 17:18:53 -0400
  From: walter.ben...@gmail.com
  To: alan...@hotmail.com
  CC: sugar-devel@lists.sugarlabs.org; a...@lists.sugarlabs.org
  Subject: Re: [Sugar-devel] Problem with number of version
  
  Please test v152 on git (gtk-2)
  
  -walter
  
  On Wed, Jul 18, 2012 at 2:37 AM, Alan Jhonn Aguiar Schwyn
  alan...@hotmail.com wrote:
  
   Hi,
  
   I try the TurtleBlocks 149.1 in a XO-1 with Sugar 0.88
   When install, I get this error:
  
   [olpc@xo-1e-66-9e DB1D-2012]$ sugar-install-bundle turtle_art-149.1.xo
   Traceback (most recent call last):
   File /usr/bin/sugar-install-bundle, line 17, in module
   bundle = ActivityBundle(sys.argv[1])
   File /usr/lib/python2.6/site-packages/sugar/bundle/activitybundle.py,
   line 67,
   in __init__
   self._parse_info(info_file)
   File /usr/lib/python2.6/site-packages/sugar/bundle/activitybundle.py,
   line
   130, in _parse_info
   (self._path, version))
   sugar.bundle.bundle.MalformedBundleException: Activity bundle
   turtle_art-149.1.xo
   has invalid version number 149.1
   [olpc@xo-1e-66-9e DB1D-2012]$
  
   Someone observed this problem?
  
   I read the recomendations of freeze the deployment for GTK-2 and only 
   make
   a bug
   fixes using .x versions.. But this have that problem..
  
   Regards!
  
   Alan
  
  
  
  -- 
  Walter Bender
  Sugar Labs
  http://www.sugarlabs.org
  ___
  Sugar-devel mailing list
  Sugar-devel@lists.sugarlabs.org
  http://lists.sugarlabs.org/listinfo/sugar-devel
 ___
 ASLO mailing list
 a...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/aslo

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

Re: [Sugar-devel] [ANNOUNCE] Design meeting Wednesday July 18th 2012 - 15:00 UTC 1hr

[Gary Martin]

Hi Sascha,

On 16 Jul 2012, at 15:17, Sascha Silbe wrote:

 Gary C Martin garycmar...@googlemail.com writes:
 
 It's time to start reviving the IRC Design Meetings for the next Sugar
 release cycle!
 
 Thanks for restarting the Design Team meetings!
 
 
 [...]
 Time: Wednesday July 18th 2012 - 15:00 UTC for 1hr
 Place: #sugar-meeting
 
 Unfortunately, I'm unavailable on Wed+Thu (always, not just this
 week). Is there any chance of re-scheduling to a different day of the
 week? Mon or Tue would be best, but anything other than Wed or Thu would
 work.

Darn. We're currently tied into Sugar/OLPC meetings Monday, Tuesday, Friday  
(around the ~15:00 UTC time slot which seems to be good for many folks time 
zones). Let's review a regular time slot for the next meeting once I've seen 
who makes it this week. We could possibly try an earlier meeting on Mondays – 
say at 14:30UTC – as Daniel's build release/triage meetings are not until 16:00 
UTC.

Regards,
--Gary

 Sascha
 -- 
 http://sascha.silbe.org/
 http://www.infra-silbe.de/

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

Re: [Sugar-devel] [ANNOUNCE] Design meeting Wednesday July 18th 2012 - 15:00 UTC 1hr

[Gary Martin]

Hi Gonzarlo,

On 16 Jul 2012, at 15:49, Gonzalo Odiard wrote:

 Can you advice about http://bugs.sugarlabs.org/ticket/3709

Sure, though I think I'll get to that ticket before the Wednesday meeting as 
it's been on my todo list a week or so now.

Regards,
--Gary

 Gonzalo
 

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

Re: [Sugar-devel] [PATCH sugar-artwork] Zoom icons: Removing grey fill color

[Gary Martin]

Hi Daniel,

On 13 Jul 2012, at 16:00, S. Daniel Francis wrote:

 I made a new patch with similar changes, but for the table/cell icons,
 also mailed to this list.

Thanks for the patches! I've not had time to review them yet, design review on 
svg diff patches sent to the mail list is a petty slow work-flow for me to 
actually get to see the end result ;) But while you pretend to listen to 
elevator music, waiting for a review, I thought you might find this of 
interest. It's an svg gird of all the other svg's currently in sugar-artwork 
mainline, hover over them to see the file name. It works well in Safari and 
Chrome (but I think Firefox's SVG support is still a little broken with regard 
to the official spec supporting the imbedding of other images in an SVG):

http://wiki.sugarlabs.org/images/e/e8/Sugar-artwork.svg

There's quite a lot of unused items in there, and some you see with grey are 
often intended to allow for the user fill and stroke entity colours (but pretty 
sure the one's you've patched so far were not intended for such user colour 
use). I'll clarify/confirm once I've had a chance to look over your patches in 
more detail.

Regards,
--Gary

 Cheers.
 
 2012/7/13 Gonzalo Odiard gonz...@laptop.org:
 Maybe Gary or Manuq can look at this issue?
 
 Gonzalo
 
 ___
 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

Re: [Sugar-devel] sugar-build component in Trac

[Gary Martin]

Hi Manual,

On 11 Jul 2012, at 17:28, Manuel Kaufmann wrote:

 Hello,
 
 Can we add a a component called sugar-build in Trac
 (bugs.sugarlabs.org) so we can report bugs related with it?

Open a ticket on bugs.SL.org, set it to Task and component of 
bugs.sugarlabs.org. In the description ask for the new component and make sure 
you state the owner (or someone willing to be the owner) of the component 
otherwise bugs can drift on without maintainer action/visibility.

Regards,
--Gary

 Thanks,
 
 -- 
 Kaufmann Manuel
 Blog: http://humitos.wordpress.com/
 Porfolio: http://fotos.mkaufmann.com.ar/
 PyAr: http://www.python.com.ar/
 ___
 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

Re: [Sugar-devel] Are weekly Design mettings occuring?[was: Are weekly dev meetings occuring?]

[Gary Martin]

Hi Eduardo,

On 9 Jul 2012, at 19:28, Eduardo H. Silva hoboprim...@gmail.com wrote:

 One more question, what about Design meetings? Those seem to be
 lagging a lot, and are very much needed in case the transition of the
 sugar shell to gtk3 opens up some avenues for improvements.

No, we have been holding off until 12.1 is finished before starting a new 12.2 
design cycle. Look out for a meeting announcement later this week.

Regards,
--Gary

 Eduardo
 
 2012/7/9, Eduardo H. Silva hoboprim...@gmail.com:
 Thanks, I'll be sure to be present tomorrow.
 
 Eduardo
 
 2012/7/8, Gonzalo Odiard gonz...@laptop.org:
 Yes! Tuesday as every week.
 
 Gonzalo
 
 On Sun, Jul 8, 2012 at 4:42 PM, Eduardo H. Silva
 hoboprim...@gmail.comwrote:
 
 Hi everybody,
 Are weekly development meetings still happening? I'd like to be part
 of one (as a spectator).
 
 Eduardo
 ___
 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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel