Re: [Sugar-devel] Physics activity
On Mon, Jul 13, 2009 at 03:11:15AM +0100, Gary C Martin wrote: Think we need to make a call on the stability of the new Physics Journal state format first, or at least make sure everyone knows the storage format may (or may not) be stable long term (hate to see a bunch of folks generating/posting examples for lesson plans only to have them all fail to resume in a few versions from now). FWIW the datastore itself can "migrate" from older to newer versions, i.e. read the contents of an old-format datastore and write a new-format one. You could do something similar in Physics so you would at least be backwards compatible. I think I've seen this in some activity as well, but can't remember which one. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ 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?)
On Mon, Jul 13, 2009 at 8:56 AM, Simon Schampijer wrote: > On 07/13/2009 04:11 AM, Gary C Martin wrote: >> >> Just cc:ing the list to keep others in the loop. >> >> On 12 Jul 2009, at 22:55, Asaf Paris Mandoki wrote: >> >>> A release will be great. >> >> Think we need to make a call on the stability of the new Physics >> Journal state format first, or at least make sure everyone knows the >> storage format may (or may not) be stable long term (hate to see a >> bunch of folks generating/posting examples for lesson plans only to >> have them all fail to resume in a few versions from now). >> +cc-ing Kne from pyBox2D -- what do you think about the stability of pyBox2D's pickling format? Will future versions likely remain backwards compatible? >>> I also suggest scheduling an IRC meeting to discuss some "long" term >>> plans about what we're going to do and how we're going to do it. >> >> Yes, an IRC meeting sounds like a good idea. I'm usually only on IRC >> for specific meetings so we'd need to pick a time. Perhaps we could >> make it a Physics specific ActivityTeam meeting on Friday, some other >> interested parties may join the discussions? >> >>> I'm thinking about adding some sort of goals and objectives but I'm >>> not sure if there is where we want to go. >> >> Well need to chat :-) but the X2o Activity seems like the place for >> driving "goals and objectives". I see Physics as more the open ended >> sand box for experiments, like a simple Paint tool for physics >> simulations. We need to keep an eye on the usability for younger kids, >> the number of tools is probably about right, but I have been looking >> at the idea of adding more options as secondary palettes, i.e. you >> hover over the circle tool and the palette includes extra options for >> "helium balloon", "rubber ball", "wooden ball", "stone ball" for some >> pre-set material types, this would vary depending on the tool, so the >> motor could perhaps have clockwise and anti-clockwise as well as some >> torque settings (strong, medium, weak). > > Hi, > > In case you did not see my post (http://erikos.sweettimez.de/?p=789): > [...] > One problem I observed with younger kids is the use of the mouse. In that > age for example moving the mouse over the whole screen (like for closing an > activity) is a hard task. Now, in physics to create an object you have to: > click on the screen, hold the button and move the mouse to create the item > at your desired size. Sounds hard doesn’t it? Proposed UI: a left mouse click with no drag creates a default (or random?) size, while clicking and dragging allows you to set your own size. Consider also how extensively the click-and-drag interaction is used in Paint, Colors, Etoys, TurtleArt and Scratch. > Maybe we can present the kid > on right mouse click with a palette and let’s say 3 objects at different > sizes to select from? Do you mean right mouse click on an object's menu item or a right mouse click on empty space? > [...] > > Might be an option for some palette information as well. > > Regards, > Simon > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] attention packagers: several fixes after 0.85.1
On Mon, Jul 13, 2009 at 00:54, Simon Schampijer wrote: > On 07/12/2009 04:14 PM, Tomeu Vizoso wrote: >> >> Hi, >> >> both sugar and sugar-toolkit contain some fixes that improve >> significantly the experience. So if you were considering packaging >> Sugar 0.85.1 for your favorite distro, consider packaging instead git >> snapshots. >> >> For your convenience I have uploaded them here: >> >> http://shell.sugarlabs.org/~tomeu/sugar-0.85.1.git05405976ad.tar.bz2 >> >> http://shell.sugarlabs.org/~tomeu/sugar-toolkit-0.85.1.git8d21a6d884.tar.bz2 >> >> Please notice that Sugar depends now on Metacity, instead of Matchbox. >> >> We could do a release if a packager really needs it. >> >> Regards, >> >> Tomeu > > Awesome, thanks for that work. Especially for taking care of the event > timestamp in the keyhandler. > > You only missed a little argument, but spotting those is my part of the game > ;p So we can drop pylint from jhbuild! Tomeu > http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/5f88a8437f6b49cb97ce87eacacee3f68fb880d3 > > Cheers, > Simon > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sane po file?
Hi, 2009/7/12 Bryan Berry : > unmadindu, > > I have created a po file using jquery in a command-line script. > > Can u look at the pot and tell me if anything is egregiously wrong? I > still need to fill in some of the msg header info. > > http://git.sugarlabs.org/projects/karma/repos/mainline/blobs/master/utils/narwhal/i18n/test.pot > The msgstrs seem to be missing. Eg, instead of msgctxt "HTML Tag: BUTTON ID: btnRestart" msgid "Restart" it should be msgctxt "HTML Tag: BUTTON ID: btnRestart" msgid "Restart" msgstr "" Normally, you can use msgfmt --check to check the sanity of a POT or a PO file. > If it is good enough, I want to progress to pootle integration and > reading in po contents at run-time. > > off-topic, Subir Pradhanang just joined OLE Nepal as Deployment Manager. > He told me that you helped him localize Open Office for Nepali. > Ah yes - please say Hi! to Subir for me :-). > tks again for all your help unmadindu! > YW :-) Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Feedback on installing the Windows sugar stick
(just received this email today, what's going on with the lists?) On Thu, Jun 25, 2009 at 23:15, Sean Daly wrote: > Many thanks Klaas for reporting the error and proposing a workaround! > > Mathieu, could you or someone you know get this info to the LiveUSB > Creator people? Here is the link to their bug tracker: https://fedorahosted.org/liveusb-creator/ Would be good to search if the issue is already tracked and enter a new one if it isn't. Regards, Tomeu > Sebastian, do you think we should update the wiki with this workaround? > > thanks > > Sean > > > On Thu, Jun 25, 2009 at 10:08 PM, klaas langhout wrote: >> Quick feedback: >> - using >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Strawberry#Windows_Users >> - did: Download the latest version of Fedora LiveUSB Creator from >> http://fedorahosted.org/liveusb-creator/ and extract it; >> >> The instructions didn't match the current LiveUSB creator. In specific, >> when I launched the app, no option to format existed but, the download for >> Sugar on a Stick was already there. It failed to create and, in looking at >> the log file it was because of a UNC path usage that was invalid on Windows >> 7 >> >> Z:\liveusb-creator-3.7[1]\liveusb-creator-3.7>type liveusb-creator.log >> tools\7z.exe x "soas-strawberry.iso" -x![BOOT] -y -oE: >> 'liveusb-creator-3.7[1]\liveusb-creator-3.7' >> CMD.EXE was started with the above path as the current directory. >> UNC paths are not supported. Defaulting to Windows directory. >> The system cannot find the path specified. >> >> I had to manually invoke as: 7z.exe x "..\soas-strawberry.iso" -x![BOOT] -y >> -oE: >> >> Cheers, thanks for puttting this together. >> > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound/Csound
On Sun, Jul 12, 2009 at 21:19, Art Hunkins wrote: > Mike Gogins, a Csound developer, has taken care of the Scons issue with > Csound5.10, as discussed below. > > I'd be overjoyed if one of you Sugar developers could take it from there so > that we can have SoaS with a Csound that works with python2.6. SoaS is based on Fedora, so I'm adding fedora-olpc to CC. I think we need someone to read the thread your forwarded and update the Fedora ticket with an explanation of what's going on and what's the suggested way forward: https://bugzilla.redhat.com/show_bug.cgi?id=510423 Regards, Tomeu > If I can help in any non-technical way, please let me know. I'm much obliged > to all your help. > > Art Hunkins > > - Original Message - > From: "Michael Gogins" > To: "Art Hunkins" ; "Developer discussions" > > Sent: Sunday, July 12, 2009 11:20 AM > Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound > > >>I patched SConstruct as suggested in the thread below. Somebody needs >> to update SConstruct from Csound CVS, rebuild Csound 5.10 using this >> patched SConstruct for Python 2.6, and then you need to install this >> new build. >> >> Hope this helps, >> Mike >> >> 1/09, Art Hunkins wrote: >>> Mike, >>> >>> Sorry, I'm technically way over my head here. I'm referring to the thread >>> below. >>> >>> Sugar on a Stick includes Csound5.10 and Python2.6. The >>> incompatibilities, >>> apparently relating to Scons, are cited below. I'm not building anything; >>> I >>> just need the SoaS download or update to handle my Python script with >>> Csound5.10 correctly. >>> >>> 5.10 doesn't work with a Python2.6 script currently. (I need 5.10 to be >>> able >>> to use multiple MIDI controllers.) >>> >>> I don't know how to explain any better, and also don't know where (else) >>> to >>> turn. Should I be looking elsewhere? (I feel really stuck currently.) >>> >>> Art Hunkins >>> >>> Mike G. wrote: >>> Art - the Python version is controllable in Sconstruct. It works with >>> 2.3, 2.4, 2.5, and 2.6 at present. Which version of Python do you need >>> Csound to work with, and how do you obtain or build Csound? >>> >>> - Original Message - >>> From: "Michael Gogins" >>> To: "Art Hunkins" ; "Developer discussions" >>> >>> Sent: Tuesday, July 07, 2009 3:13 PM >>> Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound >>> >>> He says SConstruct has a bug, which he has patched. I think he's probably right, and I will patch SConstruct accordingly. The bug makes the installation not know the right name (soname) for the csnd extension module shared library. Regards, Mike On 7/6/09, Art Hunkins wrote: > Victor and Mike G. (especially) - > > You're familiar with my problems getting Csound5.10 working on SoaS. > > Aleksey, one of the Sugar developers, sent me the "solution" (below) to > this > problem (a Scons issue apparently). > > I don't know what to do with it, and look to you for either > implementation > or explanation. > > I'm really interested to get 5.10 working with Sugar. > > Art Hunkins > > - Original Message - > From: "Aleksey Lim" > To: "Art Hunkins" > Cc: ; ; > > Sent: Monday, July 06, 2009 3:37 AM > Subject: Re: [Sugar-devel] Sugar on a Stick - and OLPCsound/Csound > > >> looks like its a SConstruct issue >> https://sourceforge.net/tracker/index.php?func=detail&aid=2817271&group_id=81968&atid=564599 >> >> this patch fixed "import csnd" in my case >> http://git.sugarlabs.org/projects/jhconvert/repos/mainline/blobs/master/patches/csound-2817271-soname.patch >> >> On Sun, Jul 05, 2009 at 05:49:23PM -0400, Art Hunkins wrote: >>> As mentioned by a member of the sugar-devel list, it seems that a >>> csound >>> (5.10) install (yum install csound), does not install several crucial >>> site-specific and library packages (csnd, _csnd, libcsnd and perhaps >>> libcsound). >>> >>> Having to erase olpcsound before installing csound deletes these >>> files >>> and they don't get restored/reinstalled. >>> >>> So, to the procedures described below, before erasing olpcsound, I >>> saved >>> the above-listed files (there were 5 or 6), and once csound was >>> installed, added them back where they came from. >>> >>> This crude procedure didn't work, and the following error log is >>> quite >>> like the one I started with: >>> >>> >>> /usr/lib/python2.6/site-packages/sugar/util.py:25: >>> DeprecationWarning: >>> the sha module is deprecated; use the hashlib module instead >>> >>> import sha >>> >>> Traceback (most recent call last): >>> >>> File "/usr/bin/sugar-activity", line 21, in >>> >>> main.main() >>> >>> File "/usr/lib/python2.6/site-packages/sugar/activity/main.py", line >>> 105, >>
Re: [Sugar-devel] sane po file?
On Mon, 2009-07-13 at 14:03 +0530, Sayamindu Dasgupta wrote: > it should be > > msgctxt "HTML Tag: BUTTON ID: btnRestart" > msgid "Restart" > msgstr "" > > Normally, you can use msgfmt --check to check the sanity of > a POT or a PO file. tks for the feedback! i will fix it -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Latest release of Read Etexts, some questions
On Sat, Jul 11, 2009 at 14:39, Jim Simmons wrote: > I took the week off and spent a great deal of it in my basement > working on an improvement to Read Etexts which should be available > soon on ASLO. The new feature is annotations, where I let you add > notes to individual pages of a book, plus make as many bookmarks as > you like, using a UI modelled on what the latest Read has. Unlike > Read, I store this information in a Zip file along with the book, > which means that when you share a book the notes and annotations go > with it. > > Another thing I did was to put the title metadata in this file, > because that seemed to be the only way that I could make sure that > when someone shared this file the received file in the Journal would > get some title better than Read Etexts Activity. That part isn't > working at the moment. I need a way to know that a file has been > received from a sharing user and not opened any other way, because > only then do I want to check the annotations file for a title. If > anyone has any ideas I'd like to hear them. When you say that the file is shared, what do you mean exactly? > I'm thinking of adding keyboard shortcuts for the bookmarks. Any > suggestions on what keys to use would be welcome. > > The next feature to be added will be highlighting, probably with > underlines. If there is a passage in a book that is important you can > underline it for emphasis. You should be able to underline multiple > passages per page. > > Finally, I updated one of my development boxes to Fedora 11. It > doesn't look like the gstreamer espeak plugin is included in that > distribution, and unfortunately that box is the one I use for testing > text to speech. Is there an RPM for Fedora 11 that I could install? The gstreamer plugin isn't packaged yet for Fedora, unfortunately. Though Aleksey might have a .rpm that you can install. Regards, Tomeu > James Simmons > ___ > 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] Latest release of Read Etexts, some questions
On Mon, Jul 13, 2009 at 11:00:12AM +0200, Tomeu Vizoso wrote: > On Sat, Jul 11, 2009 at 14:39, Jim Simmons wrote: > > Finally, I updated one of my development boxes to Fedora 11. It > > doesn't look like the gstreamer espeak plugin is included in that > > distribution, and unfortunately that box is the one I use for testing > > text to speech. Is there an RPM for Fedora 11 that I could install? > > The gstreamer plugin isn't packaged yet for Fedora, unfortunately. > Though Aleksey might have a .rpm that you can install. (not sure) you can attach soas repo and insall gstreamer-plugins-espeak http://download.sugarlabs.org/soas/repositories/2 or just download rpm http://download.sugarlabs.org/soas/repositories/2/gstreamer-plugins-espeak-0.3.3-1.fc11.sl.i386.rpm -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Choosing to merge: a mockup
On Tue, Jul 7, 2009 at 20:12, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mockup: > http://dev.laptop.org/~bemasc/merge_share_selection_mockup.png > > Idea: > If I resume an Activity session from my Journal, and there is already a > session in progress with the same activity_id, and the Activity in > question supports automerge, then Sugar will show me the above screen, > asking me whether I want to merge my work with the shared session, or to > work alone. This is enough to enable basic asynchronous collaboration. > > The screen simply has two buttons. One is the image of the shared session > in question, identical to the one shown in the Neighborhood View. The > other is an image of my XO icon. The text below each button explains its > purpose, and also gives the name of the shared session and the local > session, as these may have diverged. Knowing the names may help the user > to decide whether or not to merge. > > As I understand it, the current activity architecture requires an activity > to know if it is a joining a shared session as soon as initialization > begins, so activity startup cannot proceed until the user makes a choice. Perhaps we should review this. Is providing the choice in the launcher screen our best option user experience-wise? Or would be better to leave it entirely in the activity's hands if it was possible? Regards, Tomeu > A rounded-corner highlight box indicates the currently selected button, in > a manner consistent with the rest of the UI, hopefully enabling simple > keyboard shortcuts. The default selection may be based on a heuristic to > predict whether the user is likely to join the shared session. For > example, the default selection may be to merge if the local copy is the > latest local version, and to remain separate if it is not. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.11 (GNU/Linux) > > iEYEARECAAYFAkpTkBUACgkQUJT6e6HFtqT8XACbBAa91c6oIvZvQYfJQvmIe6ht > LdIAoJfmeKU0VWvuK8gjeHvNbK8yKmur > =8W9M > -END PGP SIGNATURE- > ___ > 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] [Cs-dev] Sugar on a Stick - and OLPCsound/Csound
2009/7/13 David Schönstein : > Hi Tomeu, > > Could we add the details of this thread to > http://wiki.sugarlabs.org/go/Development_Team/Sound ? Sure, feel free to do so. Currently I'm not working on anything related to sound, so would be great if other people that are interested in this subject organize themselves and the info they want to share. Thanks, Tomeu > Thanks > > David > > 2009/7/13 Tomeu Vizoso >> >> On Sun, Jul 12, 2009 at 21:19, Art Hunkins wrote: >> > Mike Gogins, a Csound developer, has taken care of the Scons issue with >> > Csound5.10, as discussed below. >> > >> > I'd be overjoyed if one of you Sugar developers could take it from there >> > so >> > that we can have SoaS with a Csound that works with python2.6. >> >> SoaS is based on Fedora, so I'm adding fedora-olpc to CC. I think we >> need someone to read the thread your forwarded and update the Fedora >> ticket with an explanation of what's going on and what's the suggested >> way forward: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=510423 >> >> Regards, >> >> Tomeu >> >> > If I can help in any non-technical way, please let me know. I'm much >> > obliged >> > to all your help. >> > >> > Art Hunkins >> > >> > - Original Message - >> > From: "Michael Gogins" >> > To: "Art Hunkins" ; "Developer discussions" >> > >> > Sent: Sunday, July 12, 2009 11:20 AM >> > Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound >> > >> > >> >>I patched SConstruct as suggested in the thread below. Somebody needs >> >> to update SConstruct from Csound CVS, rebuild Csound 5.10 using this >> >> patched SConstruct for Python 2.6, and then you need to install this >> >> new build. >> >> >> >> Hope this helps, >> >> Mike >> >> >> >> 1/09, Art Hunkins wrote: >> >>> Mike, >> >>> >> >>> Sorry, I'm technically way over my head here. I'm referring to the >> >>> thread >> >>> below. >> >>> >> >>> Sugar on a Stick includes Csound5.10 and Python2.6. The >> >>> incompatibilities, >> >>> apparently relating to Scons, are cited below. I'm not building >> >>> anything; >> >>> I >> >>> just need the SoaS download or update to handle my Python script with >> >>> Csound5.10 correctly. >> >>> >> >>> 5.10 doesn't work with a Python2.6 script currently. (I need 5.10 to >> >>> be >> >>> able >> >>> to use multiple MIDI controllers.) >> >>> >> >>> I don't know how to explain any better, and also don't know where >> >>> (else) >> >>> to >> >>> turn. Should I be looking elsewhere? (I feel really stuck currently.) >> >>> >> >>> Art Hunkins >> >>> >> >>> Mike G. wrote: >> >>> Art - the Python version is controllable in Sconstruct. It works with >> >>> 2.3, 2.4, 2.5, and 2.6 at present. Which version of Python do you need >> >>> Csound to work with, and how do you obtain or build Csound? >> >>> >> >>> - Original Message - >> >>> From: "Michael Gogins" >> >>> To: "Art Hunkins" ; "Developer discussions" >> >>> >> >>> Sent: Tuesday, July 07, 2009 3:13 PM >> >>> Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound >> >>> >> >>> >> He says SConstruct has a bug, which he has patched. I think he's >> probably right, and I will patch SConstruct accordingly. >> >> The bug makes the installation not know the right name (soname) for >> the csnd extension module shared library. >> >> Regards, >> Mike >> >> On 7/6/09, Art Hunkins wrote: >> > Victor and Mike G. (especially) - >> > >> > You're familiar with my problems getting Csound5.10 working on SoaS. >> > >> > Aleksey, one of the Sugar developers, sent me the "solution" (below) >> > to >> > this >> > problem (a Scons issue apparently). >> > >> > I don't know what to do with it, and look to you for either >> > implementation >> > or explanation. >> > >> > I'm really interested to get 5.10 working with Sugar. >> > >> > Art Hunkins >> > >> > - Original Message - >> > From: "Aleksey Lim" >> > To: "Art Hunkins" >> > Cc: ; ; >> > >> > Sent: Monday, July 06, 2009 3:37 AM >> > Subject: Re: [Sugar-devel] Sugar on a Stick - and OLPCsound/Csound >> > >> > >> >> looks like its a SConstruct issue >> >> >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=2817271&group_id=81968&atid=564599 >> >> >> >> this patch fixed "import csnd" in my case >> >> >> >> http://git.sugarlabs.org/projects/jhconvert/repos/mainline/blobs/master/patches/csound-2817271-soname.patch >> >> >> >> On Sun, Jul 05, 2009 at 05:49:23PM -0400, Art Hunkins wrote: >> >>> As mentioned by a member of the sugar-devel list, it seems that a >> >>> csound >> >>> (5.10) install (yum install csound), does not install several >> >>> crucial >> >>> site-specific and library packages (csnd, _csnd, libcsnd and >> >>> perhaps >> >>> libcsound). >> >>> >> >>> Having to erase olpcsound before installing csound delet
[Sugar-devel] Sound on Sugar
Hello Sugar Community, A general project to improve the sound on Sugar has been initiated. See: http://wiki.sugarlabs.org/go/Development_Team/Sound It is aimed at bringing together all known issues and solutions relating to sound on Sugar. The expansion of this wiki will enable a coordinated approach to fixing the known issues. It will also allow contributors, from inside and outside the Sugar community, to participate and follow the work being done. I invite you all to visit the wiki and take a couple of minutes to list any initiatives you might be working on relating to sound on Sugar. Thanks David ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SugarCamp Bolzano 2009
Hi, added a topics section and some ideas about hacking to the wiki: http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009#Topics http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009#Hacking_ideas So feel free to add what you think it's important. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SoaS Meeting TODAY at 10.30 EDT
Sorry for the short notice, but please join if you can. That's in half an hour from now! Topics will include the roadmap & features for v2. --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Latest release of Read Etexts, some questions
Tomeu, By "sharing" I mean pretty much what the core Read Activity does when it shares a book. The person doing the sharing either uses the drop-down on the Activity toolbar to share the book with the whole neighborhood or goes to the neighborhood view and invites an individual to share the book. The person or persons invited will see a Read Etexts icon in their neighborhood view and can choose to join it. Once they do they will receive a copy of the book. The file being transferred will be a zip file containing both the book text and a pickle file containing annotations and bookmarks, plus the title of the original book in the Journal of the original user will be in the same pickle file. Here is the issue: when someone receives a shared book he only gets a file. In the neighborhood view he will see "The Hound of the Baskervilles by A. Conan Doyle" but the Activity itself doesn't seem to be able to get that information. He knows he has joined an Activity of another user, but the title of the Activity that he saw in the neighborhood view does not seem to be available to his own Activity. As a result, when the user receives the book his own Journal entry will be named "Read Etexts Activity". Of course he can rename it later but it would be better if the received Journal entry had the same name as the one sharing the book. Now the Read Activity seems to get around this by using metadata stored in the PDF it is sharing. So it occurred to me that I could include the title in my pickle file with the annotations and pass it along that way. This works, almost. Finally we get to the real problem: I need to know in my program if the file I'm reading is an existing Journal entry, in which case I leave the title alone, or if it has in the current session been received from another user, in which case I want to change the title of my own Journal entry to whatever is in the pickle file. Now that I've written this all out it occurs to me that there might be another way to do this that I haven't tried. So I may yet figure this out myself. But I'm still interested in suggestions. James Simmons > When you say that the file is shared, what do you mean exactly? > > Regards, > > Tomeu > >> James Simmons >> ___ >> 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] Latest release of Read Etexts, some questions
Aleksey, Thanks, I'll try this tonight. James Simmons > (not sure) you can attach soas repo and insall gstreamer-plugins-espeak > http://download.sugarlabs.org/soas/repositories/2 > > or just download rpm > http://download.sugarlabs.org/soas/repositories/2/gstreamer-plugins-espeak-0.3.3-1.fc11.sl.i386.rpm > > -- > Aleksey > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Turtle Art-54
Url: http://activities.sugarlabs.org/addon/4027 Release notes: http://activities.sugarlabs.org/addon/4027#release-notes Reviewer comments: Trusted activity Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS Meeting TODAY at 10.30 EDT
Hi Sebastian, Sorry I missed this one. Will the minutes be published anywhere? Peter On Mon, Jul 13, 2009 at 3:01 PM, Sebastian Dziallas wrote: > Sorry for the short notice, but please join if you can. That's in half > an hour from now! Topics will include the roadmap & features for v2. > > --Sebastian > ___ > 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] [Cs-dev] Sugar on a Stick - and OLPCsound/Csound
Aleksey, Thanks for undertaking this task. Please let me know when the revised build of Csound5.10 is available for update on SoaS. I'm eager to be assured that it solves the compatibility issue with python 2.6. Art Hunkins - Original Message - From: "Aleksey Lim" To: "Art Hunkins" Cc: "Michael Gogins" ; Sent: Monday, July 13, 2009 12:02 AM Subject: Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound/Csound > On Sun, Jul 12, 2009 at 03:19:31PM -0400, Art Hunkins wrote: >> Mike Gogins, a Csound developer, has taken care of the Scons issue with >> Csound5.10, as discussed below. >> >> I'd be overjoyed if one of you Sugar developers could take it from there >> so >> that we can have SoaS with a Csound that works with python2.6. > > I can build rpm for soas env. but I'm waiting for fixing my problems with > ISP > so, I can't do it in nearest few days. > > Just an option, using Mandriva of Suse ;) > > -- > Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Latest release of Read Etexts, some questions
On Mon, Jul 13, 2009 at 09:38:50AM -0500, Jim Simmons wrote: > Tomeu, > > By "sharing" I mean pretty much what the core Read Activity does when > it shares a book. The person doing the sharing either uses the > drop-down on the Activity toolbar to share the book with the whole > neighborhood or goes to the neighborhood view and invites an > individual to share the book. The person or persons invited will see > a Read Etexts icon in their neighborhood view and can choose to join > it. Once they do they will receive a copy of the book. The file > being transferred will be a zip file containing both the book text and > a pickle file containing annotations and bookmarks, plus the title of > the original book in the Journal of the original user will be in the > same pickle file. [1] takes more common approach, and [2] as well In fact trunk version of Library can browse shared Journal objects(but cannot download them). I just decided to integrate all Library(implemented of future) features to Journal [3].. and at the end it was postponed for 0.88. Anyway I'm going to continue coding it for 0.86(as a standalone activity) or for 0.88 as soon as possible. [1] http://wiki.sugarlabs.org/go/Features/Peer_to_Peer_Objects_Sharing [2] http://wiki.sugarlabs.org/go/Features/Server_Objects_Sharing [3] http://wiki.sugarlabs.org/go/Features/Unified_Browser_for_Objects -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [API proposal] Source editor and widget
I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It would be similar to what can be found in jarabe.view.viewsource. Exact names of classes and/or module are up for debate. I'm also thinking of adding a FileView class in there, but I'm not sure about it. I've already seen almost the exact same code in Pippy and viewsource.py; now I'm writing almost the same code in my branch of Browse and it could be a base for the proposed Clipboard text editor (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I believe it's a common enough need. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS Meeting TODAY at 10.30 EDT
MeetBot Log: http://meeting.sugarlabs.org/sugar-meeting.log.20090713_1034.html MeetBot outline: http://meeting.sugarlabs.org/sugar-meeting.minutes.20090713_1034.html On Mon, Jul 13, 2009 at 10:59 AM, Peter Robinson wrote: > Hi Sebastian, > > Sorry I missed this one. Will the minutes be published anywhere? > > Peter > > On Mon, Jul 13, 2009 at 3:01 PM, Sebastian Dziallas > wrote: > > Sorry for the short notice, but please join if you can. That's in half > > an hour from now! Topics will include the roadmap & features for v2. > > > > --Sebastian > > ___ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > ___ > Fedora-olpc-list mailing list > fedora-olpc-l...@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] Source editor and widget
On Mon, Jul 13, 2009 at 18:09, Lucian Branescu wrote: > I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It > would be similar to what can be found in jarabe.view.viewsource. Exact > names of classes and/or module are up for debate. May be better if you first code your new stuff and then we discuss about merging it in the sugar-toolkit? viewsource.py doesn't add too much around gtksourceview2.View itself, so you may end up with more differences than similarities with viewsource.py. Regards, Tomeu > I'm also thinking of adding a FileView class in there, but I'm not > sure about it. > > > I've already seen almost the exact same code in Pippy and > viewsource.py; now I'm writing almost the same code in my branch of > Browse and it could be a base for the proposed Clipboard text editor > (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I > believe it's a common enough need. > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Turtle Art-54
On Mon, Jul 13, 2009 at 7:49 AM, Sugar Labs Activities wrote: > Url: > http://activities.sugarlabs.org/addon/4027 > > Release notes: > http://activities.sugarlabs.org/addon/4027#release-notes There is nothing in the Release Notes. "Version 54 — July 13, 2009 — 3,330 KB" What was changed? > Reviewer comments: > Trusted activity > > > Sugar Labs Activities > http://activities.sugarlabs.org > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Latest release of Read Etexts, some questions
Aleksey, The kind of sharing I'm talking about is entirely handled by the Activity itself. If the book is shared using the Journal Send To feature or the Library Activity I would not do anything to change the Journal title of the received document as I would assume these other methods of sharing would take care of giving the received Journal entry a proper title (and if they don't it is not my problem). Read Etexts, like Read, contains its own code for sharing books. If Read Etexts itself downloads a book from another user that's when I want to know about it. James Simmons On Mon, Jul 13, 2009 at 10:19 AM, Aleksey Lim wrote: > On Mon, Jul 13, 2009 at 09:38:50AM -0500, Jim Simmons wrote: >> Tomeu, >> >> By "sharing" I mean pretty much what the core Read Activity does when >> it shares a book. The person doing the sharing either uses the >> drop-down on the Activity toolbar to share the book with the whole >> neighborhood or goes to the neighborhood view and invites an >> individual to share the book. The person or persons invited will see >> a Read Etexts icon in their neighborhood view and can choose to join >> it. Once they do they will receive a copy of the book. The file >> being transferred will be a zip file containing both the book text and >> a pickle file containing annotations and bookmarks, plus the title of >> the original book in the Journal of the original user will be in the >> same pickle file. > > [1] takes more common approach, and [2] as well > > In fact trunk version of Library can browse shared Journal objects(but > cannot download them). I just decided to integrate all > Library(implemented of future) features to Journal [3].. and at the end > it was postponed for 0.88. Anyway I'm going to continue coding it for > 0.86(as a standalone activity) or for 0.88 as soon as possible. > > [1] http://wiki.sugarlabs.org/go/Features/Peer_to_Peer_Objects_Sharing > [2] http://wiki.sugarlabs.org/go/Features/Server_Objects_Sharing > [3] http://wiki.sugarlabs.org/go/Features/Unified_Browser_for_Objects > > -- > Aleksey > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS Meeting TODAY at 10.30 EDT
Well, that's certainly understandable, given that I rushed the whole thing quite a bit. 30 Minutes is not that much time... ;) Fred was still quicker with posting the logs... thanks! --Sebastian Peter Robinson wrote: > Hi Sebastian, > > Sorry I missed this one. Will the minutes be published anywhere? > > Peter > > On Mon, Jul 13, 2009 at 3:01 PM, Sebastian Dziallas > wrote: >> Sorry for the short notice, but please join if you can. That's in half >> an hour from now! Topics will include the roadmap& features for v2. >> >> --Sebastian >> ___ >> 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] SoaS Meeting TODAY at 10.30 EDT
I'm sorry I missed this. Re deployments. I think (beyond Local Labs) we need to reflect on how to create an ecosystem for providers to schools - deployers. We absolutely need to be present ourselves at pilots (I hope to start one or two in Paris), but that's only because we have lacked the feedback. However, of course that doesn't scale. As we gain experience and deal with the more serious issues (difficulty of exiting Activities, etc.), we can work on how deployers or local Labs could return structured or consolidated feedback. SoaS is a key part of convincing a school to pilot Sugar; moving to Sugar on anything else is in my view most likely a second step. Sebastian - When I can I will look over the SoaS v2 features wiki page (I will be travelling again over the next couple of days). I'm wondering if a simpler (i.e. more teacher-friendly) method than installing and configuring a school server can be found to back up Learners' Journals from sticks, since it is 100% guaranteed that sticks will be damaged or lost in a school setting. Perhaps a designated PC with multiple USB ports (breakout hub), which could extract Journals with a script, by Learner name? Sean On Mon, Jul 13, 2009 at 6:11 PM, Frederick Grose wrote: > MeetBot Log: > http://meeting.sugarlabs.org/sugar-meeting.log.20090713_1034.html > MeetBot outline: > http://meeting.sugarlabs.org/sugar-meeting.minutes.20090713_1034.html > > On Mon, Jul 13, 2009 at 10:59 AM, Peter Robinson > wrote: >> >> Hi Sebastian, >> >> Sorry I missed this one. Will the minutes be published anywhere? >> >> Peter >> >> On Mon, Jul 13, 2009 at 3:01 PM, Sebastian Dziallas >> wrote: >> > Sorry for the short notice, but please join if you can. That's in half >> > an hour from now! Topics will include the roadmap & features for v2. >> > >> > --Sebastian >> > ___ >> > Sugar-devel mailing list >> > Sugar-devel@lists.sugarlabs.org >> > http://lists.sugarlabs.org/listinfo/sugar-devel >> > >> >> ___ >> Fedora-olpc-list mailing list >> fedora-olpc-l...@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-olpc-list > > > ___ > 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] [API proposal] Source editor and widget
I've attached a file with a SourceView class.
I'll try to write up a FilesView class as well, since 3 of the 4
aforementioned use cases do something like this.
2009/7/13 Tomeu Vizoso :
> On Mon, Jul 13, 2009 at 18:09, Lucian Branescu
> wrote:
>> I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It
>> would be similar to what can be found in jarabe.view.viewsource. Exact
>> names of classes and/or module are up for debate.
>
> May be better if you first code your new stuff and then we discuss
> about merging it in the sugar-toolkit? viewsource.py doesn't add too
> much around gtksourceview2.View itself, so you may end up with more
> differences than similarities with viewsource.py.
>
> Regards,
>
> Tomeu
>
>> I'm also thinking of adding a FileView class in there, but I'm not
>> sure about it.
>>
>>
>> I've already seen almost the exact same code in Pippy and
>> viewsource.py; now I'm writing almost the same code in my branch of
>> Browse and it could be a base for the proposed Clipboard text editor
>> (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I
>> believe it's a common enough need.
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
import os
import mime
import gobject
import pango
import gtk
import gtksourceview2
from sugar.activity import activity
from sugar.graphics import style
from sugar.graphics.icon import Icon
class SourceView(gtk.ScrolledWindow):
'''TextView-like widget with syntax coloring and scroll bars
Much of the initialisation code if from Pippy'''
__gtype_name__ = 'SugarSourceView'
def __init__(self, syntax_color=True, width=None, height=None):
gtk.ScrolledWindow.__init__(self)
self.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
self.mime_type = mime_type
self.width = width or int(gtk.gdk.screen_width()/2)
self.height = height or int(gtk.gdk.screen_height()/1.5)
self._file_path = None
# buffer
self._buffer = gtksourceview2.Buffer()
if syntax_color:
if hasattr(self._buffer, 'set_highlight'):
self._buffer.set_highlight(True)
else:
self._buffer.set_highlight_syntax(True)
# editor view
self._view = gtksourceview2.View(self._buffer)
self._view.set_size_request(self.width, self.height)
self._view.set_editable(True)
self._view.set_cursor_visible(True)
self._view.set_show_line_numbers(True)
self._view.set_wrap_mode(gtk.WRAP_CHAR)
self._source_view.set_right_margin_position(80)
#self._source_view.set_highlight_current_line(True) #FIXME: Ugly color
self._view.set_auto_indent(True)
self._view.modify_font(pango.FontDescription("Monospace " +
str(style.FONT_SIZE)))
self._source_view.modify_font(_SOURCE_FONT)
self.add(self._view)
self.show_all()
def set_mime_type(self, mime_type):
lang_manager = gtksourceview2.language_manager_get_default()
if hasattr(lang_manager, 'list_languages'):
langs = lang_manager.list_languages()
else:
lang_ids = lang_manager.get_language_ids()
langs = [lang_manager.get_language(lang_id)
for lang_id in lang_ids]
for lang in langs:
for m in lang.get_mime_types():
if m == mime_type:
self._buffer.set_language(lang)
def get_text(self):
end = self._buffer.get_end_iter()
start = self._buffer.get_start_iter()
return self._buffer.get_text(start, end)
def set_text(self, text):
self._buffer.set_text(text)
text = property(get_text, set_text)
def _set_file_path(self, file_path):
if file_path == self._file_path:
return
else:
self._file_path = file_path
if self._file_path is None:
self.text = ''
return
mime_type = mime.get_for_file(self._file_path)
self.set_mime_type(mime_type)
self.text = open(self._file_path, 'r').read()
def _get_file_path(self):
return self._file_path
file_path = property(_get_file_path, _set_file_path)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Decoupling of Sucrose (was Re: Initial implementation of toolbars design)
On Sat, Jul 11, 2009 at 19:42, Aleksey Lim wrote: > On Sat, Jul 11, 2009 at 06:15:21PM +0200, Tomeu Vizoso wrote: >> On Sat, Jul 11, 2009 at 16:53, Eben Eliason wrote: >> > On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin >> > wrote: >> >> On 11 Jul 2009, at 14:40, Aleksey Lim wrote: >> >>> On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote: >> a) DESIGN: discuss the design further and get some mockups >> together, one >> question that came up is: do we always have a one line secondary tool >> bar? >> >>> >> >>> Do you mean hiding sub-toolbars like palettes? >> >>> I'm using new toolbar in Memorize, and should say - its much useful to >> >>> have persistent sub-toolbar(and not auto-hiding them like palettes) >> >> >> >> Ebens designs describe both interaction methods: >> >> >> >> 1). If you hover over one of the new tab replacement buttons the >> >> palette appears (over the top of the canvas) and will auto-hide if you >> >> move the mouse way (just like any normal palette) >> >> >> >> 2). If you click one of the new tab replacement buttons the palette >> >> appears (and shifts the canvas down the screen) and is locked in >> >> place. Clicking the button a 2nd time unlocks it so it behaves like a >> >> regular palette again. >> > >> > Yup, that's the idea. I think it should be up to the activity, by the >> > way, to decide if any of the secondary toolbars are "locked in" when a >> > new activity instance is created. For instance, Paint might decide >> > that making the colors available by default is the wise choice. >> > >> > We should also institute policy for retaining toolbar state in the >> > metadata for a given activity entry in the Journal, so that resuming >> > restores that context. Perhaps this is something that the toolkit can >> > do so that activity doesn't have to think about it. >> > >> How would more complex widgets like the color chooser look like >> http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they >> open from the secondary palette? >> >>> >> >>> I'm personally, +1 for >> >>> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11 >> > >> > Just to be clear, this new toolbar design is in no way intended to >> > replace palettes in general. Instead, it's provided as a unique >> > alternative to tabs that allows palette-like interaction, but also >> > allows these secondary toolbars to be locked in place persistently, >> > which can be of great usefulness. Therefore, we needn't ask ourselves >> > "how does look/work in the new toolbar design?" at all. >> > We should be asking "which of " would work better >> > functionally as a secondary toolbar?". >> > >> > I think that Paint, for instance, would gain heaps of usability if the >> > colors were a secondary toolbar, and that were shown by default. That >> > doesn't mean that Write, for instance, necessarily needs to replace >> > the current color chooser palette. It's should be up to activities to >> > decide what parts of the UI are best suited to the two modes. >> > >> > Both primary and secondary toolbars can have as many normal "palette >> > buttons" as desired. >> > >> >> I guess one unanswered question is do you allow the stacking of more >> >> than 2 rows of toolbar... And, how much work is going to be needed on >> > >> > This is something we tossed around a little bit while designing them. >> > I think the answer is no, personally, since it adds a lot more >> > complexity to the UI, and also begins to consume too much of the >> > screen. I'm hoping that [primary toolbars > secondary toolbars > >> > palettes] are sufficient for most use cases here; we don't want to >> > wind up with MS Word-like feature complexity! >> > >> > That said, if we do support it, I think the rule is basically that >> > closing any parent toolbar hides all of its children, and reopening a >> > parent toolbar that had child toolbars open when it was last hidden >> > should reveal all those same children open as they were. But again, >> > I'd much rather just support one level of secondary toolbars. >> > >> >> all the Activities if you start hand redesigning and customising each >> >> edge case. I think the current colour palette in Write would work as >> > >> > Yup. >> > >> >> is, at least that's how I was going to show it in a mockup, Activity >> >> bar -> text bar below -> existing drop down colour palette from its >> > >> > One advantage of this design is that the primary toolbar is always >> > visible, and secondary toolbars can be shown or hidden as needed. The >> > mockups of Browse and Paint try to illustrate how useful this can be >> > in defining a set of "core tools" that are always—or nearly >> > always—applicable to interacting with the activity. In the case of >> > browse, the forward and back buttons, address bar, and bookmarking >> > button are always available in the primary toolbar. In Paint, some of >> > the core painting tools are surfaced. >> > >> > So, the idea her
Re: [Sugar-devel] Decoupling of Sucrose (was Re: Initial implementation of toolbars design)
On Mon, Jul 13, 2009 at 07:51:44PM +0200, Tomeu Vizoso wrote: > On Sat, Jul 11, 2009 at 19:42, Aleksey Lim wrote: > > On Sat, Jul 11, 2009 at 06:15:21PM +0200, Tomeu Vizoso wrote: > >> On Sat, Jul 11, 2009 at 16:53, Eben Eliason wrote: > >> > On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin > >> > wrote: > >> >> As an Activity author, this is what breaks my heart. 99.5% or more of > >> >> our users will be unable to get the benefits of new Activity releases. > >> >> That's real tough psychology, and very de-motivating for volunteer > >> >> authors. > >> > > >> > Yeah, that's a hard one to get around. We've had these designs since > >> > the first release of Sugar, but there just wasn't time or resources to > >> > make it happen. On a positive note, these new designs were developed > >> > based directly on feedback from kids and teachers, and address a > >> > number of issues that they found frustrating or confusing. Based on > >> > the enthusiastic responses to the designs among all of you as well, I > >> > think we're onto something good. > >> > > >> > I wish I had some suggestions on how to avoid the backwards > >> > compatibility problem, though... > >> > >> I think that Aleksey's sugar-port addresses well that problem. The > >> downside is that when someone files a bug for an activity, we won't > >> know at first if the activity was running code in a copy of sugar-port > >> or in sugar-toolkit, but well... Perhaps sugar-toolkit should be > >> maintained by the Activity Team, so they can make these decisions with > >> more knowledge of cause. > > > > My dream is having this(these) library out of sucrose release cycle > > so, its should use only dbus api to cooperate with shell > > I'm having trouble understanding this. Which D-Bus services would we > need to add? looks like I thought about Library(I had to copy/paste/adapt some code from shell, at least to activate objects).. but maybe thats another(specific) case -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Mon, Jul 13, 2009 at 06:16, Aleksey Lim wrote: > On Mon, Jul 13, 2009 at 04:14:33AM +, Aleksey Lim wrote: >> On Sat, Jul 11, 2009 at 01:29:08PM +, Aleksey Lim wrote: >> > On Sat, Jul 11, 2009 at 11:42:19AM +0200, Tomeu Vizoso wrote: >> > > Another possibility is having Aleksey working on converting Write to >> > > the new toolbar and getting frequent feedback about it. Suggesting >> > > Write here because it has a crowded toolbar, could be the journal as >> > > well because we already have mockups. >> > >> > I've taken it >> >> New toolbars in Write >> http://git.sugarlabs.org/projects/write/repos/toolbars > > forgot to say, > this Write's clone needs > http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars Here is a screencast showing Write with the new toolbars: http://shell.sugarlabs.org/~tomeu/toolbars_aleksey.ogv Excellent job! Will look at the code next, maybe tomorrow. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On 13 Jul 2009, at 19:48, Tomeu Vizoso wrote: > On Mon, Jul 13, 2009 at 06:16, Aleksey Lim > wrote: >> On Mon, Jul 13, 2009 at 04:14:33AM +, Aleksey Lim wrote: >>> On Sat, Jul 11, 2009 at 01:29:08PM +, Aleksey Lim wrote: On Sat, Jul 11, 2009 at 11:42:19AM +0200, Tomeu Vizoso wrote: > Another possibility is having Aleksey working on converting > Write to > the new toolbar and getting frequent feedback about it. Suggesting > Write here because it has a crowded toolbar, could be the > journal as > well because we already have mockups. I've taken it >>> >>> New toolbars in Write >>> http://git.sugarlabs.org/projects/write/repos/toolbars >> >> forgot to say, >> this Write's clone needs >> http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars > > Here is a screencast showing Write with the new toolbars: > > http://shell.sugarlabs.org/~tomeu/toolbars_aleksey.ogv > > Excellent job! > > Will look at the code next, maybe tomorrow. Hey wow that's looking like the toolbars are functioning great! Thought I'd layout their content rather differently ;-) I'll have a toolbar design mock-up for Write uploaded later tonight. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Conozco Uruguay on Activities.Sugarlabs.org?
Hi, I'd like to let the GPA 3rd graders play with Conozco Uruguay on Weds. Is there any chance someone could put it onto Activities.Sugarlabs.org for me? It would be easier for kids to find and it would also teach them how to get new activities. Its not a show stopper,we can have them find it on laptop.org but it would be nicer to have it on a.sl.o Thanks, Caroline -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] Turtle Art-54
54 * debug button * no more decimals by default for print -walter On Mon, Jul 13, 2009 at 12:39 PM, Edward Cherlin wrote: > On Mon, Jul 13, 2009 at 7:49 AM, Sugar Labs > Activities wrote: >> Url: >> http://activities.sugarlabs.org/addon/4027 >> >> Release notes: >> http://activities.sugarlabs.org/addon/4027#release-notes > > There is nothing in the Release Notes. > > "Version 54 — July 13, 2009 — 3,330 KB" > > What was changed? > >> Reviewer comments: >> Trusted activity >> >> >> Sugar Labs Activities >> http://activities.sugarlabs.org >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > -- > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name > And Children are my nation. > The Cosmos is my dwelling place, The Truth my destination. > http://earthtreasury.org/worknet (Edward Mokurai Cherlin) > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
Really great stuff. -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] Collaboration Plan for the GPA tomorrow
We will be at the GPA tomorrow and we'll have time to test after class, probably around 12:30. So far all I have planned is to try getting rid of the jabber key on the master and try cloning some new sticks. We will also enable debugging following Dave's suggestion: To do that I edit ~/.Xclients to include this if [ -f ~/.sugar/debug ]; then . ~/.sugar/debug fi before eval \\\$(dbus-launch --sh-syntax --exit-with-session) Then we need to edit ~/.sugar/debug to fix a couple of typos: Missing space between exportGABBLE_LOGFILE and exportSALUTLOGFILE. It should be export GABBLE_LOGFILE... export SALUT_LOGFILE Are there any other suggestions? We got a hint from collabora that we should check the "keepalive" setting. Does anyone know what that is or how we could change it? There seems to be a separate bug that keeps local collaboration from working. Does anyone have any thoughts of what it might be or how to get more information? -- Forwarded message -- From: Caroline Meeks Date: Mon, Jul 13, 2009 at 5:28 PM Subject: Collaboration Plan for the GPA tomorrow To: Caroline Meeks -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Background Screen Color for SoaS Activity
Gary -
Thanks so much for these helpful suggestions.
With them I've been able to change the color of the basic Sugar display, and
to create boxes of differing colors.
Several major issues remain (which may not be surmountable?):
1) when text displayed on the basic screen (in no box) - that area reverts
to gray;
2) importantly, nothing else displays in my colored boxes; this includes
frames, other boxes, text and buttons.
Can you guide me toward solutions here?
I'm basically modifying Lazzarini's csndsugui.py. Here is the revised box
code:
def box(self, vert=True, colour=(0x, 0x, 0x), parent=None,
padding=5):
"""creates a box
vert: True, creates a vertical box; horiz.
otherwise
parent: parent box, None if this is a toplevel box
padding: box padding
returns the widget instance"""
if vert:
box = gtk.VBox()
else:
box = gtk.HBox()
self.event_box = gtk.EventBox()
self.event_box.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(colour[0],
colour[1], colour[2], 0))
if parent:
parent.pack_start(self.event_box)
else:
self.outbox.pack_start(self.event_box)
self.window.set_canvas(self.outbox)
self.boxes.append(box)
self.event_box.show()
box.show()
return box
I suspect that chaages in the last few lines are required (especially in the
"boxes" line and probably the packing).
And here is the current "text" code. I rather imagine if this could be
gotten to display in a box with the box retaining its color, I might be on
the way to success (but this may be the hard part; can other things be
displayed "over" an event_box?). This code is straight from Lazzarini:
def text(self, name, box=None,colour=(0,0,0)):
"""Creates a static text label
name: text label
box: parent box, None if text is to be placed toplevel
colour: RGB values in a tuple (R,G,B)
returns the widget instance"""
label = gtk.Label(name)
label.modify_fg(gtk.STATE_NORMAL,
gtk.gdk.Color(colour[0],colour[1],colour[2], 0))
if box:
box.pack_start(label, False, False, 5)
else:
self.outbox.pack_start(label, False, False, 5)
label.show()
return label
I very much appreciate your help. I, too, wonder if all this hassling over
color is worth it. If only there were some simple way to make the overall
display white instead of gray! I'm wanting the color change strictly for
readability; I need more color contrast to read the text (which is
unfortunately profuse in my project).
Art Hunkins
- Original Message -
From: "Gary C Martin"
To: "Art Hunkins"
Cc: "Tomeu Vizoso" ;
Sent: Tuesday, July 07, 2009 10:07 AM
Subject: Re: [Sugar-devel] Background Screen Color for SoaS Activity
> Hi Art,
>
> On 7 Jul 2009, at 03:46, Art Hunkins wrote:
>
>> Tomeu,
>>
>> I've had no luck modifying background color for anything except buttons.
>>
>> No boxes, even when the box is completely empty.
>>
>> Does anyone know how to change the color of the entire screen, or of a
>> box?
>
> I can remember hitting my head on this when first playing with gtk. I
> wanted a black area to place a moon image in. The trick seems to be using
> a gtk.EventBox(). Have a look in moon.py at about line #114:
>
> http://git.sugarlabs.org/projects/moon/repos/mainline/trees/master
>
> Just quickly scraped out the lines I think might be interesting, does
> seem quite a bit for just a black screen :-)
>
> # Create the main activity container
> self.main_view = gtk.HBox()
>
> # Blackness
> self.event_box = gtk.EventBox()
> colormap = gtk.gdk.colormap_get_system()
> self.black_alloc_color = colormap.alloc_color('black')
> self.event_box.modify_bg(gtk.STATE_NORMAL, self.black_alloc_color)
> self.main_view.pack_end(self.event_box)
>
> # Display everything
> self.event_box.show()
> self.main_view.show()
> self.set_canvas(self.main_view)
> self.show_all()
>
> Regards,
> --Gary
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On 13 Jul 2009, at 21:01, Gary C Martin wrote: > On 13 Jul 2009, at 19:48, Tomeu Vizoso wrote: > >> On Mon, Jul 13, 2009 at 06:16, Aleksey Lim >> wrote: >>> On Mon, Jul 13, 2009 at 04:14:33AM +, Aleksey Lim wrote: On Sat, Jul 11, 2009 at 01:29:08PM +, Aleksey Lim wrote: > On Sat, Jul 11, 2009 at 11:42:19AM +0200, Tomeu Vizoso wrote: >> Another possibility is having Aleksey working on converting >> Write to >> the new toolbar and getting frequent feedback about it. >> Suggesting >> Write here because it has a crowded toolbar, could be the >> journal as >> well because we already have mockups. > > I've taken it New toolbars in Write http://git.sugarlabs.org/projects/write/repos/toolbars >>> >>> forgot to say, >>> this Write's clone needs >>> http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars >> >> Here is a screencast showing Write with the new toolbars: >> >> http://shell.sugarlabs.org/~tomeu/toolbars_aleksey.ogv >> >> Excellent job! >> >> Will look at the code next, maybe tomorrow. > > Hey wow that's looking like the toolbars are functioning great! > > Thought I'd layout their content rather differently ;-) > > I'll have a toolbar design mock-up for Write uploaded later tonight. Here are my image mock-ups for Write. All tabs are swapped out as is, for toolbar buttons. With no need to move existing tab content features about: http://wiki.sugarlabs.org/go/Design_Team/Proposals/Toolbars#Top_level_Activity_toolbar_for_Write Regards, --Gary P.S. Eben, would be great to have your feedback on the mock-ups and Aleksey's work so far. The obvious design difference seem to be that I'm keeping the activity title input widget and sharing widget visible at all times; where as Aleksey's work puts these into a secondary toolbar and tries to use the extra space to expose more regular features at the top (Aleksey, FWIW would be much better if you could use the Activity icon instead of the XO icon for your Activity toolbar button icon – that way the top toolbar is visually identifiable with the Activity at a single glance). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on Beagle board.
Hi Elena On Mon, Jul 13, 2009 at 12:51 AM, Elena of Valhalla wrote: > Hi > > On 7/8/09, Rafael Enrique Ortiz Guerrero wrote: >> On Irc bernie was telling me that you might have some written >> documentation about how >> to install Sugar on the beagle board, > > no, unluckily I don't have any written documentation, and lately I > didn't have time to work on it (I've also been away from my main > computer for a while, sorry for the late answer) > > It is currently possible to use the openembedded dev tree to build an > image that includes sugar and can be installed on the beagleboard, but > it's still missing at least a dependency > > if you have any question about it feel free to ask; often I'm also > online on irc in #sugar, #oe and #beagle on freenote, as valhalla > Thanks for the pointers >> I'm kind of investigating this kind of enviroments for Sugar >> solutions, so i was wondering if you can share the documentation with >> us? it would be very useful. > > As soon as there is some, of course I would be glad to share it; > anyway I'm trying to get something that can be installed like any > other Angstrom beagleboard image, using the existing documentation. > > Another option that I didn't try yet would be to install debian on the > beagleboard and apt-getting sugar, but I'm afraid that it would > include version 0.82 of sugar. yep. I'm afraid that's truth. Thanks again for your reply...i'll be in touch on IRC. > > -- > Elena ``of Valhalla'' > > email: elena.valha...@gmail.com > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
