Re: [Sugar-devel] maintenance of 0.84 branches
On Thu, 2009-11-26 at 09:45 +, Tomeu Vizoso wrote: > We'll need that they make explicit which modules want to take > maintenance of and then each current maintainer should agree or > disagree. All of glucose, I guess. Right now we only have patches for sugar-toolkit and sugar. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] maintenance of 0.84 branches
On Thu, 2009-11-26 at 09:53 +, Daniel Drake wrote: > On Thu, 2009-11-26 at 09:45 +, Tomeu Vizoso wrote: > > We'll need that they make explicit which modules want to take > > maintenance of and then each current maintainer should agree or > > disagree. > > All of glucose, I guess. Right now we only have patches for > sugar-toolkit and sugar. Actually, we'd rather only take over maintenance where it has stopped. So for sugar and sugar-toolkit at least that seems necessary. If existing maintainers of other components are able to continue taking new patches (from master) and translations and publishing releases then we'd rather leave the job to them. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] libabiword with Nepaly bugs fixed?
On Fri, 2009-11-27 at 16:10 +0100, Martin Langhoff wrote: > Hi Daniel, > > cannot locate any libabiword-2.6.5-3 -- Did it ever happen? yes, it's in koji Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Fri, 2009-11-27 at 22:16 +, Aleksey Lim wrote: > Hi all, > > While preparing new 0.88 features, I encountered some in consistence in > "activities vs. activity bundles" case, so I'm going to reveal > "Activity as regular objects"(see [1] ml thread) feature but make it > less invasive in case existed user experience. > > http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object I feel that this is quite a fundamental change to the Journal philosophy. Until now, the Journal is something that record what the user has done, and it only stores the work (or history) of the users session within the activities. In tune with this, the Journal is empty when you start for the same time. This would no longer be the case with this feature. I think this topic needs larger forward-thinking discussion. Personally, I prefer the concept of the Journal for what it is now. > The major reason for this feature is eliminating confusion when: > > * theres are activities(in Home view) and activity bundles(in Journal) > * user can remove bundle from Journal and activity will be preserved(and > vise versa) > * activities could not have bundles in journal(were deleted or its a > system wide activity), so user can't copy activity(e.g. to share it via USB > stick) using regular shell workflow(Journal) and should be aware of stuff > like Terminal I guess it depends on the UI, but I worry this would actually add confusion. Users would be prone to accidentally deleting the activity installation from their Journal when they think they are just deleting some work they have done in that activity. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
2009/11/30 Walter Bender : > This isn't quite accurate. We've been adding some pre-loaded content > to the Journal for quite some time now, Are you sure? Or are you referring to a manual process that you do in certain deployments? I have yet to see a sugar installation that comes with a non-empty journal. And also I can't think of any non-horrible way that you'd be able to hook into the sugar profile creation stages to pre-provide the content, even if I did like the idea. > and some activities (as you > noted, Turtle Art) have been adding content to the Journal as well. This is the only one I'm aware of, and it was a big surprise, to the extent that I filed bugs upstream and downstream that were confirmed by other people who also didn't realise this. I also got the impression from you that you don't feel like it is the appropriate place to put it, you just did it because it is the only option. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
2009/11/30 Wade Brainerd :
> I disagree that showing activities in the Journal, in addition to
> activity instances and MIME objects, will cause confusion. Many
> activities are more like content. Activities can be downloaded,
> copied, modified, and deleted. In Sugar terminology, Activities are
> intended to be verbs while Journal objects are like proper nouns. But
> if an activity is a verb, the object which performs the activity can
> still be a noun. For example, the word "hammer" is both a noun and a
> verb. The noun in the Journal ("Hammer.xo") is an object which
> enables the verb in the Home view ("Hammer Activity"). It's quite
> simple.
I agree. I find it simple too. I'd have no problem with it.
The problem is when you give it to 6 year olds -- do you also expect
them to be able to understand this?
Have you followed the number of problems caused to deployments by the
activity removal feature that was added to sugar-0.82? The children do
this because they think they are removing work created with the
activity.
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
2009/11/30 Wade Brainerd : > No, but perhaps we could take this opportunity to reduce this problem... > > When deleting an object from the Journal that is an activity bundle, > we ought to display an alert with a scary icon. The alert should > clearly state that Journal entries will no longer be able to be opened > until the activity is reinstalled. > > Really delete Hammer? > If the Hammer activity is deleted, all 14 Hammer entries will no > longer be usable. There is already a warning not too dissimilar from this. My experience in the field is that children have trouble understanding such dialogs and either give random responses, or continue sticking to their guns that they are removing their work, not the application code itself. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OLPC updates from ASLO
2009/12/1 Aleksey Lim : > AFAIK OLPC will use 0.84 release and will lack of native sugar updater > but it could be useful idea to keep activities repository in one place. We are using the sugar control panel applet for activity updates as we have done before. > So, the question is will html page which lists all ASLO activities in > microformat enough for OLPC updater. Having the microformat on ASLO would be great and I never understood why this wasn't the approach taken in the first place, rather than the considerable task of adding some strange XML format support to the updater applet for later versions. The great thing about the microformat is that not only did it provide an interface for those of us single-users who have fast internet connections, it was designed inherently for simplicity, scalability and replication, and came with a decent amount of documentation of how you would replicate this on a deployment. The XML thing seems to be lacking in those areas. However I think there are 2 additional things that would block moving the activity group to ASLO: 1. It's not possible to create a group with specific locked versions, right? One reason for doing it separately is that we want to control the flow of activity updates pushed to customers. I'm concerned that activities are not seeing much QA or testing and regressions are too easy to come by. I'm also concerned that the amount of testing that developers do on 0.84 before marking activities as 0.84-compatible will decrease over the next few months/years. 2. No content bundle support Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] write compatibility
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. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] 0.84 maintenance
Hi, Earlier this year, OLPC began developing a new laptop (XO-1.5) and OLPC OS (based on Fedora 11). Sugar-0.84 was hot off the presses at that time so even though it may feel a little dated today, it's what we've been working with and will soon be shipping in large quantity. One issue that we've been facing is various regressions since Sugar 0.82, some of which have been fixed in Sugar versions later than 0.84 and some which are still pending. As nobody seems to look after 0.84 any more we've been backporting these fixes into a local branch for our OS builds. Now we're going to move to making these changes in the usual sugarlabs git repositories (sucrose-0.84 branches) and publishing them as regular Sugar releases of the main components. This is an improvement/cleanup to our current development processes and will open it up for other people to become involved. (we already have our 'offline fork' including about 15 patches, but we're not being very organised with our development working this way) So, OLPC will take over maintenance. To start with we'll just be working with sugar and sugar-toolkit. Me and Sayamindu will be taking care of this. There may be exceptions, but in general we'll only be taking patches that are already in master. We'll focus on fixes, but if there are really important features then we'll take them too (ad-hoc networking support is the 1 example we have right now). Of course, we'd love support from those of you who are actively involved in Sugar development. In a way it's a bit sad for us to see that 0.84 maintenance already seems to have been halted, but at the same time it's certainly our responsibility to make contributions as well. So we'll try and keep the community updated on the issues that we are facing, and hopefully you will be interested in helping us out. We'll be shipping this to a lot of children. Thanks for the continued developments on sugar, but don't forget that developing is only a small part of the challenge...! 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. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.84.8
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.8.tar.bz2 == News == * intro screen doesn't unfreeze dcon #1601 * font configuration through gconf #1584 * Journal list view: jumping back to first page when popping up a palette #1235 * Process non-ds object in the right way in Journal #1262 * multiple copies of activity opened upon resume #1276 * ObjectChooser does not show file content of external USB devices #881 * Several Access Points with the same essid #330 * add star badge to APs that are in our connections #19 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.6
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.6.tar.bz2 == News == * font configuration through gconf #1584 * multiple copies of activity opened upon resume #1276 * ObjectChooser displays USB media files, but fails to access file (datastore traceback) #1241 * Telepathy doesn't create log files #1178 * Do not fail while displaying activity icon for bundles in Journal #1175 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Removing Log and Terminal from favorites view
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. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Issues with mesh network on XO 1.5
Hi Mohit, On Fri, 2009-12-04 at 17:48 +0530, Mohit Taneja wrote: > I did a little bit of testing on Mesh network today on XO 1.5. > > I tried connecting XO 1.5, with an XO-1, I was trying to collaborate > the FoodForce2 activity, but it failed. But later i realized that they > were not even able to detect each other. Even other activities (I > tried Chat activity) were not able to connect. > > Then I tried connecting them with an acer laptop running SOAS, but > still no success, it was neither able to detect the XO 1 nor XO 1.5. > Any help is appreciated. Before anyone can help you, you're going to need to be more specific about the details of your network setup, and exactly what the failure was (was there an error message?). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Issues with mesh network on XO 1.5
On Mon, 2009-12-07 at 14:11 +1100, James Cameron wrote: > For what it is worth, with two XO-1 running 802, and two XO-1.5 running > os54, a network created by one of the os54 units does not show on the > neighbourhood view of the two 802 units, though it does show on the > other os54, and is included in the "iwlist eth0 scan" output on the > 802s. Sugar-0.82 does not support ad-hoc networks. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Issues with mesh network on XO 1.5
On Mon, 2009-12-07 at 15:51 +0530, Mohit Taneja wrote: > Well then, is there a way to connect XO-1 running Sugar 0.82 and an > XO-1.5 ? Yes. Through an infrastructure (BSS) network. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.7
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.7.tar.bz2 Fix bold font style. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] sugar-toolkit-0.84.7
On Wed, 2009-12-09 at 16:04 +0100, Jonas Smedegaard wrote: > On Wed, Dec 09, 2009 at 06:53:38AM -0500, Daniel Drake wrote: > >== Source == > > > >http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.7.tar.bz2 > > > >Fix bold font style. > > Just a note for future releases and other distributors wondering like > me: it seems you tagged the 0.84.6 release slightly wrong so it included > above bold font style fix. It doesn't appear that way - can you be more specific about what you're looking at? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.84.9
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.9.tar.bz2 == News == * can't connect to WEP shared key networks #1602 * import translations for ad-hoc networking UI ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to enable activities
2009/12/14 Bert Freudenberg : > That's what I had in mind. > > Plus, when you are already in home view, where nobody would normally press F3 > again unless they know this trick, make it switch to list view. While we're on this topic: I included an idea regarding this behaviour in http://wiki.sugarlabs.org/go/Features/Content_support I often see users being confused between the list view and the journal, and my suggestion is to make the list view like a window (like the file picker, or control panel) to give it a less Journal-like appearance, and also that as soon as you switch away from the home view, the window would automatically close. That way, pressing F3 always gets you back to the "familiar" favourites view. Daniel ___ 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 Tue, 2009-12-15 at 06:07 +, Aleksey Lim wrote: > * 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 There's enough going around that you could work on which would be a huge benefit to deployments. Here are a few ideas. We know about projects from Paraguay and Uruguay implementing 3G support. Why not step in early and review their code and send them some patches? Look for bug reports from Soas developers and users, and OLPC too. These people are likely closer to deployments than you are. Here are OLPC ones: http://dev.laptop.org/report/43 (you'll have to filter the list) You could perhaps try and put yourself into a role where you address these needs on an ongoing basis. This would be a dream come true for deployers and distributors. Some more project ideas here: http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10631.html Documentation: there's very little good documentation on how to deploy sugar in a classroom scenario. If you were to start some documentation, not only would it be a huge help for deployments, it would also make you think more about the real-life challenges which may lead to some development projects. Bryan's point about Sugar not supporting the classroom scenario of handing work to your teacher is a good one. Some things that I think would be of large benefit: Supporting the mass of content that has already been generated: http://wiki.sugarlabs.org/go/Features/Content_support This would help simplify ad-hoc networking: http://lists.laptop.org/pipermail/devel/2009-December/026831.html This is a biggie: http://bugs.sugarlabs.org/ticket/1608 I suspect this flicker is going to be quite disruptive for field users: http://bugs.sugarlabs.org/ticket/1596 F11-for-XO1 work would be of a huge impact to the largest part of sugar's current userbase. Right now they cannot receive any of the improvements you make to sugar because the project is not (quite) stable enough for deployments. It has a buildmaster but not much development progress apart from the bits that can be directly picked up from OLPC's XO-1.5 work. We seem to even lack good diagnosis of the outstanding problems. You could look at Sayamindu's recent tickets on bugs.sugarlabs.org. We have identified various places where sugar cannot gracefully deal with corruption. I believe there are still various well-known 0.86 regressions (over 0.84). For example, Record not working. These regressions are going to be a huge headache to anyone who tries to upgrade, perhaps you could squash a few of those. OLPC mesh: NM-0.8 now supports this, sugar patch needs to be brushed up and merged. And help backporting the patches to NM-0.7 would be useful too. > * 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 feel this too. But you can solve it with less drastic changes. Which you seemed to be doing already. I've read briefly over your various 0install feature proposals and I've yet to form an opinion on the technology. I need to read them again, but at least on my quick reads, I'm still left unaware what the user experience will be like, nor the developer experience, and what the inefficiencies of the system will be. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS vis-a-vis XO-1.0/1.5
2009/12/25 Art Hunkins : > 1) Assumption: SoaS, for a variety of reasons, allows (even encourages) > deployments and individual users to set different basic font sizes. I think this is desired but is not (currently) true. The versions of Sugar that are shipped by SoaS do not have a font configuration mechanism. The (very new) versions of Sugar that do have this mechanism lack documentation and a UI. On SoaS and any system it is indeed possible to change the font settings by modifying the Sugar source, fontconfig configuration or X config, but I'm not aware of any such documentation on this topic - making it largely inaccessible to deployments and users. > Text-based activities thus need to incorporate scrollbars to cope with > enlarged text. OTOH, the XO-1 deals with fixed screen format, and does not > encourage changing the basic font size. Therefore, scrollbars are not > necessary for such activities on the XO-1.0. The XO1 screen can be rotated which is quite a substantial change in screen format, I guess this will often add scrollbar requirements where there weren't any before. I'm preaching about an unimplemented feature but in the future all Sugar users and deployments will be able to change font size very easily (see the font configuration feature). My suggestions are: - render your text at the default size - if you provide zoom in/out functionality, make it a function of the default font size - make your program dynamically add scrollbars and/or resize other UI elements as space runs out Then your software will work well in all configurations both now and for the forseeable future. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.8
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.8.tar.bz2 == News == * set activity font settings earlier #1607 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.84.10
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.10.tar.bz2 == News == * can't create ad-hoc network when name is 7+ characters #1604 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] write compatibility
On Tue, 2009-12-01 at 17:01 +, Gary C Martin wrote: > > 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. This is not so urgent any more - I managed to fix the bugs entirely outside of the write activity. Let's hope that we don't find any more :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] suggestions for additions to platform page
vte (and Python bindings) should be added (Terminal requires this) and it should be noted explicitly that python bindings for csound are required (Pippy and other activities use these) What's the process for making such changes? or am I allowed just to use common sense for once? :) ___ 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
On Fri, 2009-12-04 at 11:27 +, Tomeu Vizoso wrote: > I'm ok with that, but I think that the favorites file in the sugar > tarball should be considered an example, and nothing that packagers > and deployers should accept as-is. OK, pushed. But one thing to be aware of: there is normally a gap between packagers and deployers, and Sugar could do a better job here. The problem is that this file is part of the regular Sugar distribution, which then becomes part of the distro package. At this point, deployers have to modify the file that is part of the package, which is generally bad practice (changes lost on upgrade, breaks package manifest checking, etc). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Fonts-configuration
2010/1/11 Art Hunkins :
> With respect to the proposed UI and "low-hanging fruit":
>
> The font-configuring code I use in OurMusic-2 strictly adheres to Daniel's
> suggestions.
>
> Basicly, Daniel's suggestion would pick up the proposed UI-set font value
> from:
> settings = gtk.settings_get_default()
> font_name = settings.get_property("gtk-font-name")
> then manipulate and display individual text instances with:
> font = widget.get_pango_context().get_font_description()
> font.set_size(int(font.get_size() [and whatever])
I don't understand why you need to get the gtk-font-name property.
That is not part of my suggestion. Activities should never be
concerned with this property.
> This presumes that the UI would change the value found with the first set of
> two code lines above, and have nothing to do with the second set. However,
> this latter set is based on system defaults which *remain unchanged* under
> the proposed feature. These defaults are not likely to change for other
> reasons either.
>
> Am I correct concerning these defaults, and should code based on the above
> continue to work on all XO and SoaS systems?
I don't understand your description or questions, sorry. Perhaps you
could explain what you're trying to do. Eithre way, I get the feeling
that you are deviating from the guidelines I am proposing.
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Fonts-configuration
2010/1/11 Art Hunkins : > My code, given in full below, does this - for XO1/1.5, SoaS Strawberry, SoaS > Blueberry (and hopefully future incarnations of Fedora SoaS), as well as > potential future non-Fedora SoaSes. It works fine and has been tested on > varying systems except for XO1.5 and non-Fedora SoaSes (obviously - and I > may be way off base here; I've assumed a similar set of font conditions to > SoaS Blueberry). Your code does not adhere to my suggested guidelines, which state that if filling a specific area is required then you should dynamically figure out the font size using regular pango functionality. See the Measure activity for an example. > My only concern is whether my code will still work once the proposed UI is > implemented. I'd appreciate any and all insight to this end. I'd say your code is unlikely to continue working well in the future regardless of whether this feature is implemented. I also think that it won't even work very well at the moment, e.g. you seem to assume that all blueberry users have identical displays. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Fonts-configuration
2010/1/11 Art Hunkins : > So, is there a way to auto-fill *all size* displays (width-wise) just by > using regular pango functionality and querying for width of screen? Yes. The Memorize activity does almost exactly this -- it renders text to fill a specific tile rather than the whole screen, but the process is the same. > Don't you need also to query default font size to be able to do this? No. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Keep confusion, again
I'm back in the field and I'm again seeing the same confusion about Keep: http://lists.sugarlabs.org/archive/sugar-devel/2009-July/016375.html The computer-literate people who produce training materials misinterpret "Keep" as "Save" (i.e. if you don't click it your work is lost) and pass on this misinformation to trainers, teachers and children. I do have something to add now though; I've noticed that Keep is translated into Spanish as "Guardar" In "regular software" unlike Sugar where saving is actually necessary, the same term is used: Guardar At least in English we have a separate word (Keep instead of Save) which hopefully introduces the idea that it's not the same as regular Save - but in Sugar's Spainsh translation this is not the case, almost certainly adding to the confusion. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] TuxPaint-3 corrupt
Hi, The TuxPaint-3 activity on activities.sugarlabs.org is corrupt, it refuses to extract. It is also 25mb smaller than the version on the OLPC wiki. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Examples of local-generated content/activities
Hi, At a training session here in Nicaragua, we're interested in demonstrating content and activities that have been generated by OLPC deployments, to start thinking about what can be done for the project here. What examples do we have? So far I have: - Epaath - Conozco Uruguay - Relatos de Paraguay - Bundles of textbooks that we distributed in Ethiopia Any other suggestions? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Control Panel Font configuration
2010/1/19 Yevlempy(Harsh Verma) : > Hi > > I am working on building the font configuring control panel, it will be a > pygtk based control panel extension for > handling the fonts. 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. Is there a reason you haven't taken the 2-button approach proposed in the Feature page? http://wiki.sugarlabs.org/go/Features/Font_configuration The font size does not need to be presented to the user. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Copy from paint broken with Rainbow
Hi,
There is a Sugar-0.82 regression in that you can't copy a selection
from paint to the clipboard (using Paint's copy button). Reproduced on
OLPC OS 8.2 with Paint-23.
Disabling Rainbow solves the issue.
At the point of failure, a broken icon is created in Sugar's clipboard
tray and this appears in shell.log
---
DBusException Traceback (most recent call last)
/usr/share/sugar/shell/view/frame/clipboardpanelwindow.py in
_owner_change_cb(self=, clipboard=, event=)
69 self._add_selection(key, selection)
70
---> 71 cb_service.set_object_percent(key, percent=100)
cb_service.set_object_percent = >
key = '/org/laptop/Clipboard/Objects/1'
global percent = undefined
72
73 def _add_selection(self, key, selection):
/usr/lib/python2.5/site-packages/sugar/clipboard/clipboardservice.py
in set_object_percent(self=,
object_id='/org/laptop/Clipboard/Objects/1', percent=100)
185 """
186 self._dbus_service.set_object_percent(
--> 187 dbus.ObjectPath(object_id), percent)
global dbus.ObjectPath =
object_id = '/org/laptop/Clipboard/Objects/1'
percent = 100
188
189 def get_object(self, object_id):
/usr/lib/python2.5/site-packages/dbus/proxies.py in
__call__(self=,
*args=(dbus.ObjectPath('/org/laptop/Clipboard/Objects/1'), 100),
**keywords={})
138 introspect_sig,
139 args,
--> 140 **keywords)
keywords = {}
141
142 def call_async(self, *args, **keywords):
/usr/lib/python2.5/site-packages/dbus/connection.py in
call_blocking(self=,
bus_name='org.laptop.Clipboard', object_path='/org/laptop/Clipboard',
dbus_interface='org.laptop.Clipboard', method='set_object_percent',
signature=u'oi',
args=(dbus.ObjectPath('/org/laptop/Clipboard/Objects/1'), 100),
timeout=-1.0, utf8_strings=False, byte_arrays=False)
628 # make a blocking call
629 reply_message = self.send_message_with_reply_and_block(
--> 630 message, timeout)
message =
timeout = -1.0
631 args_list = reply_message.get_args_list(**get_args_opts)
632 if len(args_list) == 0:
DBusException: org.freedesktop.DBus.Python.IOError: Traceback (most
recent call last):
File "/usr/lib/python2.5/site-packages/dbus/service.py", line 702,
in _message_cb
retval = candidate_method(self, *args, **keywords)
File "/usr/share/sugar/service/clipboardservice.py", line 123, in
set_object_percent
new_uri = self._copy_file(format.get_data())
File "/usr/share/sugar/service/clipboardservice.py", line 201, in _copy_file
shutil.copyfile(uri.path, new_file_path)
File "/usr/lib/python2.5/shutil.py", line 46, in copyfile
fsrc = open(src, 'rb')
IOError: [Errno 13] Permission denied:
'/home/olpc/isolation/1/uid_to_home_dir/1/instance/tmpwL_h6t.png'
Could someone running a more recent Sugar with rainbow setup please
test to see if this regression still exists?
cheers
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] One More Font Display Question
On 5 February 2010 15:52, Art Hunkins wrote: > Can anyone explain why this is happening? (I assume ?? that the actual font, > presumably DejaVu, has not changed.) I saw a discussion about Fedora enabling a different font rendering algorithm in freetype now that the patents on it have finally expired. This might have happened for F13 and could certainly explain something like this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Write 60 possible bug saving shared work
On 6 February 2010 05:58, Tomeu Vizoso wrote: > You are right, thanks for spotting it, would be nice to backport the > fix to 0.84. But there is no space in the version number namespace to do another Write release for 0.84, unless the newer versions are made compatible :( Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automatically Retrying an AP?
On 4 February 2010 08:04, Martin Langhoff wrote: > Hi list! > > We have a bug on 802/8.2.1 where in some cases (specific combination > of WPA2 with certain AP chipsets) we fail to associate on the very > first attempt, and then subsequent attempts succeed. This is an 8.2.1 regression, because several libertas patches were added late with little testing. I would suggest reverting those patches. The reason that it works in F11 is that those patches were never sent upstream and hence are not included in that kernel. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automatically Retrying an AP?
On 8 February 2010 16:38, Martin Langhoff wrote: > On Mon, Feb 8, 2010 at 4:03 PM, Daniel Drake wrote: >> This is an 8.2.1 regression, because several libertas patches were >> added late with little testing. > > IIRC, the libertas patches did fix interop with other APs. We fixed > some, broke some. Broke all WPA/WPA2 ones, at least when talking about the first connection attempt. Additionally, the only reports of improved connectivity that I've seen came from Marvell/cozybit, who told me that they were not using OLPC's XO nor sugar at the time. I haven't seen equivalent feedback from actual users. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] journal (0.82) backup
On 11 February 2010 08:16, Esteban Arias wrote: > Hi, > > I work with journal (0.82) backup. The idea is on jornal activity add button > "backup" and "restore". and then run the script. as a subprosses. > > may have a problem if I run script if the journal active ? I suspect it's not safe to run that journal restore script while Sugar is active. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Font display revisited
On 19 February 2010 17:04, Art Hunkins wrote: > This makes no sense whatever to me. It gives the developer little control > over text display at all, with the possible exception of furnishing > different code for each incarnation of SoaS. (This is what I'm currently > doing - but I'd rather this not be a lifelong task.) Is SoaS hardcoding a DPI value for the display? This would explain what you are seeing. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Font display revisited
On 22 February 2010 03:13, Tomeu Vizoso wrote: > You may want to ask in the soas ml, but in 0.88 we are going to make > it easier to users to change the default font size, so apps shouldn't > make any assumptions based on a fixed value for that. But, in the few cases where it is of importance, they should still be able to assume that a size 13 font will be rendered at physical size of 13/72 inches on a decent display. If Soas continues to hardcode a DPI value, this will not be true. Daniel ___ 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
On 12 March 2010 02:35, James Cameron wrote: > I don't think this is the right way to fix the problem. It will work > for only as long as the fonts don't change again. Agreed. I also saw this problem but it magically went away before I could continue. But while I was looking at it, I was suspecting a GTK+ bug. That would be my next step in diagnosing. Figure out why the spacing negotiations aren't happening as normal, causing the button to fall off. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] logging activity
Hi Wendy, Sorry for the delay in responding to your mail. On 10 March 2010 05:02, Wendy van Thiel wrote: > For a study, we would like to analyze what is actually done with the laptop > (version os708). With the journal activity, it is possible to get the data > store from the laptops to see which activities are done and when. The > question remains how long these activities are done actively. There are > several ways imaginable of trying to get this information from the XO. > Currently, I just want to insert some code that if activity has taken place > (e.g. key press, touch pad) it adds a line to a specific log file with the > type of activity every one or two minutes. Before spending more time on > exploration, I would like to discuss possibilities or hear your suggestions > about the best approach to reach (and implement) this. I think you're correct in observing that information about the activeness of the activity use is not currently recorded. As for the actual implementation, it depends on the things that you are interested in tracking/recording. If it's just mouse/keyboard activity then you could probably set up some gdk/gtk signal handlers in the sugar.activity class which would produce appropriate log messages from time to time. But then you have the issue that sugar only keeps logs for the last 6 sessions or so (or were things different in os708 days?). Maybe you could save the information elsewhere and implement your own system for making sure the information doesn't get too big. Good luck! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Keep confusion, yet again
Argh! Another country, another core team confused by the Keep button. The Argentinian in-house generated teaching materials say: (translated from Spanish) To save the work that you did in the activity, go to the toolbar at the top of the screen and click the Keep button. Same story every single time. Pretty please can someone please pick up the project of improving this situation? Even if it's just killing this button for the time being. I've seen this confusion in all 6 of the countries that I've visited. And in most of those cases, it's written in the teacher training materials, so the trainers pass this misinformation onto the teachers who pass it onto the children. For now I am going to update the Spanish translation to say "Guardia copia" (Keep a copy) but this is not the solution... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep confusion, yet again
On 19 April 2010 09:41, Daniel Drake wrote: > For now I am going to update the Spanish translation to say "Guardia > copia" (Keep a copy) but this is not the solution... Meant to write Guardar copia. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keep confusion, yet again
On 21 April 2010 18:48, Chris Ball wrote:
> Hi Jorge,
>
> > - self.props.tooltip = _('Keep')
> > + self.props.tooltip = _('Keep a copy')
>
> I think this will break translations.
I think that's what we want; this new string will come up as
untranslated in pootle, alerting translators to submit translations
for the clearer string.
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] use ConsoleKit instead of HAL for shutdown/reboot
On 21 April 2010 19:07, James Cameron wrote: > On Wed, Apr 21, 2010 at 10:17:14AM +0200, Sascha Silbe wrote: >> Since I've run into the same issue before (i.e. with HAL), I suppose >> the default is the same but the OLPC builds explicitly configure HAL >> to allow shutdowns even for multiple sessions? > > I've looked and not found where this might occur. See PolicyKit-olpc Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove the keep button from the default activity toolbar
On 23 April 2010 15:02, Sascha Silbe wrote: > I like the proposal of renaming Keep to Copy and placing it in the palette > of the Stop button. I was a bit worried about it getting confused with the > clipboard action of the same name, but making it a secondary action of the > Stop button should help with that. This sounds odd. To make a copy of my work I have to go to the Stop menu? I've never seen Keep used in the field -- I've only seen misuse. Does anyone have any experience-backed counter opinions? I still think removing the button altogether will be a big improvement until the more advanced Journal solutions are actually implemented, even though technically you could say it would cause a functionality regression. If someone really does want to do a bit of hacking on this, put the Copy/Duplicate option in the Journal details view... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 3/4] fix AP association failure after removing encryption #1674
On 22 April 2010 23:01, James Cameron wrote: > The name has multiple purposes in Sugar and Network Manager > interaction: > > 1. it identifies a connection (and Sugar was using it to identify an > essid instead, before this patch), > > 2. it appears in Network Manager logs, > > 3. it is stored in connections.cfg as a section key. So it breaks compatibility with the old file format. Your saved secrets won't work after upgrading? If we're going to do this it would make sense to use the network ID, already used to separate APs into networks uniquely based on name, encryption, etc. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 3/4] fix AP association failure after removing encryption #1674
On 25 April 2010 22:35, James Cameron wrote: > Yes, but the additional work might delay a solution. Do you have a > patch? No, but you're already knee deep, it would be trivial for you to do this. And breaking compatibility is something that needs extra attention. It can't be rushed. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] VncLauncher doesn't run on F11
Hi, Using VncLauncher-4 on F11: it fails to start the VNC server because the binary links against the wrong version of libssl. This activity is used very often in deployments for presentations, training sessions, etc, so it would be nice to have a new version. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Experimental work... updated.
On 28 April 2010 11:57, Michael Stone wrote: > You couldn't find logs of the failure because olpc-dm is redirecting stdout > and > stderr to /dev/null. I don't think this is true. > Fortunately, olpc-utils rebuilds easily on the XO as soon as its builddep, > ConsoleKit-devel, is installed. > > (Just run "make -f Makefile.build; make -f Makefile.build install".) > > Then you can redirect the stdout/stderr output to the log file of your choice but if I'm wrong, maybe we can improve this. Can you be more specific about the changes you're making before the rebuild? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO QA process
On 29 April 2010 09:46, Bernie Innocenti wrote: > I liked your proposal of creating per-deployment collections to manage a > set of activities that has been tested and approved. I think this is one > of the things Uruguay wanted. > > If we decided to go this path, what would be missing? Does our update > API support collections? Can anyone create a collection easily? More requirements: 1. Support for content bundles 2. Locking to specific versions (maybe already possible with collections -- not sure) rather than a collection always including the latest 3. Reproducibility in low-connectivity deployments, or even for cases such as paraguay where connectivity is good but going to ASLO will really be slw and it's much more desirable to set up some simple infrastructure to run it within the school. i.e. that simple infrastructure needs to be developed and good documentation needs to be written. (easiest approach for #3: support OLPC activity microformat. clean, simple format, well documented, designed for low connectivity situations, simple infrastructure is already developed and has been replicated around the world.) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO QA process
On 29 April 2010 18:22, Bernie Innocenti wrote: > This is easily done by tuning Squid to cache large files if they > have .xo extensions. The update panel only does one uncachable query to > ASLO. Not quite: 1. squid still makes the outgoing request to the upstream server, to check the size of the file and to check if the local copy is still valid 2. squid purges its cache after a time 3. It makes the assumption that you have internet in the first place. 4. Maybe you have internet, but squid won't have a cache until 1 user does the download, and you're talking hundeds of mb for the whole activity set - your (heavily shared) connection may not be fast enough to do this realistically. It's close, but is not an acceptable solution for the OLPC world. You need to be a bit more intelligent in the design. But we don't need to look for a solution for this, we already have one: XS comes with an activity server, and its trivial to synchronize activities by USB, or over the internet (as is done in py). The format and design is also well-documented. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Cairo performance (was Re: SVG performance)
On Tue, Dec 9, 2008 at 8:59 AM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > There's a cairo configure option: > > --disable-some-floating-point > Disable certain code paths that rely heavily on > double precision floating-point calculation. This > option can improve performance on systems without a > double precision floating-point unit, but might > degrade performance on those that do. > > > Maybe someone can do some tests with this flag on. Did we come up with some reasonable tests/benchmarks? Anyway, here's a cairo build with that flag: http://koji.fedoraproject.org/koji/taskinfo?taskID=988722 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar] [RELEASE] Browse 100
Simon, On Wed, Oct 29, 2008 at 7:43 PM, Simon Schampijer <[EMAIL PROTECTED]> wrote: > Dear Browse, > > happy birthday! Marco and Tomeu honored you and provided excellent new > features and fixed a very hard one - the download/upload alert issue for > multiple instances! > > Wish you 100 more, >Simon > > sources: > http://dev.laptop.org/pub/sugar/sources/web-activity/Browse-100.tar.bz2 Where is the .xo bundle for this release? Would like to get it in Joyride (while carefully making sure it doesn't get included as an 8.2 update). Thanks! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Soas snapshot
2009/1/27 Gary C Martin : > Any tips as to what to do with these 2 on an XO? The only thing I've > done with .img and .crc before is copy-nand from firmware – is it > possible to run them from a usb stick without wiping nand or effecting > the existing nand install (so we can encourage safe(er) testing of new > code)? You can copy-nand to get them on NAND. Or you can use the USB stick process described here: http://sugarlabs.org/go/Sugar_on_a_Stick (please let us know if it works on XO!!) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] consequences of re-registering with XS
Hi, As I noted here: http://wiki.laptop.org/go/Deployment_wishlist#Delete_registration_info we are in a sticky situation where a load of XOs are registered to one XS, which no longer exists. We want to register them to a new one, and we are having to manually go to each laptop and modify the sugar config file to allow us to register again. To avoid this situation in future (should we ever run into it again, fingers crossed we won't), we are considering a small modification to the paraguay OS build which makes the "Discard network history" button also clear the XS registration information (by deleting the server.backup1 line from sugar config). This code modification can be done with a single sed call, since there is already an unused sugar function to clear registration info. Of course, this means that the users (children) can now trivially lose their registration data. Are there any undesirable consequences of this that I am missing? For example, what happens if a user deletes the registration data and then re-registers with the same server.. does the XS cope with that happily? Any other points I should keep in mind, or any other options to avoiding this small nightmare in future? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] joyride, staging builds, sugar releases
2009/2/12 victor : > Sorry to insist on this, but I have not got it quite yet. > > Joyrides => obsolete (even though the builder script keeps > churning them out and telling the olpc devel list). Obsolete, but not really obsoleted by anything usable *yet*. > staging => what are these? Obsolete too? This is where we are staging changes to be used in v8.2.1. > release builds => only last week there was a release build > announced on the olpc devel list. Are these obsolete too? You are referring to the v8.2.1 candidate release? This is not obsolete, it is being pushed to various deployments. > And another thing: olpc-update is not to be used anymore, > or is it still on? It is still on for v8.2. It's future is perhaps a bit uncertain (maybe once we have working pure-Fedora builds it won't be active for a while, but it possibly will be resuscitated or replaced in future). I think the real question is: who are you developing for? v8.2 is pretty frozen and slow moving - the upcoming 8.2.1 includes only a handful of fixes (plus a couple of features for much improved deployability, that do not really affect the user experience). It will be adopted by deployments over the next few months, and will continue to be rolled out for probably a long time (e.g. Uruguay still using build 656 even though development terminated a long time ago). There may be an 8.2.2 with a similar collection of small fixes, depending on demand from deployments. If you want to develop for these deployments on this timeline, then you should work on top of 8.2 (sugar-0.82) and limit yourself to activity-level changes only. As for the future, the hope is that we will have a similarly-functional OS that includes the latest version of sugar asap. OLPC is working with Fedora on this, and while I suspect that the end result will be pushed as a "reference OS" by OLPC, there are also some other efforts which I think OLPC would probably be happy to flash onto machines at the factory (I can't speak officially, I am only a volunteer right now), including debXO, and a possibility of the community taking the 8.2 OS release and adding sugar-0.84 and some other things as an intermediate step before the pure-Fedora builds are suitable replacements. However, I personally think that all of these efforts are 6-12 months away (at least) from producing something adoptable by deployments. If you want to develop for the-future-with-unknown-timeframe, then you should work upstream at sugarlabs for sugar-0.84. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 'Resume activity' is confusing for user
2009/2/15 Mikus Grinbergs : > I've been very enthusiastic about the OLPC as a way to bring > technological assistance to people without reliable electricity or > on-line servers or much disposable income or even roads. To me, the > combination of rugged low-power (with current Joyride) hardware and > ease-of-learning software (original Activities) hit a "sweet spot". I'm sorry to hear about your frustration, I know it is shared by others and partially even by myself, but you should understand that the community is still active and OLPC still aims to have fundamentally the same software offering on the machines. Things are difficult because conditions outside of our control (i.e. employment status of key contributors) have changed, and it's a shame that the next development release is currently before the stages of being able to boot, but abandoning the project for these reasons is something I would urge anyone to reconsider... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] consequences of re-registering with XS
2009/2/14 Martin Langhoff : > On Fri, Feb 13, 2009 at 2:25 AM, Daniel Drake wrote: >> To avoid this situation in future (should we ever run into it again, >> fingers crossed we won't), we are considering a small modification to >> the paraguay OS build which makes the "Discard network history" button >> also clear the XS registration information (by deleting the >> server.backup1 line from sugar config). This code modification can be >> done with a single sed call, since there is already an unused sugar >> function to clear registration info. > > And if you post it as a nice patch, I'll push for it to be folded into > Sugar. It's been on my Sugar wishlist for a while... I've come short of a nice patch (too many pressures at the moment, sorry) but I have shared our hack here: http://dev.sugarlabs.org/ticket/362 > Nope. If an XO forgets it's registered and registers again, nothing > bad happens. The XS welcomes back the long lost son, no prickly > questions asked. Excellent, thanks for the clarification. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi Michael, 2009/2/24 Michael Stone : > In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. How realistic is it to make rainbow something generic that all environments and applications could use? In an ideal world, such a security system should be available to everyone, not just sugar users -- but I'm not sure which technical challenges are entailed. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] 0.82 activity updates
Hi, In Paraguay we'd like to roll out a new Browse release for sugar 0.82 including this fix: http://dev.laptop.org/ticket/8857 Could/should I do this officially through the appropriate Browse git branch? I think we already have a problem with overlapping version numbers between the releases for 0.82 and 0.84. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.82 activity updates
2009/4/28 David Farning : > With all that being said, the goal for Sugar Labs should be, 'How can > Sugar Labs help you support your local deployment?' I'm perfectly capable of taking care of it locally. My question is not that complicated: can/should I share my work with the larger community? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.82 activity updates
2009/4/29 Tomeu Vizoso : > If nobody else is interested, then you probably should use > infrastructure local to .py. OK. If anyone else is interested, here is Browse-101 for 0.82 including the fix for http://dev.laptop.org/ticket/8857 http://dev.laptop.org/~dsd/py-activities/Browse-102.xo As for the general versioning discussion, have we considered a scheme similar to GNOME? That is, the GNOME image viewer for GNOME 2.26 gets released as version 2.26.0, incremental release is 2.26.1, etc. So we might have Browse-0.84.3 as the 3rd Browse release for sugar-0.84. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu
2009/5/4 : > I basically don't want students to be able to erase any activities. After > our first deployment here in Afghanistan, we had to reinstall a lot of > laptops because students accidentally deleted most of their activities. We see this lots in Paraguay too. We have solved it here by: 1. Using a .xo bundle to install /home/olpc/Activities/.groups pointing to http://schoolserver/activities see http://wiki.laptop.org/go/Software_update#Activity_groups 2. Importing all the activities into the XS activity server see http://wiki.laptop.org/go/XS-activity-server 3. Improving the in-school behaviour of the activity updater see http://dev.laptop.org/ticket/9259 Then when the children delete activities, restoring them is just a few clicks...run the activity updater from the control panel and let it do it's thing. It is working well so far. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] dumping datastore to another filesystem
2009/5/12 Sameer Verma : > Is there a script that will dump all objects from the sugar datastore > to another filesystem (FAT or ext2)? Dragging and dropping objects one > at a time from the journal onto the USB icon is painfully slow. Some scripts we use in paraguay for full backup/restore to XS: http://dev.laptop.org/ticket/9250 Could easily be adapted to work with other mediums. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sugar on a website
The great team in paraguay have a new website, based on an interface you might recognise :) http://www.paraguayeduca.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse-101 for 0.82 and XS-0.6 interop
2009/5/21 Martin Langhoff : > Simon (aka erikos) has just uploaded Browse-101.xo to > http://activities.sugarlabs.org/en-US/sugar/addons/versions/4024#version-101 > > This is the currently recommended Browse for XOs running 8.2.x wanting > to interoperate with the upcoming XS 0.6 . This version was previously > available but hard to find -- Daniel Drake posted a (probably > identical) version recently, but it was missing from the SL's download > facility. > > Now it's there, easy to find, recommended. Thanks! Someone posted my version here: http://wiki.laptop.org/go/Activities/G1G1/8.2 It is not exactly the same, it includes a fix for http://dev.laptop.org/ticket/8857 too. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] Browse-101 for 0.82 and XS-0.6 interop
2009/5/21 Martin Langhoff : > IIRC, Simon's release also had a patch from Sayamindu. Not sure if > that's in Daniel's version. In any case, both versions have tested > a-ok with the XS :-) Is there anything new in Simon's 101 that has appeared on activities.sugarlabs.org or is it identical to the one that was announced 1-2 months ago? My 102 is the Browse-101-for-8.2 that was announced 1-2 months ago, plus the fix for the ticket that I mentioned. So it should have all the other relevant patches and fixes, unless something was silently added since initial release. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] disabling "tap to click"
2009/5/28 roshan karki : > The problem with gsynaptics is I don't have any section with "synaptic" as > identifier in xorg.conf Yes, the XO ships with the standard PS/2 driver, so the touchpad runs in the PS/2 "emulation" mode. This works but means you don't have control over the more advanced features of the new touchpad, such as enabling/disabling tap-to-click. And as you have noted, the new touchpad has tap-to-click enabled in the PS/2 emulation mode. If you do want that extra control, you have to install and configure the synaptics driver to suit your needs. If my recollection is correct, OLPC did not do this for 8.2.1 as it was decided that the change was too major for a bug-fix release, and while the sudden change is a little undesirable, it was hoped that kids being kids would "adapt" without problems. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar + OLPC mesh network selection logic
Hi, I'm looking to implement network selection logic in sugar-0.84 using the NetworkManager D-Bus API to implement something similar to what was present in NetworkManager-0.6 for OLPC's mesh device. (the logic is now being moved out of NetworkManager into sugar) My work in progress is: NM-0.7 with OLPC mesh support http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi sugar-0.84.5 patch to add mesh support (connects to link local mesh when selected on neighborhood view) http://dev.laptop.org/~dsd/20090610/sugar-0.84-olpc-mesh.patch I'm looking for some feedback on my plan, particularly for the interacting-with-NM side of things. This is how sugar works at the moment (I think): - Only infrastructure networks are supported. - On a new install, it doesn't attempt any connections. - When the user clicks on a network to connect, sugar makes an NMSettingsConnection object and and uses ActivateConnection() to activate it. - If the connection succeeds, sugar saves the details internally. - When starting up again later, sugar loads all its saved networks, creating NMSettingsConnection objects with the autoconnect flag set. - It doesn't call ActivateConnection() on anything, but presumably NM notices the new connections (with the autoconnect preference) and picks one to try. And now the logic I want to implement, which is similar to that in previous OLPC OS releases: - First, attempt to connect to any known access points that are in range using saved credentials. Always prefer known APs to mesh. - As a fallback if those APs fail, or if no APs are available or if we've never connected to any (e.g. on first boot), try the mesh. "try the mesh" means trying each of these configurations in turn, stopping on the first one that succeeds: 1. Connect to school server on channel 1 (i.e. dhcp with XS anycast address) 2. Connect to mesh portal on channel 1 (i.e. dhcp with MPP anycast address) 3. Connect to school server on channel 6 4. Connect to mesh portal on channel 6 5. Connect to school server on channel 11 6. Connect to mesh portal on channel 11 7. Connect to link-local simple mesh on channel 1 (cannot fail) [the mesh device settings class has properties 'channel' and 'dhcp-anycast-address' therefore the way to try each configuration is by creating and activating a new NMSettingsConnection object for each one] My uncertainty is how to implement the above logic. Is it possible to assign a priority or preference to a NMSettingsConnection object? If so, I could just create high-priority objects for all APs, and decreasing priority objects for the mesh configurations, all with the autoconnect flag. The priorities would cause Networkmanager to try them in order suggested above. Alternatively, we could always set autoconnect=False for all networks, and have some kind of management layer inside sugar which iterates through all the networks, monitoring the device states, calling ActivateConnection and moving onto the next one if it failed to connect. But immediately it gets tricky.. for infrastructure networks, we have to consider which APs are available, and what happens if they appear later?, etc. Or, other options? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Design review plea.. OLPC desktop switcher
Hi Eben/other interested victims, I've designed (it's usually bad news when I've designed things) some interfaces that allow for switching between Sugar and GNOME for the XO-1.5 builds. I'm looking for feedback on the design and any suggestions/contributions. By default, laptops boot straight up into Sugar. But you might notice a new icon in the control panel named "Switch desktop" http://dev.laptop.org/~dsd/20090619/sugar-controlpanel.png If we click on that, under normal circumstances you will see: http://dev.laptop.org/~dsd/20090619/sugar-active-sugar.png Then, when you click the "Switch to GNOME" button, it will look like this: http://dev.laptop.org/~dsd/20090619/sugar-active-gnome.png And if everything works right, this one will never be seen, but allows for an escape route if something goes wrong: http://dev.laptop.org/~dsd/20090619/sugar-active-unknown.png When you're in GNOME, there is an icon that says "Switch to Sugar" on the desktop. It's also on the Applications menu, under System. When you click on it, it brings up a dialog box that tells you to restart and then you'll be back in Sugar again. In this screenshot you can see the desktop item, the menu item, and the output dialog box: http://dev.laptop.org/~dsd/20090619/gnome-ui.png Code for all of that is at git://dev.laptop.org/users/dsd/olpc-switch-desktop (latest updates to be pushed in a few minutes) The Logout menu item in sugar is disabled. It's still there in GNOME, but I'll look for a way to hide it. (when you logout, it just basically restarts the desktop environment, so it's kind of pointless. A reboot is acceptable for changing DE, and the logout concept is confusing when there wasn't any logging in to begin with.) Thoughts? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design review plea.. OLPC desktop switcher
On Fri, 2009-06-19 at 17:04 +0100, Lucian Branescu wrote: > This looks great! > > What I don't like though, is the 'switch to sugar' functionality being > available as a button. Wouldn't it be better to keep it as a GDM > session option? Thanks for the feedback. We aren't shipping GDM or similar, particularly for new users it is very important that the laptops boot straight into Sugar without any confusing login screens coming up first. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] datastore results inconsistency
Hi Tomeu, I found the issue with the journal showing a duplicated entry after hand-deleting a datastore entry. It's an issue in the datastore, in the same function: DataStore.find() After your patch, we now weed out the entries that don't exist on-disk, but we still return "count" items (which is not adjusted accordingly) My suggested fix: decrement count in the loop if the file does not exist. for uid in uids: if os.path.exists(layoutmanager.get_instance().get_entry_path(uid)): metadata = self._metadata_store.retrieve(uid, properties) entries.append(metadata) + else: + count = count - 1 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] datastore results inconsistency
On Sat, 2009-06-27 at 12:57 +0200, Tomeu Vizoso wrote: > On Fri, Jun 26, 2009 at 18:57, Daniel Drake wrote: > > Hi Tomeu, > > > > I found the issue with the journal showing a duplicated entry after > > hand-deleting a datastore entry. > > Thanks for looking at this. As we discussed on IRC, things are a bit > more complex than I initially thought and we should rebuild all the > index when we find that the disk contents don't match the index. > > Would be great if you could try these patches and see if the journal > is more resistant in these cases: > > DS: http://shell.sugarlabs.org/~tomeu/rebuild_index_on_inconsistency.patch > Shell: http://shell.sugarlabs.org/~tomeu/remake_cache_on_inconsistency.patch Thanks, these seem to fix the problem! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar + OLPC mesh network selection logic
On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> If other APs appear later, it may well trigger the
> schedule_activate_check() which might cause NM to try to connect to that
> new network. To combat that, I'd suggest that the mesh device block the
> wifi device from activating if it already failed by putting it into the
> UNAVAILABLE state or something, but that could be error prone. What I
> think we really want here is the 'device idle' concept that asac and I
> have been talking over for a while.
The same consideration has to apply for when the mesh device disconnects
the eth device, because the user requested a mesh connection. Right now,
NM immediately reactivates eth0 (usually reconnecting to the same
network as before) and "wins."
What is the "device idle" concept? What do you think of an approach
along these lines? This way the mesh device can attach to the
autoconnect-allowed signal on the main device, and influence when it can
and cannot be used for automatic connections.
Daniel
>From bf78fa416ecf96bf9e607d1dd7c8fec29652a821 Mon Sep 17 00:00:00 2001
From: Daniel Drake
Date: Mon, 6 Jul 2009 16:42:55 +0100
Subject: [PATCH] Allow devices to inhibit autoconnect through a signal
This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.
---
src/NetworkManagerPolicy.c |2 +-
src/nm-device.c| 45
src/nm-device.h|1 +
3 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/src/NetworkManagerPolicy.c b/src/NetworkManagerPolicy.c
index 6bba92f..e2d4c95 100644
--- a/src/NetworkManagerPolicy.c
+++ b/src/NetworkManagerPolicy.c
@@ -726,7 +726,7 @@ schedule_activate_check (NMPolicy *policy, NMDevice *device)
if (state < NM_DEVICE_STATE_DISCONNECTED)
return;
- if (!nm_device_can_activate (device))
+ if (!nm_device_can_activate (device) || !nm_device_autoconnect_allowed (device))
return;
for (iter = policy->pending_activation_checks; iter; iter = g_slist_next (iter)) {
diff --git a/src/nm-device.c b/src/nm-device.c
index 5826a2a..488b2cf 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -50,11 +50,19 @@
#include "nm-setting-connection.h"
#include "nm-dnsmasq-manager.h"
#include "nm-dhcp4-config.h"
+#include "nm-marshal.h"
#define NM_ACT_REQUEST_IP4_CONFIG "nm-act-request-ip4-config"
static void device_interface_init (NMDeviceInterface *device_interface_class);
+enum {
+ AUTOCONNECT_ALLOWED,
+ LAST_SIGNAL,
+};
+
+static guint signals[LAST_SIGNAL] = { 0 };
+
G_DEFINE_TYPE_EXTENDED (NMDevice, nm_device, G_TYPE_OBJECT,
G_TYPE_FLAG_ABSTRACT,
G_IMPLEMENT_INTERFACE (NM_TYPE_DEVICE_INTERFACE,
@@ -360,6 +368,34 @@ nm_device_can_activate (NMDevice *self)
return TRUE;
}
+static gboolean
+autoconnect_allowed_accumulator (GSignalInvocationHint *ihint,
+ GValue *return_accu,
+ const GValue *handler_return, gpointer data)
+{
+ if (!g_value_get_boolean (handler_return))
+ g_value_set_boolean (return_accu, FALSE);
+ return TRUE;
+}
+
+gboolean
+nm_device_autoconnect_allowed (NMDevice *self)
+{
+ GValue instance = { 0, };
+ GValue retval = { 0, };
+
+ g_value_init (&instance, G_TYPE_OBJECT);
+ g_value_take_object (&instance, self);
+
+ g_value_init (&retval, G_TYPE_BOOLEAN);
+ g_value_set_boolean (&retval, TRUE);
+
+ /* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+ * value being changed if no handlers are connected */
+ g_signal_emitv (&instance, signals[AUTOCONNECT_ALLOWED], 0, &retval);
+ return g_value_get_boolean (&retval);
+}
+
NMConnection *
nm_device_get_best_auto_connection (NMDevice *dev,
GSList *connections,
@@ -2380,6 +2416,15 @@ nm_device_class_init (NMDeviceClass *klass)
g_object_class_override_property (object_class,
NM_DEVICE_INTERFACE_PROP_MANAGED,
NM_DEVICE_INTERFACE_MANAGED);
+
+ signals[AUTOCONNECT_ALLOWED] =
+ g_signal_new ("autoconnect-allowed",
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_LAST,
+ 0,
+ autoconnect_allowed_accumulator, NULL,
+ _nm_marshal_BOOLEAN__VOID,
+ G_TYPE_BOOLEAN, 0);
}
static gboolean
diff --git a/src/nm-device.h b/src/nm-device.h
index 9084816..b230da8 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -159,6 +159,7 @@ void nm_device_activate_schedule_stage4_ip_config_timeout (NMDevice *device);
gboolean nm_device_deactivate_quickly (NMDevice *dev);
gboolean nm_device_is_activating (NMDevice *dev);
gboolean nm_device_can_interrupt_activation (NMDevice *self);
+gboolean nm_device_autoconnect_allowed (NMDevice *self);
NMDeviceState nm_device_g
Re: [Sugar-devel] poor man's mmap "sliding window" on Python 2.5.x
On Wed, 2009-07-08 at 15:23 +1200, Martin Langhoff wrote: > Had some time to retest this on the plane, and I think it was > mis-diagnosis. The original code I was testing is lost. In re-testing > this I find that the problem is more nuanced, and I may have been > wrong: looking at 'top', the kernel does not appear very eager to > discard old mapped pages. You can probably influence this by marking the ranges that you're done with with madvise(). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar + OLPC mesh network selection logic
On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> > http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi
>
> Though you're really not going to want to use HAL fdi files for this,
> since master now uses only udev. You'll either want to hardcode the
> Marvell device IDs into nm-hal-manager (or match on "mshX") or you'll
> want to tag it with udev rules and grab the property from NM instead.
OK. I think udev rules is nicer. Do you think such rules should be
shipped within NM, or in udev itself?
The rule is currently:
KERNEL=="msh*", SUBSYSTEM=="net", DRIVERS=="usb", ATTRS{idVendor}=="1286",
ATTRS{idProduct}=="2001", ENV{NM_DEVICE_TYPE}="olpcmesh"
I don't know why we can't match on DRIVER=="libertas" (it's blank, must
be a libertas bug) so it's a bit messy. Also soon we will be adding
another rule since the XO-1.5 will come with wifi on SDIO.
Thanks,
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Nobody understands "Keep"
Hi, Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. Even with all the expertise on-site they seem to have been advising the (incorrect) use of the Keep button here: http://lists.sugarlabs.org/archive/iaep/2009-July/007038.html and then they wondered why they had 2 copies in the Journal. I have seen misuse of this button by the country teams in Ethiopia and Paraguay, in both cases they were giving teacher training and teaching the teachers the wrong thing... Perhaps it's time for a rethink/redesign. This functionality could be moved to the journal itself, in a place where it can be presented with more context, something like "Create duplicate copy." Or even some kind of visual feedback (to appear after clicking Keep) that makes it pretty obvious that you've just forked your work - that way you'd quickly learn the true functionality and know when and when not to use it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands "Keep"
On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: > On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: > > Nobody in the world seems to understand the Keep button. People think > > it's for regular saving and you should do it before you close or switch > > away from your activity. > > That's not far from the truth, right? At least in any work-losing or > surprising way... It's far from the truth in that it's not normally what you want to do. To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as "insurance" or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
On Wed, 2009-07-15 at 10:17 -0500, David Farning wrote: > Attached is a very early prototype of a sugar updater which pulls from ASLO. > > It kind-of works on jhbuild;-/ To test, unzip and drop it into > sugar-jhbuild/install/share/sugar/extensions/cpsection. > > run using 'install/share/sugar/extensions/cpsection/updater/model.py' > > Big Issues: > The GUI interface is reporting a network error. I personally feel that this kind of approach is not a great idea, but I suppose it depends who your target users are. This type of setup seems inappropriate for low-bandwidth/high-latency OLPC-style deployments, since it seems to rely on the internet. Unless you're suggesting that people run the updates website on the school server, in which case xs-activity-server would need to be reworked into that, or an alternative solution developed which does not require deployers doing too much setup. The current updater has some nice properties in that the microformat is simple, the surrounding infrastructure is in place for deployments (use xs-activity-server, or maintain a .html file), and that at least with this patch it will operate very well even without internet access: http://dev.laptop.org/ticket/9259 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proxy Settings in Network Control Panel
On Wed, Mar 13, 2013 at 10:43 PM, Ajay Garg wrote: > For more details of the "http_proxy" interactions with GTK+, please see the > source-code of webkit, in particular > http://svn.webkit.org/repository/webkit/trunk/Tools/GtkLauncher/main.c GtkLauncher is not a part of WebKit (the library, as used by Sugar). It is a standalone test app. So unless you have another place truly inside webkit where $http_proxy is used, I am doubtful that webkit is using this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
On Mon, Nov 21, 2011 at 2:27 PM, Anish Mangal wrote: > I'd like to propose "Network proxy configuration in Sugar" > > http://wiki.sugarlabs.org/go/Features/Proxy_configuration I would say that this feature does not fit particularly nicely with some items of our guidelines: http://wiki.sugarlabs.org/go/Features/Policy#Things_you_should_consider_when_proposing_a_feature In other words, I can't imagine every 6-12 year old student in a school going into the control panel and typing (without error) a load of proxy details. In my experience things like this are incredibly challenging especially because the users cannot relate to the task at hand (unless you want to teach them about computer networks first). A more sensible model would be that this is somehow automated by the deployer or by the school infrastructure, such that the user is not distracted and does not have to care. I'm aware that such generalizations can't be applied to all cases and that this feature is probably driven by some users where this indeed can't be applied. So I'm not in opposition to this feature (even though it would be nice to have the more automated approach designed as well), but I think we need to consider the implications on our more "regular" target userbase. For example, what happens if a user who is on a proxy-free network types "hello" into the proxy configuration textbox? Does that break all networking? One problem that I have seen in various places, children untick the "Radio enable" checkbox in Sugar's control panel and then return their laptop for repair because they can't get online. I fear that proxy configuration could become support headache like this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
On Thu, Mar 14, 2013 at 2:08 PM, Alan Jhonn Aguiar Schwyn wrote: >>One problem that I have seen in various places, children untick the >>"Radio enable" checkbox in Sugar's control panel and then return their >>laptop for repair because they can't get online. I fear that proxy >>configuration could become support headache like this. > > Thinking in the same way, we must block the command "rm" from the > terminal because the childrens can remove important files. Or the > command "mv" because generates that an activity no works I can see why you might think that way. However, I have never experienced this being a problem, and I don't recall seeing other reports of this, so I would not argue for any blocking of terminal commands. The radio checkbox is a real headache that *actually happens* though. Taking a guess as to why we see the radio problem but not the terminal one in our field experiences, I would imagine the crucial difference is that the radio checkbox is presented in a way that it is easily accessible but commonly uncomprehendable to our regular user base. In comparison, those dangerous commands in the terminal are in their own world of inaccessibility... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
On Thu, Mar 14, 2013 at 2:31 PM, Gonzalo Odiard wrote: > About the network proxy configuration, I agree is better have a automatic > configuration _if_possible_, but there are times when is not possible, > then we should provide a solution. Has been a request for a long time, > and the development is already 90% done I would still appreciate the answer to this question: For example, what happens if a user who is on a proxy-free network types "hello" into the proxy configuration textbox? Does that break all networking? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OLPC France 12.1.0 testing results
On Fri, Mar 15, 2013 at 4:03 PM, wrote: > We're currently preparing the 2013 mission to our Nosy Komba deployment: 150 > XO-1 + 50 XO-1.5. > > So, a team of volunteer have tested on 12.1.0/Sugar 0.96 our 63 activities > currently deployed there on OLPC 883/Sugar 0.94.1. > > I know it's a "hot topic" here :-) so following is the result of our test. Thanks a lot for the report. This kind of thing is always very interesting and useful. > · Fix the last issue regarding hulahop incompatibility on 3 > activities (Map, Madagascar, HelpFR), I'm sure you will find help here if this proves challenging. > · Do intensive testing on XO-1 to check the performance issue > mentioned here recently (most of our testing has been done on SoaS or > XO-1.5), According to testing within OLPC, 12.1.0 should not introduce significant performance issues here. 13.1.0 is where the significant slowdowns are introduced. We will try to work on this. > · Try to optimize the size of our bundle to adapt to the new size of > free space on 12.1.0, I'm sorry that the image has grown a bit. It is a battle that we haven't had enough resources to fight well enough. > · Find a new way to create our bundle. Until this year we've got a > customization key but unfortunately it's not supported now: we can't > deployed 63 activities, one by one on 200 XO! You probably already know, what we recommend here is http://wiki.laptop.org/go/OS_Builder Feel free to ask any questions on de...@lists.laptop.org If your laptops are secured, get in contact with OLPC (with a list of serial numbers) to help unlock them. I imagine for a project like yours, you will appreciate the simplicity added overall (i.e. removing the step where you have to use the customization stick), even though you will face a small learning curve first. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available
Extend the sound backend selection code to consider using ALSA. On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x. It also fixes XO-4 sound recording which was not working on any previous version. Index: etoys-5.0.2408/etoys.in === --- etoys-5.0.2408.orig/etoys.in2013-03-27 15:06:22.0 -0400 +++ etoys-5.0.2408/etoys.in 2013-03-27 15:06:33.0 -0400 @@ -6,6 +6,7 @@ VM="squeak" VMOPTIONS="-encoding UTF-8 -vm-display-x11 -xshm" +VMSOUND="" IMAGE="@prefix@/share/etoys/etoys.image" IMOPTIONS="" DOCUMENT="" @@ -85,18 +86,24 @@ # make Compose input methods work [ -z "$LC_ALL" ] && export LC_ALL="$LANG" -# if pulseaudio is running, use it if VM has the driver, or fall back to OSS +# if pulseaudio is running, use it if VM has the driver if pulseaudio --check 2>/dev/null ; then if "$VM" -help 2> /dev/null | grep -q vm-sound-pulse ; then -VMOPTIONS="$VMOPTIONS -vm-sound-pulse" +VMSOUND="-vm-sound-pulse" else -VMOPTIONS="$VMOPTIONS -vm-sound-oss" if padsp true 2>/dev/null ; then +VMSOUND="-vm-sound-oss" WRAPPER=padsp fi fi fi +# Otherwise use ALSA if available +[ -z "$VMSOUND" -a -e /proc/asound/cards ] && VMSOUND="-vm-sound-ALSA" + +# Fall back on OSS +[ -n "$VMSOUND" ] || VMSOUND="-vm-sound-oss" + # enable compositioninput case "$LANG" in bn* | gu* | hi* | kn* | ml* | mr* | ta* | te* | sa* ) @@ -110,5 +117,5 @@ # VM, Image, and Document are non-optional # Document has to be present even if empty for IMOPTIONS to work -$DEBUG $WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS -exec $WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS +$DEBUG $WRAPPER "$VM" $VMOPTIONS $VMSOUND "$IMAGE" "$DOCUMENT" $IMOPTIONS +exec $WRAPPER "$VM" $VMOPTIONS $VMSOUND "$IMAGE" "$DOCUMENT" $IMOPTIONS ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Music keyboard stuck keys
Hi, Some testers at the OLPC office in Nicaragua found that it's quite easy to break the shiny new piano. 1. Use one finger to play a note on the piano (and hold that finger down). 2. Use another finger to scroll up and down in the instrument selector above the piano. 3. Remove the instrument-scroll finger. 4. Remove the piano note finger. The piano note stays held down (shown in yellow, with the sound continuing). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Music keyboard stuck keys
On Fri, Apr 5, 2013 at 5:20 PM, Gonzalo Odiard wrote: > I will try. > Is not the same issue we see in Paint with the mouse emulation? No, because there is no mouse movement involved. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available
Hi, On Wed, Mar 27, 2013 at 1:10 PM, Daniel Drake wrote: > Extend the sound backend selection code to consider using ALSA. > On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x. > It also fixes XO-4 sound recording which was not working on any previous > version. Ping, any news here? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
On Fri, Apr 12, 2013 at 6:42 PM, Daniel Narvaez wrote: > I might not have yet made explicit what a web application provides on the > top of an html page loaded in a browser, which is what we get with 1. Taking > a look to the Chromium documentation is a good way to get an idea of it. > > http://developer.chrome.com/trunk/apps/api_index.html Thanks, I was waiting for someone to succinctly explain the perceived benefit of using Chrome as a backend for this project, and this seems to be it. One way to think about this is that we are used to Python, which has a nice standard library. But javascript basically doesn't have that. And this Chrome API provides some kind of equivalent. For this discussion, we might divide the Chrome API into 2 different parts 1. General utility functions (e.g. i18n, events) 2. Integration with low level system functions (e.g. bluetooth) I would say we have multiple alternatives for #1. e.g. qooxdoo is one that I am familiar with. So the real benefit of the Chrome thing is the system integration? Is that something really needed for Sugar? It would be necessary if we were to port *all* Sugar activities to javascript, but I am not sure if that is our goal. There are certainly a lot of things that can be done without such system access. I also have some other concerns about using Chrome as a backend (please correct any inaccuracies): 1. We have to accept all constraints of Chrome - both present and future. We have found two already: the challenges of handling of multiple versions, and the challenges of making this system work without having chrome running in the background all the time. 2. From my limited understanding, Chrome/Chromium is technically an open source project, since code is made available, but does not fit under many more definitions of "open source project". It's not something that is developed in the open with decisions run past the community etc. That doesn't fit the Sugar model very well. 3. I see this project as a way of taking us closer to Sugar (in some sense) on Android. Can Chrome webapps work as first-class citizens on Android? > (Hopefully they will some day converge between browsers!). There is already convergence in the "utility function" part of such APIs - for example you can take qooxdoo and use all of its API on any browser. I think it is only a matter of time until some kind of system emerges that provides a browser-independent API to low level system functions as well. (or maybe we already have that: gobject-introspection, which can be used in javascript?) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
On Wed, Apr 17, 2013 at 9:39 AM, Daniel Narvaez wrote: > But is WebKit so much better? For example the WebKit2 decision _seems_ to > have been made by Apple engineers without even talking to major > contributors. The gtk bits are maintained the way we would like them to > but... I'm not sure that applies to the rest of the codebase. I think WebKit is better, but I am no expert. I have seen extensive technical discussions on public mailing lists. I have gotten good and detailed responses on the public bug tracker. I've also benefitted from information posted on bug reports reported by other people. And the GTK guys have done a great job at catering to our immediate needs. There are other factors too. Chromium bundles a load of libraries, rather than using systemwide ones, which is not really the model that we expect on the open source desktop. I think this is the main reason why it is not in Fedora (Fedora has a guideline against that, and packaging Chromium is no easy task as a result). WebKit is much better there, and in being in general a good "open source desktop friendly" solution. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available
On Mon, Apr 15, 2013 at 10:20 AM, Bert Freudenberg wrote: > On 15.04.2013, at 07:53, Daniel Drake wrote: >> On Wed, Mar 27, 2013 at 1:10 PM, Daniel Drake wrote: >>> Extend the sound backend selection code to consider using ALSA. >>> On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x. >>> It also fixes XO-4 sound recording which was not working on any previous >>> version. >> >> Ping, any news here? >> >> Thanks >> Daniel > > > Ah, I'm sorry, didn't get to it yet. Thanks for the reminder! Another quick reminder for this patch :) Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python <-> js IPC
On Thu, Apr 25, 2013 at 3:59 PM, Daniel Narvaez wrote: > Hello, > > I wrote a quick prototype for a possible python <-> js IPC. I am missing some background here. In what cases do we need such IPC? The two cases that spring to mind are journal and collaboration. > I think in an ideal world the javascript code would communicate directly > with system services. I agree. To me, gobject-introspectionis the obvious choice here, and it can be used from javascript (in some form at least). How hard would it be to make it available here? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Fallback to _NET_WM_PID to map windows to activities
Thanks, this can be used to fix the problem detailed in my mail "Window handling for non-Python activities" I have tested it. On Sat, Feb 2, 2013 at 6:18 AM, Daniel Narvaez wrote: > -def get_type(self): > +def get_bundle_id(self): > """Retrieve the activity bundle id for future reference""" > -if not self._windows: > -return None > -else: > -return SugarExt.wm_get_bundle_id(self._windows[0].get_xid()) > +self._bundle_id Missing return statement here? > diff --git a/src/jarabe/view/service.py b/src/jarabe/view/service.py > index 61b3d59..c7187c7 100644 > --- a/src/jarabe/view/service.py > +++ b/src/jarabe/view/service.py > @@ -80,9 +80,9 @@ class UIService(dbus.service.Object): > return False > > @dbus.service.method(_DBUS_SHELL_IFACE, > - in_signature='ss', out_signature='') > -def NotifyLaunch(self, bundle_id, activity_id): > -shell.get_model().notify_launch(activity_id, bundle_id) > + in_signature='ssi', out_signature='') > +def NotifyLaunch(self, bundle_id, activity_id, pid): > +shell.get_model().notify_launch(activity_id, bundle_id, pid) This is an API change. The toolkit calls this method so it must be updated as well, otherwise activity launch breaks. And I guess we might have broken compatibility with some other things like etoys. I wonder if we can avoid this API change - can the receiver of the dbus message look up the PID of the sender? Some possible clues here: http://lists.freedesktop.org/archives/dbus/2008-September/010403.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Fallback to _NET_WM_PID to map windows to activities
On Wed, May 1, 2013 at 3:25 AM, Daniel Narvaez wrote: > It has been a while since I wrote this patch, hopefully I'm not > misremembering... I think NotifyLaunch is in practice private to the shell, > activities should have no need to use it (and are not supposed to be > importing activityfactory.py). When I tested it yesterday it did break activity launch until I fixed the toolkit for this API change. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH TamTam 1/2] Output to ALSA directly from csound
TamTam sound is crackly on some setups (e.g. XO-1.5 and newer with
dmix running at 48000Hz). http://dev.laptop.org/ticket/12651
Clooper seems to implement its own ALSA sample rate resampling,
as well as upsampling of the period rate to overcome any differences
in csound period size and ALSA period size. This code is the cause of
the crackles.
Switch to csound's internal ALSA backend, which works well, and does
not have these problems. Tested on XO-1, XO-1.5, XO-1.75 and XO-4.
---
common/Config.py| 5 -
common/Resources/tamtamorc.csd | 2 +-
common/Util/CSoundClient.py | 4 +-
common/Util/Clooper/Makefile| 2 +-
common/Util/Clooper/aclient.cpp | 122 ++---
common/Util/Clooper/audio.cpp | 237
6 files changed, 14 insertions(+), 358 deletions(-)
delete mode 100644 common/Util/Clooper/audio.cpp
diff --git a/common/Config.py b/common/Config.py
index b1c1318..bb9c3ff 100644
--- a/common/Config.py
+++ b/common/Config.py
@@ -55,13 +55,8 @@ for i in (INSTANCE_DIR, DATA_DIR, SNDS_INFO_DIR, TMP_DIR):
PLUGIN_DEBUG = os.getenv("CSOUND_LOGFILE", "")
PLUGIN_VERBOSE = DEBUG
PLUGIN_UNIVORC = join(FILES_DIR, "tamtamorc.csd")
-PLUGIN_KSMPS = 64
PLUGIN_RATE = 16000
-## PLUGIN ALSA PARAMETERS:
-PLUGIN_PERIOD = 1024
-PLUGIN_NPERIODS = 2
-
try:
from sugar3.graphics.toolbarbox import ToolbarBox, ToolbarButton
HAVE_TOOLBOX = True
diff --git a/common/Resources/tamtamorc.csd b/common/Resources/tamtamorc.csd
index f0a63f1..3adf81b 100644
--- a/common/Resources/tamtamorc.csd
+++ b/common/Resources/tamtamorc.csd
@@ -1,6 +1,6 @@
--n -m0 -W -s -d
+-n -odac -m0 -W -s -d
sr=16000
diff --git a/common/Util/CSoundClient.py b/common/Util/CSoundClient.py
index 3cf6794..c082137 100644
--- a/common/Util/CSoundClient.py
+++ b/common/Util/CSoundClient.py
@@ -47,9 +47,7 @@ class _CSoundClientPlugin:
def __init__(self):
sc_initialize( Config.PLUGIN_UNIVORC, Config.PLUGIN_DEBUG,
-Config.PLUGIN_PERIOD, Config.PLUGIN_NPERIODS,
-Config.PLUGIN_VERBOSE,
-Config.PLUGIN_KSMPS, Config.PLUGIN_RATE)
+Config.PLUGIN_VERBOSE, Config.PLUGIN_RATE)
self.on = False
#self.masterVolume = 100.0
self.periods_per_buffer = 2
diff --git a/common/Util/Clooper/Makefile b/common/Util/Clooper/Makefile
index 0f28366..eaefae9 100644
--- a/common/Util/Clooper/Makefile
+++ b/common/Util/Clooper/Makefile
@@ -23,7 +23,7 @@ all : aclient.so
mv aclient.so $(LIB_NAME)/
touch $(LIB_NAME)/__init__.py
-aclient.so : aclient.cpp audio.cpp
+aclient.so : aclient.cpp
g++ $(CXXFLAGS) -shared -o $@ $< $(LDFLAGS)
clean :
diff --git a/common/Util/Clooper/aclient.cpp b/common/Util/Clooper/aclient.cpp
index f238c36..f8ecaea 100644
--- a/common/Util/Clooper/aclient.cpp
+++ b/common/Util/Clooper/aclient.cpp
@@ -14,18 +14,7 @@
#include
#include
-static double pytime(const struct timeval * tv)
-{
-struct timeval t;
-if (!tv)
-{
-tv = &t;
-gettimeofday(&t, NULL);
-}
-return (double) tv->tv_sec + (double) tv->tv_usec / 100.0;
-}
#include "log.cpp"
-#include "audio.cpp"
int VERBOSE = 3;
@@ -510,52 +499,31 @@ struct TamTamSound
MYFLT tick_total;
/** the upsampling ratio from csound */
-unsigned int csound_ksmps;
snd_pcm_uframes_t csound_frame_rate;
snd_pcm_uframes_t csound_period_size;
-snd_pcm_uframes_t period0;
-unsigned int period_per_buffer; //should be 2
-int up_ratio; //if the hardware only supports a small integer multiple of
our effective samplerate, do a real-time conversion
log_t * ll;
-SystemStuff * sys_stuff;
-TamTamSound(log_t * ll, char * orc, snd_pcm_uframes_t period0, unsigned
int ppb, int ksmps, int framerate )
+TamTamSound(log_t * ll, char * orc, int framerate )
: ThreadID(NULL), PERF_STATUS(STOP), csound(NULL),
music(),
ticks_per_period(0.0),
tick_adjustment(0.0),
tick_total(0.0),
-csound_ksmps(ksmps),//must agree with the
orchestra file
csound_frame_rate(framerate), //must agree with the
orchestra file
-period0(period0),
-period_per_buffer(ppb),
-up_ratio(1),
-ll( ll ),
-sys_stuff(NULL)
+ll( ll )
{
-sys_stuff = new SystemStuff(ll);
-if (0 > sys_stuff->open(csound_frame_rate, 4, period0,
period_per_buffer))
-{
-return;
-}
-sys_stuff->close(0);
-up_ratio = sys_stuff->rate / csound_frame_rate;
-csound_period_size = (sys_stuff->period_size % up_ratio == 0)
- ? sys_stuff->period_size / up_ratio
- : csound_ksmps * 4;
-
csound = csoundCreate(NULL);
-int argc=3;
+int argc=4;
const char **argv = (const char**)malloc(argc*sizeof(char*));
argv[0
[Sugar-devel] [PATCH TamTam 2/2] Clooper: strip built library
This saves some disk space. The unstripped version can still be built with "make aclient.so" --- common/Util/Clooper/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/common/Util/Clooper/Makefile b/common/Util/Clooper/Makefile index eaefae9..8dfd624 100644 --- a/common/Util/Clooper/Makefile +++ b/common/Util/Clooper/Makefile @@ -20,6 +20,7 @@ LDFLAGS+= $(python-config --libs) \ all : aclient.so rm -rf $(LIB_NAME) mkdir $(LIB_NAME) + strip aclient.so mv aclient.so $(LIB_NAME)/ touch $(LIB_NAME)/__init__.py -- 1.8.1.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
