[Sugar-devel] [RELESAE] Clock-15
== SOURCE == http://download.sugarlabs.org/sources/honey/Clock/Clock-15.tar.bz2 == BUNDLE == http://activities.sugarlabs.org/en-US/sugar/downloads/file/28622/clock-15.xo == NEWS == * Fix for manual hand move mode where it would sometimes report incorrect hour (SL#4506) * In manual mode, dragging hour hand past 12 now correctly updates AM/PM (SL#4508) * Fix to prevent the simple clock face tick marks from extending slightly past the edge of the clock face Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Clock-14
== Source == http://download.sugarlabs.org/sources/honey/Clock/Clock-14.tar.bz2 == Bundle == http://activities.sugarlabs.org/en-US/sugar/downloads/file/28585/clock-14.xo == News == * A corrected activity bundle that actually includes the below features: ** Use standard lips icon for speech features (thanks Walter!) ** Feature allowing dragging of clock hands to manually explore how an analogue clock works for both direct XO-4 touch interaction and trackpad use (many thanks Manuq!) ** AM/PM display on main clock face Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Clock-13
== Source == http://download.sugarlabs.org/sources/honey/Clock/Clock-13.tar.bz2 == Bundle == http://activities.sugarlabs.org/en-US/sugar/downloads/file/28584/clock-13.xo == News == * Use standard lips icon for speech features (thanks Walter!) * Feature allowing dragging of clock hands to manually explore how an analogue clock works for both direct XO-4 touch interaction and trackpad use (many thanks Manuq!) * Translation updates * Redraw performance updates * AM/PM display on main clock face Regards, --Gary P.S. This is intended to make the 13.2.0 OLPC release, and specifically includes features for the XO-4 touch hardware (though the features also work well with older trackpad/mouse only hardware). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Maliit 0.93.0 OSK language layout cycle key testing
Hi Peter,I wasn't having much luck withyum 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.rpmmaliit-framework-gtk2-0.93.0-1.fc18.armv7hl.rpmmaliit-framework-gtk3-0.93.0-1.fc18.armv7hl.rpmmaliit-plugins-0.93.0-1.fc18.armv7hl.rpmWanted 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 thelanguage 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).Regards,--Gary[1]http://arm.koji.fedoraproject.org/koji/builds[2]http://dev.laptop.org/ticket/12205[3]___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Release] Calculate-41
== Bundle == http://activities.sugarlabs.org/en-US/sugar/downloads/file/28268/calculate-41.xo == Source == http://download.sugarlabs.org/sources/sucrose/fructose/Calculate/Calculate-41.tar.bz2 == News == * Latest translation updates * Additional button controls for cursor left, right, and backspace * Disable on screen keyboard for main input field to allow easier touch HW interaction (fix solution thanks to Simon Gonzalo) * Major rework of the user interface layout to closer match the original design (from Eben), UI contrast is improved and button spacing improved, portrait layout is improved (though could do with further work) * Equation and variable views now use user fill and stroke colours and black or white text for improved text contrast * Fixed: Code that used CanvasIcon was commented out in 2007, remove it SL#3673 * Fixed: All equations and Show history buttons have some problems SL#2135 * Fixed: Calculate plot image alignment glitch when previous results contain very long answers SL#2126 Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Hidden Browse feature (from webkit I think)
Hi folks, While I remember... Just accidentally spotted a rather nice sneaky feature in the new webkit browse (in 13.0.1 build 2). Apologies if this is old news, but is rather handy... You can type non-URL text into the Browse location field and web kit will realise it is not a valid url and will try a google search with it instead. Something for the release notes :) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Design] Accelerometer icon
Hi Gonzalo, Some weeks back you requested an icon to represent an accelerometer, or accelerometer data. Can you give a little more context as to where you'd like to use this icon? I'm currently thinking you might possibly want it in the Memorize toolbar as a data source, in the Maze toolbar as an alternative controller, Walter might want it if he implements a Newtonian Turtles feature, and in the Physics toolbar as a way of enabling manual gravity control – OK so that last one was mine ;) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Announce] No official design meeting today
Hi folks, Apologies, I'll not be able to chair a design meeting today. I'll follow up on existing [Design] email threads, and can run a meeting later this week if there is enough demand. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Design] On Screen Keyboard – part of the 'get Sugar touch ready' feature set
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! Regards, --Gary P.S. For those interested in more background touch related notes see [4], [5], [6], and [7]. [1] http://wiki.sugarlabs.org/go/User:Garycmartin/Maliit#Maliit_OSK_style_and_layout_design [2] http://wiki.sugarlabs.org/go/Features/Touch/Development#Sugar_theme [3] http://wiki.sugarlabs.org/index.php?title=User_talk:Garycmartin/Maliit [4] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Touchscreen/On-screen_Keyboard [5] http://wiki.sugarlabs.org/go/Design_Team/Sugar_Shell_Touch_Input [6] http://wiki.sugarlabs.org/go/Talk:Design_Team/Sugar_Shell_Touch_Input [7] http://wiki.sugarlabs.org/go/Design_Team/Activity_Touch_Input ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [REMINDER] Design team meeting today - Tuesday August 14th 2012 - 16:30 UTC
Hi folks! Just a reminder about today's Design Meeting - Tuesday August 14th 2012 - 16:30 UTC http://wiki.sugarlabs.org/go/Design_Team/Meetings Agenda: - Home list view, hover highlight/click results in confusion for favourite icons [1] ''Frederick'' - Examples support for activities – using the ObjectChooser and/or also the Journal volumes bar to allow activities to provide access to an examples folder inside their bundles. [2] ''tch'' - Followup on lease expiry information display in My Settings - About My Computer, [3], [4]. ''Anish'' - Followup on multi-selection and batch operations on Journal entries [5], [6] - Design review/testing/feedback of touch [7] features, patches [8] available for testing ''Simon'' - Visual clue about secondary palette options [9] ''Gonzalo'' - Higher-resolution Journal thumbnails for Activities [10] ''Walter'' - Your agenda item here Regards, --Gary [1] http://bugs.sugarlabs.org/ticket/3147#comment:3 [2] http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038588.html [3] http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038571.html [4] http://wiki.sugarlabs.org/go/Features/Lease_Information_Display [5] http://wiki.sugarlabs.org/go/Features/Multi_selection_screenshots [6] http://lists.sugarlabs.org/archive/sugar-devel/2012-July/038558.html [7] http://wiki.sugarlabs.org/go/Features/Touch/Development [8] http://dev.laptop.org/~erikos/touch/ [9] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038926.html [10] http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038929.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Design meeting Tuesday August 7th 2012 - 16:30 UTC 1hr
On 5 Aug 2012, at 17:02, Gary C Martin g...@garycmartin.com wrote: Design meeting: 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. I'm hoping the majority of design conversations will take place on mail-list design threads, wiki pages and or http://bug.sugarlabs.org tickets. http://wiki.sugarlabs.org/go/Design_Team/Meetings Agenda * 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 * Examples support for activities – using the ObjectChooser and/or Journal volumes bar to allow access to examples folder inside activity bundles. tch * Your agenda item here Time: Tuesday August 7th 2012 - 16:30 UTC 1hr Place: #sugar-meeting Thanks to all those who made it to the design meeting, made some good progress! Here's the links to the minutes and log: Minutes: http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-08-07T16:30:14.html Log: http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-08-07T16:30:14 Regards, --Gary Hope to see you there! --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Design meeting Tuesday July 31st 2012 - 16:30 UTC 1hr
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
Re: [Sugar-devel] [Design] Proposal on some Help toolbar design details
Hi folks, On 4 Jul 2012, at 21:48, Gary C Martin g...@garycmartin.com wrote: Hi folks, I just wanted to try and formally clarify some design details regarding the activity Help toolbar. The actual Help content UI varies quite a bit from activity to activity depending on the activity needs and how the developer wants to tackle it (drop down palette of text and icons, pop-up animation, adding additional help text to the main canvas area), but we should at least try to stick with one Help icon design, and put it in a place in the toolbar that keeps with the 'new' toolbar design goals. Proposal: An activity Help toolbar icon, if present, should be placed as the last icon in the toolbar before the Stop icon, but should be left aligned with the existing custom activity icons, not right aligned next to the Stop button. A standard Help icon (already agreed previously on mail-list) should also be added to sugar-artwork for future Sugar releases for easy activity developer use, see ticket for proposed svg [1]. Activity [Edit] [View] [Custom1, Custom2 .. CustomN] [Help] ___ Stop Rational: The Stop icon is the most important activity primary toolbar mechanism and should, where possible, be on its own to the far right of the toolbar, for clear obvious access. Placing other buttons next to it makes Stop less visible and increasses the chance of pressing Stop accidentaly when aiming for a nearby button. Known affected activities are Implode [2], Finance [3], TurtleArt [4] (already fixed as of TurtleArt-148), Chart. To follow up on this previous thread, several activities are now following this help proposal. I've put a simple HIG page together to cover the design for Activity authors [1]. If there are no objections I'll place it somewhere more formal (perhaps as a first step in updating the old HIG with all the design changes that have landed in Sugar in the last few years). Regards, --Gary [1] http://wiki.sugarlabs.org/go/User:Garycmartin/Activity_Toolbar_Help#Design_details_regarding_activity_Help_toolbar Regards, --Gary [1] http://bugs.sugarlabs.org/ticket/3746 [2] http://bugs.sugarlabs.org/ticket/3721 [3] http://bugs.sugarlabs.org/ticket/3720 [4] http://bugs.sugarlabs.org/ticket/3718 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr
On 19 Jul 2012, at 22:06, Gary Martin wrote: 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! Thanks again to all who could make it along today! Next design meeting will be announced here later this week (likely at a slightly later time next Monday or Tuesday to allow more folks to make it). Minutes: http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-07-23T14:31:15.html Log:http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-07-23T14:31:15 Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Design] BulletinBoard feedback
Hi Walter, Finally had a chance to have a play with your Bulletin Board-2 activity [1][2] and just wanted to pass along some quick design related feedback from my first impressions: - The default view for the activity feels like it should be Thumbnail view, not Slide view. Instantly presenting a user with a 'Bulletin Board' like view of the activity showing numerous thumbnails pinned to the screen makes the activity intent more obvious. Slide Thumb primary toolbar icon positions should swap if Thumb becomes the default view. - The canvas fill colour should be a neutral light grey or white, the two colour fill/stroke border frames around the thumb images are strong enough already to clearly see the owners custom fill/stroke colours. I was pretty swamped with some un-expected user choice of lurid colour fullscreen ;) - The 'Update description' tool in the primary toolbar is rather confusing with regard to the similar functionality and similar icon in the Activity secondary toolbar 'Description'. Suggestion; drop the primary toolbar tool 'Update description' and make the description text areas editable on the main canvas below each slide. It can have a subtle help hint in the input area where a description text is empty, tempting folks to interact (e.g. the standard Description icon with some hint text next to it, something like Empty description and a button marked (+) Add description, as per an empty Journal search, or see Jukebox for a similar canvas use case, mockup here [3]). - Ideally the Title on the canvas would also support editing (to match the above behaviour) so the Journal entry titles can be modified as well. - [Bug] The 'Update description' tool in the primary toolbar was used to add a description to one slide, the same text was then in that palette for every other slide (the other slides had no descriptions of their own). The palette field only updates if there is description text already there, otherwise it shows previously displayed stale text. - In thumbnail view can a single click interaction switch to Slide view for that slide. - Is there any way to transfer a specific shared entry into your own Journal rather than just viewing low-res thumbnails, or is this out of the scope of the activity? - My expectation for the audio recording feature was that there could be an audio recording per slide, so you could navigate through and hear a description of each slide. It appears to be a single audio recording which is over written if you record again, requiring manual navigation of the slides if it is intended as a narration. If audio recording can be per slide, the 'buddy with speak bubble' icons could appear on the main canvas in the text description area, rather than the secondary toolbar, to allow playback of the different recordings from each collaborator for each slide). - [Bug] Audio recording only produced a series of clicking echo like audio feedback (tested on an XO-1.75) - [Bug] Main canvas does not re-scale or re-centre. Opening secondary toolbars pushes the description area slightly off screen, and rotating the screen causes a grey area of undrawn canvas at the bottom and the main content to partially disappear off the right side of the display. - [Bug] Still trying to examine this one so apologies for vagueness. Sharing issues using two XO-1.75 running latest 12.1 build 18 on a local network, with no collaboration server defined. Share from 1st machine with 6 item starred; join activity from Neighbourhood view on 2nd machine with no items shared; result is 2nd machine showns the warning about having no items starred; stop both activities; star a few Journal items on 2nd machine; resume activity on 1st machine; join activity from Neighbourhood view on 2nd; result, 1st machine still just sees its own starred items, 2nd machine see only its own starred items. The machine joining the other displayed the other in the right Frame buddy area, but the initial sharing machine did not see the other in the right Frame buddy area (I tried this a couple of times starting with different machines first). - [Bug] Given the above, I was not sure what the Refresh tool was for in the Activity secondary toolbar, I clicked it a number of different times in different situations (starring extra items in my Journal after beginning the activity, after trying to collaborate). From the wiki I guess this is intended for case 2 rather than case 1 (rescan of journal starred items). - [Bug] (After testing with a 3rd XO-1 on 12.1 build 18 I managed to see share working) Thumb view shows incomplete state if the activity is in the progress of synchronising with another's slides when you switch to it. Should show a loading or progress bar if state is incomplete (or a spinner if you're not sure how many items are to by synched). If the number of items is known, you could open blank thumb containers with spinners or a loading message in each so that
[Sugar-devel] [ANNOUNCE] Design meeting Wednesday July 18th 2012 - 15:00 UTC 1hr
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 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
[Sugar-devel] [Design] Proposal on some Help toolbar design details
Hi folks, I just wanted to try and formally clarify some design details regarding the activity Help toolbar. The actual Help content UI varies quite a bit from activity to activity depending on the activity needs and how the developer wants to tackle it (drop down palette of text and icons, pop-up animation, adding additional help text to the main canvas area), but we should at least try to stick with one Help icon design, and put it in a place in the toolbar that keeps with the 'new' toolbar design goals. Proposal: An activity Help toolbar icon, if present, should be placed as the last icon in the toolbar before the Stop icon, but should be left aligned with the existing custom activity icons, not right aligned next to the Stop button. A standard Help icon (already agreed previously on mail-list) should also be added to sugar-artwork for future Sugar releases for easy activity developer use, see ticket for proposed svg [1]. Activity [Edit] [View] [Custom1, Custom2 .. CustomN] [Help] ___ Stop Rational: The Stop icon is the most important activity primary toolbar mechanism and should, where possible, be on its own to the far right of the toolbar, for clear obvious access. Placing other buttons next to it makes Stop less visible and increasses the chance of pressing Stop accidentaly when aiming for a nearby button. Known affected activities are Implode [2], Finance [3], TurtleArt [4] (already fixed as of TurtleArt-148), Chart. Regards, --Gary [1] http://bugs.sugarlabs.org/ticket/3746 [2] http://bugs.sugarlabs.org/ticket/3721 [3] http://bugs.sugarlabs.org/ticket/3720 [4] http://bugs.sugarlabs.org/ticket/3718 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Release] Clock-9
== Bundle == http://activities.sugarlabs.org/en-US/sugar/downloads/file/28114/clock-9.xo == Source == http://download.sugarlabs.org/sources/honey/Clock/Clock-9.tar.bz2 == News == - Translation issue fix, replace pgettext with gettext to work around broken genpot string generation (SL#3668) - Translation issue fix for always using an English spoken accent when using gstreamer-espeak plugin (SL#3687) - Latest translations == Note == Tested with language set to Spanish (Peru), and English (USA) on: * XO-1 with a very old 802 OLPC build * XO-1 with 883 OLPC build * XO-1 with a 12.1.0 13 build * XO-1.75 grid membrane with 12.1.0 13 build. * XO-1.75 HS with 12.1.0 13 build. All toolbar string translations look correct, written text time translations looks good, speech using correct Spanish/English accent. Also did a quick test in French (France) with 12.1 build 13 and all looked/sounded good. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Labyrinth Sugar dependency bugs
Hi Guys, Just a heads-up. Walter pinged on IRC to say Labyrinth was no longer starting on Sugar 0.84. With a little digging it seems that Jorge Saldivar's feature addition (font styles) added the use of sugar.graphics.colorbutton, which is only available in Sugar 0.83.4 and above; it also had a variable, self.mods, only defined in an 0.86 try block (breaking Labyrinth for 0.84 users). I've gone back to ASLO and marked the Labyrinth-9, Labyrinth-10, Labyrinth-11 and Labyrinth-12 versions as incompatible with Sugar prior to the 0.86 release. Fixing the self.mods omission could be a trivial fix to get a new Labyrinth release working for existing 0.84 users, but working around the sugar.graphics.colorbutton is probably more effort than it's worth for support of 0.82 users. Thanks Walter for the bug report! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Release] Physics-10
== Bundle == http://activities.sugarlabs.org/downloads/file/28097/physics-10.xo == Source == http://download.sugarlabs.org/sources/honey/Physics/Physics-10.tar.bz2 == News == - Update to latest translations - Fix for grab tool crash on OLPC 12.1 F17 development builds SL#3361 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH calculate] Remove dependency on CanvasIcon
Hi Sascha, On 5 Jun 2012, at 17:17, Sascha Silbe wrote: Sascha Silbe sascha-ml-reply-to-201...@silbe.org writes: Excerpts from Sascha Silbe's message of 2011-11-14 21:59:11 +0100: The code that used CanvasIcon was commented out in 2007 already. [...] Gary, can you include this patch in Calculate, please? Ping. Thanks for the ping. Sorry previous email was flagged but lost deep in an inbox of flags. Have created SL#3673 ticket for it so I'll see it as I cycle through Calculate maintenance for the next release: http://bugs.sugarlabs.org/ticket/3673 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
[Sugar-devel] [Activity Team] Wiki guidance for adopting orphaned Activities / Activity co-maintainer
Hi folks, This is a quick tentative shot a providing some FAQ guidance on the wiki for adopting orphaned Activities, or becoming an Activity co-maintainer. Nothing too dramatic or rocket-science but the conversation came up on IRC today with bernie and cjl so here it is: http://wiki.sugarlabs.org/go/Activity_Team/FAQ#How_do_I_adopt_an_orphaned_Activity.2C_or_become_an_Activity_co-maintainer Shout if you disagree! :) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Design Team meeting, Sunday 10th 15:00 UTC, #sugar-meeting
Hi folks, Just a (late) reminder for the Design Team meeting in #sugar-meeting, Sunday 10th April at 15:00 UTC: http://wiki.sugarlabs.org/go/Design_Team/Meetings I've not made much new progress myself over the last couple of weeks, but hopefully we can at least try and chip away at some more of the topic items. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Design meeting
Just a heads up that I don't think I can make it for a design meeting tomorrow (Sunday 3rd). I'll read the logs if someone else wants to chair a meeting. If not, hopefully we can try to get through some more agenda items Sunday 10th. Apologies, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Contact sheet for all sugar-artwork icons
Hi Folks, For some time I've been meaning to create a contact sheet for all sugar-artwork svg icons to help as a quick reference, and for general icon polishing/standardisation. Finally – having been fiddling with svg xml for my SOM generation code – I got around to the task: http://wiki.sugarlabs.org/go/File:Sugar-artwork.png Christian: Given the Design Meeting conversation on Sunday, you might be interested in 5 along, 7 down (view-source AKA the cog), and 2 along, 8 down (preferences-system AKA the spanner). Gonzalo: You might like to check out 12 along, 9 down (camera-external) for re: your Record toolbar work as I think it gives a stronger, more sugar standard version of a camera icon than currently shown in your mockups (would need to update your video and microphone icon styles to match): http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Design Team meeting, Sunday 20th 16:00 UTC, #sugar-meeting
Hi Folks, Just a reminder for the follow-up Design Team #sugar-meeting this Sunday 20th 16:00 UTC: http://wiki.sugarlabs.org/go/Design_Team/Meetings This one could be a little more bumpy than last weeks, with less #agree due to the more controversial edge, depth/impact, and longer time scale to the topics. Still, good to make a dent in some of these and get more feedback. See you there, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Messages notification
Hi Martin, Just wanted to give you a heads up that I have a slightly different design coming together for notifications. After further, more detailed, work the frame corner notification history palette idea is not coming together so well. I've switched to mockups that actually badge the existing icons in the frame, and add the notification messages to the end of their existing pop-up palettes. It holds truer (I think) to the original HIG and previous mockups of Eben's intent for notifications. I'll try and get the set of new images uploaded to the wiki later this week for folks to review. Regards, --Gary On 17 Nov 2010, at 19:17, Martin Abente wrote: Change the want for need and we have: When there is something they _need_ to know And that is exactly the same reason why we are already using the Icon notifications and the same reason why we are already using Alert widgets all over sugar (outside activities), and there are still more cases that we don't do because we simply don't have this feature fully implemented yet. That's all i got. Abrazos, :) On Wed, Nov 17, 2010 at 3:27 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Nov 17, 2010 at 1:10 PM, David Farning dfarn...@gmail.com wrote: This patch has a place in Dextrose. Dextrose is looking at the question, How can we provide support staff the necessary information to effectively fix and/or report problems to a higher level of service and support? Let's not jump to conclusions. Can this be limited to... when the user _wants_ it? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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 UI Dictator
Hi Martin, On 20 Nov 2010, at 09:32, Martin Dengler wrote: On Fri, Nov 12, 2010 at 12:06:56AM -0500, Michael Stone wrote: Martin and I talked for bit this evening and I believe that I managed to persuade him to support my [UI Dictator team] proposal. I do, for the reasons mentioned in Michael's key arguments. P.S. - Later [...] we discovered a confusion about the mandate of the proposed committee; to wit: Is the main purpose of the committee to act as a UI Maintainer (e.g., by deciding which UI-related patches to merge) or is the main purpose of the committee to make UI-related decisions on an as-requested basis? I think it is both act as maintainer and make UI-related decisions. It seems we're re-invented the Design Team. I spoke with Gary Martin and Bernie and, despite having lost the logs of my conversation with Gary, my hazy recollection is that that they also came to this conclusion. With that in mind, I think we should just have more people actively participate in the design team. I'm interested, so have put my name down on http://wiki.sugarlabs.org/go/Design_Team/Contacts#Team_Members . I hope anyone else interested in being active, will do the same. Michael Stone, Bernie Innocenti, I'm looking at you. Gary, can you add / correct anything from our conversation? Summary: A two prong attack. 1) HIG cleanup and polishing effort (one ring to rule them all) 2) Focus on keeping a core of HIG compliant quality activities to act as our ambassadors Hope you don't mind me posting, here's the irc log for those that want to skim: [03:45] mtd: garycmartin: I was wondering if you had any thoughts about the UI dictator proposal [03:45] mtd: garycmartin: given you're one of the victims m_stone named [03:45] garycmartin: mtd: yea... :) [03:46] garycmartin: mtd: I see two main prongs of attack. [03:46] garycmartin: mtd: HIG (one ring to rule them all) [03:47] garycmartin: mtd: Quality activities (make sure we have a handful of excellent HIG compliant examples) [03:48] mtd: garycmartin: ok, good to remember what we're after :) [03:49] garycmartin: mtd: Unfortunately most ports or new contributors don't seem to either read the first, or look at any of the second. Many can't even provide a basic HIG compliant icon :-( [03:50] garycmartin: mtd: as to how we get there... [03:51] garycmartin: mtd: I've been threatening to edit the HIG, there's plenty of obviously dud history in there now that can go with close to zero discussion. [03:52] garycmartin: mtd: I was thinking of initially striking thru the out of date text, but leaving it there for some weeks/months. [03:53] mtd: garycmartin: cool [03:53] mtd: garycmartin: I think a new HIG version makes plenty of sense [03:53] mtd: garycmartin: and wow, you want to do it :) [03:53] garycmartin: mtd: With perhaps a new text colour for any additions I make, again for a month or so to give those with an interest the time to scan through. [03:54] mtd: garycmartin: cool [03:55] garycmartin: mtd: I'm pretty fed up with pinging folks on the list and replying to random email. It never seems to end and often seems to go silent. Would be quicker just to point folks to the HIG. [03:56] mtd: garycmartin: yeah, I don't think that'd be too contentious [03:56] mtd: garycmartin: (to take that approach) [03:56] garycmartin: mtd: As to landing specific patches, I'd have to go with If it's not HIG compliant, it gets an instant NAK, with a pointer to the HIG. [03:57] mtd: garycmartin: understood and agreed [03:57] mtd: garycmartin: so when you're done, I have a few questions. But please continue. [03:59] garycmartin: mtd: The patcher can then request a HIG update if they feel strongly about their proposed HIG design. Argument, as per usual, one the dev list by interested parties. If there's no agreement, it must default to a NAK. [04:00] garycmartin: (s/one/on/) [04:01] mtd: garycmartin: sounds good [04:01] garycmartin: mtd: Go on, fire some questions. [04:03] mtd: garycmartin: two points to consider, more than questions: the actions you've set out imply, to me, that the committee / dictator is acting as the UI maintainer; is that intentional? [04:03] mtd: garycmartin: second, it also seems to imply that it owns the HIG; intentional as well? [04:04] mtd: garycmartin: one minor one is: for patch acceptance, do we require HIG update sometimes / always if the HIG is silent / ambiguous on something affected / influencing the patch? [04:04] • mtd finishes. [04:04] garycmartin: mtd: yes I didn't completely follow that end argument from Michael. [04:06] mtd: garycmartin: do my questions make it clearer? or shall I clarify? [04:06] garycmartin: mtd: I don't think the HIG should often change, any edits should be minimal, but we do need a good parse through it just now to get back in sync. Obviously there are also some totally new areas such as touch support. [04:08] garycmartin: mtd: HIG grey (or blank) area cases you mean? [04:10]
[Sugar-devel] Bridge activity code maintenance
Hi fang, Just wanted to ping and check you have no objections to me picking up maintenance of the Bridge activity. I note that you originally uploaded the version 2 activity bundle to ASLO and so wanted to give you a heads up: http://activities.sugarlabs.org/en-US/sugar/addon/4231 A number of new developers have contacted me and asked if they can contribute to Sugar activities, I suggested Bridge was a good candidate to start on as there is already a number of enhancements/fixes from similar work on the Physics activity that we could easily land. I'll create a new git.sugarlabs.org repository for the work, migrating over from dev.laptop.org, and we'll post new releases to the ASLO once ready. Kind Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] looking to contribute
Hi Jon et al, Hope you don't mind me cc:ing the sugar-devel mail-list, it helps give other folks a head's up on likely activity. Folks may want to join the mail-list as it's useful for posting questions, getting help – though traffic can be a little noisy at times. On 20 Oct 2010, at 19:24, WSU CS401 wrote: On Wed, Oct 20, 2010 at 2:04 PM, Gary C Martin garycmar...@googlemail.com wrote: Hi Lindsey, On 19 Oct 2010, at 19:51, WSU CS401 wrote: Hello, We are four college students looking to contribute to sugar activities. Your activities caught our eye and we were wondering, as you are a maintainer, if you have any projects/fixes (small at first) that we could help with as we are new to sugar. Did you have an activity in mind? Physics, Clock, Labyrinth, Calculate, Moon are the ones I try specifically to help maintain in my free time, though Moon is the only one I originally wrote, the others are all adopted. There are quite a few activities out there that could do with some minimal maintenance/release effort, perhaps a few feature additions if something grabs your interest and your time allows. One quick example: I've been hoping to pick up Bridge at some point: http://wiki.laptop.org/go/Bridge It's based on the same code as Physics and I've plenty of patches there that I'm sure could be easily made to Bridge with minimal effort. It's a fun little game that needs a bit of tidy-up (was originally written as part of a game jam over a few days). As far as features, it could do with some game level progression (only one level at the moment), perhaps a budget system where you only have so many coins to spend on building materials. Someone did at least upload the Bridge-2 bundle to activities.sugarlabs.org: http://activities.sugarlabs.org/en-US/sugar/addon/4231 But they made no changes and didn't make a git repository for the source code, would be a fine candidate to help out on. Shout if it doesn't grab your interest, sure there are other I can find that are in need of help. That sounds excellent, just the kind of thing we were looking for. How should we go about starting this project? We have done a lot of research, but we are still unsure of how sugar's development cycle actually works. Thanks a lot for your reply! :) Good question ;) OK, so I've created some Sugar Labs resources for Bridge to get things going. First a quick wiki page template, nothing too exciting but feel free to tinker and add to it as needed: http://wiki.sugarlabs.org/go/Activities/Bridge The git source repository is here http://git.sugarlabs.org/projects/bridge Each member of the team that's going to work on code should create a user account on git.sugarlabs.org. On the machine/home directory you each intend to work from you'll need to create a SSH key pair, and add the public key to your git.sugarlabs.org accounts, this allows you to git push your changes back to the main repository. Once you have accounts, I can either add commit privileges for you to the Bridge mainline, or initially the best workflow is usually to create your own clone or clones to experiment with first: http://git.sugarlabs.org/projects/bridge/repos/mainline (login to see the Clone repository link to the right) I've filed a request for a Trac component, we use this to collect bug/enhancement/task tickets, if you also create accounts at bugs.sugarlabs.org tickets can easily be assigned so we know who working on what issue (useful if there are a number of folks all wanting to work in parallel): http://bugs.sugarlabs.org/ticket/2470 The usual workflow when there is more than one of you working is something like: - file some Trac tickets for various bugs/enhancements/tasks making sure the component is set to Bridge. - assign tickets you want to work on to yourself so others can see who is doing what - make yourself a local clone of a repository ready to work on - make the _minimal_ code changes necessary for your assigned ticket - once your happy and tested locally, push your clean changes back to the public repository - request a merge of your public repository into mainline - wait for review feedback or notification that your change was accepted and merged - repeat BTW I'm no master git user, I try to stick to a simple git workflow so as not to get into a source code tangle :) Have a skim through the Activity Team wiki pages, it has various FAQs and links to using git and other useful topics that may help get things up and running: http://wiki.sugarlabs.org/go/Activity_Team If something confusing/missing let me know as wikis are notorious for gathering moss and going off at tangents. Regards, --Gary Jon B. WSU Senior | Computer Science Kind Regards, --Gary Thanks, Lindsey L. WSU Senior| Computer Science ___ Sugar-devel
[Sugar-devel] [RELEASE] Physics-7
== Source == http://download.sugarlabs.org/sources/honey/Physics/Physics-7.tar.bz2 == News == - Fix for cpu idling events when in background special case for Sugar 0.84. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] coping with the traffic in sugar-devel
On 5 Oct 2010, at 17:05, Walter Bender wrote: On Tue, Oct 5, 2010 at 12:01 PM, Gary Martin garycmar...@googlemail.com wrote: On 5 Oct 2010, at 12:05, Bernie Innocenti wrote: On Tue, 2010-10-05 at 11:19 +0200, Tomeu Vizoso wrote: What about marking in some way those incoming emails that belong to a thread that has included the word 'bernie'? That's really hard... Procmail, my email sorting software, is stateless. There's also the option of just going through the subjects, read the threads that look interesting then marking all of them as read when finished. That's better, but it adds delay: I open my mailing list folders to check for new mail only once in a while, when I'm done with everything else. I'm starting a new thread about this because I often hear from people who have missed important developments because cannot cope with the traffic. I'm also on way more lists that I can read, but with a bit of automatic labelling and organization I think I manage to miss little of the relevant info. Any other tips? Just mucking around with a quick hack, how about this? It's a SOM for the month of Sept of every email from iaep, dextrose, and sugar-devel that mentioned bernie (including emails from bernie). That's about ~1171 emails filtered down to ~171 that mentioned bernie and mapped. I dialled up the number of top features from the usual 200 terms to 400 for a little more textual depth: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-bernie.png And just for comparison and so I'm not picking on Bernie, here's the same thing for gary: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-gary.png I could do this for any keyword (the more unique the better), so it would be easy to perhaps map etoys or some other term a summary map might be of interest, also easy to include more mail-lists into the data set. Here's one for the Etoys keyword: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-etoys.png Cc'ing people conservatively is standard practice on many high-traffic lists. Today the old arguments of wasted bandwidth are just ridiculous. Occasionally someone complains for receiving dupes, but all modern MUAs provide ways to suppress them. Sascha elegantly solved the issue by setting the Mail-followup-to header to exclude himself from replies (if the remote MUA supports it). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://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 fun!! when will be be able to click on the words and go to the email message in the archive :) I'm procrastinating on the implementation :) but now that the wiki supports image maps, that is likely the easy, if not most graceful/elegant, route**. Clicking on a word would link to the N emails where the term was used. ** really this should be a nice dynamic/interactive map web app, where the text labels are added dynamically over the contour map images, with panning/zooming/search/filter type features... And the ability for admins to add in new data resources to be mapped :) 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] [RELEASE] Calculate-34
== Source == http://download.sugarlabs.org/sources/sucrose/fructose/Calculate/Calculate-34.tar.bz2 == News == - Includes latest .de translations - Locale correctly included in bundle for language support ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial F14 developers-only release for XO and XO-1.5
On 24 Sep 2010, at 13:08, Simon Schampijer wrote:
On 09/23/2010 05:01 PM, Simon Schampijer wrote:
On 09/22/2010 06:24 PM, Simon Schampijer wrote:
On 09/11/2010 04:56 PM, Simon Schampijer wrote:
On 09/11/2010 04:20 PM, Jon Nettleton wrote:
The XO-1.5 build does not boot for me, I get the following after
flashing the image:
Boot device: /wlan Argumenst:
Scan for: OLPCOFW not found
Scan for: school-mesh-0 not found
Scan for: school-mesh-1 not found
Scan for: school-mesh-2 not found
buf...@ff83b080:0:
Can't open boot device
Anyone else booted the XO-1.5 image already?
I have booted the XO-1.5 image but did not use OFW to install it.
Since I am running it from an SDHC card I manually extracted the
filesystems onto the card. I have an updated kernel rpm that fixes a
few of initial bugs that needed squashing with the XO 1.5. I can post
that if people want to do extended testing.
Sure! Keep it rolling :)
That error looks like OFW is not finding a bootable device. What
output do you get if you do dir int:\boot\ from the OFW prompt?
-Jon
Thanks Jon for following up and sharing the command. It helped to find
out that the bootfw package was missing. Daniel will do a new build.
Regards,
Simon
As a quick heads up. I just built an image for XO-1.5 with the latest
development branch (f14). Booted fine. Thanks Daniel!
More to come,
Simon
I uploaded a new XO-1.5 build (2GB with reduced set of activities) at
[1]. An issue I know of is that when booting you do not get into Sugar,
the booting screen stays on. Restarting X ctrl+alt+erase will work.
There are also some other bugs I have filed today [2] [3].
If you are sure that a bug is in 0.90 and not due to the XO platform you
can file it in the tracker [4]. Please make sure to leave a note where
you found the bug that we can treat it accordingly.
Of course, this is a development build I do to find and fix 0.90 bugs on
F14. Please treat it as well like that :)
Regards,
Simon
I have uploaded now as well a build for the XO-1 [1] (which does not
have the issue with the booting screen described above). I disabled the
Sugar Ad-hoc networks and set the gconf option
/desktop/sugar/user/default_nick to 'disabled' in order to allow to set
the nick on the startup screen.
Thanks for the image Simon, great to have something working on the XO-1 to
test! Have been poking a stick at it yesterday and today – here's a quick brain
dump (no tickets filed yet) just to get the ball rolling on this 0.89.6 Sugar
based build:
- First boot dcon speckled/corrupt video image initially, and then just before
first boot name/colour chooser, did not happen on subsequent boots
- XO boot animation ends with the XO character with one dot below it, think
this is the wrong frame to end on – it should hold with the XO and full circle
of dots
- Non-Sugar style cursor for interacting with first boot name/colour chooser
- Terminal-31 activity console and tabs text layout/redraw vte (?) issues
- When activities launch on an XO-1, you see a brief flash of a non-Sugar
themed window before going correctly fullscreen
- Display brightness XO-1 keys have no effect
- Journal toolbar empty space to left of new 'sort by' icon, would expect the
search field to expand to take any available space
- Tried sharing Chat-67 with neighbourhood and later stopping, it does not
remove the Chat icon from neighbourhood view
- Resuming/Joining a shared Chat always resumes as private mode
- Home fav view ring re-suffles its activity order after a reboot for no
obvious pattern, but seems somewhat related to activities used
- Experienced Sugar crashing and rebooting on several occasions just after
switching between two activities, or just after trying to start one (sorry
couldn't find any useful logs)
- The 'My Settings' control panel still overflows module icons off the right
edge, did the patches to fix this not land in mainline?
- Missing gettext dependency for using ./setup build when developing/hacking
activities ;)
- Implode-9 non-standard stop keyboard short cut (alt + esc and ctrl + Q do
nothing)
- Implode-9 missing locale directory
- Etoys-113 non-standard stop keyboard short cut (alt + esc and ctrl + Q do
nothing)
- Calculate-33 missing locale directory
- Paint-28 failed to start:
** Message: pygobject_register_sinkfunc is deprecated (HippoCanvasBox)
Traceback (most recent call last):
File /usr/bin/sugar-activity, line 21, in module
main.main()
File /usr/lib/python2.7/site-packages/sugar/activity/main.py, line 115, in
main
module = __import__(module_name)
File /home/olpc/Activities/Paint.activity/OficinaActivity.py, line 74, in
module
from Area import Area
File /home/olpc/Activities/Paint.activity/Area.py, line 70, in module
from fill import *
File /home/olpc/Activities/Paint.activity/fill/__init__.py, line 21, in
module
raise('cannot find proper binary blobs')
[Sugar-devel] Feedback on favourite view ring/spiral for 0.90
Hi Simon, I'll be out for most of tomorrow morning so just a quick late night email in case it is of help. I've been testing from 0 to 135 activities in 5 activity increments (have an animation I could upload if needed), and I'd prefer to see the the discrete icon size steps removed (per the original ring codes smooth icon size changes) as the current ring layout does rather 'jump around' as it reaches its max radius (~25-35) and then resizes icons down by a large step, so the ring radius also drops considerably. Once you hit about 40 activities and up, the spiral looks great :) I'd much rather see Walter ring/spiral patch land as is, than have it delayed and slip the release. Perhaps we can tune it for the bug fix release. One point I'd like to raise though is that if triangle and square layouts are enabled, they are effected by the spiral patch, I'm not sure if this is intentional? Both triangle and square will switch over to spiral once they reach their max size. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Class vs. Exec activity.info
Hi, I'm just starting to see some bug tickets and mention in the 0.90 notes that the activity.info class parameter is being dropped, with the exec parameter replacing it. Could someone explain what's going on, point me to some documentation, and/or a mail-list thread about it? There are plenty of activities that will now be broken and need fixing up, is this an intentional activity red flag change day to kill off any unmaintained activities? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Retro resource management game, anyone remember?
Hi Guys, For a while I've been looking for an old educational game I remember from way back that I'd like to re-write for Sugar, but have not been able to find/reference. From what I recall: 1) It was a simple resource management sim 2) Pretty sure it was on the BBC/Electron in mostly basic code (remember hacking at the code a little) 3) Kingdom is the name I recal, but that may be wrong, google has not helped 4) Game view consisted of a simple map with a blocky village/town, a river, mountains, plains 5) You got to allocate resources each year or perhaps season (people to work on the dam, guard the village, plant/harvest the crops etc) 6) The map then animated the results (notably a flooding river, or thieves from the mountains stealing grain were the highlight animations I remember) 8) A text summary of your gains/losses was shown before your next resource allocation 9) Game played until either everyone had left, or village/town reached a certain population goal Anyone else remember this? Was reminded by the recent health related discussion threads, seems like it could be extended a little to include a few more resources/events in that direction, perhaps also with collaboration so several neighbouring villages/towns (players) could share resources. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Read/evince quick follow up
Hi Lucian, Fab thanks. A git clone of your http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for testing in SoaS Mirabelle. Toolbars look good this time :-) I've only tested it on a couple of Gutenberg text PDFs so far, so yes as you mentioned the Edit toolbar is not so functional yet (no copy, no search). Everything else seems great so far e.g. - creating bookmarks work - page count and current page is correct - forward/back work moving one screens worth at a time (sub menus for by page and bookmarks also work) - view zoom in/out is good - view zoom to fit width is good - incremental zoom widget good - full screen view (and back again) good I'll try a wider range of test PDF's later (with more image content, some really great edu material at http://www.ck12.org if perhaps at our upper target age range). Are there any other document types that evince was supporting that I should go test? Fantastic work!! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Physics: license fixes #1596
Hi James, On 21 Jun 2010, at 04:36, James Cameron wrote: Found some patches in my repository not yet merged upstream, so I'm sending them again. -- James Cameron http://quozl.linux.org.au/ 0001-fix-olpcgames-license.patch0002-wrap-olpcgames-license.patch0003-include-license-fixes-1695.patch Sorry, giving up after screwing up my local rep twice and having to wipe and start again. Clearly I don't have a pointy enough hat, even the first dead simple patch fails at Hunk #1 at 1, and Hunk #2 at 12. Could you use gitorius to make a clone at: http://git.sugarlabs.org/projects/physics/repos/mainline Apply your changes, push, and request a merge? That I can then pull into mainline. Regards, --Gary P.S. I'm no lawyer so I'll just have to accept these legal text changes from you with no understanding of why they are needed. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] New Toolbar for Physics Activity
Hi,
On 20 Jun 2010, at 20:41, akashg1611 wrote:
The following patch incorporates the new toolbar design in
the Physics Activity. Also attached is the SVG icon of the
Create button, as was required for the new toolbar.
Thanks for taking the time to make a patch! Is it possible for you to create
clone using gitiorus at:
http://git.sugarlabs.org/projects/physics/repos/mainline
Make your changes, commit, push, and then request a merge?
Having a quick scan through the below patch I don't see any fallback to the old
toolbar setup if someone is running an older version of Sugar. I don't want to
loose compatibility 99% of our current user base if at all possible (check the
git reps of Moon, Calculator, TurtleArt, and I'm sure many other activities for
dual toolbar support).
Thanks again for taking the time to submit a patch.
Kind Regards,
--Gary
Signed-off-by: akashg1611 akashg1...@gmail.com
---
activity.py | 77 ++---
icons/toolbar-create.svg | 44 ++
2 files changed, 88 insertions(+), 33 deletions(-)
create mode 100644 icons/toolbar-create.svg
diff --git a/activity.py b/activity.py
index 273a001..ca18aad 100644
--- a/activity.py
+++ b/activity.py
@@ -21,6 +21,10 @@ import olpcgames
import pygame
from sugar.graphics.radiotoolbutton import RadioToolButton
from sugar.graphics.toolbutton import ToolButton
+from sugar.graphics.toolbarbox import ToolbarBox
+from sugar.graphics.toolbarbox import ToolbarButton
+from sugar.activity.widgets import ActivityToolbarButton
+from sugar.activity.widgets import StopButton
from sugar.activity import activity
from gettext import gettext as _
import gtk
@@ -34,6 +38,44 @@ class PhysicsActivity(olpcgames.PyGameActivity):
super(PhysicsActivity, self).__init__(handle)
self.metadata['mime_type'] = 'application/x-physics-activity'
+toolbar_box = ToolbarBox()
+
+activity_button = ActivityToolbarButton(self)
+toolbar_box.toolbar.insert(activity_button, 0)
+activity_button.page.keep.props.accelerator = 'CtrlShiftS'
+activity_button.show()
+
+create_toolbar = self._create_create_toolbar()
+create_toolbar_button = ToolbarButton(
+page=create_toolbar,
+icon_name='toolbar-create')
+create_toolbar.show()
+toolbar_box.toolbar.insert(create_toolbar_button, -1)
+create_toolbar_button.show()
+
+ stop_play = ToolButton('media-playback-stop')
+ stop_play_state = True
+stop_play.set_tooltip(_(Stop))
+stop_play.set_accelerator(_('ctrlspace'))
+stop_play.connect('clicked', self.stop_play_cb)
+ toolbar_box.toolbar.insert(stop_play, -1)
+stop_play.show()
+
+separator = gtk.SeparatorToolItem()
+separator.props.draw = False
+separator.set_expand(True)
+toolbar_box.toolbar.insert(separator, -1)
+separator.show()
+
+ stop_button = StopButton(self)
+stop_button.props.accelerator = 'CtrlShiftQ'
+toolbar_box.toolbar.insert(stop_button, -1)
+stop_button.show()
+
+ self.set_toolbar_box(toolbar_box)
+toolbar_box.show()
+
+
def write_file(self, file_path):
Over-ride olpcgames write_file so that title keeps working.
@@ -46,31 +88,8 @@ class PhysicsActivity(olpcgames.PyGameActivity):
event.block()
event.retire() # - without this, title editing stops updating
-# setup the toolbar
-def build_toolbar(self):
-# make a toolbox
-toolbox = activity.ActivityToolbox(self)
-
-# modify the Activity tab
-activity_toolbar = toolbox.get_activity_toolbar()
-activity_toolbar.share.props.visible = False
-self.blocklist = []
-# make a 'create' toolbar
+def _create_create_toolbar(self):
create_toolbar = gtk.Toolbar()
-
-# stop/play button
-self.stop_play_state = True
-self.stop_play = ToolButton('media-playback-stop')
-self.stop_play.set_tooltip(_(Stop))
-self.stop_play.set_accelerator(_('ctrlspace'))
-self.stop_play.connect('clicked', self.stop_play_cb)
-create_toolbar.insert(self.stop_play, 0)
-self.stop_play.show()
-
-separator = gtk.SeparatorToolItem()
-create_toolbar.insert(separator, 1)
-separator.show()
-
# make + add the component buttons
self.radioList = {}
firstButton = None
@@ -87,15 +106,7 @@ class PhysicsActivity(olpcgames.PyGameActivity):
create_toolbar.insert(button,-1)
button.show()
self.radioList[button] = c.name
-
-# add the toolbars to the toolbox
-toolbox.add_toolbar(_(Create),create_toolbar)
-create_toolbar.show()
-
[Sugar-devel] [PATCH] fix malformed svg module-updater icon revealed in F13
OK, not strictly a patch but attached is an updated version of the currently malformed svg module-updater icon that's not drawing correctly in F13. Not sure who this needs to get to (could only find it in Bernie's old depreciated software update git rep). It should live in the filesystem at: /usr/share/sugar/data/icons/module-updater.svg TA was the only other broken svg in Sugar on F13 I've seen, Walter has already patched that in git. FWIW the general svg issue seems to be not setting the stroke/fill/stroke-width for a given element and relying on what looks like a side effect default behaviour in the older svg lib. Regards, --Gary inline: module-updater.svg ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Lost at sea, Calculate-31
Hi Guys, Was just having to re-installing activities to a fresh Sugar (trying to get to test recent Physics patches), and noticed that Calculate is only on ASLO up to version 30! Version 31 was the one supporting the new Sugar toolbars. I guess an official release of it must have slipped through the release cracks. Anyone have any objections to me releasing 31 (it's all in git ready to go)? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fructose Dependencies?
Hi Guys, Should pygame be listed as an official Fructose Dependency (or even Glucose)? I can't find it referenced on the wiki road map pages. Only ask as have just installed Sugar as the desktop in a regular F13 install and it didn't pull in pygame as a dependency, so will cause failures for things like Pippy, Physics, Maze when added from ASLO. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v1 00/10] Journal sorting by file size and creation time.
Hi Andrés, On 27 May 2010, at 03:08, Andrés Ambrois wrote: On Wednesday 26 May 2010 02:39:01 pm Gary C Martin wrote: Hi Andrés, On 24 May 2010, at 01:16, Andrés Ambrois wrote: On Sunday 23 May 2010 04:08:51 pm Michael Stone wrote: Andrés, I've read these patches and tested them locally (with minor changes due to merge conflicts with some of my experimental work) and the results are quite pleasing to me. Thanks! The one issue that I would like you to fix before I merge these patches into my tree is that I would like you to include additional patches for the new icons that your ListViewButton requires to function as intended. (I don't really care whether the new icons are different from the old icons; I merely care that I still have a normal-looking ListViewButton after I select one of your new sort modes rather than the thin grey bar that I currently see.) I only have the filesize icon I made for testing, but I usually stay away from graphics work (I suck at GIMP). Gary, I see you uploaded [0] to the wiki, which is what this patchset is based on. Do you have SVG versions of the icons you put in there? I've built the 3 icons out as SVGs attached, here's PNGs of them as well for easier quick review: Thanks a lot Gary! Attached are a couple of screenshots. Hey, that's looking great. I've been thinking if the ListViewButton icon should change. Yes changing the icon seems helpful, though we'd need to make sure all the 'sort by' icons all are clearly icons representing sorting when seen individually. I'll have a think. Perhaps some simple visual element that's part of all icons so that they are all clearly types of sort. The current icons could become badges to this other visual; or the other visual could be used to badge the current icons. The last column should be sufficient indication of when we are sorting by file size, but there seems to be no other way of distinguishing between creation time and last edit time... thoughts? Perhaps controversial... sorting by creation time could show absolute date strings, rather than relative. When sorting by creation date it could be argued the actual date is more useful (eg, what were the photos I took on my grandmothers birthday, my school opening day, a national holiday). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v1 00/10] Journal sorting by file size and creation time.
Hi Andrés, On 24 May 2010, at 01:16, Andrés Ambrois wrote: On Sunday 23 May 2010 04:08:51 pm Michael Stone wrote: Andrés, I've read these patches and tested them locally (with minor changes due to merge conflicts with some of my experimental work) and the results are quite pleasing to me. Thanks! The one issue that I would like you to fix before I merge these patches into my tree is that I would like you to include additional patches for the new icons that your ListViewButton requires to function as intended. (I don't really care whether the new icons are different from the old icons; I merely care that I still have a normal-looking ListViewButton after I select one of your new sort modes rather than the thin grey bar that I currently see.) I only have the filesize icon I made for testing, but I usually stay away from graphics work (I suck at GIMP). Gary, I see you uploaded [0] to the wiki, which is what this patchset is based on. Do you have SVG versions of the icons you put in there? I've built the 3 icons out as SVGs attached, here's PNGs of them as well for easier quick review: inline: view-lastedit.png inline: view-created.png inline: view-size.png Would love to see a quick screenshot of them in place in the palette – it is usually a bit of a struggle (time wise) for me to apply patches and see for myself. Regards, --Gary Regards, and thanks for all your hard work here, Thank you for reviewing! Michael [0] http://wiki.sugarlabs.org/go/File:Journal_mockup_gary_list_extended_palette.png -- -Andrés inline: view-created.svg inline: view-lastedit.svg inline: view-size.svg___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Physics activity (Was: Release v3 tonight?)
Hi SJ, On 20 May 2010, at 20:34, Samuel Klein wrote: An aside about Physics - it was used with great happiness by the children in Gaza, and features in some of the photos we just got back from there. More as soon as we have release to publish them :-) Can't wait! It's always great to see photos with children actually using specific activities, Maze is usually the one that shows up most often :) Regards, --Gary P.S. Physics is next on my radar to update, now I have more spare time. Craig Macomber kindly posted some refactoring patches I need to test and release, and I'd like to at least add new toolbar support. SJ On Tue, Jul 28, 2009 at 11:49 AM, Gary C Martin g...@garycmartin.com wrote: Hi Asaf, On 28 Jul 2009, at 02:41, Asaf Paris Mandoki wrote: Great! For now, we will just be unzipping the elements / box2d .egg libraries into lib/ (until we figure out how to include setuptools from within an activity). Will commit this within the next few days. Could you put the current elements version there? Once I commit the new save method to the Physics activity, what will be missing to have v3 release? Not much I think. I'd like to do some testing here as soon as your new state saving work is committed; also want to make the icon changes we discussed (irregular polygon, hand grab icon). I haven't seen the translations being committed. Does anyone know if there's a problem with the translation system? Another problem I have is that I got a friend to suggest a French translation but I cant set his suggestions as the actual translated text. I'll take a look once I'm back on-line (travelling today), though I didn't notice any po updates last time I checked. Perhaps the translate push cycle is currently being timed along with the current 0.85.x. 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] [PATCH v1 00/10] Journal sorting by file size and creation time.
Hi Andrés, On 24 May 2010, at 01:16, Andrés Ambrois wrote: On Sunday 23 May 2010 04:08:51 pm Michael Stone wrote: Andrés, I've read these patches and tested them locally (with minor changes due to merge conflicts with some of my experimental work) and the results are quite pleasing to me. Thanks! The one issue that I would like you to fix before I merge these patches into my tree is that I would like you to include additional patches for the new icons that your ListViewButton requires to function as intended. (I don't really care whether the new icons are different from the old icons; I merely care that I still have a normal-looking ListViewButton after I select one of your new sort modes rather than the thin grey bar that I currently see.) I only have the filesize icon I made for testing, but I usually stay away from graphics work (I suck at GIMP). Gary, I see you uploaded [0] to the wiki, which is what this patchset is based on. Do you have SVG versions of the icons you put in there? No, but they soon could be. I'll SVG them, and email to you for inclusion in your patch (view-lastedit, view-created, view-size). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Co-maintaining labyrinth
Hi Bernie, On 19 Apr 2010, at 19:46, Bernie Innocenti wrote: Gary, have you gone MIA? :-) Yea sorry, keeping up on sugar/olpc has recently way exceeded my time available – triggered by a client project taking up my time over the last 6-8 weeks, enough to leave me behind with 3500 unread sugar/olpc emails and no way to catch up. I did make it through 1000 emails over about 12hrs of train travels, but it's a pretty high noise ratio :-( and I'm now just searching for keywords and will discard the rest. Email bankrupt! We really need to get these changes in for this release. I'll ask alsroot to add Jorge as a maintainer of Labyrinth in ASLO so we can upload a new bundle. I'd rather just hand the whole thing over if Jorge will take it – I'm more a lone wolf. Releasing, documenting, testing, and fixing my own code changes is bad enough ;-) Regards, --Gary Hope it's ok with you. If, at a later time, you decide that this feature should have been implemented differently, or does not belong to Labyrinth altogether, we'll work together on a new release. On Wed, 2010-04-14 at 12:39 -0400, Bernie Innocenti wrote: Ping? On Thu, 2010-04-08 at 10:28 -0300, Bernie Innocenti wrote: Hello Gary, at Paraguay Educa we started doing some heavy lifting on Labyrinth: http://bugs.sugarlabs.org/ticket/1829 Can you please review the patch and roll a new update in ASLO? If you don't mind, Jorge would like to co-maintain Labyrinth and issue updates for it on ASLO. If you agree, give write permission to userr jasg in Gitorious. If you'd prefer all patches to go through you, we'd be equally happy with this workflow. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Co-maintaining labyrinth
Hi Bernie, On 20 May 2010, at 17:56, Bernie Innocenti wrote: we're adding Jorge Saldivar as a committer in Labyrinth. Unless you're opposed, we'd like to make him the current maintainer, too. Sure, what do I need to change from my side? In git.sugarlabs.org I could find no way to transfer project ownership, only add extra commiters (which Jorge already is). I did manage to added Jorge as the owner of Labyrinth at activities.sugarlabs.org, so he can now make the official releases. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Silly 0.88 question
Hi Tomeu, On 19 Mar 2010, at 09:56, Tomeu Vizoso wrote: On Tue, Mar 16, 2010 at 03:43, Gary C Martin g...@garycmartin.com wrote: Apologies for the daft question, I was about to build new .xo bundles for some of the activities I'm involved with, even though I don't necessarily have much else to include other than updated translations (big thank you to all translators!). Do I, with my 'activity developer' hat on, sit around until 0.88 officially goes golden master? When should I take time out to do a fresh activity build for including new translations? Is there a 'translation freeze' so I know when to hang about for? Last chance translation saloon and all that... I would think that the closer to that date would be the 0.88 final release. OK, thanks. I'll wait until after Mar 31 before re-building activities I'm involved with (to pick up new strings). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Porting a game to Sugar
Hi Guys, On 17 Mar 2010, at 14:45, James Simmons wrote: Tomeu and everyone, John is trying to follow my instructions on setting up a collaboration test environment for his Sugar Activity. It isn't working for him on F12 and I couldn't get my own test environment working on F11. All the testing I did for the book was on F10 using Salut with the F10 firewall program disabled. I think my instructions are good as far as they go, but there may be security issues preventing them from working. The only thing I can think of that MIGHT help is to use jabber.sugarlabs.org as a server. It seems to me that has worked for me on F11 in the past. The problem I had with it when it didn't work recently was that I could see others on the network but my instances could not see each other. I believe this was caused by configuration on the server that limited the number of active users. If anyone can help him he'd be grateful. The only things I can suggest are: 1). Use jabber.sugarlabs.org instead of Salut. 2). As a *last* resort, downgrade to F10 and disable the firewall. FWIW: under 0.86.x (pretty sure, certainly 0.84.x) I could test local (gabble) in F11 using sugar-jhbuild by launching two instances of sugar using the SUGAR_PROFILE=. environment variable. I've just tried to retest this now that my F11 environment is running the latest Sugar 0.87.x and it will only launch one (the first) instance. Additional invocations for other SUGAR_PROFILE= values just hang with no console output unless you first kill the previous process (so not much use for testing collaboration anymore). SUGAR_PROFILE=1 ./sugar-jhbuild run sugar-emulator pops up file SUGAR_PROFILE=2 ./sugar-jhbuild run sugar-emulator have to kill above process before it appears Any one else seeing this? I can open a ticket if someone tells me which logs would be of use for debugging this. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Width of the TitleEntry widget
Hi James, On 15 Mar 2010, at 10:25, James Cameron wrote: Was not able to see the HIG grid constants defined anywhere in sugar-toolkit or sugar-base. Can you advise, Tomeu? Not sure if it's what you're after, but I was using this to set the size of a secondary toolbar (height) at one point: from sugar.graphics import style self.set_size_request(-1, style.GRID_CELL_SIZE) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Silly 0.88 question
Apologies for the daft question, I was about to build new .xo bundles for some of the activities I'm involved with, even though I don't necessarily have much else to include other than updated translations (big thank you to all translators!). Do I, with my 'activity developer' hat on, sit around until 0.88 officially goes golden master? When should I take time out to do a fresh activity build for including new translations? Is there a 'translation freeze' so I know when to hang about for? Last chance translation saloon and all that... Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sucrose 0.87.7 Development Release --- Release Candidate
Hi Simon, On 11 Mar 2010, at 07:34, Simon Schampijer wrote: Dear Sugar Community, This is our 0.88 Release Candidate! Quick FWIW, just trying to update my sugar-jhbuild in F11 for 0.87.7, seems to pull, update, build fine, and deps check saying it has everything needed, but Sugar fails to launch complaining: .../install/lib/python2.6/site-packages/jarbe/model/bundleregistry.py line 34 ImportError: cannot import mimeregistry Should I go file a bug on this? Regards, --G The Features have been landed, we are in UI and String freeze and only critical bug fixes can be landed by now. Many thanks to the community members that helped in the last days to clean up the review queue and fixing bugs! Now it is time for another big round of testing and fixing the bugs found. Let's go and make this release a big success! See [1] for more 0.88 schedule details. All the details about the code changes in this particular release can be seen at [2]. We are currently doing nightly soas builds [3]. The current build does not contain the 0.87.7 release yet, I will send another note when it landed, though you can certainly start to test the latest build and find possible bugs that has not been fixed with this release. Thanks everyone for your great contributions! In behalf of the sugar community, Your Release Team [1] Schedule: http://wiki.sugarlabs.org/go/0.88/Roadmap [2] Release Notes: http://wiki.sugarlabs.org/go/0.88/0.87.7_Notes [3] http://alt.fedoraproject.org/pub/alt/nightly-composes/soas/ ___ 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] Sucrose 0.87.7 Development Release --- Release Candidate
Hi Sascha, On 13 Mar 2010, at 16:21, Sascha Silbe wrote: On Sat, Mar 13, 2010 at 04:07:31PM +, Gary C Martin wrote: .../install/lib/python2.6/site-packages/jarbe/model/bundleregistry.py line 34 ImportError: cannot import mimeregistry Please try make distclean in source/sugar and building sugar again (sugar-jhbuild buildone -n sugar). Bernies patch to enable maintainer mode got applied recently and should fix this kind of issue, but you need to do a clean build once to pick up that change. Fab, many thanks, that did the trick. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Write - H1 - H4 other minor things
Hi Tim, On 13 Mar 2010, at 06:40, Tim McNamara wrote: Hi all, A few thoughts on the version of Write which I cloned today. H1 ... H4 Do we know how these term has been received by the education sector? No, but more generally, the real push for the new toolbar design landed to solve the very common complaint/feedback that folks could not always work out how to stop an activity, they would often get lost in some other text tabs, and end up going to home view and launch a new (duplicate) activity instance. The new toolbar always shows the Stop icon whatever other toolbars you have visible. The old text tabs use of text meant a higher literacy level was needed, cause additional translation effort, and were quite thin mouse click targets to hit. I wonder if we could change the string literals to something like Major heading Subheading Minor heading. I haven't got too much experience with teaching children in a classroom, but this is closer the language I remember from school. H1 ... H4 seems like something that HTML created. The graduating line thickness of each, and position of the H1 H4 were meant to help ;-) I agree the reference to H is not great; unfortunately nothing better came up at the time. Write really was the worst case in terms of toolbar migration from the old text only tabs to full icons. Icons need to be as language/translation agnostic as possible so we should avoid string literals, unless each local is willing to create custom svg content (I was trying to avoid latin characters where possible, but that gets tough for most text processing functions). Very happy to see refinement/replacement ideas! Export Great feature! Would be great to rotate the arrow on this icon outwards to match the word :) FWIW there are several approaches to exposing Export functionality. Some backstory: In the old Sugar toolbar design, export was hidden as sub items under the Keep icon – but no one really seems to understand the Keep feature correctly (most folks think, and try to use it as Keep a copy), so overloading that misconceived functionality with export was a pretty confusing mental model... So, with the new toolbars export is showing up in the Activity toolbar either; 1) as a single uncoloured Journal icon with arrow pointing towards journal, holding a palette of export formats; 2) as separate 'document' icons (with arrow pointing towards document) for each export format supported (see Walter's TurtleArt). I rather like option 2 and may well move some activities over to that more explicit visual design. Insert/Delete Row I would have + - visual indicators, rather than simply arrows. Yes, I'd hoped to have found something better here also (ran out of time), however the arrows do at least show the direction the rest of the cells move in when making changes. Perhaps there's a way to combine both? That is all. If you're interested, I could probably submit SVGs for review to deal with the last two points. Love to see more icon treatments bounced about, happy to see quick sketches/doodles (easier than building full Sugar HIG correct SVGs every time). Thanks for the feedback! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason
On 13 Mar 2010, at 18:12, Bernie Innocenti wrote: On Sat, 2010-03-13 at 12:07 -0500, Martin Langhoff wrote: On Sat, Mar 13, 2010 at 11:50 AM, Bernie Innocenti ber...@codewiz.org wrote: If you ask me: our recent F11-XO1 builds have reached equal or better quality than build 801, provided you disable automatic power management. Are all activities working, including collaboration? In Gnome, can you actually use FF? Camera? Hopefully, they will complain a little less on the next upgrade to 0.86 and 0.88... Until they finally get used to the idea that software tends to improve over time rather than getting worse. Or we slow down to a rhythm that they can cope with ;-)! Slowing down deployment of new versions might make things even worse! The more changes accumulate, the less familiar the new version will look like, and the more time the users got to get used to the experience provided by the old version, no matter how buggy it was. The Vista vs XP effect. The only way to reduce user adversity to change is getting them used to smooth change by providing a short development cycle with few changes that deliver clear improvements to the user experience in terms of new features or fewer bugs. Agreed, though this argument only really works if the changes each time are easy to install from the user perspective with no loss of data. I wish we were doing much better here. It feels uncomfortable that Sugar 0.84 is already a year old effort as of this week, from its official release, too far ahead of deployments? --G The #1 bait we used to push this new release onto teachers was 3G support. Suffice saying, GSM connectivity is very popular in places with no wired broadband. Unfortunately, this wasn't quite true, bacause many popular Huawei modems use by default a Windows compatible mode in which they show up as mass-storage devices. After backporting udev to F-11, I found out that now users are being sold an even newer model of Huawei modem which is not yet supported by the Fedora 12 version of udev's rules. Teachers blamed the new Sugar for breaking their shiny new modems: they seem unable to distinguish between a regression, a bug in new feature, or an entirely missing feature. Heh... Anyway, now I found a temporary workaround and reported the missing feature upstream: http://bugzilla.redhat.com/show_bug.cgi?id=573250 Too bad it was so easy: support for new devices would have maed a major selling point for the next version of Fedora :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://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] Running SWF files standalone in Sugar? Simple Activity wrapper?
Hi Martin, On 10 Mar 2010, at 14:38, Martin Langhoff wrote: Is there a smart way to run a swf in Sugar, starting it up as an Activity? Hopefully something that works with Gnash and (if installed) Adobe's version? I had the impression the Nepal team had a way to do this... but I can't remember if (early on) they were bashing Flash or using Flash. Karma now is all HTML5 but I thought they had started using some Flash content. See Tomeu's gnash Work: http://blog.tomeuvizoso.net/2009/05/progress-on-sugar-activities-with-swf.html http://blog.tomeuvizoso.net/2009/04/embed-flash-movies-with-gnash-in-your.html The EatBoom activity is pretty easy to swap in your own swf content (just make sure it's not built requiring a very recent Flash, eg must work with Gnash). This is a trivial path to activities for any one who has developed in Flash, though it throws up issues of source visibility and localisation (there are some tricks to make this work reasonably well if any one is interested pushing on this path): http://git.sugarlabs.org/projects/eatboom Regards, --Gary cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Running SWF files standalone in Sugar? Simple Activity wrapper?
Hi Thomas, On 10 Mar 2010, at 15:44, Thomas PLESSIS wrote: I've try this solution too, but it seems that it does not work perfectly with Adobe Flash player (as you said). My game is running, but there're no mouse interaction, no sounds, the introduction popup of the game didn't appears... I'm loosing track of the various iterations of Flash, can you publish your game for Flash 5? Version 5 should certainly run fine**, perhaps 6 should be ok also, published swf's above that I think you'd have a good chance of things breaking (but it probably depends just what fancy feature you're using). ** I developed full time with Flash for about 4-5 years before getting utterly fed up with Macromedia/Adobe feature creep, compatibility breaks, and huge price jumps. I dumped most of their tool sets for more open/standards compliant work flows, so I've lost touch now. Regarding sound, it's very lightly you are currently using a propriety audio codec on storing your sounds. Edit your swf publishing settings and set the sounds to use something like WAV – Gnash can legally support this without big companies trying to chase them down for royalty/licensing payments... Is there any way to run adobe air on OLPC? I've tried but installation does not work, i've some errors with librpmbuild library in the log file. Sorry, pretty sure no way; and remember even if you did manage to install this dependancy somehow, no one else would have it (i.e. nobody would be able to run your game anyway). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity bundles reformation
Hi Aleksey, On 9 Mar 2010, at 18:38, Aleksey Lim wrote: On Tue, Mar 09, 2010 at 03:07:29PM -0300, Jorge Saldivar wrote: btw I guess it is not only problem with uploading 35M on every version but for downloading as well for Paraguay users? Yes, uploading and downloading of 35M is a problem here in paraguay, the internet conexion is so slow.- just a feedback from the field about another usecase where fully-bundled .xo don't work. Out of curiosity – I'm not sure what activity this refers to – what was all the 35Mb of, images/video/audio? Or was this a genuine case of trying to use (large) technologies out side of the agreed Sugar Platform? Regards, --G ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] [ASLO] Binary based activities approving moratorium
Hi Aleksey, So you're auto removing/blocking all .xo bundles from ASLO _now_ that have any binary components and blocking any uploads until folks agree to your terms? Bye bye Physics, Colors (and I'm sure a bunch of other nice activities). Apologies if I mis-read/understood your email. Regards, --Gary On 4 Mar 2010, at 21:04, Aleksey Lim wrote: Dear ASLO uploaders and editors, All activities that where requested to be public (or new versions of activities) with binaries bundled (or with non Sugar Platform dependencies) will be postponed until accepting ASLO editors policy. Policy draft will be based on results of http://lists.sugarlabs.org/archive/sugar-devel/2010-March/022800.html SLOBs request. Later information will be posted to sugar-devel@ with tags [ANNOUNCE] [ASLO] -- Aleksey ___ 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] Showing 3G Connection Errors
On 26 Feb 2010, at 15:59, Tomeu Vizoso wrote: On Fri, Feb 26, 2010 at 13:30, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: I've applied Eben's mockup, I also tried to show the connection errors using an alert inside the palette. This solution has the problem that Tomeu said: when user clicks connect, the palette is hidden and users could miss the notification. Is a solution that doesn't look nice, because the palette should resize to show the errors. We could bring attention to the issue by using a notification, but I'm not really seeing a good solution for this. Any ideas? Is it possible to override the dismissing of the palette when connect is clicked? User sees a 'connecting' positive feedback message in the palette, with the palette only auto-dismissing after a successful connection? Regards, --Gary Thanks, Tomeu On Sun, Feb 21, 2010 at 12:27 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Fri, Feb 19, 2010 at 16:41, Eben Eliason eben.elia...@gmail.com wrote: On Wed, Feb 17, 2010 at 2:27 PM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: Hi, today we don't show all the 3G connection errors. The unique error that we show is the Authentication Error when the Pin/Puk Sim configuration is wrong. In this case we show the error in the connection pallete. When users clicks over the message, the pallete returns to normal behavior. We want to display all the connection errors. How is the best way to show this? I'd recommend showing one or more buttons for dismissing the error and taking any other relevant actions within the palette. Clicking on the text label likely won't be very discoverable. For instance, this error might have two normal buttons for Cancel and Show Settings (assuming something in settings can be adjusted to improve the situation; I don't know enough about what this error means). Hmm, but if the error appears in the palette, and the palette is hidden when the Connect option is clicked, won't most users miss the notification? Regards, Tomeu Eben -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ 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 -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ 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][FEATURE] 3G modem support
On 27 Jan 2010, at 15:25, Tomeu Vizoso wrote: On Wed, Jan 27, 2010 at 16:06, Eben Eliason eben.elia...@gmail.com wrote: On Wed, Jan 27, 2010 at 6:54 AM, Simon Schampijer si...@schampijer.de wrote: I had a chance to apply the latest code that is attached in #1622 and played a bit with a gsm-device. I think we discussed this already in some parts before but I am still not sure about the following: With my device attached I see the modem and hit 'connect' in the device palette. I get no feedback when that action was not successful and what went wrong. And I have no hint that I should set options in the Control Panel. I know we wanted to keep it simple but maybe someone has a smart idea how one could enhance the feedback and a hint to use the control panel to set This sounds like a good time to revive the global notification idea. The design intent there was to each corner of the screen with one edge of the Frame (lower-right would be devices), and to have notification icons (the device icon itself, usually) slide in and out of the corners to grab attention in various cases, such as a failed connection attempt. We also had thoughts about adjusting the contents of the palette in these cases, to contain the error message, and also provide options to resolve the issue. For instance, the GSM device might indicate a failed connection and offer try again and change settings options. I think nailing this in a way that's useful system-wide and in all edges of the Frame will take a bit of thought, but this is a good opportunity to discuss it. I also agree there, but I think that for 0.88 we need something simpler to implement. Struggling to think of a friendly alternative, best I have just now is to keep the palette open until the successful connection is made, you'd be looking at a connecting... message or spinner of some kind (hopefully with an option to cancel); once an error/timeout is reached you are left looking at that message in the palette (until you click away). If the GSM device is not yet configured via the CP, should the device palette just report that as the error (ideally with an entry to jump to the CP, but that can be a future feature). Keep in mind we'll have similar UI needs for other devices needing configuration (i.e. certainly the printer device GSOC project, if it ever make it in to Sugar). Could be nice to offer a jump to the CP option for other devices as well in the future (battery device could provide a jump to the CP energy saving module; wifi device could provide a jump to the CP network module). the options? Didn't Eben suggested once to add an option to be able to launch the CP from within the device? Yeah, I think hot-linking directly to the CP module for variouos devices would be a logical addition. Excellent feature for 0.90. +1 That seems very sane and useful. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review queue
Hi Luke, On 27 Jan 2010, at 15:35, Luke Faraone wrote: On Wed, Jan 27, 2010 at 10:33, Tomeu Vizoso to...@tomeuvizoso.net wrote: What about submitting the patches to a mailing list (which is as simple as invoking git send-email for the submitter) for review instead of on Trac where significant effort is required not only to post but also to locate and inspect them? I like this from the patches POV, but I would miss the tracking part of it. The book Producing Open Source Software talks about the importance of the bug tracker and the mailing list being integrated, I think this is similar to Debian's system? *cough* Launchpad lets you mark bug attachments as patches, so you can quickly do a query to find unreviewed ones. We can do the same in trac with keywords, probably. Can you, (or other Launchpad focused minds) give the dev list a follow-up on the successes (and failures) of the move the SoaS distro made to Launchpad. I'd hoped it would generate some clear data on the matter. It's been some time now and I at least would be very interested in how folks (including wider community and deployments) felt the move went. I'm still concerned that another move for core could kill more contributions than we would gain (assuming there is real measurable benefit in a move) by pulling the rug out under our current core teams workflow (and loosing a month or three trying to correct all the kinks, catch up, and regenerate active participation). I understand there are admin and maintenance benefits to a Launchpad move, but (and no disrespect to the much appreciated work/time Bernie has put in) I'd hate to see the Sugar team effort diluted and distracted by such change of obvious mid term impact. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Deleting an entry in the Journal while the activity is running
On 25 Jan 2010, at 12:01, Simon Schampijer wrote: Hi, I came across the following: There is an option to delete an entry in the Journal entry palette and one in the detail section of an entry. This entry is as well available when an activity is running. Currently when you delete an entry of a running activity the entry gets recreated when closing the running activity. So we do not have any data loss. Two options I discussed so far with Sascha on irc: We could either make the delete option inactive when an activity is running or display an alert when the button is pressed. Any other options? How do you like them? FWIW: Having read Sascha's Walter's and Aleksey's responses, I think I prefer just inactivating the erase UIs for instantiated activity objects, as Simon already mentioned. Perhaps another slant on this would be to change** Journal erase into stop palette entries for instantiated activities? ** I know we're not big on menu items that change function, but I'll be damned if I'm going to suggest adding a stop item to every Journal object palette (and the details view toolbar); the Journal palettes are already way too large/complicated... [though it would still seem to be a valid reinforcement of the object model] Regards, --Gary Personal Note: While I like the inactive-option I am not sure this tells the user why an option is not available. 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] Test protocol for Resume vs. Start new
Hi Christian, On 23 Jan 2010, at 15:01, Christian Marc Schmidt wrote: Hi all: For our meeting at 10:30pm EST today, I put together a draft of a test protocol (in email body below). Please look it over and feel free to edit or add to. Thanks, Christian -- Sugar Home View Concept Testing Draft 01/23/10 Goal: Evaluate the Home view for Resume activity and Start new activity functionality. Protocol: Alternate between two builds, one per student: The current build [Build A], which makes Resume the default action, and a test build [Build B] making Start new the default action. Duration: 5 mins per student Student Profile: Should be a current user (not a first-time user). Age and grade should be recorded, along with duration of overall Sugar experience. 1. Begin at Home screen after boot up 2. Test cognitive model • Describe what you see in this view. • What are the symbols in the ring? • Describe what each symbol in the ring is. • Do you know why the symbols are different colors? • What activity did you last work on? 3. Test pathways [Alternate between two pathways, one per student] Pathway 1: • Show how you would go back to the activity you last worked on. Describe what you are doing. [Student shows pathway to resume activity.] • Now, show what you would do if you wanted to start a new [Write/Draw/Browse, etc.; should be of the same kind] activity. Describe what you are doing. [Student shows pathway to start a new activity of the same kind.] • Now, show what you would do if you wanted to start a new [Write/Draw/Browse, etc.; should be a different activity than the current one] activity. [Student shows pathway to start a new activity different from the current activity.] Pathway 2: • Show how you would start a new activity. Describe what you are doing. [Student opens a new activity.] • Now, show what you would do if you wanted to go back to the activity you last worked on. Describe what you are doing. [Student shows pathway to resume a previous activity.] • Now, show what you would do if you wanted to start a new [Write/Draw/Browse, etc.; should be of the same kind] activity. Describe what you are doing.[Student shows pathway to start a new activity of the same kind.] 4. General questions If you could change anything about Sugar, what would make it easier for you to go back to a previous activity? What would make it easier for you to start a new activity? Is there anything else about Sugar that you would change? I know we've drifted from a usability study model, to a focus group model for practical classroom reasons – but I though Jakob Nielson's latest article was a timely piece worth a quick read through given we are going to be getting feedback from existing Sugar users. Summary: It's more difficult to conduct usability studies with experienced users than with novices, and the improvements are usually smaller. Still, improving expert performance is often worth the effort. http://www.useit.com/alertbox/experienced-users.html Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development
On 22 Jan 2010, at 20:42, Francis Xavier Fitzpatrick wrote: I was just curious as to what set up you all use to develop applications on Sugar? For me it's a combination of: 1) Mac OS X running a VM of Fedora + sugar-jhbuild or (currently) a Blueberry image 2) Sugar on physical XO-1s ...and for coding: 1) Xcode (when pythoning on a Mac) 2) vim (when pythoning on an XO or VM) Using git for version control. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Control Panel Font configuration
Hi Yevlempy, On 19 Jan 2010, at 19:22, Yevlempy(Harsh Verma) wrote: Hi I am working on building the font configuring control panel, it will be a pygtk based control panel extension for handling the fonts. Cool, thanks for volunteering! I have been working on few mockups for designing the font configuring control panel. There are three different kind of rough mockups i am giving here, with there own features and would like your advice and feedback on which to work upon. 1 http://img693.imageshack.us/img693/8779/sugarfontpanel1.png This contains a simple drag menu to adjust the size as starting from 5 to 48 with default 10 and default font Sans Serif .[1]This will also contain a restart sign at the bottom of the frame. This 1st design appeals to me the most. Simple, clean, not too overwhelming. Will there be a mark or label where the default 10 value would be, so that once you move it, you know what the original default was? Am I right in assuming that just the font size is being adjusted (the other designs suggest that the font may also change). For the restart button, other control panels reveal an alert if you try to exit with a changed value (and show a small warning triangle and message at the bottom of the canvas once you change from the current value). inline: require_restart.png Regards, --Gary 2http://img5.imageshack.us/img5/4790/sugarfontpanel2.png This contains the same features as in gnome font panel, the button at the middle of the frame works same as desktop fonts work in gnome, on pressing it we will get various font and size changing options. 3http://img39.imageshack.us/img39/5271/sugarfontpanel3.png The third one will kinda work as the language settings in sugar works i.e a dropdown menu will appear containing the font sizes. [1] By saying this i mean a icon at the bottom that updates the changes in font, the next time system is rebooted Kindly provide your feedback, so that i can start working on it. Thanks, yevlempy -- yevlempy | Harsh Verma Fedora Ambassador(INDIA) http://yevlempy.wordpress.com/ ___ 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] Joke Machine XO-1 build 802
Hi David, On 18 Jan 2010, at 04:05, David Leeming wrote: Can anyone verify that Joke Machine versions 8, 9 and 10 will run on an XO-1 running build 802 ? FWIW I've tested versions 8, 9, and 10 on an XO-1 build 762 with Sugar 0.82.1, I'll need to check later and see if I have an 802 build installed on either of my other test XOs, but I think they're both running much more recent test images (Sugar 0.84.x). Any way, for XO-1 build 762 with Sugar 0.82.1, versions 8, 9, and 10 of Joke Machine tested fine: - launched correctly - allowed viewing the built-in lesson plan (just viewed first page) - allowed creating a jokebook (only tested with text content) - allowed adding a joke (only tested with text content) - allowed reading the jokebook - stopped correctly - resumed correctly from Journal with content just created Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Mockups of Home view showing Start new ring and separate row of icons for resume
Hi folks, Some quick mockups of a Home view idea mentioned in previous discussions. Just intended as extra material for todays irc design meeting. 1) Ring of activity icons reverts to the Start new behaviour; Journal icon is always shown for easier access, with recent activities shown below for quick resuming. Journal icon and recent activities are shown horizontally for better screen balance (at cost of not matching the real Journal list display orientation). http://wiki.sugarlabs.org/go/File:Home_mockup_with_horizontal_journal_and_start_new_defaults.png 2) Same as above except that the Journal icon is top left and a top to bottom resume icon order is used so that recent activities are shown in the same order and direction as is experienced in the Journal list view: http://wiki.sugarlabs.org/go/File:Home_mockup_with_journal_and_start_new_defaults.png Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Mockups of Home view showing Start new ring and separate row of icons for resume
On 16 Jan 2010, at 15:26, Simon Schampijer wrote: On 01/16/2010 04:14 PM, Gary C Martin wrote: Hi folks, Some quick mockups of a Home view idea mentioned in previous discussions. Just intended as extra material for todays irc design meeting. 1) Ring of activity icons reverts to the Start new behaviour; Journal icon is always shown for easier access, with recent activities shown below for quick resuming. Journal icon and recent activities are shown horizontally for better screen balance (at cost of not matching the real Journal list display orientation). http://wiki.sugarlabs.org/go/File:Home_mockup_with_horizontal_journal_and_start_new_defaults.png 2) Same as above except that the Journal icon is top left and a top to bottom resume icon order is used so that recent activities are shown in the same order and direction as is experienced in the Journal list view: http://wiki.sugarlabs.org/go/File:Home_mockup_with_journal_and_start_new_defaults.png Regards, --Gary Hi Gary, thanks, I think that helps to better visualize this proposal. The problem I see with this design is, that the title of the activities does lack. I guess you would see it in a palette when hovering over it. But that would be as quick as going to the Journal directly. One could imagine displaying the title in the vertical layout, but that would make the home view crowded. Just a few thoughts, so I do not forget my first impressions ;p :-) Here's a 3rd for the mentioned double ring of activity icons; inside non-colour icons for Start new behaviour, outside ring of coloured icons for Resume behaviour. Journal icon shown at top of ring for easy access (note that its coloured icon in the Start now ring is now out of place): http://wiki.sugarlabs.org/go/File:Home_mockup_with_double_ring_of_start_new_and_resume.png Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity
On 11 Jan 2010, at 20:44, Walter Bender wrote: On Mon, Jan 11, 2010 at 3:32 PM, Simon Schampijer si...@schampijer.de wrote: On 01/11/2010 06:12 PM, Wade Brainerd wrote: My feeling regarding all this is that the problem is deeper than finding a way to Resume Latest or Start New from the home screen. IMO, the whole idea of Resume Latest is broken and needs to be ditched. The Journal is the place to resume activities. We need to make the Journal more discoverable and usable instead of trying to mash its features into the home screen. My findings are as well that the Journal is the natural place to resume an activity. The home view is the natural way to create a new activity, since it contains a graphical representation with the available activities. I think resuming is a secondary option we can provide, but should not be the default option when you click on the icon. To overcome the issue of constantly creating new activities I liked the 'open the full palette on left click' option. The learner is then provided with options to choose from. I like this too. It is worth mentioning that on non-OLPC-XO hardware, there is no easily discovered (or typed) dedicated key or mouse movement to get you to the Journal--one of the reasons we have also discussed having the Journal icon always available in the Home View (I am in favor of always at the bottom of the circle). All of these changes collectively may help. I've been trying to stay out of this discussion so far, watching for what might stick. So summing up so far: - Always show Journal in the home ring, though I'd favour having it as the first item, so that would make it always at the top of the circle ;-) - Home view reverted back to the 'start new' activity focus, all icons are un-coloured. - Single left click always reveals the palette with the 'start new' item at the top and 'resume' items below. Some minus design points here as 'start new' and 'resume' will both become 2 clicks away, and take extra palette cursoring dexterity to reach. You could argue both 'start new' and 'resume' will drop to second level features with 'activity palette information' becoming the top level home feature. Being able to read (some of) this palette text would also now be required, so our 'low floor' just got a little higher :-( I do agree though that this provides a compromise between reducing Journal spam and preventing the unintentional overwrite of existing Journal work by making the choice explicit. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] 'Resume' vs 'Start a new' Activity
Hi Simon, On 13 Jan 2010, at 16:38, Simon Schampijer wrote: Hi Gary, thanks very much for your feedback. On 01/13/2010 02:15 PM, Gary C Martin wrote: On 11 Jan 2010, at 20:44, Walter Bender wrote: On Mon, Jan 11, 2010 at 3:32 PM, Simon Schampijersi...@schampijer.de wrote: On 01/11/2010 06:12 PM, Wade Brainerd wrote: My feeling regarding all this is that the problem is deeper than finding a way to Resume Latest or Start New from the home screen. IMO, the whole idea of Resume Latest is broken and needs to be ditched. The Journal is the place to resume activities. We need to make the Journal more discoverable and usable instead of trying to mash its features into the home screen. My findings are as well that the Journal is the natural place to resume an activity. The home view is the natural way to create a new activity, since it contains a graphical representation with the available activities. I think resuming is a secondary option we can provide, but should not be the default option when you click on the icon. To overcome the issue of constantly creating new activities I liked the 'open the full palette on left click' option. The learner is then provided with options to choose from. I like this too. It is worth mentioning that on non-OLPC-XO hardware, there is no easily discovered (or typed) dedicated key or mouse movement to get you to the Journal--one of the reasons we have also discussed having the Journal icon always available in the Home View (I am in favor of always at the bottom of the circle). All of these changes collectively may help. I've been trying to stay out of this discussion so far, watching for what might stick. So summing up so far: - Always show Journal in the home ring, though I'd favour having it as the first item, so that would make it always at the top of the circle ;-) That sounds like a good compromise to me. Side-Note: While thinking about it, Walter mentioned that the Journal is not as accessible, especially on non XO-hardware. Another thing which is hard to discover is the frame. I see a lot of kids having issues here. This is one reason why the Journal is hard to find but as well to see which activities are open at the moment. Oh no, don't bring up discoverability of the frame! One problem at a time ;-) - Home view reverted back to the 'start new' activity focus, all icons are un-coloured. Yes. - Single left click always reveals the palette with the 'start new' item at the top and 'resume' items below. Some minus design points here as 'start new' and 'resume' will both become 2 clicks away, and take extra palette cursoring dexterity to reach. You could argue both 'start new' and 'resume' will drop to second level features with 'activity palette information' becoming the top level home feature. Being able to read (some of) this palette text would also now be required, so our 'low floor' just got a little higher :-( I do agree though that this provides a compromise between reducing Journal spam and preventing the unintentional overwrite of existing Journal work by making the choice explicit. I tested today, to have the left click reveal the palette directly (patch attached for those who want to try it out). You are right, that you need two clicks, now. For me it would be ok, to just revert the behavior to 'start new' by default and leave it to the merchandise (including teacher) to set the message: resume is in the Journal. So resume from home view becomes the secondary palette action, I'd be OK with that, though it leaves outstanding the issue of Journal spam for those who just start new activities every time. FWIW I'm not equating 'Journal spam' and the (more serious) 'out of storage space' state. The largest consumers of storage I'm aware of are a few monster sized activities kids may try and install**. ** random thought, is it feasible to have Browse not start a download unless there is enough storage space? Side-Note 2: I figured today that our use of left click is inconsistent. In the home view clicking on the activity icon does choose one default option on left click. Clicking on the XO icon does not have a meaning, you need the palette. Same is true for clicking on a buddy icon in the neighborhood or group view. The 'add friend' is not the default. However, clicking on an activity icon in the neighborhood view does join it, clicking on an AP does try to connect by default. Yep. I believe we've had this discussion before :-) I seem to remember Eben agreed that what was always intended was for any button that did not have a primary click event should have the click event reveal the full palette. So clicking on the big XO icon should instantly show the palette; clicking a buddy in the neighbourhood should just show the full 'add friend' palette, etc. That way something would at least always happen when a user clicks on a button. I did
Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow
Hi Tomeu, On 20 Dec 2009, at 19:31, Tomeu Vizoso wrote: On Sun, Dec 20, 2009 at 17:54, Sean DALY sdaly...@gmail.com wrote: Many thanks Luke, a good catch as developers are difficult to reach in fact I've been thinking of placing such an ad with the Ad Bard network after our December free run for Blueberry is done - they cycle ads on dev-oriented sites Before we ask the designers to work on this, we need to decide what to write Should we seek Activity, or platform devs? Maybe first activities? Makes an easier start. Python or gtk+ experience should be enough. Tomeu, what do you think a developer would react to? Something like Got Python? Change the world!? Not sure how much room we have. Also, developers are a quite heterogeneous bunch when it comes to motivation, can we target a defined profile? e.g.: sugar labs logo Nonprofit volunteer org seeks talented developers interested in improving the lives of Sugar's second million children. Join us! URL join.sugarlabs.org Sounds pretty good, a reference to concrete technologies as python and gtk are may help, because developers tend to group around the technologies they use and like. Just a FWIW: gtk was a pain word and kept me away from tinkering for some time, Hey Python, fab; oh hell GTK+, not another random GUI toolkit to learn. But then again, I don't really consider myself an OSS developer so am likely an outlier. Regards, --Gary Regards, Tomeu thanks Sean On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone l...@faraone.cc wrote: Hi, StackOverflow, a popular programmer Q/A site, is soliciting adverts from FOSS projects looking for developers. Does anybody have some spare time to whip up a 220px by 220px image? -- Luke Faraone http://luke.faraone.cc ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing ___ Marketing mailing list market...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/marketing -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ 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] [IAEP] Future of Zero Sugar
On 15 Dec 2009, at 13:36, Aleksey Lim wrote: On Tue, Dec 15, 2009 at 10:52:56AM -0200, Tomeu Vizoso wrote: On Tue, Dec 15, 2009 at 04:07, Aleksey Lim alsr...@member.fsf.org wrote: On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: I strongly agree w/ tomeu on this. Making Sugar easier to contribute to isn't anywhere near the top of the list of requested features by our kids and teachers in Nepal. The far and away most requested feature by teachers in Nepal is a mechanism for kids to turn in homework. I am not talking about invasive testing here. The typical Nepali teacher just wants to know which students out of 50-70 kids are failing to understand basic concepts. I absolutely agree with such points, but: * as a 3rd party developer, I don't see such teachers requests listed somewhere on wiki, that let me see what can I do and peek most interesting/suitable-for-my-skils/etc task I'm painfully aware of this situation and have been spending my energies on this problem for already a good while. Our colleagues at Uruguay and Paraguay are already working on upstreaming their developments, but are also going to work with us in identifying the most pressing needs in deployments. Have already some ideas about what to work on, how do you think we should track them? Since we have nothing for now, any movements are welcome. In my mind having wiki page(one page with links to subpages, or category) is enough, the major things I'd look for is is having priority(deployment schedules etc), summary/description and contacts (having irc contact would big plus). * I'm feeling huge discomfort as a developer when I need to package binary blobs to my .xo, w/o instrument which let me unify installing/upgrading process of such non-SP/specific-to-my-activity dependencies I agree this is a problem, but also think that many activities shipping binaries don't actually need them. Bindings for libraries can be written in ctypes, without need to use a .so. * I'm feeling less(but still big) discomfort as a developer when I don't have standard method to share my core related changes, for-testing-purposes/to-show-what-I-have-in-mind, well please, attach my cloned repos, install them still works but not so attractive for users What about generating a SoaS (or Trisquel, etc) image with such changes? This is something that can be done today without so much trouble. * implementing Zero Sugar initiative, in my mind, is providing fishing-rod for developers/doers instead of feeding users thus has prime priority I don't see things so black and white. I have been working on this same problem for a while now (view source key, extensions, etc) and our users are taking advantage of at least the extensions facility. We are going to see patches very soon for keybindings, device icons and control panel sections. And that code can be already deployed without waiting for upstreaming because of the extensions mechanism. So _today_ we have empowered users that are deploying shell extensions without disrupting the rest of the shell, and simultaneously are working with the community and sharing the fruit of their work. The technical part has been in place since a year ago, but the trigger for this to happen has been actually social interaction. There's no point in making our platform super-hackable if we don't work as well in the non-technical part of the problem. Just to be clear, the technical part of Zero Sugar is http://wiki.sugarlabs.org/go/Activity_Team/Services its not something huge, just a set of declared rules how to work with external(to activity or SP) dependencies. Code is ready for first release usage and I'm going to spend this week(and looks like next) to prepare proper docs/tutorials/infrastructure and remove blobs from all ASLO activities. Woooaaahhh... Removing binary blobs from all ASLO activities!? Now I'm no fan of having to include a binary blob (I avoid it if I have any choice), but Sugar is not targeted at an environment of always on internet cloud computing. An activity must be a self contained, sharable bundle for 99% of our users, needing no downloads of eternal resources at first run/install. I'm most happy to see some smooth fallback mechanism for the 1% running some hokey-pokey hardware/software platform, but resources (binary or otherwise) for our majority use cases should live inside activity bundles. Regards, --Gary That's my strong intension and not only as a developer but also as a ASLO editor - I think we should stop posting bundled binaries to ASLO as soon as possible. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sharing work across XOs/SOAS
Hi Sascha, On 15 Dec 2009, at 18:05, Sascha Silbe wrote: On Tue, Dec 15, 2009 at 12:36:43PM -0500, Gerald Ardito wrote: 1. Create the game. 2. Save it to the Journal FWIW: This step is automatic (activities save their state to the Journal whenever you switch away from them). Unfortunately not in the case of Memorize (you actually have to 'save to journal', and then 'load from journal' before you can even play your own just created game in the interface)! :-( :-( Simon was interested in re-designing/building this when we worked on the new toolbars (we did some cycles of ideas), but other 0.86 events overtook and Memorize never had it's toolbars updated/reworked. Needs some careful design planning and rework to switch between play and edit mode in a natural, understandable way. Regards, --Gary 3. Go to Browse CU 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sounds in Speak
On 14 Dec 2009, at 15:30, Aleksey Lim wrote: On Tue, Jul 28, 2009 at 05:48:39PM -0700, Sameer Verma wrote: Hello everybody, This afternoon, I had an interesting conversation with a Montessori teacher, about Speak. She asked me why Speak says a when a is pressed and not the *sound* of the letter a. Montessori teachers teach the shape and sound of letters first, and then the name of the alphabet. I did not have an answer for her, but I wondered if it would be possible to have an option in Speak to do so. not sure it could be done in existed Speak(it just passes string to speak engine). But it could separate activity or mode in Speak which teaches alphabet. FWIW: I had a go at this quite a while back. At the time, on an XO-1, I found the latency was much to high for even quite slow typing. The sound was delayed arriving, often stuttered, and typing became quite difficult due to the poor responsiveness. Not sure anything has really changed since I last tried. Regards, --Gary I'd imagine that the sound of the letter would vary depending on language, right? cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ 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] File Share Activity
Hi Justin, On 13 Dec 2009, at 01:56, Justin Lewis wrote: Thanks for the feedback Gary. - Is it possible to create your git repository on http://git.sugarlabs.org/ or is it already somewhere public? Yep, it is currently on Gitorious (http://gitorious.org/jlew/xo-file-distro). I can move it to git.sugarlabs.org if that would be better for everyone in the sugar community. Thanks, that rep's fine for me if that's where you're already set-up to work :-) - You named your bundle FileShare-2009-12-11.xo, I'd just go with FileShare-1.xo to stick with current convention, and start bumping up the version integer for each new release from now on (that way Sugar will happily upgrade a previous version correctly). Ok, I'll do that next time I release a build. I will try to put download buttons next to each file and convert my current download button into a download all (I think I will still have it download all the files as separate objects but have it download them all automatically to keep the system simple). Cool. Will keep an eye out for your next build! And feel free to any UI/design feedback as well. This is my first use of gtk, so if you have any suggestions, please let me know. Yea, gtk is still a huge amorphous blob of unexpected classes and methods to me as well, the only way I get by is with constant reference to the class documentation, poking through other people's code, and living by what wits I have :-) Took me the best part of half a day just to work out how to add an optional scrollbar to a text label widget! Regards, --Gary Justin Lewis On Sat, Dec 12, 2009 at 1:28 PM, Gary C Martin g...@garycmartin.com wrote: Hi Justin, On 12 Dec 2009, at 16:17, Justin Lewis wrote: I am not the author of Bundle. If people would like to test it, fine by me. This was written mainly to get some sort of file transfer system on the olpc. Another reason is on the 84, it seems you have to pick a file and send it to a specific user, where this system lets you pick files and then send them to anyone who has joined. +1! Being able to publish a number of items for download is a very useful feature (imagine a teacher sharing several resources for a specific class lesson). Thanks for stepping up to do this. There has been talk on Journal at some future point providing something similar, but to be honest a really clean/simple/robust activity would be better, why? 1). Journal could be kept clean and simple instead of trying to overload it with multiple types of sharing features (technically possible, but the design will just get more and more unusable until it looks like a Microsoft office product). 2). As a separate activity it can be developed out side of the Sucrose development/release cycle and team. 3) As a separate activity it can be used by folks not running the latest and greatest version of Sugar (think a generation of hundreds of thousands of kids who use 0.82, and perhaps only ever will). I have not had much testing with it yet so if they would like to test it, that would be great. I still have a few things I need to work on, but any feedback would be great. I'll try and give it some testing, I might have some UI/design type feedback as well if that's OK with you? ;-) Couple of quick questions: - Is it possible to create your git repository on http://git.sugarlabs.org/ or is it already somewhere public? - You named your bundle FileShare-2009-12-11.xo, I'd just go with FileShare-1.xo to stick with current convention, and start bumping up the version integer for each new release from now on (that way Sugar will happily upgrade a previous version correctly). Thanks again for having a go at tackling this one! Regards, --Gary P.S. I think Tomeu mentioned the Bundle activity (I never saw it correctly working when I tested), as there could be a workflow where basically a zip of a bunch of Journal entries could be created by an Activity, and then transferred in one go as a single compressed file (or perhaps in chunks like a torrent). Your File Share activity could potentially subsume this workflow, or do something similar i.e. could provide Download All as the primary button that would trigger a downloading of a single zip of everything; then have little download buttons next to each file if folks want to get just a few (and avoid the need for users to have to select file rows and click on a separate download button). Sorry just rambling, only looked at your screen shot so far ;-) -- You received this message because you are subscribed to the Google Groups FileShareActivity group. To post to this group, send email to fileshareactiv...@googlegroups.com. To unsubscribe from this group, send email to fileshareactivity+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fileshareactivity?hl=en
Re: [Sugar-devel] File Share Activity
Hi Justin, On 12 Dec 2009, at 16:17, Justin Lewis wrote: I am not the author of Bundle. If people would like to test it, fine by me. This was written mainly to get some sort of file transfer system on the olpc. Another reason is on the 84, it seems you have to pick a file and send it to a specific user, where this system lets you pick files and then send them to anyone who has joined. +1! Being able to publish a number of items for download is a very useful feature (imagine a teacher sharing several resources for a specific class lesson). Thanks for stepping up to do this. There has been talk on Journal at some future point providing something similar, but to be honest a really clean/simple/robust activity would be better, why? 1). Journal could be kept clean and simple instead of trying to overload it with multiple types of sharing features (technically possible, but the design will just get more and more unusable until it looks like a Microsoft office product). 2). As a separate activity it can be developed out side of the Sucrose development/release cycle and team. 3) As a separate activity it can be used by folks not running the latest and greatest version of Sugar (think a generation of hundreds of thousands of kids who use 0.82, and perhaps only ever will). I have not had much testing with it yet so if they would like to test it, that would be great. I still have a few things I need to work on, but any feedback would be great. I'll try and give it some testing, I might have some UI/design type feedback as well if that's OK with you? ;-) Couple of quick questions: - Is it possible to create your git repository on http://git.sugarlabs.org/ or is it already somewhere public? - You named your bundle FileShare-2009-12-11.xo, I'd just go with FileShare-1.xo to stick with current convention, and start bumping up the version integer for each new release from now on (that way Sugar will happily upgrade a previous version correctly). Thanks again for having a go at tackling this one! Regards, --Gary P.S. I think Tomeu mentioned the Bundle activity (I never saw it correctly working when I tested), as there could be a workflow where basically a zip of a bunch of Journal entries could be created by an Activity, and then transferred in one go as a single compressed file (or perhaps in chunks like a torrent). Your File Share activity could potentially subsume this workflow, or do something similar i.e. could provide Download All as the primary button that would trigger a downloading of a single zip of everything; then have little download buttons next to each file if folks want to get just a few (and avoid the need for users to have to select file rows and click on a separate download button). Sorry just rambling, only looked at your screen shot so far ;-) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
On 10 Dec 2009, at 14:58, Eben Eliason wrote: On Thu, Dec 10, 2009 at 7:54 AM, Paul Fox p...@laptop.org wrote: benjamin wrote: Hello, On Wed, 2009-12-09 at 22:43 -0500, Art Hunkins wrote: I've now got whole-screen scrollbars working well in my music activities, but I'd like to make the bars wider. The automatic settings (as used in most activities) are too narrow for my taste. First of all I would like to say: Please do not play with themes, just because you don't like something that much ... (especially should you dislike them in general and not only in your activity) Other than that. IIRC the reason for the scrollbars to be that narrow was the plan to use the Grab-Key+Touchpad for scrolling. This means that the main purpose of the scorllbar is to show the position, but not to use the handle itself for scrolling. and just in case it's not clear from the above -- the grab-key+touchpad feature is present in XO-1.5 releases, and available for the XO-1 if the olpc-kbdshim package is installed. I was a proponent for grab scrolling in the early days of Sugar at OLPC. However, it seems clear now that, without customized hardware (which was the assumption back then) this solution simply isn't viable as an intuitive and discoverable way to navigate content. I think that retaining the functionality via some other mapping or shortcut would be nice (especially to offer the functionality as designed on the XO hardware itself), but I don't see reason not to improve the usability of Sugar on all platforms by increasing the scrollbars to a more manageable width. I'd argue the narrow scrollbar width is still a relevant design choice, being there to indicate document length and current view location into it. Most non-XO hardware platforms are very likely to have their own hardware support for a scroll wheel type behaviour. I very rarely need to drag a scrollbar these days, it's all two fingered scrolling which works fine in Sugar on a VM (though we could do with a control panel to adjust sensitivity). Regards, --Gary Of course, in addition to this we should make sure that wherever possible the scrollbars are given every last pixel up to the edge of the screen, so that they become, effectively infinite in width (or height, when horizontal), thus making them difficult to miss. Eben paul =- paul fox, p...@laptop.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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.86 Favourites View behaviour - Browse
Hi Tim, On 6 Dec 2009, at 21:28, Tim McNamara wrote: Am running Sugar 0.86.3. In general, I like how Sugar now opens the most recent item from the Journal, rather than starting a brand new file. However, I think with Browse - it's still useful for this to default to the homepage. Is there an easy way to make this happen? Do other people agree? I'm not sure I'd like different activities in the ring able to override the resume / start new behaviour. Could be quite unexpected and confusing to learn the behaviour (you'd have to remember which activities did what). One trick you might not have found yet is that holding down the Alt key. It will toggle the home favourites view resume / start new behaviour, so you can hold Alt and click on Browse to get a new fresh activity instance at the home page. FWIW: in early versions of the new home feature (in 0.83 I think), there was a check box in the Favourites view menu that allowed you to pick one or the other resume / start new behaviours. Hope that helps a little :-) Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking feedback on sketch of a new color selector
Hi Walter, On 7 Dec 2009, at 17:52, Walter Bender wrote: On Mon, Dec 7, 2009 at 12:39 PM, Gary C Martin g...@garycmartin.com wrote: Hi Walter/Simon, On 7 Dec 2009, at 10:37, Simon Schampijer wrote: On 12/06/2009 11:05 PM, Walter Bender wrote: On Sun, Dec 6, 2009 at 8:54 PM, Simon Schampijersi...@schampijer.de wrote: A few questions: - in the Feature page you mention the 'random selector', is this option still available in the latest design? This is still in the new design in that I didn't remove it from the code. (If you click on the central XO icon, you get a random color as before.) It is a decision I leave to the design team. Ok. Maybe the design team want to comment if they think that the random functionality is a good one to have. Sorry, not quite following the 'random functionality' comment. Just to check, my understanding that 'forwards' and 'backwards' are hooked up to change a seed value used for a random calculation of the fill/stroke colour choices (an almost infinitely large carousel of random choices, left or right). Where the buttons act something like the below image to maintain the current behaviour where clicking the large Xo icon still progresses forward: Regards, --Gary Just to bring clarity to what I have implemented so far: (1) clicking on the left xo icon or the icon causes the color pair to cycle to the previous color pair in the list of colors found in xocolor.py (2) clicking on the right xo icon or the icon causes the color pair to cycle to the next color pair in the list of colors found in xocolor.py (3) clicking on the large xo icon causes a random color pair to be selected from the list in xocolor.py and resets the index used in #1 and #2. (Essentially the same as the present behavior). There is also a hidden button (a temporary kludge) to undo (useful for undoing the random selection). The intention is to associate a key (Ctrl-z) to the undo function. A... Hmmm. Now, for me I think that implementation would be rather an unexpected/confusing behaviour, click the large XO and the little ones would seem to randomly change as well. Now I understand why the videos you posted caused me some confusion (I was expecting 3 colour choices in the xo XO xo to always scroll left or right). Do you have a clone somewhere on git.sugarlabs.org I can look at? As per previous button mockup image, marching through a random set, left or right, would seem to provide the existing behaviour, plus the equivalent of an undo, and a mini-me preview for what would be next/before undo. Sorry for the confusion. Of course, you can still back out of the whole thing by canceling the changes in the manner currently supported: hitting x instead of ✓ on the panel. Comments on the above: (a) The order of the colors in xocolor.py is reason to cycle through. If you get a close approximation from random, you can fine-tune your selection by searching through adjacent colors. But only fine tune in 1 dimension? Would have to scroll a long way to see a change in the other fill/stroke colour. (b) I don't know how to get icons that can both be recolored and use accelerator keys, hence the kludge above. For accessibility purposes, it would be nice to add short-cuts to all the buttons in the control panel. (c) Gary, I tried the stacked icons vs running them in a row. The stacked icons didn't do it for me (or Eben, as I recall). The current configuration is xo XO xo. OK, sorry missed that. FWIW, I think my main objection was that for the control panel positioning case, the XO was no longer central, being off centre to the right. I guess this could be easily fixed by moving the xo XO xo widgets down below the grey text Click to change your color: so the text does no longer pushes the widgets off to the right. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
Hi Joshua, On 30 Nov 2009, at 06:23, Joshua Minor wrote: Looks great to me. Can you wrangle doing a release? My dev/testing environment is way out of date. I have a gameplay question regarding the 3 local player mode currently implemented. Are the local users meant to be cooperating or competing with each other? I notice that the level moves on if any one of the 3 local players reaches the goal (this suggests 3 folks on one computer are cooperating to potentially compete against remote player or players). Just wondering if that was the intended behaviour. I only ask as I'm pondering possible Journal state usage. Maze level, seed is an obvious one I currently find frustrating as I often want to carry on from previous rounds; Journal state could also keep a leader board of previous players (or teams) for the last N levels, i.e: - maze would keep levelling up as it does now - after N levels a quick leader board animation could show who (or teams) did best (think a quick Pacman chase animation depending on who's doing best). - there would be no total score kept so kids could join at any time and soon catch-up Still tweaking/thinking, but FWIW here's the current basic face rep: http://git.sugarlabs.org/projects/maze/repos/garycmartins-face-clone In various sizes, the 3 local player faces currently look like this: inline: huge.png inline: large.png inline: medium.png inline: small.png inline: tiny.png Regards, --Gary P.S. For the record I'm still very interested in a face avatar identicon generator to potentially replace all uses of the XO buddy icon throughout the Sugar UI, so face variations would augment the current colour identity metaphor. -josh On Nov 29, 2009, at 8:32 PM, Gary C Martin wrote: Hi Josh, On 29 Nov 2009, at 21:22, Joshua Minor wrote: The border size change sounds fine. Just check that it works okay when the maze is relatively large. (Hit + a bunch of times to get a large maze). When you use the other sets of keys to control your blip in the maze, you get other shapes (circle, triangle, etc). I tried a bunch of shapes, but even something like a star gets lost when the maze is even slightly large. Faces would probably get lost too. I did try a number of Maze levels to check how well the face details scaled. Here's a more exhaustive set, it's a pity pygame doesn't seem to offer too much in terms of anti-aliasing, but I think the face still survived the scaling pretty well (and could fit in a cube/triangle if needed): maze_face_size_test.png The face idea is pretty neat. My other activity, Speak, has a bunch of face editing stuff in it. I think that would be great to factor the face editor out into the Sugar layer (to the same place where you edit your colors). It would be more like the Mii editor in a Nintendo Wii - where your character shows up in whatever game you are playing. You can see a remake of it here: http://www.myavatareditor.com/ Hit the random button a few times :) I'm not sure we would want to introduce a more complicated Sugar UI for this. If you take the current buddy colour picker and have it just generate different face shapes along with the two random colours, kids could just click through until they find a colour and face shape avatar that they like. Walter recently posted an 0.88 working feature proposal that allows undo for the buddy colour picker (actually more like previous -- large current icon -- next), so as not to be frustrating when if you pass over one you liked and want to go back. That would work well if face shape was added to the identity mix. I had not heard of identicons before - neat! Lots of different types out there based on hashes of either IP addresses or email addresses. Mainly tessellated/rotated geometric designs, but there are a few examples of monsters and faces (though too fussy for my liking, they would need to be clean/strong stroke/fill designs for Sugar UI use). Just bouncing ideas about to see if anything sticks :-) Regards, --Gary -josh On Nov 29, 2009, at 11:39 AM, Gary C Martin wrote: On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another
Re: [Sugar-devel] 0.84 maintenance
Hi Tomeu, On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/12/1 Daniel Drake d...@laptop.org: Also on this topic - we will certainly run into issues where activities themselves progress beyond the Sugar-0.84 platform; if activity authors could work to minimize these cases (i.e. keep backwards compatibility, remain responsive to bugs) it would help us avoid a huge headache, and will help your activities spread to various corners of the globe. I think this is a current policy of the activity team? The word policy seems a little official, but yes, I'd certainly not want one of the activities I help maintain to intentionally break under 0.84 (or 0.82 for that matter). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Lim alsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature Process for Activities was (Re: Sugar Digest 2009-11-30)
Hi Simon, On 4 Dec 2009, at 11:14, Simon Schampijer wrote: On 11/30/2009 10:56 PM, Simon Schampijer wrote: On 11/30/2009 09:28 PM, Walter Bender wrote: [snip] 2. Simon Schampijer, the Sugar Release Manager, has put together a detailed set of pages in the wiki outlining our policy [[http://wiki/sugarlabs.org/go/Features/Policy]] and process [[http://wiki/sugarlabs.org/go/Features/Feature_Template]] for proposing new Sugar features. The main goal of the feature policy is to make systematic and predictable the process by which community ideas on how Sugar should evolve get transformed into actionable proposals. Simon and I have been discussing the scope of this policy in IRC. It is appropriate and customary for the Release Manager to set policy, but I would like to see the process followed more generally, as it provides a structure that the Activity Team can also leverage as part of the on-going Sugar activity update process. Activities updates wouldn't be tied to Sucrose release cycle, but it provides a nice framework for community feedback and makes clear the roles of ideation, implementation, and packaging and maintenance. Of course I am happy if the Feature Process Framework will be used as well by the activity team. So far I only thought about the Sucrose release using the Framework. A process gets to be something useful - the moment it is used. For the Sucrose release we have been seen use and it has delivered some value, too. Is the activity community interested in using the Framework, too? If yes) There is the part in the wiki, where we describe what is needed to get a Feature in a a Sucrose release [1]. How would the activity team describe that part? What is the policy for getting an activity Feature into an activity release? Please discuss here, and/or use the talk page to describe the activity team policy. We can merge it then in the main page. Direct edits are not that easy for me to keep a track on. Thanks, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle I moved the activity feature specific part out from the main policy page. As it was only described for proposing a feature and all the rest of the page was about how to get a Feature included into a Sucrose release, i found it a bit confusing (activities are not part of Sucrose). As I said, there might be some value for the activity team to use the Feature Framework, too. As the main goal is: The main goal of the feature policy is to make systematic and predictable the process by which community ideas on how Sugar should evolve get transformed into actionable proposals. However we need to define the process on how to get the Feature into an activity release. I sketched something up here on the talk page: http://wiki.sugarlabs.org/go/Talk:Features/Policy Activity maintainers please comment, Hmmm, I'm not sure what value is added by trying to formally document this. I understand the need for a strict process in Sucrose as there are many authors working on different components that have to end up forming a whole product. For activities, most have an individual author, or perhaps several interested individuals (forming ad-hoc teams when needed e.g. Asaf, Brian, and myself pooled together to work on the last couple of releases of Physics). As an activity maintainer, I watch the mail-lists/blogs for useful feedback, try to keep an eye on where Sucrose and other activities are going (e.g new toolbar support to improve usability, Journal send to feature requiring that activities to set a MIME type for their objects), and use bugs.sl.org trac tickets to work through formally reported bugs and feature suggestions. Something like Browse is perhaps an exception. It's a critical activity for Sugar as it is part of so many users work flows – downloading assets, external research communication, and uploading of final work – any major changes/additions to it's features may impact many users. In such a case it is likely in the activity author's interest to seek community feedback on an idea before making a significant change. That could be via the mail-lists, or a wiki page if that's more appropriate. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removing Log and Terminal from favorites view
Hi Daniel, On 4 Dec 2009, at 11:15, Daniel Drake wrote: Hi, For the OLPC builds we're removing Log and Terminal from the default favorites view. Is there any interest in making this change in upstream sugar too? The reasons being that these activities are confusing/useless for young children, but are left discoverable in the list view for older users as well as other people who end up working on more technical tasks with the laptops. +1 makes sense, the default favourite ring content should be kept to a nice low number of quality items so as not to overwhelm new users and give a good first impression. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
On 3 Dec 2009, at 19:38, Raul Gutierrez Segales wrote: On Thu, 2009-12-03 at 14:25 -0500, Eben Eliason wrote: On Thu, Dec 3, 2009 at 1:44 PM, Martin Abente mabe...@paraguayeduca.org wrote: Today i finished the systray device icon. (but i still need the icon graphic... any artist around?) I'd be happy to sketch some icons. Do you have any suggestions or examples of what an appropriate icon might be for a 3G modem? As far as I know, they come in all shapes and sizes—including, of course, cell phones—and I'm not sure there is an accepted or easily recognizable form for an icon. Some cultural background: Here in Paraguay people call 3G modems a soap (jabón) since almost all of them are small and it has a sopa-like shape. You hear it all the time can you lend me your soap.. Perhaps a little soap might be meaningful for other deployments? Maybe not :) Raúl P.S.: IIRC a telco here started a marketing campaign in which they coined that phrase (3G modem == soap). For what it's worth, during the G3 thread I've always pictured a simple mobile phone shape (rounded rectangle 'soap' shape with a display and a few buttons) with 2 or 3 of arcs radiating from one corner to represent wireless signal (perhaps move arcs to left or right phone edge to make icon more square). Is there a control panel module for configuring the G3 settings? Will likely want to use the same or very similar icon in both locations. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] write compatibility
Hi Daniel, On 1 Dec 2009, at 16:31, Daniel Drake wrote: Hi Gary, Just wondering how much work you think it would be to do a new Write release that supports 0.82 - 0.88 I'm facing a focus-related bug for 0.84 which I think may warrant a new write release, and there is no namespace left in the versioning scheme. I'd be happy to put back in the old sugar toolbars (I've done this with Moon, Labyrinth, Calculate, and Wade has done some others I think). I'm not aware of any other reasons for a version break. Might be a ~week or so before I can get around to it. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
Hi Josh, On 30 Nov 2009, at 06:23, Joshua Minor wrote: Looks great to me. Can you wrangle doing a release? My dev/testing environment is way out of date. Sure, will do. I'll create a clone of Maze in git.sl.org and push there until happy. Regards, --Gary -josh On Nov 29, 2009, at 8:32 PM, Gary C Martin wrote: Hi Josh, On 29 Nov 2009, at 21:22, Joshua Minor wrote: The border size change sounds fine. Just check that it works okay when the maze is relatively large. (Hit + a bunch of times to get a large maze). When you use the other sets of keys to control your blip in the maze, you get other shapes (circle, triangle, etc). I tried a bunch of shapes, but even something like a star gets lost when the maze is even slightly large. Faces would probably get lost too. I did try a number of Maze levels to check how well the face details scaled. Here's a more exhaustive set, it's a pity pygame doesn't seem to offer too much in terms of anti-aliasing, but I think the face still survived the scaling pretty well (and could fit in a cube/triangle if needed): maze_face_size_test.png The face idea is pretty neat. My other activity, Speak, has a bunch of face editing stuff in it. I think that would be great to factor the face editor out into the Sugar layer (to the same place where you edit your colors). It would be more like the Mii editor in a Nintendo Wii - where your character shows up in whatever game you are playing. You can see a remake of it here: http://www.myavatareditor.com/ Hit the random button a few times :) I'm not sure we would want to introduce a more complicated Sugar UI for this. If you take the current buddy colour picker and have it just generate different face shapes along with the two random colours, kids could just click through until they find a colour and face shape avatar that they like. Walter recently posted an 0.88 working feature proposal that allows undo for the buddy colour picker (actually more like previous -- large current icon -- next), so as not to be frustrating when if you pass over one you liked and want to go back. That would work well if face shape was added to the identity mix. I had not heard of identicons before - neat! Lots of different types out there based on hashes of either IP addresses or email addresses. Mainly tessellated/rotated geometric designs, but there are a few examples of monsters and faces (though too fussy for my liking, they would need to be clean/strong stroke/fill designs for Sugar UI use). Just bouncing ideas about to see if anything sticks :-) Regards, --Gary -josh On Nov 29, 2009, at 11:39 AM, Gary C Martin wrote: On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper patch
Re: [Sugar-devel] Maze file structure different than others
Hi Tim, On 29 Nov 2009, at 08:47, Tim McNamara wrote: Hi all, I am downloading the svg icons from http://git.sugarlabs.org/. I've noticed a minor issue, Maze has a different file structures from other activities. http://git.sugarlabs.org/projects/maze/repos/mainline/trees/master/Maze.activity/activity vs http://git.sugarlabs.org/projects/log/repos/mainline/blobs/master/activity/ Is this significant at all? No I don't think so, just looks like Joshua decided to make the repository one directory level up than usual, holding some other misc files and directories. The repository is not the usual practice, extra misc doc items are usually kept under the top level of the activity, and the .xo bundles are not usually kept in the git repository at all (that's what ASLO is for). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancement suggestion - Maze
On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper 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] Enhancement suggestion - Maze
Hi Josh, On 29 Nov 2009, at 21:22, Joshua Minor wrote: The border size change sounds fine. Just check that it works okay when the maze is relatively large. (Hit + a bunch of times to get a large maze). When you use the other sets of keys to control your blip in the maze, you get other shapes (circle, triangle, etc). I tried a bunch of shapes, but even something like a star gets lost when the maze is even slightly large. Faces would probably get lost too. I did try a number of Maze levels to check how well the face details scaled. Here's a more exhaustive set, it's a pity pygame doesn't seem to offer too much in terms of anti-aliasing, but I think the face still survived the scaling pretty well (and could fit in a cube/triangle if needed): inline: maze_face_size_test.png The face idea is pretty neat. My other activity, Speak, has a bunch of face editing stuff in it. I think that would be great to factor the face editor out into the Sugar layer (to the same place where you edit your colors). It would be more like the Mii editor in a Nintendo Wii - where your character shows up in whatever game you are playing. You can see a remake of it here: http://www.myavatareditor.com/ Hit the random button a few times :) I'm not sure we would want to introduce a more complicated Sugar UI for this. If you take the current buddy colour picker and have it just generate different face shapes along with the two random colours, kids could just click through until they find a colour and face shape avatar that they like. Walter recently posted an 0.88 working feature proposal that allows undo for the buddy colour picker (actually more like previous -- large current icon -- next), so as not to be frustrating when if you pass over one you liked and want to go back. That would work well if face shape was added to the identity mix. I had not heard of identicons before - neat! Lots of different types out there based on hashes of either IP addresses or email addresses. Mainly tessellated/rotated geometric designs, but there are a few examples of monsters and faces (though too fussy for my liking, they would need to be clean/strong stroke/fill designs for Sugar UI use). Just bouncing ideas about to see if anything sticks :-) Regards, --Gary -josh On Nov 29, 2009, at 11:39 AM, Gary C Martin wrote: On 29 Nov 2009, at 19:17, Wade Brainerd wrote: I love the faces! Joshua, what do you think about Gary's change? -Wade OK, if faces get the +1, I'd like to also suggest that we vary the face design. It could just use some hash of the colour and/or user name, and then use this value to vary some base features like an identicon**, (square eyes, round eyes, several mouth shapes, noses, face shape, etc). That way we get colour identity reinforced by shape identity in an engaging way (get your friend to join your shared maze and see what funny face they have). ** such identicon type thoughts have been drifting about the Sugar UI, at one point Michael suggested to me activity icons could potentially use some such scheme to make Journal entries more unique. Buddy icon shapes are another obvious candidate. Perhaps we should make a standard 'funny face image avatar generator? ;-) (only half joking). Regards, --Gary On Sun, Nov 29, 2009 at 2:05 PM, Gary C Martin g...@garycmartin.com wrote: Hi Tim, On 29 Nov 2009, at 09:15, Tim McNamara wrote: Something I would like feedback on. After several sessions playing Maze with 6 year olds, I've noticed that it's sometimes very hard to distinguish the difference between opponents if they have the same core colour. E.g. blue w/ light blue stroke is hard to distinguish from blue w/ dark blue stroke. I think a solution would be to increase the stroke width. This would make the distinguishing factor easier to see. Any thoughts? You could give it a quick try and see if it helps: 1) look in the directory ~/Activities/Maze.activity 2) edit the text file called player.py 3) at line 45 note the line that says border = size / 10. 5) change it to read something like border = size / 5. to double the thickness (see attached screen shot): Testing such changes on real children would be gold class feedback! :-) I'd like to suggest a different change to try. How about a simple face inside the circle to use more of the stroke colour? Here's my quick hack on the code, with screenshot, if you want to give it a try (if folks like this face idea, shout and I'll submit a proper 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] some efforts that would be really useful for deployments
Hi Sayamindu, On 25 Nov 2009, at 16:55, Sayamindu Dasgupta wrote: On Wed, Nov 25, 2009 at 9:47 PM, Daniel Drake d...@laptop.org wrote: ..snip snip Another constant headache is with translations. How do you roll out new translations for old software? The best we have right now is language packs but they install files which conflict with both system packages and activity bundles. And they are difficult for deployments because you need Linux skills to execute them. For Sugar 0.88, I will be doing an extended gettext as sugar.gettext which will allow parallel installation of translations (and will get priority over the translations in the activity directory). In that way, we may at least ensure that there is a clean way to upgrade Activity translations. I'm curious, is there something flawed with the current process where deployments add translations to pootle via translate.sugarlabs.org so strings are pushed over to activities held in git.sugarlabs.org ready for re-release? Will this new mechanism lead to new activity releases with new translations being over ridden by old translation files installed in parallel by deployments? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fructose - What is it? What should it be?
Hi Tomeu, On 26 Nov 2009, at 12:41, Tomeu Vizoso wrote: On Tue, Nov 24, 2009 at 17:44, Simon Schampijer si...@schampijer.de wrote: On 11/24/2009 03:18 PM, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote: Hi, this came up several times now. People where wondering what Fructose is. From the definition it is: The Sugar developers will need some example set of activities with which to demonstrate Sugar. This set is Fructose. The packages in Fructose should be selected to make the resulting environment as impressive as possible for a potential client or user. Packages should therefore be stable, polished, and exercise the widest possible range of features. Fructose may also serve as an example for people constructing their own Activity sets. [1] The current list of activities can be found at [2]. The fructose activities follow the Sucrose development cycle (0.84, 0.86...). This means they follow the freezes, provide source tarballs, need a present maintainer etc. The duties are described at [3]. The activity gets noted in release notes, possibly more attention by the localization teams as revenue. In the end their are downsides and upsides to be part of Fructose. There were some arguing, that only system dependent activities should be part of it (e.g. Browse with the dependency on hulahop). There were some discussions that we would loose the show case activities when an activity would not be part of Fructose anymore. This comes down to packaging, as for rpm packaging one needs to provide the source tarballs and need to follow certain rules. Some distributors may ship the .xo bunles at one point, otherwise probably won't, so it is a good habit to do the source releases. Anyhow, this is a bit of the background. Let's think how we can move forward on this topic. We should do it quickly, to be able to keep the work on 0.88 going. In my mind, the best thing we can do is making clear definition: 1) we have core with strong release cycle * glucose(and its dependencies) * sugar platform(additional dependencies) (core) 2) various sugar activities (the rest of development community) 3) sugar users (the rest of community) Relations between 1) and 2) totally depends on sugar release cycles. Activity developers decide what release cycles they can/should/will support. For activities like Browse it will several activities versions per SP release. Most activities will support several SP release. Relations between 2) and 3) is task for various deployment methods. Since fructose makes sense mostly for users, its content should totally depends on deployers not core. So I can't see the 4rd place for fructose, only as a part of 2). So far, I conclude, that Fructose as we have it today is outdated. The tarball issue could be solved with adding for example a field to ASLO, to be able to upload a tarball too, when doing a release. As I think where to upload a tarball was one big issue back in the days. The packaging (rpm, xo, deb) and how you install/upgrade, where you install (system vs user space) is then up to the deployer. As the tarball is available, that should work out nicely. Activities that rest coupled to the Sucrose release would be Browse and Etoys as they have strong platform dependencies. I think hulahop is more mature now and won't change as much in the future. Also Python allows us to do lots of tricks to keep backwards compatibility, but it all takes time developing and testing. Browse may be now in the same situation as Read. I don't think the problem is that Browse depends too much in hulahop, but that the only help the maintainer has with regard to this issue is when people complaint that the last released Browse is not working in the release they are running. With some more manpower I think we could surmount these issues. Sorry, just to be sure I read correctly, were you recommending/suggesting that we should try to update the Browse activity so that it works on past and present versions of Sugar (let's say 0.82 and up) rather than forking versions at every new Sugar release? Does anything else need hulahop, or could it just be bundled inside Browse? I know there was a lot of talk about creating a simple html widget for any activity to easily use, but just wondered if anything else is actually using hulahop now. Karma perhaps, the Help-french activity, Lucuan's Webified? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
Hi Simon, On 24 Nov 2009, at 11:20, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Should we also try and resolve the Fructose issue as well here? Is Fructose just a random grab bag of demo activities, or is it the set of activities that are dependant on a single specific release of Glucose? Right now it contains a mix of both. I'd be against including Sugar version numbers in activity version number (unless perhaps they fail to work in other sugar releases). Activity development should be as far removed from the Glucose development cycle as is feasibly possible. If Fructose becomes the set of Glucose dependent activities (like Browse), they could be the only ones that require special versioning support b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. Fixes would go into 115.1, 115.2... Yes, seems simple enough, but only if/when you have to support an activity that has to fork compatibility between Sugar releases. c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be 115.0.0. Fixes would go into 115.1.0, 115.2.1... Not sure this adds much to the above major.minor option. What do people like best? We need to keep in mind not breaking existing deployments. If I have to start releasing Moon-11.0.xo, Moon-11.1.xo, Moon-11.2.xo, I'd be really annoyed/frustrated if this broke things for our current user base – so I guess that means I'll be sticking with integer version numbers for all my activity work in the foreseeable future, which ever way this goes. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] While checking the latest Soas image (soas05.iso) I realized that po.it file do not correspond to latest versions
Hi Carlo, On 24 Nov 2009, at 13:28, Carlo Falciola wrote: Gary, I understood you're maintaining the Moon activity. A few days ago I realize thre where a little version mismatch in .po files (for italian) and filed a bug in launchpad (maybe it was the wrong place...) https://bugs.edge.launchpad.net/soas/+bug/484280 would it be possible for you to give a check to it? Yes, Sebastian kindly floated the ticket up to http://bugs.sugarlabs.org/ticket/1574 so I could catch it :-) My trac comment: Thanks for the ping, I was hoping to add the new 0.86 toolbar support for the next release, and at least a new option to export the Moon image to the Journal for use in other activities. If I don't get time to work on it in the next day or two, I'll just go ahead and release the existing version with the updated translations. Hoping to give it a poke later today, perhaps also make the text window scrollable as workaround for text font size vs. low screen resolution on some laptops. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] language and keyboard options for intro dialog
Hi Walter, On 24 Nov 2009, at 14:35, Walter Bender wrote: I've begun working on language and keyboard options for the Sugar intro dialog. More details can be found at: http://wiki.sugarlabs.org/go/Features/Feature_intro_language_keyboard_options Comments/feedback sought. I was initially worried that the language and keyboard buttons would be a distraction from the clean, simple first impression of the Sugar start-up; but I like your subtle placement for the two icon only buttons. Could we make them use the same dark grey vs. light grey colors with an outer stroke, as per the ( Next) button? Happy to clean up the icons (I see the keyboard graphic is using a nasty black fill instead of transparent). I'm assuming you plan to reuse the existing control panel language and keyboard modules so as to keep new code for the actual dialogues to a minimum? Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [NEW FEATURE] write to the journal whenever you want
Hi Walter, On 19 Nov 2009, at 19:32, Walter Bender wrote: Many of us love the Naming Alert, but even more seem to despise it. With this feature, it is invoked from a toolbar button instead of automatically invoked on quit. It lets the learning take notes repeatedly and at any time during an activity session. See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime This is a quick hack. We may want to revisit the toolbar integration and certainly need a better icon :) :-) The first thing that comes to mind is something Journal icon like (but still distinguishable from the Journal activity icon), the original Journal with pencil seems a good place to work from (as Eduardo already mentioned). Comments? Yes, I do like the intent, though I'm not sure we have activity toolbar space for another new icon. How about the whole dialogues content be placed in the activity icon secondary toolbar design (I think Simon raised this once before)? This would also make it non-modal, so you can add notes and interact with your activity canvas without the 'click the tick' edit cycle. The secondary toolbar does scale to fit the content height, but you'd need to be sensitive with the amount of space used as some activities will layout badly if too much of their canvas space is eaten away. I could try a few mockups if this approach seems reasonable. One thing that does seem a shame is that this indicates the Journal UI for adding details is not easy enough to use. Ideally we would have one single UI as part of the Journal for entering all entry details (for both code maintenance and design simplicity reasons). Activities could then providing a quick way to switch there. When the current original naming dialogue was first added I was hoping a way would be found to replace the new dialogue by just switching directly to the existing Journal detail view instead. Perhaps this should be the design goal (improving Journal integration/use rather than new separate activity based dialogues). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking feedback on sketch of a new color selector
Hi Walter, On 11 Nov 2009, at 15:48, Walter Bender wrote: I made a patch to the color selector on the About Me panel to make it a little easier to navigate the color selections. Please see my screen cast at http://dailymotion.virgilio.it/video/xb42um_color-selector_tech . I needed to watch through a number of times before I could work out the logic for the colours of the two smaller buddy icons. First couple of times through I thought one was a swapped fill/stroke, and the other was a 'light' version, then third time through I decided they must all just be random, finally I twigged that it was a scrolling history moving from right to left (small -- big -- small). Quick thoughts: - What you have now would be visually understandable after a single click if you added a brief transition animation so that the icons scroll left/right and resize (like a carousel). - Not convinced you need the undo icon if you can add the transition animation, it feels slightly odd at the moment that the undo is right next to the yet too be seen new colour combination (perhaps it could go above or below the centre icon if it really needs to stay in the design). - The alternative is to have N small buddy icons around the central large icon, where the small icons are a close variation of the central large icon colours. Clicking the centre icon picks a completely new random base set of colours; clicking any small icon moves it to the centre large position, and generates a new set of small variants. The colour variants could just be +/- small random steps from the main base colours, or have some spacial meaning (left/right could be +/- fill colour, up/down could be +/- stroke colour). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
