Re: [Sugar-devel] [DESIGN] Icon for toolkit
On 08/21/2013 03:44 PM, Manuel Quiñones wrote: 2013/8/21 Walter Bender walter.ben...@gmail.com: I like the Join_Developer approach, although it seems a bit overly complex. Yes. I will try removing the buddy, keeping only the tools. Mind that we already have the icon for the control panel using the screw-wrench, the icon should be distinguishable from that one. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
This thread is about the technical solving of the issue, did we agree on
making this change, really? I am not at all convinced.
What do people think about my proposal with adding a picture/drawing per
kid that is part of the Palette then? We can see if we want to transfer
this compressed to the other users to have that available in the
neighborhood views. But we would have the same issue with the modified
icon that is proposed here.
Simon
On 06/19/2013 04:43 PM, Walter Bender wrote:
Here are some thoughts about the custom icon patch:
(1) if we prepend ~/.sugar/icons to the theme icon path, then anything
in that path will be used (as long as we flush the cache) as per
dnarvaez's comment on the patch
(2) if we have a sugar activity for selecting svg files (from the
journal and some samples) and loading the selected file as
computer-xo.svg into ~/.sugar/icons then we are done.
#1 is a two-line addition to jarabe/main.py
icons_path = os.path.join(os.path.expanduser('~'), '.sugar', 'icons')
Gtk.IconTheme.get_default().prepend_search_path(icons_path)
#2 is similar to what you already did for the cpsection, only it is a
stand-alone activity similar to xo-colors
We can use Turtle Art and other activities to generate SVGs. (The old
version of xo-colors let you edit the XO icon... with revisiting in
this context.)
We need to figure out how to flush the icon cache.
regards.
-walter
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On 06/20/2013 12:16 PM, Daniel Narvaez wrote: On Thursday, 20 June 2013, Simon Schampijer wrote: This thread is about the technical solving of the issue, did we agree on making this change, really? I am not at all convinced. The technical solution proposed here has pretty strong implications on the feature though. It becomes completely optional being an activity. That might affect our decision on making the change or not. For such a change I would like to see a design discussion first independent from the implementation. It is relatively easy to quickly implement something that sort of works, to hack something but creating a good user experience and work flow is not. There are all those little details to consider. The original question stands: do we make it easy to customize the most central icon in our UI. And there were concerns that we should not do it. As far as I understand the current proposal is to do it only locally. So it would change the XO icon in which places: The HOME/Groups/Neighborhood View for my icon? Will it change in the Frame as well? If I am sitting next to my friend and look on his screen for myself, why do my icon have the original shape? How would my icon look like in the members view of the Memorize activity when I play a game collaboratively? The color chooser in the CP uses this new icon? --- We actually made the background customizable, the shape of the circle is theoretically. The latter could be made easier imho maybe in a CP section. As well, I still think adding a photo/drawing would be a valuable addition. It is true it is not as present as the user icon change but would help to personalize. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On 06/20/2013 01:28 PM, Walter Bender wrote: I agree that the technical solution we have come up with to a large extent obviates the need for consensus around whether or not to implement this feature as it pushes it to the user space in the from of an activity. (Gonzalo and I have been discussing the fact that other cpsection widgets could also be moved to activities, but that is for another day. Regarding the specifics of this feature, I have not found any of the arguments that this feature is somehow going to confuse our users even remotely convincing. Three observations: (1) any change to the icon is driven by explicit user action, so no surprises there; (2) in virtually every other system or service our users encounter, there is the ability to set a personal avatar, so to argue that this is somehow going to confuse them in Sugar seems a stretch; and (3) particularly in light of the new approach, making it easier for our end users to make modifications to the system is in keeping with our overall pedagogy -- moving away from requiring root access to make changes is a good thing and while we don't want our users to inadvertently break things irreparably, there is something to be said for learning from the experience of breaking things. Bottom line, I seem to have more faith in the abilities of our users than perhaps is warranted, but I think that is aligned with our goals to encourage our users to take change. (The fact that this feature comes from one of our users says a lot.) Regarding our broken decision-making process, the problem I have is less that we don't reach consensus than that the discussions are happening very late in the process. We had, for example, had an email from our release manager months ago about the features proposed for this release. That was the time to question whether or not this feature should be accepted. To wait until now is not fair to the person, in the case, Ignacio, who has been working hard on his implementation. It is fine to give technical criticism at this point, and I think that discussion has been fruitful, but in my opinion, we really need to be more forthcoming earlier in the process about the features themselves. Has that feature been accepted for 0.100? I must admit that I do not read all the mails and I might have overseen this one, at least I first saw [1] when the patch was submitted. Has there been a mail to ask for feedback for the design? The process tries to make room for that early feedback, especially for Features that changes UI or work flow. Simon [1] http://wiki.sugarlabs.org/go/Features/Icon_Change [2] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About customization of xo icon
On 06/16/2013 07:19 AM, Gonzalo Odiard wrote: I think we should decide if changing the xo icon is a feature we _really_ want include in sugar. I am not sure if add too much value, but probably can add confusion, more if is applied in all the places where the xo icons is used , like the actual implementation do. May be we can limit the change to only the favorites view? About the change in the control panel, in the past we tried to not add more items, like in the case of the proxy configuration, and that was a feature needed in some deployments. Other opinions? Gonzalo I agree with the possible confusion if we allow changing the outlines of the user icon easily: imagine the situation in the Neighborhood view. At the moment you can identify more or less easily what is a user, what an Access point and what a shared activity. This will be way harder if everyone uses another icon for his appearance. As well having the same icon for everyone does unite the learners as well. Everyone has the same basic shape, just the color differs. There are arguments for similar concepts like for example a school uniform going into both directions, I think here it can be thought as a strength. About the point raised by Walter that allowing the learner to customize the icon as not having much value, I would argue that it would have value if the learner would find out how to hack the device to change the file himself :) A counter proposal to allow for customization: I would prefer doing the personalization with the addition of a user photo/drawing. You would see this in the Palettes of the XO icon in the home/friends/neighborhood view. We had plans and probably sketches about that in the early Sugar days. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Use ObjectChooser filtering by activity
On 06/13/2013 06:35 PM, Daniel Narvaez wrote: On 13 June 2013 18:26, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 June 2013 18:23, Gonzalo Odiard gonz...@laptop.org wrote: That is the reason is better modify the behavior of the activity filter, than allow any random list of mime types. I'm not sure to understand this. You are proposing to show all the files with mime types the activity can open right? That's pretty much a list of random mime types as far the filtering combo is concerned... You can't select Anything, you can't select a generic type and you can't select an activity (this might actually be the nearest to accurate, but it's not quite because the files are not necessarily created by the activity). Oh I see, you are talking about the approach in your patch. That's still quite tricky though... Would you keep the current filtering behavior for journal? Would it apply to object chooser only? To certain object choosers only? Yes, the trickiest bit is how to display that in the UI. Non of the current filters does match this case here, using the activity icon would confront with what it currently means in the filter, as it means an object of that activity. Maybe this special objectchooser has just no filter sub-toolbar? And the message when no matching object could be found reads as No entry found that can be opened with Activity [Name of activity]. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Use ObjectChooser filtering by activity
On 06/17/2013 03:37 PM, Daniel Narvaez wrote: I like the idea of disabling the filter in this objectchooser. On 17 June 2013 15:34, Simon Schampijer si...@schampijer.de wrote: On 06/13/2013 06:35 PM, Daniel Narvaez wrote: On 13 June 2013 18:26, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 June 2013 18:23, Gonzalo Odiard gonz...@laptop.org wrote: That is the reason is better modify the behavior of the activity filter, than allow any random list of mime types. I'm not sure to understand this. You are proposing to show all the files with mime types the activity can open right? That's pretty much a list of random mime types as far the filtering combo is concerned... You can't select Anything, you can't select a generic type and you can't select an activity (this might actually be the nearest to accurate, but it's not quite because the files are not necessarily created by the activity). Oh I see, you are talking about the approach in your patch. That's still quite tricky though... Would you keep the current filtering behavior for journal? Would it apply to object chooser only? To certain object choosers only? Yes, the trickiest bit is how to display that in the UI. Non of the current filters does match this case here, using the activity icon would confront with what it currently means in the filter, as it means an object of that activity. Maybe this special objectchooser has just no filter sub-toolbar? And the message when no matching object could be found reads as No entry found that can be opened with Activity [Name of activity]. Simon Talked about it with Gonzalo, so: As we said, there are two options to filter for in regard to Activities: (a) filter for objects of type activity X (b) filter for bjects that can be opened with activity X In the Journal (a) is important, because (b) can be solved with using the options in the resume-with-Palette. With the object chooser we are interested in (b) when we have the case like Read Open a book for Reading or Jukebox Something to play (Music or video). I would leave the Journal case untouched and suggest to add another ObjectChooser for the described case. It would have no filter toolbar. I was thinking about making it inactive but that would suggest no filtering has been applied which is not correct here. Maybe where the filter is now there could be a explanation sub title like: Filtered for objects that can be opened with this activity. or Filtered for objects that can be opened with [Activity Name]. Technically I would add another parameter to the ObjectChooser, defaulting to None to make it backwards compatible. The name could be suited_filter. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
On 06/13/2013 01:32 AM, Manuel Quiñones wrote: 2013/6/7 Daniel Narvaez dwnarv...@gmail.com: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. I'm far from expert on licenses, but given Daniel Narvaez description, I vote for Apache too. -- .. manuq .. Mozilla for gaia seems to be going for the Apache 2 license [1]. Here are two posts with some background information about the licensing [2][3]. I could not find any information about what is the license that can/should be used in the web apps developed for Firefox OS. The example apps have different ones, some none, the documentation does not talk about it. Regards, Simon [1] https://github.com/mozilla-b2g/gaia/commit/73fd5736a13dc05f3e47246bbae9810f2f5aaec5 [2] http://blog.gerv.net/2013/01/mozilla-and-non-copyleft-licensing/ [3] https://mail.mozilla.org/pipermail/rust-dev/2012-November/002664.html [4] https://marketplace.firefox.com/developers/docs/reference_apps ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Licensing of the javascript libraries
On 06/13/2013 11:29 AM, Daniel Narvaez wrote: On 13 June 2013 11:26, Simon Schampijer si...@schampijer.de wrote: On 06/13/2013 01:32 AM, Manuel Quiñones wrote: 2013/6/7 Daniel Narvaez dwnarv...@gmail.com: I'm still undecided really but since it's important to make a call soon, my vote goes for Apache, both for sugar-web and for activities we develop. I'm far from expert on licenses, but given Daniel Narvaez description, I vote for Apache too. -- .. manuq .. Mozilla for gaia seems to be going for the Apache 2 license [1]. Here are two posts with some background information about the licensing [2][3]. I could not find any information about what is the license that can/should be used in the web apps developed for Firefox OS. The example apps have different ones, some none, the documentation does not talk about it. I guess that's left to the activity authors to decide. In our case, if we make our libraries licensed under Apache 2 an activity author could use Apache 2 or GPL3 for his activity but not GPL2, correct? Here another interesting summary of the pros and cons of licensing Android under ASL2 [1]. Simon [1] http://arstechnica.com/uncategorized/2007/11/why-google-chose-the-apache-software-license-over-gplv2/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities and i10n
On 06/06/2013 01:17 AM, Daniel Narvaez wrote: Hello, I setup a fork of webL10n. I amdified it and replaced API with the gaia one minus the b2g specific stuff. https://github.com/sugarlabs/webL10n I do not see any changes from you there, why do we need the for again? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities and i10n
On 06/06/2013 11:34 AM, Daniel Narvaez wrote: On Thursday, 6 June 2013, Simon Schampijer wrote: On 06/06/2013 01:17 AM, Daniel Narvaez wrote: Hello, I setup a fork of webL10n. I amdified it and replaced API with the gaia one minus the b2g specific stuff. https://github.com/sugarlabs/**webL10nhttps://github.com/sugarlabs/webL10n I do not see any changes from you there, why do we need the for again? They are on the sugar-web branch. You mean why we need the changes? Couple of reasons, to make it work well with requirejs and to get a better public API (the same gaia is using). This code is sort of thought to be forked, mozilla are forking it themself despite being the upstream in practice. Oh, ok - did not see the branch. Thanks, gets clearer now. /me has not seen as many forks and copy-pastes as in the last weeks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activities and i10n
On 06/06/2013 11:38 AM, Daniel Narvaez wrote: I'm not sure they really need to be on a branch btw. I've doing that to keep master the same of upstream. But maybe fetching the upstream repo on another remote gives everything you need. Yes, maybe using the master branch for the changes is a bit more clear, and then pull upstream into a separate branch. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk3 sugar on Android
On 06/03/2013 01:15 PM, Daniel Narvaez wrote: Hi, It seems like things are coming together pretty nicely for a port of gtk3 sugar on Android. * libhybris is making progress http://mer-project.blogspot.fi/2013/05/wayland-utilizing-android-gpu-drivers.html * Gtk3 has been ported to wayland. There is still work left to do for the wayland backend [1][2]. I gave it a quick try under F19 and the bits Matthias talks about (decorations) did not land yet. Sounds like quite bleeding edge still. * WebkitGtk have almost been ported to wayland. https://bugs.webkit.org/show_bug.cgi?id=81456 The only missing part seems to be porting the Sugar window management bits to wayland. Then it should be possible to build Sugar in a linux arm chroot and run it with accelerated graphics on Android [3][4]. As discussed on irc, one of the downsides is that you can not integrate with the native Android apps that way. As well using intents would not be possible that way [5]. Regards, Simon [1] http://blogs.gnome.org/mclasen/2013/03/26/adventures-in-wayland/ [2] https://live.gnome.org/Wayland/GTK+ [3] https://github.com/libhybris/libhybris [4] https://www.yoctoproject.org/ [5] https://developer.android.com/guide/topics/media/camera.html#intents ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hacking web activities on Windows/OS X
Am 02.06.2013 um 23:52 schrieb Daniel Narvaez dwnarv...@gmail.com: Hello, it seems like we could increase a lot the number of potential contributors by making it easy to hack on web activities and libraries on Windows and OS X. Not many people are running Linux and installing it is not the easiest task. I think this would involve 1 Document how to install volo and I suppose some kind of shell on Windows. 2 Document how to install volo on OS X. Someone with any of those systems should report back about how to install it. First you need to install nodejs and then volojs. https://github.com/volojs/test-gh-app 3 Make sure sugar-web works in Firefox and/or Chrome. That would be straight foward to do. Simon It shouldn't be much work and it seems like it could benefit the effort a lot. Thoughts? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Broken build, terminal
On 05/31/2013 09:39 AM, Daniel Narvaez wrote: Hello, the build is still broken because of this issue. Can we please fix or revert asap? Build bugs should be fixed with the highest priority because they affects everyone, not just your activity. Pushed a tmp-workaround to get the build going: https://git.sugarlabs.org/terminal/mainline/commit/951ebb574bff05b37810b4bfd779a57e8f29f230 However, we still see a segfault on F18 when the activity is closing [1]. The fix needs latest vte. Also it needs gobject-introspection .1.36 and pygobject3 3.8.1 to work, those are in Fedora 19 already. Simon [1] http://fpaste.org/15739/13699988/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Renaming HTML --- Web
Hi, we an informal discussion we agreed on calling the activities that are coded in a browser-supported programming language (such as JavaScript, combined with a browser-rendered markup language like HTML) and reliant on a common web browser to render the application executable [1]: Web activities. This is in line with the term used for web applications. The following repositories have been deprecated and are only available in Daniel's user space: sugar-html-test sugar-html-template sugar-html-activity sugar-html-bus sugar-html-datastore The latter three have been merged into: sugar-web sugar-html-test is now called sugar-web-test and sugar-html-template has been renamed to sugar-web-template. The repositories sugar-build and sugar-toolkit-gtk3 have been changed accordingly. Same as the documentation at [2]. If you update your sugar-build, the directories *html* won't be deleted automatically, you will have to delete them by hand, sorry for the inconvenience. Writing a web activity has never been that easy, please follow the instructions at [3]. In order for us to shape the web activity API in this development cycle we encourage activity authors to start writing web activities now. The API will still see changes, the environment will see changes and yes there will be bumps here and there but you will benefit from this 'at the edge' experience and help us to get to a great result we all will enjoy in the end. Thanks in advance for your participation. Regards, Simon [1] https://en.wikipedia.org/wiki/Web_application [2] http://developer.sugarlabs.org/ [3] http://developer.sugarlabs.org/activity.md.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to deploy the webactivity libraries
On 05/29/2013 08:17 PM, Daniel Narvaez wrote: Since I'm the one proposing the implementation, and I'm actually not too keen about the idea itself, let me take a step back before I get blamed for it forever :) My feeling is that we should *not* implement this for 0.100 but rather consider (very carefully) if it's something we need in one of the next iterations. Cutting on philosophical considerations, I think we are not going to be able to provide anything like a stable API for 0.100, for several reasons including * We are all too new to this game. * The time is short and we are not seeing activities being developed yet. * The web platform is a moving target. * I have the feeling stable API on html+css+js might be harder than on traditional interfaces. Without a stable API, system libraries are just going to cause more issues then benefits, with activities randomly breaking because the library is too new or too old. So you mean for now, we should just add a copy of sugar-web library into each activity bundle. And then in the next step deal with the packaging of sugar-web as a dependency? On the packaging end this means that for the next release the packaging of the core will not change at all (sugar, sugar-toolkit-gtk3...). Only the webactivities need to be packaged and those contain sugar-web. I think this would be a good compromise for now, given that things are in flux. And in the html+css+js world things seem to change fast, let's see which package management will survive the next months [1]. Maybe volo is gone by then. About activity development: we should shape the API while we develop activities. I am starting with that process now. The more people doing that the better, as now we can change API quickly. Of course for a developer this means a rather flux environment. Regards, Simon [1] https://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-package-management/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Broken build, terminal
On 05/30/2013 11:14 AM, Daniel Narvaez wrote: Traceback (most recent call last): File /home/buildbot/slave/raring-amd64-quick/build/build/out/install/lib/python2.7/site-packages/sugar3/activity/activity.py, line 906, in _prepare_close self.save() File /home/buildbot/slave/raring-amd64-quick/build/build/out/install/lib/python2.7/site-packages/sugar3/activity/activity.py, line 740, in save self.write_file(file_path) File /home/buildbot/slave/raring-amd64-quick/build/build/out/install/share/sugar/activities/Terminal.activity/terminal.py, line 424, in write_file text, attr = page.vt.get_text(is_selected, None) AttributeError: 'Terminal' object has no attribute 'get_text' Caused by commit b90dac1ad2b8916b123e71b73848636f83fa9fe7 Author: Simon Schampijer si...@laptop.org Date: Sat Nov 3 15:17:09 2012 +0100 Get back a working activity history, SL #4131 It breaks on Debian and Ubuntu, it works on Fedora 18 and 19. I guess it's either a Fedora patch or a more recent libvte required? I'd prefer to change the code to work also with old/unpatched libvte then to add a new module to the build for Ubuntu and Debian. http://bugs.sugarlabs.org/ticket/4131 should point to the upstream fix. And state which upstream has the fix. Which version etc. Gonzalo, can you put some light on it. The upstream ticket was [1]. Simon [1] https://bugzilla.gnome.org/show_bug.cgi?id=676999 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.98.7
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.98.7.tar.bz2 == News == * Release 0.98.7 (Simon Schampijer) * Add a binding for gconf_client_set_list (using strings) (Daniel Narvaez) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Broken build, terminal
On 05/30/2013 12:00 PM, Daniel Narvaez wrote: The upstream bug seems to have no activity? https://bugzilla.gnome.org/show_bug.cgi?id=690610 Right, that is why I have no clue what fix Gonzalo means. Anyhow, he will let us know. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] How to deploy the webactivity libraries
Hi, we talked yesterday on irc about how to handle the deployment of the webactivity libraries like sugar-html-graphics. We came up with three basic ways of dealing with it. It follows a summary. Please comment, fill in the missing items. It is an interesting item that needs discussion and research before we decide on using one or the other. Thanks, Simon ===Include a copy of the library in each webactivity=== Each activity carries a copy of the libraries it uses. For example sugar-html-activity and sugar-html-graphics. This has the advantage that the activities are self contained. The downside is that for a change in the library each activity has to be updated. This is the current common model for webapps. With nodejs for example every library you install uses its own dependencies so that it can use specific versions and not have to deal with API breaks etc. If webapp X, needs a fix that is only available in sugar-html-graphics 1.5 it can pull in that dependency and run on the same system as webapp Y with sugar-html-graphics 1.3. An interesting case is when a library fix is made how to deploy that for 20 webactivities. This could be made independent of the maintainers duty. If a downstream wants to deploy webapp X when aggregating the webapps could pull in their latest dependencies (unless a specific version is specified). ===Import from a web url and pre caching=== This requires a permission system. This has general security concerns. ===load the library from the filesystem=== The activity loads the library from the filesystem something like: /usr/share/sugar/sugar-html-activity/activity.js The advantage here is that you only have to modify one place when a change to the library is made and all the activities get it directly. There might be security concerns here as well. In webOS the framework is available from the system Unlike most JavaScript frameworks, you won't need to include the Mojo framework with your application code since Palm includes the framework in every webOS device. [1]. [1] webOS framework: https://developer.palm.com/content/resources/develop/overview_of_webos/overview_of_webos_software_developer_kit.html#c20332 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to deploy the webactivity libraries
Hi Daniel, thanks for the feedback, a few questions about your proposal: On 05/29/2013 01:30 PM, Daniel Narvaez wrote: Hi Simon, nice summary. I just got an idea... Our installed activities are served over a custom activity:// protocol, HTMLActivity is doing the mapping between the path in the url and the path on disk. Yes: https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/activity/htmlactivity.py#L46 If we include the volo package.json in the activity bundle we can map library paths to somewhere in the system for unversioned dependencies. Don't we include it already in the activity bundle? https://github.com/sugarlabs/sugar-html-template/blob/master/package.json I looked at the volojs docs but couldn't figure out how exactly the version comes into play here. https://github.com/volojs/volo/wiki/Library-best-practices#wiki-volodependencies Is that part of the url, like in github:requirejs/domReady/2.0.1? Maybe that example can help: https://github.com/volojs/create-responsive-template/blob/master/package.json Can you elaborate on who would do the mapping? This should give the best of both worlds because the bundles would still be self contained, but at the same time we would able to use the latest available version of the library installed in the system. So a copy of the library is included into the activity bundle, and if no version is specified for that dependency it is checked if a newer library is installed in the system for usage. Thanks, Simon For hosted activities I think the right solution is loading from a web url, but we don't even have to worry about that case until we actually have a permission system in place. On 29 May 2013 12:29, Simon Schampijer si...@schampijer.de wrote: Hi, we talked yesterday on irc about how to handle the deployment of the webactivity libraries like sugar-html-graphics. We came up with three basic ways of dealing with it. It follows a summary. Please comment, fill in the missing items. It is an interesting item that needs discussion and research before we decide on using one or the other. Thanks, Simon ===Include a copy of the library in each webactivity=== Each activity carries a copy of the libraries it uses. For example sugar-html-activity and sugar-html-graphics. This has the advantage that the activities are self contained. The downside is that for a change in the library each activity has to be updated. This is the current common model for webapps. With nodejs for example every library you install uses its own dependencies so that it can use specific versions and not have to deal with API breaks etc. If webapp X, needs a fix that is only available in sugar-html-graphics 1.5 it can pull in that dependency and run on the same system as webapp Y with sugar-html-graphics 1.3. An interesting case is when a library fix is made how to deploy that for 20 webactivities. This could be made independent of the maintainers duty. If a downstream wants to deploy webapp X when aggregating the webapps could pull in their latest dependencies (unless a specific version is specified). ===Import from a web url and pre caching=== This requires a permission system. This has general security concerns. ===load the library from the filesystem=== The activity loads the library from the filesystem something like: /usr/share/sugar/sugar-html-**activity/activity.js The advantage here is that you only have to modify one place when a change to the library is made and all the activities get it directly. There might be security concerns here as well. In webOS the framework is available from the system Unlike most JavaScript frameworks, you won't need to include the Mojo framework with your application code since Palm includes the framework in every webOS device. [1]. [1] webOS framework: https://developer.palm.com/** content/resources/develop/**overview_of_webos/overview_of_** webos_software_developer_kit.**html#c20332https://developer.palm.com/content/resources/develop/overview_of_webos/overview_of_webos_software_developer_kit.html#c20332 __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Error doing ./osbuild build
On 05/28/2013 01:16 PM, Daniel Narvaez wrote: On Tuesday, 28 May 2013, Gonzalo Odiard wrote: [..] * Split the compilation, one part to compile sugar and another to compile sugar-web, sugar-web is more unstable, and have a lot of issues. This would add more maintenance, buildbot etc work that I personally don't have time to do. I welcome anyone to jump in and maintain a sugar-without-html build if it is considered necessary. IMO we decided that HTML activities was the main goal for the release and it would good if it was more of a collective effort, including testing and fixing the build. Right now is mostly just me and Manuel... Most other people seems to be annoyed by the build issues rather than trying to participate. If we wanted to have only a small part of the team work on it and the rest not being bothered by the changes, it would have been better to work on a branch until stuff was more stable. If we do not use mainline for such a big effort like html5 activities we won't be able to achieve our goals because only a few people will work on it as the others are not bothered. This has to be disruptive. I agree with Daniel that we should group around our goal. And that not only Daniel is responsible for keeping the build infrastructure/environment running. Maybe he has raised expectations high by maintaining it so well over the last months. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-build] Anyone running sugar-build on i386 distros?
On 05/24/2013 03:49 PM, Daniel Narvaez wrote: Hi, I'm wondering if anyone at all is using sugar-build on i386. I suppose everyone has x86_64 hardware these days but maybe people are still installing i386 distros, it's the Ubuntu default for example. It's just that maintaing i386 buildbot slaves is a bit of a waste if no one is using it. We should keep one slave to make sure stuff keep working there but... maybe we don't need one per distro. It is true that even myself switched these days to x86_64 for my development environment. Maybe just keep the Fedora one around, I expect the most users there, if. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-artwork-0.98.5
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.98.5.tar.bz2 == News == * Release 0.98.5 (Simon Schampijer) * Added function prototypes for theme_* to satisfy f19's gcc (William Orr) * Remove black background in Browse tab pages - SL #4469 (Manuel Quiñones) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.98.6
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.98.6.tar.bz2 == News == * Release 0.98.6 (Simon Schampijer) * Use gettext algorithm to determine locale for activity.linfo (Walter Bender) * Replaced deprecated GObject methods with GLib methods (William Orr) * Fixed crash in journal when mousing over activity icons (William Orr) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 5 of 40 messages translated (0 fuzzy). (Pootle daemon) * Palette: handle the case where setting the transient window does fail, SL #4221 (Simon Schampijer) * i18n get_locale_path: handle the case when the default locale is not set, SL #4450 (Simon Schampijer) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.98.8
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.98.8.tar.bz2 == News == * Release 0.98.8 (Simon Schampijer) * Update Sucrose version for 0.98.8 (Simon Schampijer) * use read_byte_async (Walter Bender) * Complete port to introspection; fix problem with language setting (Walter Bender) * Use the GLib.MAXINT32 instead of GObject.G_MAXINT32 (Simon Schampijer) * Commit from Sugar Labs: Translation System by user cjl.: 390 of 390 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 390 of 390 messages translated (0 fuzzy). (Pootle daemon) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build after osbuild change report
On 05/20/2013 07:43 PM, Simon Schampijer wrote: On 05/20/2013 05:52 PM, Daniel Narvaez wrote: On 20 May 2013 12:48, Daniel Narvaez dwnarv...@gmail.com wrote: Ok, great. Would be fantastic if '--help' would print the list of possible arguments. I'd like to avoid maintaining the docs in two places :) Though perhaps using docker we can figure out something to have both --help and the docs be generated from the same source. I have made it print out the list of commands only (no descriptions) for now, with a link to the docs. Thanks Daniel! [sugar-build sugar-build]$ ./osbuild --help Don't run osbuild inside a sugar-build shell, you can just run the commands directly. [sugar-build sugar-build]$ exit [erikos@t61 sugar-build]$ ./osbuild --help = Setup osbuild = * Create the python virtualenv * Install python packages = Available commands = shell run check-config docs clean check build bug-report check-system pull See also http://developer.sugarlabs.org/build.md.html [erikos@t61 sugar-build]$ Pulling today I got: [erikos@t61 sugar-build]$ ./osbuild pull = Updating build system = * Pulling sugar-build Already up-to-date. = Pulling = * Pulling automake * Pulling glib * Pulling gobject-introspection * Pulling pygobject * Pulling dbus-python * Pulling libsoup * Pulling webkitgtk Command failed, tail of /home/erikos/sugar-build/build/logs/pull-0.log Already up-to-date. From git://github.com/dnarvaez/webkitgtk 23a61f3..562e907 master - origin/master error: Your local changes to the following files would be overwritten by merge: GNUmakefile.in aclocal.m4 configure Please, commit your changes or stash them before you can merge. Aborting Updating 23a61f3..562e907 I did not have made any changes in webkitgtk, I did a git reset --hard origin in the webkitgtk directory and now things work. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-build] Is webkitgtk becoming a barrier?
On 05/19/2013 01:41 PM, Daniel Narvaez wrote: Hey, It seems like building webkitgtk is a bit of a pain for many people. I would like people feedback on how bad of an obstacle it really is and about a couple of possible solutions: 1 Have buildbot generate snapshots of the base system dependencies which most people are unlikely to want to modify anyway and upload those. It would probably be a system.img file which you would put in your sugar-build directory. With that file present, the external sugar dependencies would not be downloaded and built at all. 2 Officially support Fedora 19, disable the webkitgtk build there and suggest people for which building webkigtk is too much to use Fedora19. I would go for option (2). Fedora 19 is not that far away [1]. Option (1) sounds like a lot of continuous work for supporting and you start digging you a hole for a while... Regards, Simon [1] https://fedoraproject.org/wiki/Releases/19/Schedule ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On 05/18/2013 07:36 PM, Manuel Quiñones wrote: 2013/5/18 Daniel Narvaez dwnarv...@gmail.com: On 17 May 2013 15:13, Daniel Narvaez dwnarv...@gmail.com wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness Summarizing the positions expressed in the thread Simon would like 1. Marco would do 2 and then consider if we can move to 1. Manuel would like 2. Walter would be happy with 2, as long as there is guidance. Gonzalo and James doesn't seem happy about requiring tests at all. I suppose Simon and Manuel needs to talk and make a decision. These are the times when it's nice to have maintainers and not be one :P I have expressed my opinion favouring testing, so 2 or 1 would be fine for me. I would say, let's start with 2: Every feature patch, then we can move to 1 gradually. I would also like to express my view on contributions. We should not block any valuable contribution. Suppose that a child finds a bug, then modifies a file in the XO and then sends the modified file to us in a email with a brief description. Very welcome! I would say. For this kind of occasional contributions, we (regular contributors) should take over and do the procedure by ourselves, and also add the testing. Yes, that sounds very good to me. If this guy sends in another patch we can start to guide him through the review process. For a one-hit-patch-wonder we can keep things simple. Also as Walter pointed, indeed we need to provide guidance to the contributors. And the review process is good for that. -- .. manuq .. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Could someone please add me to the Sugarlabs organization on github.
On 05/19/2013 12:43 PM, Daniel Narvaez wrote: I tested it now. There was a couple of leftovers in sugar-html-activity and sugar-html-template. I pushed fixes for these. I went without a review for the sake of avoiding regressions. If anyone has comments I'm happy to fix them now, but they was really simple changes. https://github.com/sugarlabs/sugar-html-template/commit/0cbfd247a99a58ad53caf2fe67576781a89abe00 https://github.com/sugarlabs/sugar-html-activity/commit/fef4b7e8e42019ffc28f4463d8a047ddb4e0c69a Absolutely fine to me to do such a fixup by a core contributor. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Update docs
Hi, the docs have been updated for the 'osbuild'-change [1]. The documentation pointed to by our README [2] is not [3]. Do we have a new documentation url already? /me lost track Cheers, Simon [1] https://github.com/sugarlabs/sugar-docs/blob/master/build.md [2] http://sugarlabs.org/~buildbot/docs/build.html [3] http://sugarlabs.org/~buildbot/docs/build.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sugar-build after osbuild change report
Hi, I had a sugar-build repo before the osbuild change. I did a git pull in my sugar-build directory and then run ./osbuild help. I got the following: [erikos@t61 sugar-build]$ ./osbuild --help Installing virtualenv... Done. /home/erikos/sugar-build/build/out/sandbox/install/bin/python: can't open file '/home/erikos/sugar-build/build/commands/--help': [Errno 2] No such file or directory [erikos@t61 sugar-build]$ So I did: [erikos@t61 sugar-build]$ ./osbuild = Distribution information = Name: fedora Version: 18 GNOME version: 3.6 Lib directory: lib64 Supported: True All the required dependencies are installed. [erikos@t61 sugar-build]$ All the deps are there, let's pull: [sugar-build sugar-build]$ ./osbuild pull = Updating build system = * Pulling sugar-build Already up-to-date. = Pulling = * Pulling automake * Pulling glib [...] Now, the sources are directly pulled into the sugar-build directory, is that intentional? Reading the docs [1] it says to run a ./osbuild build, let's do then: [sugar-build sugar-build]$ ./osbuild build = Clean = * Emptying install directory * Cleaning automake * Cleaning glib * Cleaning gobject-introspection * Cleaning pygobject * Cleaning dbus-python * Cleaning libsoup * Cleaning webkitgtk * Cleaning gwebsockets * Cleaning node * Cleaning grunt-cli * Cleaning volo * Cleaning karma * Cleaning jshint * Cleaning docker * Cleaning json-format * Cleaning flake8 * Cleaning sugar-docs * Cleaning sugar-toolkit-gtk3 * Cleaning sugar * Cleaning sugar-artwork * Cleaning sugar-datastore * Cleaning gst-plugins-espeak * Cleaning sugar-runner * Cleaning sugar-html-datastore * Cleaning sugar-html-template * Cleaning sugar-html-bus * Cleaning sugar-html-activity * Cleaning sugar-html-graphics * Cleaning browse * Cleaning chat * Cleaning read * Cleaning log * Cleaning terminal * Cleaning pippy * Cleaning imageviewer * Cleaning jukebox * Deleting state = Pulling = * Pulling libsoup * Pulling webkitgtk * Pulling gwebsockets * Pulling node * Pulling grunt-cli * Pulling volo * Pulling karma * Pulling jshint * Pulling docker * Pulling json-format * Pulling flake8 * Pulling sugar-docs * Pulling sugar-toolkit-gtk3 * Pulling sugar Oh, no it cleans my copy of webkitgtk...? :/ Regards, Simon [1] https://github.com/sugarlabs/sugar-docs/blob/master/build.md ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Update docs
On 05/20/2013 10:40 AM, Daniel Narvaez wrote: I think the buildbot slave which uploads the docs hasn't yet had a successfull build since the doc was changed, so no updates yet. I'm on it, I should have probably made all these changes a bit more gradually. Great! Did the infra team handed out the new docs url already? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build after osbuild change report
On 05/20/2013 10:48 AM, Daniel Narvaez wrote: On 20 May 2013 10:12, Simon Schampijer si...@schampijer.de wrote: Hi, I had a sugar-build repo before the osbuild change. I did a git pull in my sugar-build directory and then run ./osbuild help. I got the following: [erikos@t61 sugar-build]$ ./osbuild --help Installing virtualenv... Done. How about we print here something like: You are in a shell now, run commands like 'build' or 'run' here directly. /home/erikos/sugar-build/**build/out/sandbox/install/bin/**python: can't open file '/home/erikos/sugar-build/**build/commands/--help': [Errno 2] No such file or directory [erikos@t61 sugar-build]$ Looks like a bug, will fix. Ok, great. Would be fantastic if '--help' would print the list of possible arguments. [sugar-build sugar-build]$ ./osbuild pull Note that you are inside a shell here. You should just pull. (I wonder if the docs are wrong now). That *might* actually break things so we should probably check and refuse to run osbuild inside a shell. Now, the sources are directly pulled into the sugar-build directory, is that intentional? Yes, I think the flatter directory structure makes it a little bit easier to hack on stuff. Hmm, I liked the layout with the sources directory. Now the sources are mixed with the 'build' directory. Do you build now in the source directories? Reading the docs [1] it says to run a ./osbuild build, let's do then: [sugar-build sugar-build]$ ./osbuild build = Clean = * Emptying install directory * Cleaning automake * Cleaning glib * Cleaning gobject-introspection * Cleaning pygobject * Cleaning dbus-python * Cleaning libsoup * Cleaning webkitgtk * Cleaning gwebsockets * Cleaning node * Cleaning grunt-cli * Cleaning volo * Cleaning karma * Cleaning jshint * Cleaning docker * Cleaning json-format * Cleaning flake8 * Cleaning sugar-docs * Cleaning sugar-toolkit-gtk3 * Cleaning sugar * Cleaning sugar-artwork * Cleaning sugar-datastore * Cleaning gst-plugins-espeak * Cleaning sugar-runner * Cleaning sugar-html-datastore * Cleaning sugar-html-template * Cleaning sugar-html-bus * Cleaning sugar-html-activity * Cleaning sugar-html-graphics * Cleaning browse * Cleaning chat * Cleaning read * Cleaning log * Cleaning terminal * Cleaning pippy * Cleaning imageviewer * Cleaning jukebox * Deleting state = Pulling = * Pulling libsoup * Pulling webkitgtk * Pulling gwebsockets * Pulling node * Pulling grunt-cli * Pulling volo * Pulling karma * Pulling jshint * Pulling docker * Pulling json-format * Pulling flake8 * Pulling sugar-docs * Pulling sugar-toolkit-gtk3 * Pulling sugar Oh, no it cleans my copy of webkitgtk...? :/ If you pulled latest sugar-build you will have to rebuild webkitgtk anyway I'm afraid, because of the various changes I made. I've seen it doing a clean before a build. I need to find a way to reproduce. I have the impression it only happens if the build is actually clean already though (which might have been your case because the build directory has been moved in recent sugar-build), so at least it shouldn't hurt for real. Ok, rebuilding from scratch now. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Update docs
On 05/20/2013 12:13 PM, Daniel Narvaez wrote: On 20 May 2013 12:07, Simon Schampijer si...@schampijer.de wrote: On 05/20/2013 10:40 AM, Daniel Narvaez wrote: I think the buildbot slave which uploads the docs hasn't yet had a successfull build since the doc was changed, so no updates yet. I'm on it, I should have probably made all these changes a bit more gradually. Great! Did the infra team handed out the new docs url already? Nope :/ Hey Bernie, did you get to reserve us the sugar-doc url already? Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-build after osbuild change report
On 05/20/2013 05:52 PM, Daniel Narvaez wrote: On 20 May 2013 12:48, Daniel Narvaez dwnarv...@gmail.com wrote: Ok, great. Would be fantastic if '--help' would print the list of possible arguments. I'd like to avoid maintaining the docs in two places :) Though perhaps using docker we can figure out something to have both --help and the docs be generated from the same source. I have made it print out the list of commands only (no descriptions) for now, with a link to the docs. Thanks Daniel! [sugar-build sugar-build]$ ./osbuild --help Don't run osbuild inside a sugar-build shell, you can just run the commands directly. [sugar-build sugar-build]$ exit [erikos@t61 sugar-build]$ ./osbuild --help = Setup osbuild = * Create the python virtualenv * Install python packages = Available commands = shell run check-config docs clean check build bug-report check-system pull See also http://developer.sugarlabs.org/build.md.html [erikos@t61 sugar-build]$ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
Am 11.05.2013 um 16:45 schrieb Daniel Drake d...@laptop.org: On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez dwnarv...@gmail.com wrote: https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel I wanted to give it a try to see how it works at least, going through the process with this ticket. I am not opposed to stay with trac though. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Git history with merges from git hub
Hi, with the merges from Github we do get a non ideal git history. The merge pull requests do only add value as they show who did authorize the merge. But they can be in another order to the actual commit. One way to handle this would be to do a git rebase before pushing and avoid the merge messages. Thoughts? Simon [1] https://github.com/sugarlabs/sugar/commits/master ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2013-05-08
On 05/08/2013 03:02 PM, Walter Bender wrote: == Sugar Digest == 1. Sugar Labs has been given 8 slots for student interns for Google Summer of Code [1]. This means we'll be able to cover a lot ground this summer: we have some very strong proposals and a great mentoring team. The next step is for the mentors and the sugar-devel team to narrow the applicants down to a short list. Many thanks to everyone who has lent a hand so far and to Google for giving us this opportunity. 2. The sugar-devel team has been really busy pushing new features for the next release and doing a general clean up of the code base. It is remarkable the current pace of activity, especially around the efforts to make HTML5/Javascript a first-class approach to Sugar activity development. You can follow the work on the devel list [2] or by reviewing (and submitting) patches on github [3]. 3. I've been trying to contribute to the overall Sugar effort, but I tend to get distracted by Turtle Blocks (AKA Turtle Art). When I was visiting RIT a few weeks back, I was inspired to enhance the debugging features Turtle Blocks. I came up with a simple way to introduce the concept of break-points to the code. I had already introduced blocks to hide and show the program as it executes. And through the rabbit and snail buttons, the user can control the speed of program execution. What I did was to combine these two concepts. By introducing a hide block into your code, the code executes at full speed. Introducing a show block causes the program to run slowly and display the status of all of its variables as it runs. A subtle change, but what it allows one to do is to surround code you want to debug with a show and hide blocks. Small blocks of code can be examined while the larger program runs at full speed. Really helpful for debugging complex projects. 4. I am also working on another new feature, this one at the request of the teachers who have been using Butia in Uruguay. The idea is to be able to save a stack of blocks for reuse in multiple projects (instances). The way to do that currently is to open a project, copy the stack to the clipboard, and then paste it into a new project -- too clumsy to be used on a regular basis. The new feature allows users to save a stack to a custom palette. This palette is loaded with each instance of Turtle, so it means the stacks are available as if they were extensions of Turtle itself. It makes it even easier for end-user customization. === In the community === 5. We'll be celebrating International Turtle Art Day (Día Mundial de TortugArte) in October. Our objectives are to: * Promote the use of Turtle Art * Share and promote best practices * Celebrate projects for children and teachers Details on how you can participate will be made available soon. 6. How embarrassing [4]. === Tech Talk === 7. Laura Vargas reports that Hexoquinasa v0.9 (BETA2) has been released [5] and is in the hands of the Ministry of Education of Perú, where it will undergo testing. 8. Daniel Narveaz reports that the initial bits of the HTML activities work has landed. It should now be relatively easy to start writing an activity. (1) You'll need the latest Sugar development environment [6]. (2) Then open a shell and move to the source directory: make shell cd source (3) Create an activity based on a template volo create my-activity ./sugar-html-template (4) Install the activity for development as usual cd my-activity python setup.py dev (5) To interact with the platform you will need to add the sugar-core-html library to your activity volo add -f ./sugar-html-core I guess that should be: volo add -f ../sugar-html-core/ from with in the my-activity directory. Once you have the activity running you can then use Ctrl+Shift+i to inspect the code [1]. Great work everyone, Simon [1] http://lists.sugarlabs.org/archive/sugar-devel/2013-May/042881.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] discussion about dropping the emulator from the sugar package...
Thanks Daniel for the writeup. On 05/06/2013 12:35 PM, Daniel Narvaez wrote: On 6 May 2013 11:47, Simon Schampijer si...@schampijer.de wrote: Yes sugar-runner should just work in fedora as a replacement of sugar-emulator. It only needs to be packaged. Why isn't it included in the sugar package, what is the advantages of it and why the hell isn't it being discussed on the devel@ list? (Adding sugar-devel to cc) It has been discussed on the list before. [1] [PATCH sugar] Drop sugar-emulator In short the advantages are that it's more solid, better maintained and tested (people are actually using it for development) and it works also from a text console, without another X11 instance running. It's split to a separate module because 1 Historic reason. It has been developed in sugar-build, in parallel with sugar-emulator which was at the time used by sugar-jhbuild. 2 I think it just makes a lot of sense code modularization wise. It's something built on the top of the normal sugar scripts and the two should not be mixed (as we have been unfortunately doing with sugar-emulator). The separate module makes the line harder to cross. For what it's worth I'm not completely opposed about folding sugar-runner back into sugar (I suppose it would make packager lives a bit easier). But I'm not going to do that work. The reasoning for that change are all ok. I am wondering the following: who is using 'sugar-emulator' at the moment on Fedora (or possibly other distributions)? I think a developer can use 'sugar-build' fine those days for his needs. It is well supported and solid, and the dependencies you need to install are the same, just that the sugar repos are built on the machine. For a developer this setup makes sense imho. The other use case is someone who wants to try out Sugar under GNOME. For him having to install the sugar packages including the emulator and then having a nice icon to start it from is a great thing to have. He does not have to log into Sugar from his session manager. If we think the latter is a use case we want to support, we should package sugar-runner. I would do it in a separate package for the reasoning Daniel described in his initial mail [1]: A separate module make sense here because most users will never run this code. It's largely a collection of hacks which are not necessary when running as a normal desktop environment. Regards, Simon [1] http://lists.sugarlabs.org/archive/sugar-devel/2013-January/041398.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH TamTam 1/2 v2] Output to ALSA directly from csound
On 05/03/2013 02:42 PM, Gonzalo Odiard wrote: Hi Daniel, Already released MusicKeyboard with this change, and waiting confirmation to release TamTam activities. Gonzalo Is that in version 7? I still hear cracking sounds when using the keyboard. Or maybe those are other cracking sounds then the ones talked about in this thread. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] discussion about dropping the emulator from the sugar package...
On 05/07/2013 12:44 PM, Daniel Narvaez wrote: On 7 May 2013 10:01, Peter Robinson pbrobin...@gmail.com wrote: Advantages of having it together is that as the sugar release changes the changes are made to sugar the changes to sugar-runner are in lock step so you should never get into a situation where either shouldn't work together. It makes it easier from a test/QA that the releases are together and you don't get into situations where you need to deal with a this version works with, doesn't work with releases. The two modules are very decoupled. I think it's unlikely you will get mismatches (although it could still happen of course). In practice, unless something changes, it's much more likely that you will get a sugar-emulator not working with the sugar in the same tarball, because no one have tested it before releasing. For what it's worth I'm not completely opposed about folding sugar-runner back into sugar (I suppose it would make packager lives a bit easier). But I'm not going to do that work. I don't have time to maintain another package either and from a packager point of view it adds quite a bit more work especially on the QA side of things. I'm also still completely unaware of what dependencies are needed to run it over the old one. The dependencies should be the same as sugar-emulator. As I said in my answer to Simon, I see sugar-runner a bit as an optional module. imo if yo don't have time to maintain it, it's fine to omit. Ok, sounds good to just omit it then, for me at least. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] discussion about dropping the emulator from the sugar package...
On 05/07/2013 01:05 PM, Gonzalo Odiard wrote: I think is important Fedora (and other distros) have a option to run sugar in a window in Gnome. If not, is more difficult develop activities. Gonzalo I think a developer is off well in just use sugar-build for that purpose. At least as long as we do not build webkitgtk in sugar-build regularly :) Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Journal share activity
On 05/03/2013 02:26 PM, Gonzalo Odiard wrote: On Thu, May 2, 2013 at 12:50 PM, Simon Schampijer si...@schampijer.dewrote: Hi, Manuel and myself have been looking at the work-flow for the Journal share activity these days: http://activities.sugarlabs.** org//en-US/sugar/addon/4656http://activities.sugarlabs.org//en-US/sugar/addon/4656 We discussed the design completely independent of possible technical constraints we will see what we can do, and what we can not but we wanted to first look at the work flow itself. Here is the state of things so far: ===Use cases=== (a) a teacher is handing out a pdf to the class (b) a teacher wants to collect a picture (Paint) or an assignment from each pupil (c) a group of pupils want to share files between each other (e.g. a project work) ===Questions=== * What can you share? You can share Journal items. Walter pointed to two other request from teachers: * share one activity. * share favorite activities configuration. While the teacher can share a .xo bundle to share the activity, if is already installed, we can run setup.py, and create the bundle if needed. Can be a future improvement. * To whom can you share? People in your current network (see other activities you share) * Can everyone share who is a member of that session? The case where a teacher wants to collect data from the pupils (b), does impose privacy concerns. There should be the possibility to send a file to one person only without making it public to all of the members. Good point * Is it a push or a pull model? (a) and (b) should be based on a push model. The receiver should be asked for confirmation of this transfer (see the current file transfers in the Sugar shell). Both sides need to know about the status of the transfer. (c) would be handled best with a pull model (see a download). Like in Browse or Record, the item to download should be updated automatically, when the user select it, is downloaded. ===Designs=== We basically started off with a UI based on tabs [1]. Each member of the session has a tab, the label contains the colored XO icon and the nick name of the learner. The first tab represents yourself. The header of each tab has information about the learner and if it is yours a button to share items with all the members. The body has the items you shared and each item a button to un-share an item. The other tabs list the items the learner shared and a button to download an item. This UI shows the pull model and handles case (c) well. It does not work for the case (b) that well, as a shared item is public to all of the members. Furthermore, a teacher would need to go to each tab in order to collect the data it needs. Based on the downsides of the first UI [1] we came up with the second UI [2]: On the left you see all the members that are present in the shared session (similar to the UI in Memorize). There is a button for each member to send him a file directly (handles case b). This list is scrollable. There could be as well a row at the bottom of the list for a 'sent to all' option to handle case (a). I like the second UI more too. On the right side at the top is the list of items you shared publically. There is a button to add new items. The list is scrollable. There is a button to un-share your items and a button to download items shared by others. This is case (c), case (a) could be handled with this model as well. Case (a) need information about who downloaded the object. Below is a widget that shows the incoming items. You can accept those incoming files individually or have a button for accept all. There should be a way to select the storage target (Journal/USB/...) either with a Palette or a dialog. This is case (b). In the second sketch in [2] you can see a feedback widget for the items you sent (one-to-one transfers). It shows if an item has been received and you can cancel a transfer (see the file transfers protocol in the Sugar shell for this). I am not sure about this part. This division between the shared items, and the incoming and sent items will show duplicates. I think we can do a single list, with information about: * Who shared it. * If you shared it, who downloaded it, if not, show a button to download it. Gonzalo I think there are two fundamental differences: - one-to-many: you share an item publically to all of the members of the session, the ones that are available should be visible in one list, in the mockup at the top left, everyone can download any of those items, the download will go into the device you specify, there should probably be an indicator if you want to store an already downloaded item into the same place (like with any generic download) - one-to-one-outgoing: you send one item to a specific person, here you need some feedback if the receiver acknowledged the incoming transfer - one-to-one-incoming: you receive a file sent by one specific person, here you need an alert for the request
Re: [Sugar-devel] [DESIGN] Journal share activity
On 05/03/2013 03:54 PM, Gonzalo Odiard wrote: I think there are two fundamental differences: - one-to-many: you share an item publically to all of the members of the session, the ones that are available should be visible in one list, in the mockup at the top left, everyone can download any of those items, the download will go into the device you specify, there should probably be an indicator if you want to store an already downloaded item into the same place (like with any generic download) - one-to-one-outgoing: you send one item to a specific person, here you need some feedback if the receiver acknowledged the incoming transfer - one-to-one-incoming: you receive a file sent by one specific person, here you need an alert for the request, that you can acknowledge I do not see any duplicates here. You can argue that the one-to-one transfers should be in one list with clear indicators what is an incoming and what is an outgoing transfer, that could work I think this is a tool to one-to-many principally (with the particular case of many-to-one defined as(b)). I am confident than in a constructivist environment, the request of privacy of kid-to-teacher should no be the most common case, because all can learn from other kids too. I don't think constructivism [1] says anything about one-to-one connections being an invalid tool to deliver the pedagogical message. In any case, just because Sugar is a great environment to teach constructivist concepts with, it does not mean we should limit it to that. I believe in diversity, as well for teaching methods. We already have a one-to-one tool in the Journal. Good point. We actually came across this as well. For the teacher collects an assignment case the file transfer in the Journal does not work that well, because a teacher does need to acknowledge all the incoming transfers and they do not stock nicely in the frame if you consider 30 coming in. Actually, we talked about how to put all the incoming ones into one Palette some time back with Gary, that could still be done. However, it still might make sense to support that use case in the Journal share activity, to have it all in one place. Regards, Simon [1] https://en.wikipedia.org/wiki/Constructivism_%28learning_theory%29 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Journal share activity
Hi, Manuel and myself have been looking at the work-flow for the Journal share activity these days: http://activities.sugarlabs.org//en-US/sugar/addon/4656 We discussed the design completely independent of possible technical constraints we will see what we can do, and what we can not but we wanted to first look at the work flow itself. Here is the state of things so far: ===Use cases=== (a) a teacher is handing out a pdf to the class (b) a teacher wants to collect a picture (Paint) or an assignment from each pupil (c) a group of pupils want to share files between each other (e.g. a project work) ===Questions=== * What can you share? You can share Journal items. * To whom can you share? People in your current network (see other activities you share) * Can everyone share who is a member of that session? The case where a teacher wants to collect data from the pupils (b), does impose privacy concerns. There should be the possibility to send a file to one person only without making it public to all of the members. * Is it a push or a pull model? (a) and (b) should be based on a push model. The receiver should be asked for confirmation of this transfer (see the current file transfers in the Sugar shell). Both sides need to know about the status of the transfer. (c) would be handled best with a pull model (see a download). ===Designs=== We basically started off with a UI based on tabs [1]. Each member of the session has a tab, the label contains the colored XO icon and the nick name of the learner. The first tab represents yourself. The header of each tab has information about the learner and if it is yours a button to share items with all the members. The body has the items you shared and each item a button to un-share an item. The other tabs list the items the learner shared and a button to download an item. This UI shows the pull model and handles case (c) well. It does not work for the case (b) that well, as a shared item is public to all of the members. Furthermore, a teacher would need to go to each tab in order to collect the data it needs. Based on the downsides of the first UI [1] we came up with the second UI [2]: On the left you see all the members that are present in the shared session (similar to the UI in Memorize). There is a button for each member to send him a file directly (handles case b). This list is scrollable. There could be as well a row at the bottom of the list for a 'sent to all' option to handle case (a). On the right side at the top is the list of items you shared publically. There is a button to add new items. The list is scrollable. There is a button to un-share your items and a button to download items shared by others. This is case (c), case (a) could be handled with this model as well. Below is a widget that shows the incoming items. You can accept those incoming files individually or have a button for accept all. There should be a way to select the storage target (Journal/USB/...) either with a Palette or a dialog. This is case (b). In the second sketch in [2] you can see a feedback widget for the items you sent (one-to-one transfers). It shows if an item has been received and you can cancel a transfer (see the file transfers protocol in the Sugar shell for this). Regards, Simon [1] http://dev.laptop.org/~erikos/share/tabs.JPG [2] http://dev.laptop.org/~erikos/share/one.jpg ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python - js IPC
On 04/25/2013 11:59 PM, Daniel Narvaez wrote: Hello, I wrote a quick prototype for a possible python - js IPC. sugar-toolkit-gtk3 patch https://github.com/dnarvaez/sugar-toolkit-gtk3/commit/5ba4e19732b4eec688dd73be8408c0d8e6a91299 hello-world patch https://github.com/dnarvaez/hello-world/commit/d102639bd43a99904d431210028a1ede66237427 You need the latest sugar-build if you want to give it a try. You will need to get twisted and autobahn, on Fedora this means: # yum install python-twisted # easy_install autobahn Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] G_MIN/MAX constants have been moved into GObject overrides
From: Simon Schampijer si...@laptop.org
See pygobject c2aa6f0d0ed4c4e60f081b106dc7a65513963fce
---
extensions/deviceicon/battery.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/extensions/deviceicon/battery.py b/extensions/deviceicon/battery.py
index 21dc5f3..6bf27ef 100644
--- a/extensions/deviceicon/battery.py
+++ b/extensions/deviceicon/battery.py
@@ -177,7 +177,7 @@ class BatteryPalette(Palette):
class DeviceModel(GObject.GObject):
__gproperties__ = {
'level': (int, None, None, 0, 100, 0, GObject.PARAM_READABLE),
-'time-remaining': (int, None, None, 0, GObject.constants.G_MAXINT32, 0,
+'time-remaining': (int, None, None, 0, GObject.G_MAXINT32, 0,
GObject.PARAM_READABLE), # unit: seconds
'charging': (bool, None, None, False, GObject.PARAM_READABLE),
'discharging': (bool, None, None, False, GObject.PARAM_READABLE),
--
1.8.1.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] G_MIN/MAX constants have been moved into GObject overrides
The patch works with the latest Pygobject 3.8.x but as well in the 3.4.x
series.
Actually, using GLib.MAXINT32 would work as well. I will ask on #python
what the correct/better one is.
Regards,
Simon
On 04/25/2013 12:45 PM, Simon Schampijer wrote:
From: Simon Schampijer si...@laptop.org
See pygobject c2aa6f0d0ed4c4e60f081b106dc7a65513963fce
---
extensions/deviceicon/battery.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/extensions/deviceicon/battery.py b/extensions/deviceicon/battery.py
index 21dc5f3..6bf27ef 100644
--- a/extensions/deviceicon/battery.py
+++ b/extensions/deviceicon/battery.py
@@ -177,7 +177,7 @@ class BatteryPalette(Palette):
class DeviceModel(GObject.GObject):
__gproperties__ = {
'level': (int, None, None, 0, 100, 0, GObject.PARAM_READABLE),
-'time-remaining': (int, None, None, 0, GObject.constants.G_MAXINT32, 0,
+'time-remaining': (int, None, None, 0, GObject.G_MAXINT32, 0,
GObject.PARAM_READABLE), # unit: seconds
'charging': (bool, None, None, False, GObject.PARAM_READABLE),
'discharging': (bool, None, None, False, GObject.PARAM_READABLE),
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] G_MIN/MAX constants have been moved into GObject overrides
On 04/25/2013 12:53 PM, Simon Schampijer wrote:
The patch works with the latest Pygobject 3.8.x but as well in the 3.4.x
series.
Actually, using GLib.MAXINT32 would work as well. I will ask on #python
what the correct/better one is.
Regards,
Simon
Confirmed on #python, we should use GLib.MAXINT32 as those are pulled in
directly from GI.
diff --git a/extensions/deviceicon/battery.py
b/extensions/deviceicon/battery.py
index 6bf27ef..362822d 100644
--- a/extensions/deviceicon/battery.py
+++ b/extensions/deviceicon/battery.py
@@ -177,7 +177,7 @@ class BatteryPalette(Palette):
class DeviceModel(GObject.GObject):
__gproperties__ = {
'level': (int, None, None, 0, 100, 0, GObject.PARAM_READABLE),
-'time-remaining': (int, None, None, 0, GObject.G_MAXINT32, 0,
+'time-remaining': (int, None, None, 0, GLib.MAXINT32, 0,
GObject.PARAM_READABLE), # unit: seconds
'charging': (bool, None, None, False, GObject.PARAM_READABLE),
'discharging': (bool, None, None, False, GObject.PARAM_READABLE),
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] G_MIN/MAX constants have been moved into GObject overrides
Thanks, pushed to master and 0.98 (as F19 will package 0.98 and we need
that fix there).
Simon
On 04/25/2013 02:38 PM, Manuel Quiñones wrote:
+1 let's push this.
2013/4/25 Simon Schampijer si...@schampijer.de:
On 04/25/2013 12:53 PM, Simon Schampijer wrote:
The patch works with the latest Pygobject 3.8.x but as well in the 3.4.x
series.
Actually, using GLib.MAXINT32 would work as well. I will ask on #python
what the correct/better one is.
Regards,
Simon
Confirmed on #python, we should use GLib.MAXINT32 as those are pulled in
directly from GI.
diff --git a/extensions/deviceicon/battery.py
b/extensions/deviceicon/battery.py
index 6bf27ef..362822d 100644
--- a/extensions/deviceicon/battery.py
+++ b/extensions/deviceicon/battery.py
@@ -177,7 +177,7 @@ class BatteryPalette(Palette):
class DeviceModel(GObject.GObject):
__gproperties__ = {
'level': (int, None, None, 0, 100, 0, GObject.PARAM_READABLE),
-'time-remaining': (int, None, None, 0, GObject.G_MAXINT32, 0,
+'time-remaining': (int, None, None, 0, GLib.MAXINT32, 0,
GObject.PARAM_READABLE), # unit: seconds
'charging': (bool, None, None, False, GObject.PARAM_READABLE),
'discharging': (bool, None, None, False, GObject.PARAM_READABLE),
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Color Palette: get back horizontal padding - SL #4325
On 04/19/2013 03:51 PM, Manuel Quiñones wrote: 2013/4/18 Simon Schampijer si...@schampijer.de: Hi Manuel, your patch does fix the Write-Color-Palette. Which is the Abacus-Palette, the custom one? Is Walter aware of this fix and would remove his workaround (at least in master)? Yes, the Abacus palette is the custom one. I'm prepared to let Walter know about this change at the moment its commited so he can remove the workaround. Gonzalo workarounded Paint too. Code looks good, please push, as well to 0.98. I have sent a new patch which adds padding as optional parameter. I think it is better API. What do you think? -- .. manuq .. The API is good, but as you add API you can not push as-is to the 0.98 branch. You can push the first one there. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Status for developing Sugar on Ubuntu
Hi, I just had another request for developing Sugar on Ubuntu. The wiki says to use sweets [1]. From what I have heard currently people on Ubuntu have been using sugar-build just fine. Should we update the docs and point devs to sugar-build? I think that section could see some update as well, and we can point people to sugar-build directly. Regards, Simon [1] http://wiki.sugarlabs.org/go/Ubuntu [2] http://sugarlabs.org/~buildbot/docs/build.html [3] http://wiki.sugarlabs.org/go/Sugar_Labs/Getting_Involved#Developer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Status for developing Sugar on Ubuntu
I am only talking about developers. For users it is again another story. But devs I can point to sugar-build in the meantime, imho. Simon On 04/23/2013 02:30 PM, Daniel Narvaez wrote: I think the wiki should clearly differentiate between users and developers. I'm not sure Sweets is good enough for users either though. We need packages, which looks pretty much unmaintained on Ubuntu these days. On 23 April 2013 14:25, Walter Bender walter.ben...@gmail.com wrote: From what I understand, sugar-build is only for 12.10. If is not currently maintained for other releases. But also, sugar-build, while a great tool for developers, may be too volatile of an environment for end users. IMHO, we still have a significant gap in our Ubuntu support. regards. -walter On Tue, Apr 23, 2013 at 5:55 AM, Simon Schampijer si...@schampijer.dewrote: Hi, I just had another request for developing Sugar on Ubuntu. The wiki says to use sweets [1]. From what I have heard currently people on Ubuntu have been using sugar-build just fine. Should we update the docs and point devs to sugar-build? I think that section could see some update as well, and we can point people to sugar-build directly. Regards, Simon [1] http://wiki.sugarlabs.org/go/**Ubuntuhttp://wiki.sugarlabs.org/go/Ubuntu [2] http://sugarlabs.org/~**buildbot/docs/build.htmlhttp://sugarlabs.org/%7Ebuildbot/docs/build.html [3] http://wiki.sugarlabs.org/go/**Sugar_Labs/Getting_Involved#** Developerhttp://wiki.sugarlabs.org/go/Sugar_Labs/Getting_Involved#Developer __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Meeting about HTML activities
On 04/17/2013 10:58 AM, Daniel Narvaez wrote: Hello, we are going to kick off the work on HTML activities for 0.100 with a meeting. Time: 22 April 2013 (14:00 UTC) Place: #sugar-meeting (freenode) It would be really useful to know how many people are interested to contribute, so please try to participate or, if you can't, let us know that you intend to work on it with us. While the discussion is pretty technical at the moment,. I expect everyone with a bit of html/javascript experience will be able to participate to development down the road. Here is a summary of the approaches that has been investigated so far * WebKitGtk based activities. The activity structure would remain pretty similar to the current one, with the HTML loaded in a WebView. We would provide HTML/javascript libraries to implement UI controls and interact with system services, like datastore and collaboration. It's not clear how communication with the native side of the activity will be implemented, there are a few alternatives that should be discussed further. * Chromium integration. We would integrate the web apps framework provided by the Chromium browser inside the Sugar shell, using a custom extension and special casing home icons and window management. The advantage of this approach is that it allows to make use of the Chromium web apps API, http://developer.chrome.com/trunk/apps/about_apps.html. * Firefox OS derivative. Basically we would take Firefox OS (which is based on Android but can run on Linux, OS X and Windows too) and replace Gaia, which is completely written in HTML/javascript and provides the user experience. The advantage is that we would able to run on the top of most popular OS system layers. The disadvantage is that all the activities and the shell would need to be rewritten in HTML for this to be possible. Other topics that should be discussed * How much integration with other OSes user experience do we require? For example on Android it might be possible to use only the system layers, or to run alongside Android native applications. So I suggest this agenda * Discuss the three approaches summarized above. * Decide which approach to take for 0.100. * Write up a TODO for the first milestone. Please let us know if you have any item to add! I am interested in performance of the HTML5 native apps. There are quotes like [1] that states that HTML5 sucks for a system and the fact that Facebook switched to a native Android app instead of their HTML5 one because of performance issues [2][3], I think those do not directly implicate that HTML5 in general is slow: it sounds merely to the facts of bad coding [4] or because on relying on connectivity for the app (turning a web site into an app). The HTML5 activities we are talking about should be native activities, self contained, that do not rely on connectivity, or if de-couple the activity in a way that does not block the UI. But we should compare the performance of the underlying backends and check which technologies can be used for the tasks at hand, e.g. a drawing activity like Paint [5], do we need acceleration to get good results for drawing curves for example. Regards, Simon [1]http://www.engadget.com/2013/03/01/firefox-os-is-repeating-the-mistakes-of-others/ [2] http://www.engadget.com/2012/08/23/facebook-updates-ios-app-says-its-now-twice-as-fast/ [3] http://www.engadget.com/2012/09/11/zuckerberg-html-5-facebook-mobile-app-mistake/ [4] http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story [5] Sketchpad: http://mudcu.be/sketchpad/ Muro: http://sta.sh/muro/ http://heidi.deviantart.com/journal/deviantART-Muro-It-s-Time-to-Draw-214232006 drawing curves: http://www.sitepoint.com/html5-canvas-draw-bezier-curves/ ___ 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 04/17/2013 05:39 PM, Daniel Narvaez wrote: Thanks Daniel. Lots of interesting points here! [...] 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? That's actually something I was thinking about. I have the feeling they cannot at the moment, but it would be useful if someone with an Android phone could confirm. It doesn't seem like a point against using Chrome in Sugar though, we wouldn't be any better off with WebKit, rather it would be in point in favor if it was possible. I looked around if it is possible to run Chrome webapps on Android. In the chrome version you can download from the store chrome://settings/ is not available, so I can not do the same thing I did in chrome on Fedora and following the webapp examples [1]. I did not find any other means on trying this out, if someone has a pointer, I have an Android device to check. While looking around I came across an article [2] about Android and Chrome merging possibly in the future. Some interesting food for the Sugar on Android discussion and if it makes sense to bet on native Android apps or webapps in chrome. Regards, Simon [1] http://developer.chrome.com/trunk/apps/first_app.html [2] http://techland.time.com/2013/03/18/the-coming-merger-of-google-chrome-and-android/ ___ 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 04/22/2013 12:24 PM, Simon Schampijer wrote: On 04/17/2013 05:39 PM, Daniel Narvaez wrote: Thanks Daniel. Lots of interesting points here! [...] 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? That's actually something I was thinking about. I have the feeling they cannot at the moment, but it would be useful if someone with an Android phone could confirm. It doesn't seem like a point against using Chrome in Sugar though, we wouldn't be any better off with WebKit, rather it would be in point in favor if it was possible. I looked around if it is possible to run Chrome webapps on Android. In the chrome version you can download from the store chrome://settings/ is not available, so I can not do the same thing I did in chrome on Fedora and following the webapp examples [1]. I did not find any other means on trying this out, if someone has a pointer, I have an Android device to check. While looking around I came across an article [2] about Android and Chrome merging possibly in the future. Some interesting food for the Sugar on Android discussion and if it makes sense to bet on native Android apps or webapps in chrome. Regards, Simon [1] http://developer.chrome.com/trunk/apps/first_app.html [2] http://techland.time.com/2013/03/18/the-coming-merger-of-google-chrome-and-android/ And of course there are different information bits to the chrome Android merge, e.g.: http://techcrunch.com/2013/03/21/chrome-android-still-merging/ http://www.omgchrome.com/when-will-chrome-and-android-merge/ Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [MINUTES] HTML activities meeting
On 04/22/2013 11:40 AM, Daniel Narvaez wrote: Time: 22 April 2013 (14:00 UTC) Place: #sugar-meeting (freenode) More info http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042558.html Minutes: http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27.html Log: http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27 Cheers, Simon ___ 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 04/17/2013 07:20 PM, Daniel Drake wrote: On Wed, Apr 17, 2013 at 9:39 AM, Daniel Narvaez dwnarv...@gmail.com 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. Yes, that is the impression I got from the reasoning from Tom 'spot' Callaway [1], and it has been like that since 2009 it looks like, state seems to be the same. Peter says that building of Chrome in general needs a lot of horse power, probably one reason it has not been build for Fedora-ARM yet. I guess with Chrome we run into the same issues as with Android regarding the openness, irregular code drops etc. Regards, Simon [1] http://ostatic.com/blog/making-projects-easier-to-package-why-chromium-isnt-in-fedora ___ 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 04/11/2013 09:52 PM, Daniel Narvaez wrote: Hello, I spent some time today thinking and experimenting with Chromium integration and I have a more detailed plan to propose now. There is an important premise to be made. In both Chromium and Firefox OS, application's installation is very much in the hands of the web browser. It happens as the result of a user clicking on a button, inside a web store. Chromium is a bit more flexible but the other possibilities are basically just developer tools. I think this limits our possibilities a lot. We need to use the browser applications management, rather then installing applications ourselves and then launching them with some command line option. Of course Chromium is open source and we could develop the stuff which is missing. But, in my opinion it's just too much work and it's going to be a pain to maintain in the future, core developers are not going to care about it, given it's not important for their products. That said, I think I mostly figured out a plan to integrate with Chromium web apps management, without having to write a lot of code. * Chromium is started up with the sugar session, using the --no-startup-window, to make it invisible. The sugar extension has a background permission, which will keep it running even with no windows. * The extension runs a python script, using chrome.runtime.connectNative. Communication uses json-rpc wrapped in the message protocol supported by the extension. The python script fetches the list of installed activities Hey Daniel, I have an extension that is using management.getAll [1] to collect the extension info. I could not find any info about chrome.runtime.connectNative, it is not part of [2], do you have any pointers? Thanks, Simon [1] https://developer.chrome.com/extensions/management.html#type-ExtensionInfo [2] http://developer.chrome.com/extensions/runtime.html ___ 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 04/13/2013 02:42 AM, Daniel Narvaez wrote: On 12 April 2013 23:18, Daniel Narvaez dwnarv...@gmail.com wrote: Hi Lionel, we are more or less understanding each other :) I think there are really three possible steps 1 A WebView with an html5/javascript based sugar-toolkit 2 Support for web activities along with native ones, inside a native shell 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 I'd expect those API to keep growing. The permission system is particularly important because it allows to do stuff which would be a security risk if done by a normal html page. (Hopefully they will some day converge between browsers!). Indeed, the packages apps, Webapps or native apps (or however you call them) have the advantage of being able to access the network and hardware devices. You can check out while building an app [1] or have a look at the [2] samples, one is using the camera and microphone for example or you can access/write files on the file system. You can even try it out on the XO (non-ARM hardware) and install chromium there [4]. Regards, Simon [1] http://developer.chrome.com/trunk/apps/first_app.html [2] git clone git://github.com/GoogleChrome/chrome-app-samples.git [3] https://github.com/GoogleChrome/chrome-app-samples/tree/master/camera-capture [4] http://fedoraproject.org/wiki/Chromium ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)
On 03/27/2013 09:03 PM, Daniel Narvaez wrote: On 27 March 2013 16:23, Manuel Quiñones ma...@laptop.org wrote: I know all this can be replaced by a fork pull workflow, and I'm used to do that in github. But gitorius interface is not as good as github, in my opinion. By the way, if we have consensus for a fork pull workflow, I have no problem switching. There was actually some discussion in irc today about using github. Reposting here for people that are not following irc. It might not be a bad idea to give a try to a github based workflow with 0.100. (git is flexible enough that giving it a try should not have a big cost, you can easily go back to gitorious at any time). 17:26 cjb honestly just moving to github is probably not a bad idea IMO 17:26 dnarvaez I like the bug tracking stuff in github 17:26 cjb you'd get pull requests you can track, link between issues and commits, it's a more standard and approachable place for collaboration to happen, and they have export functions for getting your data back out 17:27 dnarvaez for review I wonder if pull requests would work 17:27 cjb sure, it's what everyone else does 17:28 dnarvaez I suppose the infra team would be glad to have few services less to support :) 17:30 cjb it made sense to run our own git when github was new and we were opposed to everyone standardizing on a centralized (and non-free software) web location for git repositories 17:30 cjb but github is huge now, and we're just losing contributors by refusing to take part, IMO 17:30 dnarvaez yeah pretty much everyone is one github these days I read a bit about the differences. For a purist the 'is not using free software on their server' springs to mind. But maybe let's focus on the work flow first. The merge requests on gitorious I never used. Maybe because I was too focused on the bug tracker or patch on email work flow. It does make sense to have a pull workflow for bigger changes that are linked to each other, for example a port-shell-to-gtk3 project. I should check if I can get used to that as a general work flow model. Maybe I check with the ayopa project to get a feeling for it. In general, I am not opposed to useing github as we do not change the underlying management system, and that stays the main part. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] can't 'yum update' from virtual environment
On 03/28/2013 10:51 AM, Basanta Shrestha wrote: Hi all, I am trying to build os for XO-1.75. I have installed fedora 14 as main OS and installed fedora for ARM (Fedora 12) under virtual machine. Everything including network is working from within virtual OS and I can ping outer world as well. I now need to install essential packages to run olpc-os-builder from within virtual machine OS, but the problem is, I am not able to update ( yum update) nor install any package. Need help. What error message do you get? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Tuxmath on 0.96+ mystery
On 03/27/2013 11:03 PM, Gonzalo Odiard wrote: Another option is use http://dev.laptop.org/~gonzalo/nicaragua/Tuxmath-3.xo and tuxmath packaged in fedora. Gonzalo Ok, the AND is important here. Would be good to write down the clear steps to get this into a build. The no-sound option on the landing page is a bit misleading, it does only mean that click sounds are not audible, the background music is still playing. Mission accomplished, Simon PS: I made it crash it my first mission, and no, my additions were correct... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] JournalShare status
On 03/27/2013 10:57 PM, Gonzalo Odiard wrote: I have created a page in the wiki to describe the status of JournalShare activity. http://wiki.sugarlabs.org/go/Activities/JournalShare Enjoy Easter Gonzalo Thanks Gonzalo for the write-up! The first thing that caught my eye was the way to define which items should be shared. I wouldn't use the favorite metaphor for that. That works for the Portfolio activity well, but here it is the wrong one, imho. It should be explicit which items I want to share, using the Objectchooser looks like the right approach. You might actually as well to share an object from a usb key or an external sd-card, here the metaphor of a favorite item works even less. Another thing that is important is the notion of other members of the session. I presume the communication should happen in all directions (e.g. a teacher and five students each member of the session can share items with the other one), therefore it is important to know who is in the session and who has offered what. Actually, we should think as well whether it should be a push or a pull model. The current file transfers (with friended buddies) are a push model where the receiver can accept or decline. I think here it is more of a bulletin board (some ideas for wording and similar you might find here [1]) where people post items they want to be shared with the group, so a pull model makes sense here, imho. Regards, Simon [1] http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Bulletin_Boards ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/26/2013 09:55 PM, Manuel Quiñones wrote: 2013/3/26 Daniel Narvaez dwnarv...@gmail.com: [...] We also had periodic design meetings guiding features. I wonder if that kind of discussion could be had on the mailing list rather than in meetings. It's problematic to find a time that works for everyone and many people just doesn't have time to spend in irc. Yes after coordination issues we concluded we better keep discussing design topics in the mailing list. We have a prefix [DESIGN] for this. I will try to be more responsive to those threads from now on. Discussing design after the development is made isn't good, imho. I couldn't agree more. The feature process has some guidelines in regard to Features that add UI: If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. Please add the flag as well if the work flow does change or new ones are added. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design does not have to be ready but the discussion should have been started. [1] Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Music Keyboard-6
On 03/21/2013 08:06 PM, Sugar Labs Activities wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4654 Sugar Platform: 0.98 - 0.98 Download Now: http://activities.sugarlabs.org/downloads/file/28522/music_keyboard-6.xo Release notes: This activity show a piano keyboard, and in devices with touch screen, can be used to play music. Can be used with a xo keyboard too, showing the played note in the screen. Sugar Labs Activities http://activities.sugarlabs.org Thanks Gonzalo for working on this awesome addition to the activity suite. I played a bit with it today and here a few feedback items: - the initially selected instrument is not selected, when I change the instrument, it is selected fine. As the widget to select an instrument is a list depending on the selection you can not always see the selected instrument, maybe you want to show the currently selected instrument as well in the toolbar or make that clear by other means - it is great that you can show different labels on the keyboard, the icon for the hardware keyboard mode is not really clear maybe you can reuse the icon from the Sugar control panel, I would add tooltips to the icons (they should hide automatically when you click the icon, recent fixes have anded for this in the sugar-toolkit-gtk3), finding good text for the tooltip involves a bit of research I guess [1], it would be great to have no-labels at all mode as well - when I hold down 'w' and 'r' pressing 't' will not give any visual or musical feedback - 'y' or 'u' does work, same that 'z' and 'c' work but 'x' does not when holding down 'w' and 'r' at the same time - sound: this is a question for the OLPC audio developers, there is a lot of noise and clipping while playing - would be fantastic to fix this as well - Future-future: it would be great to show the corresponding note in the musical representation [2], [...] recording would be nice, play-along [...] but that probably let the scope of the activity explode :) Regards, Simon [1] https://en.wikipedia.org/wiki/Do_%28musical_note%29 [2] https://en.wikipedia.org/wiki/File:Middle_C.png ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Music Keyboard-6
On 03/27/2013 12:27 PM, Gonzalo Odiard wrote: On Wed, Mar 27, 2013 at 7:38 AM, Simon Schampijer si...@schampijer.dewrote: On 03/21/2013 08:06 PM, Sugar Labs Activities wrote: Activity Homepage: http://activities.sugarlabs.**org/addon/4654http://activities.sugarlabs.org/addon/4654 Sugar Platform: 0.98 - 0.98 Download Now: http://activities.sugarlabs.**org/downloads/file/28522/** music_keyboard-6.xohttp://activities.sugarlabs.org/downloads/file/28522/music_keyboard-6.xo Release notes: This activity show a piano keyboard, and in devices with touch screen, can be used to play music. Can be used with a xo keyboard too, showing the played note in the screen. Sugar Labs Activities http://activities.sugarlabs.**org http://activities.sugarlabs.org Thanks Gonzalo for working on this awesome addition to the activity suite. I played a bit with it today and here a few feedback items: Thanks!. Can we add it to the favorite activities in the new images to expose it to more testers? Yes, is a good idea! Daniel can you add the musical keyboard to the favorites in 13.2.0? - the initially selected instrument is not selected, when I change the instrument, it is selected fine. As the widget to select an instrument is a list depending on the selection you can not always see the selected instrument, maybe you want to show the currently selected instrument as well in the toolbar or make that clear by other means Agree. We need think how is the best way to show the selected instrument. I don't like put labels in the toolbar, but in this case, may be is not a problem. Yes, the toolbar is the place for actions, not the best place to show status only items. Reordering the list to always have the selected item on top is not really good neither as it might be confusing to the user. Or how about, you scroll to the row with the currently selected item? That should work UI and technical wise. - it is great that you can show different labels on the keyboard, the icon for the hardware keyboard mode is not really clear maybe you can reuse the icon from the Sugar control panel, I would add tooltips to the icons (they should hide automatically when you click the icon, recent fixes have anded for this in the sugar-toolkit-gtk3), finding good text for the tooltip involves a bit of research I guess [1], it would be great to have no-labels at all mode as well Good. About the tooltips, I was not sure about the scales denomination. In some places, the scales with letters is named German and in other is American ! The scale starting in DO can be named Latin, but is not really clear for me and there are a lot of changes by countries and in the history. See: https://en.wikipedia.org/wiki/Musical_note Yes, I looked about a good way as well but could not find a global labeling myself. As you say, some say latin, others say german... We need a musicologist here... - when I hold down 'w' and 'r' pressing 't' will not give any visual or musical feedback - 'y' or 'u' does work, same that 'z' and 'c' work but 'x' does not when holding down 'w' and 'r' at the same time Good catch. Requires research. Yes, might be an issue with the underlying musical engine. - sound: this is a question for the OLPC audio developers, there is a lot of noise and clipping while playing - would be fantastic to fix this as well Yes. - Future-future: it would be great to show the corresponding note in the musical representation [2], [...] recording would be nice, play-along [...] but that probably let the scope of the activity explode :) +1 and +1 May be we can propose these as tasks to GSoC. Yes, sounds good to me. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.100 release schedule
On 03/27/2013 01:36 PM, Daniel Narvaez wrote: Hello, here is an initial schedule for 0.100 http://wiki.sugarlabs.org/go/0.100/Roadmap Notes: * Still unclear if it's going to be 0.100 or 1.0. We should probably decide after we know what the focus of the release is going to be. That sounds good, 0.100 is a good working name for now. * I have not allocated dates for unstable tarballs. Is it actually worth spending time building those? Is anyone using them? So far, Fedora has been picking them up and they made their way into the OLPC images that way. It is not much overhead to do, I would stick to it. * I merged a few freezes together to simplify things. Like Gonzalo said a few mails later, it is a good thing to have the Feature freeze before the UI and String freeze. Often Features have been landed just at this date and then we had to arrange for exceptions of changes for UI and Strings later. Sometimes a Feature sees quite significant changes once more people test it, that is why it is good to separate them. * Relevant GNOME and Fedora schedules are still unknown so I couldn't try to sync with those. Yes, those appear always a bit later. GNOME is usually around the end of September, so your current dates work. Thoughts? About the general strategy, it would be great to foster around a common goal, to me the html5 activities would fit perfectly here. There is still to define the exact goals of the feature itself but the research Daniel has been doing here is a good base for it. The nice thing with html5 activities is that they can be used on different platforms, for example the discussions about Sugar on Android would benefit from that work. And it would be a nice addition to get new developers on board. For the other features, I would suggest to limit them and check the ones that have been deferred previously (e.g. multi select in Journal) in releases and the one that have been submitted as of today (e.g. background in Home) for inclusion in this cycle. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.100 release schedule
On 03/27/2013 06:58 PM, Daniel Narvaez wrote: On 27 March 2013 18:47, Simon Schampijer si...@schampijer.de wrote: * I have not allocated dates for unstable tarballs. Is it actually worth spending time building those? Is anyone using them? So far, Fedora has been picking them up and they made their way into the OLPC images that way. It is not much overhead to do, I would stick to it. Is Fedora still going to pick these up? (Since soas is going to stick with 0.98 for F19). They can pick it up for F20 then, F20 is already open :) Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal on how to speed up patch reviews
On 03/25/2013 01:27 PM, Gonzalo Odiard wrote: While I agree in theory with all this, we can improve our actual situation if we look at our resources, time and people. * Time: we don't have a schedule, then feature discussion can't start. We can improve if we have a clear path and start to define what features will be included in the next cycle. I am sure different players right now have different ideas of what the next cycle can/should be, we need a agreement and try to push together. Yes, having a schedule will help. I guess if there is not a good reason to switch to feature based releases we can stick with time based ones. And keep on following the GNOME/Fedora schedule that would be September/October again. I guess your brain can start to think about what you want to achieve in such a time frame...(yes we should make a general call for this). * People: We don't have enough people really, and this situation can be temporally more difficult if some maintainer have by example a baby :) (to not use the classic Linus gets hit by a bus) As a project, we need take care of the people working with us, see at the personal situations, and the maintainers should open the door to more people to be involved if possible. For a long time, we had only Simon and Sascha doing sugar maintainership, and was not enough, now we have Simon and Manuq, and there are too much work to do. I think we should continue work on trying to get somebody else involved as maintainer. Gonzalo If you see people around that want to be maintainers and feel ready for it, great. I think I have not pushed back on someone who stepped up so far :) But I think even if you aren't a nominated maintainer you can help the current maintainers with the work load. As described in this thread people can help with review and testing and helping with product polish especially in the last part of a cycle is helpful as well. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/25/2013 09:32 PM, Daniel Narvaez wrote: Forgot to reply all... -- Forwarded message -- From: Daniel Narvaez dwnarv...@gmail.com Date: 25 March 2013 21:12 Subject: Re: [Sugar-devel] Proposal on how to speed up patch reviews To: Simon Schampijer si...@schampijer.de On 25 March 2013 12:37, Simon Schampijer si...@schampijer.de wrote: To improve that situation, I think we have to put some lights on all those roles and I think often the situation of the maintainer is not understood well enough. I can at least say that we had this discussions for the last years in Sugar, with different maintainers and I have seen it happening in many other projects as well. It is a known issue, and it is not an easy one, never less I think we can improve. In my experience Sugar has been much worst than both GNOME and mozilla though. I know it's not easy but we should keep trying. (I hope it's absolutely clear that I'm not blaming anyone for the situation, just pointing out the importance of fixing it or at least trying to) [bugfix] A bugfix is the simplest case. The submitter is interested in solving the specific issue he is working on. It is not hard to find a reviewer or tester. Either someone from the community that has been annoyed by the same issue or the maintainer himself because he is interested in seeing the issue solved, his interest is a working code base in the end. Here it is easy as well for a maintainer to trust another reviewer and acknowledge based on his positive review. In my experience those patches are not laying around for long if there is not a technical blocker in the patch itself. Evaluation is relatively easy here. I had at least one obvious bug fix patch unreviewed for months. Maybe I was unlucky. Anyway I agree this is the easiest of the cases and where things work best. That is bad of course. Could have been several reasons. Maybe the decoupling of patches and the bug tracker, maybe just felt of the table... Sometimes a ping is valid option. But yes, the easiest area to solve. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. From my experience the work on a feature and the polish of it gets often underestimated. The first 90% are done in 10% of the time the last 10% are done in 90% of the time. I would like to establish a sense of the work needed to finish a feature, not to make people afraid of starting to work on features but to be realistic. That might explain a general bigger resistance to features by maintainers. How can we help each other to make this a better process? I think narrowing the focus is the best we can do, but I'll elaborate more about that while answering Gonzalo email. [feature/UI] All what have been said above applies to the feature that adds UI as well. I have separated that item because it adds another complexity. We have the UI process for this (as written in the feature policy [1]). Basically it adds more care taking of all the roles involved. Even if we go with my propiosal, I think maintainers should keep a strong supervision role on features, UI or not. I'd say it's responsibility of the reviewer to make sure the maintainer is happy in this regard... we should add it to our review checklist (well we don't have one yet afaik, but we should). Yes, from my experience, the UI review part of a Feature takes even longer than the code review. First of all we do not have as many designers as people who can do review and good consistent UI is not easy. Gary and Manuel are currently helping on that end. Probably good to hear them, if they have anything to add that could help to make things go more smooth. Online services patches, unreviewed for more than one month http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html Unreviewed for more than one month This one is part of the [feature] category. It can be mostly explained with the maintainers having their heads still in bug fixing for 0.98. Here applies as well what I said with high level descriptions of features and the feature process [2]. In an ideal world, a reviewer which is not busy with 0.98 should have given a first pass to the patches and at the same time started a discussion, involving the maintainer, about
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/26/2013 11:13 AM, Daniel Narvaez wrote: On 26 March 2013 10:53, Simon Schampijer si...@schampijer.de wrote: That is bad of course. Could have been several reasons. Maybe the decoupling of patches and the bug tracker, maybe just felt of the table... Sometimes a ping is valid option. But yes, the easiest area to solve. I did try to ping a couple of times on that specific patch. The thing is that if you see maintainers are busy with a ton of stuff you just don't dare pinging too hard and at some point you give up... (Just trying to give a contributor perspective here). Ok, it is good to hear the different stories from the parties involved. This is a thread to analyze the situation and see how we can do better. Appreciated. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. From my experience the work on a feature and the polish of it gets often underestimated. The first 90% are done in 10% of the time the last 10% are done in 90% of the time. I would like to establish a sense of the work needed to finish a feature, not to make people afraid of starting to work on features but to be realistic. That's my experience too. But are you saying the hardest 10% is in the hands of maintainers? That happens in my experience, but it doesn't have to, or at least not most of the time. Yes, I think that happens sometimes. Part of it is maybe if the submitter feels responsible or not for a feature after it has been landed and how much he is willing to follow up during the process. Of course for the contributor it does not help if the process (a) takes long and (b) if the process has not started for a long time after he has sent the patches and he is already doing something else. If roles and responsibilities are clear and we have a timeframe and guidelines to enforce things can get better. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/26/2013 12:21 PM, Manuel Quiñones wrote: I would like to applaud the discussion. Yes, I think we are blocking too much, in regards to stuff that is out of bugfixing, and polishing the gtk3 port. This is indeed not good for the community. When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. We also had periodic design meetings guiding features. Discussing design after the development is made isn't good, imho. It would be great if someone can stand up and become a maintainer. Maybe you, Daniel? You have demonstrated your skills with sugar-build, and helping on the gtk3 port. A reviewer with the authority described in this discussion is probably a good first start. I think that is what Daniel would be able to help us with. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Next release
On 03/26/2013 01:20 PM, Walter Bender wrote: On Tue, Mar 26, 2013 at 8:07 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, we are pretty late in the cycle for the next release without much development having been landed on the master branch. At this point I think we need to consider what our options are. If we had to release 6 months after 0.98.0, that would be the beginning of June, thus only 2 months and half left. Things are even worst if we consider the GNOME schedule, which have been trying to stay somewhat synced with. In fact 3.8 is being released these days. So, here are the possibilities I see 1 Try to stick to the plan anyway, land the features that have been developed so far and try to stabilize them in time for June. 2 Focus on a polish only release for June and delay new features to the next cycle. 3 Skip the June release altogether, start a new 6 months cycle now. Work on another stable release in parallel. My feeling is that 1 is not very realistic. There is very little time and our maintainers and most active contributors are going to be busy polishing for upcoming OLPC release. We should consider that Fedora 19 will stay on 0.98. So even if we manage to release in time, the release won't be much distributed. I'm not too sure about 2 vs 3. Our maintainers haven't been getting much help with the polishing phase of the release cycle and it would be good to send a message to the community that it's an important part of the work, by dedicating a few months exclusively to it. Though I'm not too keen of blocking master for another few months, keeping code which has already been submitted long ago out of the tree. What does everyone think? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I don't think it is worth pushing out a half-baked release just to keep on a time-based release schedule, so I agree about not going with option #1. Re #2, it would be good to get a feel for what polish is needed and what would be realistic to land. (I've been for example, trying to get some of the core activities better tuned for touch and screen rotation, but there has been little comprehensive discussion of this theme on devel. I doubt we'd be able to land these changes in this release cycle.) Re #3, personally, I think we should go with this option. We have extra time to make it a great release for Sugar 1.0. Can we start with putting together a schedule in the wiki [1]. regards. -walter [1] http://wiki.sugarlabs.org/go/1.0/Roadmap (just a stub) I would go for option #3, I like the idea of sending the 'bugfixes are an important part of the game message out but I think it is good to keep master open. OLPC 13.2.0 will ship a polished 0.98 release, this release is feature based depending on a few XO-4 polish items. For 0.98 polish this means to just get as many bug fixes in as possible, and make bugfix releases often enough. Help is highly welcome on that effort of course. So this could be the message to pass to not only think on master and help polish the stable branch in parallel. This will benefit as well the upcoming Soas/Fedora 19 release which will include that polished 0.98 version. To get a feeling of open items, here is a list of 0.98 regressions [1] and the currently tagged 0.98 bugs [2]. Back to the next unstable release, going for the September/October 2013 release and keeping aligned with GNOME the platform we are building on is a good goal. As stated by different people several times, we should list the goals and then work together to achieve them. By limiting the features and/or foster around a bigger one we can foster our resources (I think about HTML5 activities here in particular as my favorite item for the next unstable release). About the branches, there is a sucrose-0.98 branch where the stable release, the 0.98 polish release does come from. Unstable development does happen on master. Bugfixes that land in sucrose-0.98 do land in master first and get cherry-picked to sucrose-0.98, we have been doing this already in the last weeks. Naming, I am a bit reluctant to call the next release 1.0 unless we define clearly what 1.0 criteria we have, API stablity etc comes here to mind. Maybe we we can defer this by just calling the next release modestly 0.100. Regards, Simon [1] http://bugs.sugarlabs.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedgroup=ownerorder=prioritycol=idcol=summarycol=milestonecol=statuscol=ownercol=typecol=prioritycol=componentcol=keywordsmilestone=0.98keywords=~regression [2] http://bugs.sugarlabs.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedgroup=ownerorder=prioritycol=idcol=summarycol=milestonecol=statuscol=ownercol=typecol=prioritycol=componentcol=keywordsmilestone=0.98 ___ Sugar-devel mailing list
Re: [Sugar-devel] Proposal on how to speed up patch reviews
Hey Daniel, thanks for the write-up! It is true that patch review, especially of non-bugfix patches is slow and can be sometimes frustrating for all parties involved, the reviewer, the maintainer and the submitter. To improve that situation, I think we have to put some lights on all those roles and I think often the situation of the maintainer is not understood well enough. I can at least say that we had this discussions for the last years in Sugar, with different maintainers and I have seen it happening in many other projects as well. It is a known issue, and it is not an easy one, never less I think we can improve. I think there are different kind of patches, let's simplify with 4 categories: [bugfix] a bugfix [feature] a Feature [feature/UI] a Feature with UI [cleanup] a cleanup/maintenance There are different kind of roles in the process and each will act differently based on his needs and duties. There are the submitters, the reviewers (can be either the maintainer, or someone else from the community) and the maintainers. Let's step through the categories and talk about the different roles: [bugfix] A bugfix is the simplest case. The submitter is interested in solving the specific issue he is working on. It is not hard to find a reviewer or tester. Either someone from the community that has been annoyed by the same issue or the maintainer himself because he is interested in seeing the issue solved, his interest is a working code base in the end. Here it is easy as well for a maintainer to trust another reviewer and acknowledge based on his positive review. In my experience those patches are not laying around for long if there is not a technical blocker in the patch itself. Evaluation is relatively easy here. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. That might explain a general bigger resistance to features by maintainers. How can we help each other to make this a better process? First of all, it is important to know the high level goals of a feature. The feature process [1] in place actually helps in that regard, the maintainer can do the evaluation based on the community feedback and the high level goals and if those are accepted can do the actual review of the code. Getting approval for a feature does take time, and the review itself often as well, this should be counted in as well from all the sides, especially when it is the desire to see a specific feature being present in a release. Setting goals at the beginning of a release and having an accepting feature period will help here as well, actually all of this is in place already. [feature/UI] All what have been said above applies to the feature that adds UI as well. I have separated that item because it adds another complexity. We have the UI process for this (as written in the feature policy [1]). Basically it adds more care taking of all the roles involved. [cleanup] These are simple as well and can be acknowledged without much thinking. In my opinion, maintainers should be able to do those without the need of a review, if uncertain or bigger parts are touched they can discuss the items with the other maintainers. [1] http://wiki.sugarlabs.org/go/Features/Policy On 03/24/2013 08:30 PM, Daniel Narvaez wrote: Hello, I think patch reviews are taking too long. It's probably a well known issue but I will give a couple of examples as a proof. Online services patches, unreviewed for more than one month http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html Unreviewed for more than one month This one is part of the [feature] category. It can be mostly explained with the maintainers having their heads still in bug fixing for 0.98. Here applies as well what I said with high level descriptions of features and the feature process [2]. [2] http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041810.html Various patches, including automated testing stuff http://lists.sugarlabs.org/archive/sugar-devel/2012-December/041218.html Unreviewed for more than three months This is nearly category [cleanup]. We should not block here on a in depth review when things pass the usual tests (pep8 etc) and the high level approach is accepted (taking for granted that the maintainer is fixing up the issues that might arise himself). I think this situation is seriously hurting the project, in several ways: Agreed. * It makes hacking on sugar not fun at all. I honestly even lost interest in the patches I sent at this point. * It
Re: [Sugar-devel] Network proxy, configuration
For this Feature it would be good to have a look at the exact use case that originated this feature request. Activity Central worked on it, maybe they can give us details about the request from their client to know which exact case we are trying to solve. Simon Am 15.03.2013 um 04:29 schrieb Tony Anderson tony_ander...@usa.net: Hi, Does this mean we will need two signed images, one for the schoolserver and one for the stand-alone XO? Until now, the default configuration has assumed that proxy is provided by the schoolserver. Tony On 03/14/2013 11:17 PM, Gonzalo Odiard wrote: On Thu, Mar 14, 2013 at 6:19 PM, Tony Anderson tony_ander...@usa.net mailto:tony_ander...@usa.net wrote: Hi, This discussion is making me nervous. The standard model of the XO has been that they are connected to the internet via the school server. Is it proposed to set up this proxy-server as a requirement for all XOs and for the user (primary school children) to have to manage this even when no access to the internet is available or even when that access is provided by the school server? No. This configuration is only needed in environments where there are not school server, and is not possible a automatic configuration. Gonzalo Tony On 03/14/2013 04:35 PM, sugar-devel-request@lists.__sugarlabs.org mailto:sugar-devel-requ...@lists.sugarlabs.org wrote: 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). _ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.__org mailto:Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/__listinfo/sugar-devel http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar PATCH] sl#3833: Now, the palettes appear fine in the bottom frame-tray.
Hey Ajay, thanks for the new patch, looks like this solves the previous issues we have been seeing there. On 03/06/2013 01:30 PM, Ajay Garg wrote: The solution has been build upon the no-caching solution provided by erikos at http://bugs.sugarlabs.org/ticket/4419#comment:4 Theerafter, the cause of http://bugs.sugarlabs.org/attachment/ticket/3833/Screenshot%20of%20_Journal_.png is not taking style.GRID_CELL_SIZE into account, when calucating the alignments for the palettes. I will have to thank manuq a great deal, for his comment http://bugs.sugarlabs.org/ticket/3833#comment:11, which helped me debug the real issue. In particular, his observation that the landscape-mode-obscurity occurs only in one of the erikos' solutions; while the portrait-mode-obscurity occurs only in both of erikos's solutions. Finally, this patch provides the no-obscurity solution for all cases :) This is information I would expect in a ticket comment but the patch description needs to inform about the issue and its solution. See the following examples for a style guide: http://git.sugarlabs.org/sugar/mainline/commit/c6e19b4df9e8c1a4216aa09b9c579b43da9684d2 http://git.sugarlabs.org/sugar/mainline/commit/0a98409be5eedb9ee27a9fd1b526e99c764f55f5 http://git.sugarlabs.org/sugar/mainline/commit/158f4384d1f3423a6c2063723434f4f331796f81 src/sugar3/graphics/palettewindow.py | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/src/sugar3/graphics/palettewindow.py b/src/sugar3/graphics/palettewindow.py index c48ae55..e192a7c 100644 --- a/src/sugar3/graphics/palettewindow.py +++ b/src/sugar3/graphics/palettewindow.py @@ -777,8 +777,6 @@ class Invoker(GObject.GObject): self._screen_area = Gdk.Rectangle() self._screen_area.x = self._screen_area.y = 0 -self._screen_area.width = Gdk.Screen.width() -self._screen_area.height = Gdk.Screen.height() self._position_hint = self.ANCHORED self._cursor_x = -1 self._cursor_y = -1 @@ -841,8 +839,8 @@ class Invoker(GObject.GObject): def _in_screen(self, rect): return rect.x = self._screen_area.x and \ rect.y = self._screen_area.y and \ - rect.x + rect.width = self._screen_area.width and \ - rect.y + rect.height = self._screen_area.height + rect.x + rect.width = (Gdk.Screen.width() - style.GRID_CELL_SIZE) and \ + rect.y + rect.height = (Gdk.Screen.height() - style.GRID_CELL_SIZE) def _get_area_in_screen(self, rect): Return area of rectangle visible in the screen @@ -850,9 +848,9 @@ class Invoker(GObject.GObject): x1 = max(rect.x, self._screen_area.x) y1 = max(rect.y, self._screen_area.y) x2 = min(rect.x + rect.width, -self._screen_area.x + self._screen_area.width) +self._screen_area.x + Gdk.Screen.width() - style.GRID_CELL_SIZE) y2 = min(rect.y + rect.height, -self._screen_area.y + self._screen_area.height) +self._screen_area.y + Gdk.Screen.height() - style.GRID_CELL_SIZE) return (x2 - x1) * (y2 - y1) @@ -882,8 +880,8 @@ class Invoker(GObject.GObject): rect.x = max(0, rect.x) rect.y = max(0, rect.y) -rect.x = min(rect.x, self._screen_area.width - rect.width) -rect.y = min(rect.y, self._screen_area.height - rect.height) +rect.x = min(rect.x, Gdk.Screen.width() - style.GRID_CELL_SIZE - rect.width) +rect.y = min(rect.y, Gdk.Screen.height()- style.GRID_CELL_SIZE - rect.height) return rect @@ -913,7 +911,7 @@ class Invoker(GObject.GObject): if best_alignment in self.LEFT or best_alignment in self.RIGHT: dtop = rect.y - screen_area.y -dbottom = screen_area.y + screen_area.height - rect.y - rect.width +dbottom = screen_area.y + Gdk.Screen.height() - style.GRID_CELL_SIZE - rect.y - rect.width This exceeds 79 chars. iv = 0 @@ -928,7 +926,7 @@ class Invoker(GObject.GObject): elif best_alignment in self.TOP or best_alignment in self.BOTTOM: dleft = rect.x - screen_area.x -dright = screen_area.x + screen_area.width - rect.x - rect.width +dright = screen_area.x + Gdk.Screen.width() - style.GRID_CELL_SIZE - rect.x - rect.width Same here. Please run another test for all the Palettes if we do not miss one, we already screwed up several times. Would be great if thorough Manuel could have another testing run on the final patch with the fixups from above. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [write PATCH] sl#4436: Making collaboration work again.
On 02/21/2013 04:35 PM, Manuel Quiñones wrote: 2013/2/21 Walter Bender walter.ben...@gmail.com: I've had to make a similar change in my activities as well. (I guess I missed the patch go by when self._shared_activity became self.shared_actvity) There is a also a method, self.get_shared_activity(), which might be better than directly referencing the instance variable. I suppose it is a style issue. Thanks both Ajay and Walter for looking at this. Thanks for digging that up! Yes, git log says to me that the usage of _shared_activity was marked as deprecated in the code for a long time, and get_shared_activity was the recommended form. This deprecation was removed in commit 70cee447 of toolkit-gtk3 in January 2012, and the API change was stated in 0.96 release notes: http://wiki.sugarlabs.org/go/0.96/Notes#API. We should check if other activities are still using it. Help welcome. I did it for Memorize in the GTK+ 3 work already [1]. I added an extra note to the 0.98 Notes [2]. [1] http://git.sugarlabs.org/memorize/mainline/commit/d23d46cac218d7495890904f84d4ef66de7bdb49 [2] http://wiki.sugarlabs.org/go/0.98/Notes#API Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] online account management
Hi Walter and Raul, this looks like a Feature scope work to me, I would like to see a Feature discussion about this first. If you fill out the form [1] it will help to discuss the separate points. Thanks, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy On 02/19/2013 04:13 AM, Walter Bender wrote: Raul and I have the first version of Sugar online account management ready for review. We've divided the code into 4 patches: 0001 adds support for comments in the Journal detail view. This extension of the detail view is independent of the other patches and is used by the Portfolio activity. 0002 adds support to integrate online account management with the Sugar journal, adding Copy-to and Refresh capabilities. 0003 adds support to the Control Panel to manage accounts. 0004 adds support specific to Facebook, taking advantage of the framework in #0002 and #0003. We are working with community members on Twitter and Google Drive extensions based on the framework in #0002 and #0003 and encourage other community members to work with us on additional services. For now, web services implementations are welcome to handle their retrieval of tokens on their own. In the future we might want to delegate that to Gnome Online Accounts or a similar auth/token provider. regards. -walter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Journal toolbar: add tooltip to favorite filter
From: Simon Schampijer si...@laptop.org
This patch adds the tooltip 'Favorite entries' to the favorite filter
button in the Journal toolbar. The button is a ToggleToolButton and
with the recent change in the toolkit-gtk3
63b8e87b1a99a854e9adbb1579b1e05244d2dc4
we do hide the tooltip when the button is clicked or touched.
This adds a new string, therefore this patch is only intended for
master. The addition and string has been discussed with Gary and Manuel.
Signed-off-by: Simon Schampijer si...@laptop.org
---
src/jarabe/journal/journaltoolbox.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/jarabe/journal/journaltoolbox.py
b/src/jarabe/journal/journaltoolbox.py
index c7ee73a..69ff777 100644
--- a/src/jarabe/journal/journaltoolbox.py
+++ b/src/jarabe/journal/journaltoolbox.py
@@ -89,6 +89,7 @@ class MainToolbox(ToolbarBox):
self._add_widget(self.search_entry, expand=True)
self._favorite_button = ToggleToolButton('emblem-favorite')
+self._favorite_button.set_tooltip(_('Favorite entries'))
self._favorite_button.connect('toggled',
self.__favorite_button_toggled_cb)
self.toolbar.insert(self._favorite_button, -1)
--
1.8.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Feature] Starting an activity in a different locale than the system locale
Hi, when talking about the 'grab watch hands' feature [1] in the Clock activity I came across the desire to show the written clock information (e.g. ten minutes to 10 am) in different languages. To make that easily manageable without reloading translations on run-time I was wondering if there would be a general desire to run activities in different locales independent from the system. One scenario would be that a teacher in a Spanish speaking country would start the Clock activity in the English locale to teach the clock in English. The question is, if starting an activity in a different locale than the system locale that would be an interesting feature in general. Advantages would be that the locale of the system does not change, making experimenting with languages not as disruptive. Would people think that would be a pedagogical interesting feature? Technically, one of doing this would be to set the 'LANG/LANGUAGE' env variable in sugar-activity, reading the config from a system file. That file could be modified in an activity section (e.g. control panel or the activity list view...) diff --git a/bin/sugar-activity b/bin/sugar-activity index abaa091..070a196 100644 --- a/bin/sugar-activity +++ b/bin/sugar-activity @@ -104,6 +104,8 @@ def main(): os.environ['SUGAR_BUNDLE_ID'] = bundle.get_bundle_id() os.environ['SUGAR_BUNDLE_NAME'] = bundle.get_name() os.environ['SUGAR_BUNDLE_VERSION'] = str(bundle.get_activity_version()) +os.environ['LANG'] = 'de_DE' +os.environ['LANGUAGE'] = 'de_DE' # must be done early, some activities set translations globally, SL #3654 locale_path = i18n.get_locale_path(bundle.get_bundle_id()) Regards, Simon [1] http://bugs.sugarlabs.org/ticket/1959 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar PATCH] Proxy feature. Wiki page: http://wiki.sugarlabs.org/go/Features/Proxy_Settings
Hi Ajay,
there are some questions open from the last time this feature was
submitted for review:
http://lists.sugarlabs.org/archive/sugar-devel/2012-August/038917.html
There are two differences to the GNOME 3 design. There is a check box
in the 'Manual' option that says 'Use authentication'. And there is an
option 'Ignored Hosts'. Can you give a bit of background on those, why
you did add those, what issue we have on the XO or discovered does it
solve?
On 02/17/2013 11:28 AM, Ajay Garg wrote:
This patch is to be applied on the master-branch.
Some details of this patch ::
a)
The proxy-settings are stored both in the gconf schema; and dconf
schema.
Can you elaborate why you have chosen to also store into dconf? At one
point Sugar wants to switch to Gsettings. Would that help for that case?
Regards,
Simon
b)
The package gnome-vfs2 is a pre-requisite for this patch to work,
since the settings are (also) stored in the dconf schema.
c)
Also, a slightly unrelated change is the persistence of the values in
the Network control-panel.
Earlier, there was a timeout involved (of 3000 milliseconds), which
would trigger the saving of the values (for eg., Collaboration Server
field was persisted this way).
Now, the values are persisted SYNCHRONOUSLY, when the tick
toolbar-button is clicked (of course, all the changes are undone, if the
user instead decides to Cancel changes).
d)
All the use-cases of the proxy, are working, as per the wiki page
http://wiki.sugarlabs.org/go/Features/Proxy_Settings
Signed-off-by: Ajay Garg a...@activitycentral.com
---
extensions/cpsection/network/view.py | 695 +++--
src/jarabe/controlpanel/gui.py | 2 +
src/jarabe/controlpanel/sectionview.py | 8 +
src/jarabe/main.py | 36 ++
4 files changed, 707 insertions(+), 34 deletions(-)
diff --git a/extensions/cpsection/network/view.py
b/extensions/cpsection/network/view.py
index b360759..99b792b 100644
--- a/extensions/cpsection/network/view.py
+++ b/extensions/cpsection/network/view.py
@@ -16,10 +16,19 @@
from gi.repository import Gtk
from gi.repository import Gdk
+from gi.repository import GConf
from gi.repository import GObject
+from gi.repository import Gio
+from gi.repository import Pango
from gettext import gettext as _
+import os
+import subprocess
+import logging
+
from sugar3.graphics import style
+from sugar3.graphics.alert import Alert
+from sugar3.graphics.icon import Icon
from jarabe.controlpanel.sectionview import SectionView
from jarabe.controlpanel.inlinealert import InlineAlert
@@ -31,6 +40,471 @@ TITLE = _('Network')
_APPLY_TIMEOUT = 3000
+# Please refer ::
+# http://developer.gnome.org/ProxyConfiguration/
+
+GSETTINGS_PROXY = Gio.Settings.new('org.gnome.system.proxy')
+GSETTINGS_PROXY_FTP = Gio.Settings.new('org.gnome.system.proxy.ftp')
+GSETTINGS_PROXY_HTTP = Gio.Settings.new('org.gnome.system.proxy.http')
+GSETTINGS_PROXY_HTTPS = Gio.Settings.new('org.gnome.system.proxy.https')
+GSETTINGS_PROXY_SOCKS = Gio.Settings.new('org.gnome.system.proxy.socks')
+
+
+client = GConf.Client.get_default()
+
+
+class GConfMixin(object):
+Mix-in class for GTK widgets backed by GConf
+def __init__(self, gconf_key, gsettings_dconf, dconf_key, widget=None,
signal='changed'):
+self._gconf_key = gconf_key
+self._gsettings_dconf = gsettings_dconf
+self._dconf_key = dconf_key
+self._notify_id = client.notify_add(gconf_key, self.__gconf_notify_cb,
None)
+initial_value = self._get_gconf_value()
+self._undo_value = initial_value
+self.set_value_from_gconf(initial_value)
+widget = widget or self
+
+def undo(self):
+Revert to original value if modified
+if not self.changed:
+return
+logging.debug('Reverting %r to %r', self._gconf_key, self._undo_value)
+self._set_gconf_value(self._undo_value)
+
+def get_value_for_gconf(self):
+
+Return the current value of the widget in a format suitable for GConf
+
+MUST be implemented by subclasses.
+
+raise NotImplementedError()
+
+def set_value_from_gconf(self, value):
+
+Set the current value of the widget based on a value from GConf
+MUST be implemented by subclasses.
+
+raise NotImplementedError()
+
+def __gconf_notify_cb(self, client, transaction_id_, entry, user_data_):
+new_value = _gconf_value_to_python(entry.value)
+self.set_value_from_gconf(new_value)
+
+def _commit(self, widget):
+new_value = self.get_value_for_gconf()
+logging.debug('Setting %r to %r', self._gconf_key, new_value)
+
+self._set_gconf_value(new_value)
+
+def _set_gconf_value(self, new_value):
+gconf_type = client.get(self._gconf_key).type
+if gconf_type == GConf.ValueType.STRING:
+client.set_string(self._gconf_key, new_value)
+
Re: [Sugar-devel] [PATCH] Journal toolbar: add tooltip to favorite filter
Pushed to master after review from Manuel.
158f4384d1f3423a6c2063723434f4f331796f81
Simon
On 02/19/2013 10:16 AM, Simon Schampijer wrote:
From: Simon Schampijer si...@laptop.org
This patch adds the tooltip 'Favorite entries' to the favorite filter
button in the Journal toolbar. The button is a ToggleToolButton and
with the recent change in the toolkit-gtk3
63b8e87b1a99a854e9adbb1579b1e05244d2dc4
we do hide the tooltip when the button is clicked or touched.
This adds a new string, therefore this patch is only intended for
master. The addition and string has been discussed with Gary and Manuel.
Signed-off-by: Simon Schampijer si...@laptop.org
---
src/jarabe/journal/journaltoolbox.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/jarabe/journal/journaltoolbox.py
b/src/jarabe/journal/journaltoolbox.py
index c7ee73a..69ff777 100644
--- a/src/jarabe/journal/journaltoolbox.py
+++ b/src/jarabe/journal/journaltoolbox.py
@@ -89,6 +89,7 @@ class MainToolbox(ToolbarBox):
self._add_widget(self.search_entry, expand=True)
self._favorite_button = ToggleToolButton('emblem-favorite')
+self._favorite_button.set_tooltip(_('Favorite entries'))
self._favorite_button.connect('toggled',
self.__favorite_button_toggled_cb)
self.toolbar.insert(self._favorite_button, -1)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.98.5
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.98.5.tar.bz2 == News == * Release 0.98.5 (Simon Schampijer) * ToggleToolbutton: do hide the tooltip when clicked or touched (Simon Schampijer) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Fix subtoolbars height - SL #4019 (Manuel Quiñones) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.98.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.98.1.tar.bz2 == News == * Release 0.98.1 (Simon Schampijer) * ToggleToolbutton: do hide the tooltip when clicked or touched (Simon Schampijer) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a low-cost tablet for an NGO in India
On 02/11/2013 04:18 PM, badday wrote: Hi there, first of all, this is my first post to this mailing list, so a warm welcome to everybody. I am currently working in an NGO in India and want to use Sugar as a tool of education. Therefore I bought a low-cost tablet, rooted it and installed Fedora ARM in a chroot environment together with Sugar. Now all that works and via VNC I have the graphical interface running smoothly including all activities (at least I did not find any not working). If there is a general interest in this project, I will post a detailed way to do that. However, the reason I started to get some interest in this project was an article on MIT Technology Review ( http://www.technologyreview.com/news/506466/given-tablets-but-no-teachers-ethiopian-children-teach-themselves/ ) describing the great success of using tablets in Ethiopia. I now face some struggle where to find all the software and material used in that project as in the sugar labs activity website I can hardly find what I was looking for. It would also be nice if somebody could tell me about the localization process regarding Hindi as I could not find too much on the web about it. I think this is one app used in this project: http://dev.laptop.org/git/users/cjb/android-matching/ Chris can probably say more about this. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 02/01/2013 02:08 PM, Gonzalo Odiard wrote: With technologies like HTML5 and EPUB3, the lines between a book and a activity start to blur. (EPUB2 prohibited the use of javascript, but is allowed in EPUB3) A nice example of a book with dynamic content is http://natureofcode.com/book/chapter-1-vectors/ The technology behind will be the same, we need think about what is better in every case, how can we improve the tools to create the books or activities, and how the users can improve, comment, and share/communicate, changing from a read-only experience to a read-write use, like in a wiki. Gonzalo The last sentence is the essential point here: 'create' and 'consume'. I especially put 'create' here first. One of the most important paradigms of Sugar :) Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
Hey Daniel, thanks for the writeup! On 01/26/2013 03:27 PM, Daniel Narvaez wrote: Hello, the desire to be able to write activities using html has been expressed several times by developers. We have seen several approaches but there is not much support for it in the core platform yet. I and Simon have been trying to figure out how to best integrate this with the existing platform. Bits of code can be pulled from the sugar-build html branch. We don't have much of a demo yet, but I think the basic pieces of the infrastucture are becoming clear, so I thought it would be good to try and summarize them in an email to the list. 1 sugar-toolkit-html * A new module. * Independent from the native sugar API, so that html activities might be run on other platforms, like Android or even inside a web browser. * HTML equivalents of the gtk widgets. For example Toolbar and Palette. * Per-platform (sugar-os, android, web-browser...) implementations of the same javascript interface to the sugar services. For example it might provide a datastore.save(metadata, file) method or an icon.get_with_colors(xo_colors) 2 sugar-http-server * A sugar-os internal component. Other platforms might implement the html/javascript API without even using an http server. * Implemented by the sugar-toolkit-html module but managed by the sugar shell. * Serves the activity bundles content with something like http://localhost:8000/org.sugarlabs.HTMLDemo/index.html. * Exposes the sugar services API with json methods like http://localhost:8000/org.sugarlabs.HTMLDemo/datastore/save As we talked about today, I was looking at node-dbus [1] in order to talk to the DS over dbus from java script. Looks straight forward. I installed the module (npm install node-dbus) and did a quick example based on the test in the repo to listen on the 'Created' signal from the DS. Works fine. Of course, if we use nodejs we have to handle the modules packaging as nodejs itself is rather limited and a most of the functionality is in the modules. Cheers, Simon [1] https://npmjs.org/package/node-dbus test-ds-listener.js Description: application/javascript ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HTML activities
On 01/28/2013 06:37 PM, Peter Robinson wrote: On Mon, Jan 28, 2013 at 5:30 PM, Simon Schampijer si...@schampijer.de wrote: Hey Daniel, thanks for the writeup! On 01/26/2013 03:27 PM, Daniel Narvaez wrote: Hello, the desire to be able to write activities using html has been expressed several times by developers. We have seen several approaches but there is not much support for it in the core platform yet. I and Simon have been trying to figure out how to best integrate this with the existing platform. Bits of code can be pulled from the sugar-build html branch. We don't have much of a demo yet, but I think the basic pieces of the infrastucture are becoming clear, so I thought it would be good to try and summarize them in an email to the list. 1 sugar-toolkit-html * A new module. * Independent from the native sugar API, so that html activities might be run on other platforms, like Android or even inside a web browser. * HTML equivalents of the gtk widgets. For example Toolbar and Palette. * Per-platform (sugar-os, android, web-browser...) implementations of the same javascript interface to the sugar services. For example it might provide a datastore.save(metadata, file) method or an icon.get_with_colors(xo_colors) 2 sugar-http-server * A sugar-os internal component. Other platforms might implement the html/javascript API without even using an http server. * Implemented by the sugar-toolkit-html module but managed by the sugar shell. * Serves the activity bundles content with something like http://localhost:8000/org.sugarlabs.HTMLDemo/index.html. * Exposes the sugar services API with json methods like http://localhost:8000/org.sugarlabs.HTMLDemo/datastore/save As we talked about today, I was looking at node-dbus [1] in order to talk to the DS over dbus from java script. Looks straight forward. I installed the module (npm install node-dbus) and did a quick example based on the test in the repo to listen on the 'Created' signal from the DS. Works fine. I added as well an example for dbus methods, you can delete DS entries now :) http://dev.laptop.org/~erikos/html-activity/ Of course, if we use nodejs we have to handle the modules packaging as nodejs itself is rather limited and a most of the functionality is in the modules. There's 100s of them currently being packaged for Fedora, there's about 50 in F-18 already, I think a lot more (maybe it just seems that way from the build reports) in F-19. yum list nodejs* will give you more details. Perfect, that is good news. This reminds me that I should switch to F18 now...:) Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3 2/2] Add missing dependencies
On 01/28/2013 07:16 PM, Daniel Narvaez wrote: From: Daniel Narvaez dwnarv...@gmail.com I'm not sure how it works with GNU ld, but it breaks with ld gold and it's clearly wrong anyway. --- configure.ac | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cb221a8..fefb8e8 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,8 @@ AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR(could not find Python headers)]) AC_PATH_PROG(PYGTK_CODEGEN, pygtk-codegen-2.0, no) -PKG_CHECK_MODULES(EXT, gtk+-3.0 gdk-3.0 gdk-pixbuf-2.0 sm ice alsa librsvg-2.0) +PKG_CHECK_MODULES(EXT, gtk+-3.0 gdk-3.0 gdk-pixbuf-2.0 sm ice alsa + librsvg-2.0 xfixes xi x11) PYGTK_DEFSDIR=`$PKG_CONFIG --variable=defsdir pygtk-2.0` AC_SUBST(PYGTK_DEFSDIR) Both patches look good, please push. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.98.4
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.98.4.tar.bz2 == News == * Release 0.98.4 (Simon Schampijer) * palettemenuwidget: Ensure the widget is realized before popping it up, SL #4388 (Carlos Garnacho) * Adapt to icon changes - SL #3569 (Manuel Quiñones) * Add testcase for CellRendererProgress - SL #1395 (Manuel Quiñones) * Truncate labels on Palettes SL #4164 (Manuel Kaufmann) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-artwork-0.98.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.98.3.tar.bz2 == News == * Release 0.98.3 (Simon Schampijer) * Add icon entry-cancel for usage inside entries - SL #3569 (Manuel Quiñones) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F18.. go sugar-build, go!
On 01/18/2013 03:56 PM, Manuel Quiñones wrote: I installed Fedora 18 last night, and I have to say I like sugar-build more and more. With just this steps in a clean F18 you get Sugar running and ready to hack each part of it: Kudos Daniel Narvaez! sudo yum install git git clone git://git.sugarlabs.org/sugar-build/sugar-build cd sugar-build make build make run Yes, fantastic work Daniel! I started to have a look at the test suite lately and I am impressed. It is getting better and better... Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Start the activity when the treeview row is activated
Thanks Daniel!
Tested to not introduce regressions for mouse usage. And tested with
your 'make check' test, impressive work, I was able to detect an error
with stopping my Terminal and could pinpoint back using the logs in
logs/check.log. Go sugar-build go!
Pushed as: 0bf9d535f55ed4b93e951de0fb980196cff84815
Cheers,
Simon
On 12/03/2012 01:59 AM, Daniel Narvaez wrote:
From: Daniel Narvaez dwnarv...@gmail.com
This makes the activate accessible action work, which is useful
both for the UI tests and accessibility.
It shouldn't interfer with the normal mouse behavior because gtk
only calls row_activated on a double click.
---
src/jarabe/desktop/activitieslist.py |8
1 file changed, 8 insertions(+)
diff --git a/src/jarabe/desktop/activitieslist.py
b/src/jarabe/desktop/activitieslist.py
index 6594ee9..738a54f 100644
--- a/src/jarabe/desktop/activitieslist.py
+++ b/src/jarabe/desktop/activitieslist.py
@@ -80,6 +80,8 @@ class ActivitiesTreeView(Gtk.TreeView):
column.add_attribute(cell_icon, 'file-name', ListModel.COLUMN_ICON)
self.append_column(column)
+self._icon_column = column
+
cell_text = Gtk.CellRendererText()
cell_text.props.ellipsize = Pango.EllipsizeMode.MIDDLE
cell_text.props.ellipsize_set = True
@@ -143,6 +145,9 @@ class ActivitiesTreeView(Gtk.TreeView):
not row[ListModel.COLUMN_FAVORITE])
def __icon_clicked_cb(self, cell, path):
+self._start_activity(path)
+
+def _start_activity(self, path):
row = self.get_model()[path]
registry = bundleregistry.get_registry()
@@ -165,6 +170,9 @@ class ActivitiesTreeView(Gtk.TreeView):
title = normalize_string(title.decode('utf-8'))
return title is not None and title.find(self._query) -1
+def do_row_activated(self, path, column):
+if column == self._icon_column:
+self._start_activity(path)
class ListModel(Gtk.TreeModelSort):
__gtype_name__ = 'SugarListModel'
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Drop sugar-emulator
Hi Daniel, the new module is this one [1] I presume. We currently have the emulator packaged for Fedora qit a Desktop file so there is an easy way to launch Sugar from within another Desktop. I guess this would then be a separate package based on sugar-runner. Regards, Simon [1] http://git.sugarlabs.org/sugar-runner [2] http://koji.fedoraproject.org/koji/rpminfo?rpmID=3585350 On 12/16/2012 12:24 AM, Daniel Narvaez wrote: From: Daniel Narvaez dwnarv...@gmail.com Replaced by the sugar-runner module. Rationale: * sugar-runner is similar in concept to sugar-emulator but it provides a better user experience. It runs also from a text console (into a standard X server). It works around Xephyr issues like international keyboards and multiple outputs. It tries to work out of the box everywhere, for example by offering to tweak Xwrapper.config where necessary. * sugar-runner is better tested with recent sugar code and recent distributions. It also integrates with sugar-build. * A separate module make sense here because most users will never run this code. It's largely a collection of hacks which are not necessary when running as a normal desktop environment. Why now: * We are starting to use GSettings, which requires to setup the xdg directories to avoid conflicts with GNOME. Thus we would require to make changes to sugar-emulator to setup these properly. Maintaining two separate implementation of basically the same thing is a waste of resources. * We are at the beginning of the cycle, the best time for potentially disruptive changes. --- README |1 - bin/Makefile.am|1 - bin/sugar-emulator | 14 --- configure.ac |1 - data/Makefile.am |3 - data/sugar-emulator.desktop.in | 10 --- src/jarabe/model/session.py| 15 +--- src/jarabe/model/sound.py | 10 +-- src/jarabe/util/Makefile.am|1 - src/jarabe/util/emulator.py| 194 src/jarabe/view/keyhandler.py |5 -- 11 files changed, 5 insertions(+), 250 deletions(-) delete mode 100755 bin/sugar-emulator delete mode 100644 data/sugar-emulator.desktop.in delete mode 100644 src/jarabe/util/emulator.py diff --git a/README b/README index 1f89810..cfc196e 100644 --- a/README +++ b/README @@ -38,7 +38,6 @@ Alt+r Rotate the screen Alt+o Toggle overlay visibility Alt+= Open the developer console Alt+0 Open the developer console -Alt+q Quit the emulator Ctrl+s Activate sketch mode in chat diff --git a/bin/Makefile.am b/bin/Makefile.am index cb671da..bd38323 100644 --- a/bin/Makefile.am +++ b/bin/Makefile.am @@ -1,6 +1,5 @@ python_scripts = \ sugar-control-panel \ - sugar-emulator \ sugar-install-bundle\ sugar-launch diff --git a/bin/sugar-emulator b/bin/sugar-emulator deleted file mode 100755 index 308aac7..000 --- a/bin/sugar-emulator +++ /dev/null @@ -1,14 +0,0 @@ -#!/bin/sh - -if [ $(id -u) -eq 0 -o $(id -ru) -eq 0 ] ; then - echo Refusing to run as root. - exit 3 -fi - -# Source debug definitions -if [ -f ~/.sugar/debug ]; then -. ~/.sugar/debug -fi - -# Start emulator -python -c import sys; from jarabe.util import emulator; sys.argv[0]='$0'; emulator.main() $@ diff --git a/configure.ac b/configure.ac index 137e53a..9eae29e 100644 --- a/configure.ac +++ b/configure.ac @@ -48,7 +48,6 @@ bin/Makefile bin/sugar data/icons/Makefile data/Makefile -data/sugar-emulator.desktop extensions/cpsection/aboutcomputer/Makefile extensions/cpsection/aboutme/Makefile extensions/cpsection/datetime/Makefile diff --git a/data/Makefile.am b/data/Makefile.am index 6a62d23..39bdb35 100644 --- a/data/Makefile.am +++ b/data/Makefile.am @@ -23,9 +23,6 @@ GTKRC_FILES = \ xsessionsdir = $(datadir)/xsessions xsessions_DATA = sugar.desktop -applicationsdir = $(datadir)/applications -applications_DATA = sugar-emulator.desktop - mime_xml_in_files = sugar.xml.in mime_xml_files = $(mime_xml_in_files:.xml.in=.xml) @INTLTOOL_XML_RULE@ diff --git a/data/sugar-emulator.desktop.in b/data/sugar-emulator.desktop.in deleted file mode 100644 index 6247bd7..000 --- a/data/sugar-emulator.desktop.in +++ /dev/null @@ -1,10 +0,0 @@ -[Desktop Entry] -Encoding=UTF-8 -Name=Sugar -GenericName=Sugar Emulator -Comment=The emulator for the Sugar Desktop Environment -Exec=@prefix@/bin/sugar-emulator -Terminal=false -Type=Application -Icon=sugar-xo -Categories=Education;Teaching; diff --git a/src/jarabe/model/session.py b/src/jarabe/model/session.py index a5cd4a4..a708633 100644 --- a/src/jarabe/model/session.py +++ b/src/jarabe/model/session.py @@ -54,9 +54,7 @@ class SessionManager(session.SessionManager): self.initiate_shutdown() def shutdown_completed(self): -if env.is_emulator(): -self._close_emulator() -elif self._logout_mode !=
Re: [Sugar-devel] Stepping down as Sugar maintainer
On 01/06/2013 09:19 PM, Sascha Silbe wrote: Hello everyone, I am stepping down as maintainer for Sugar and some related services. This is mostly due to lack of time, but even if I had more of that to spare for Sugar, the way I work is sufficiently different from that of the most active contributors that I'd do more harm than good. For some time now, my business didn't have any Sugar-related contract, so as an entrepreneur I can't afford investing time, effort or money into Sugar. My spare time is pretty limited these days and I tend to spend what's left of it on reflecting, relaxing and some minor non-Sugar projects, so even as a volunteer I can't spend much on Sugar. However, I will continue using an XO as my primary laptop, so I may contribute to some of the lower-level parts of the stack (powerd, kernel, etc.) from time to time. I'll also continue working on some data store stuff (gdatastore, datastore-fuse, etc.), but strictly outside of Sugar as I wouldn't be able to hold your pace. It's been exciting times working with you and I've learned a lot. But now it's time to move on and let younger folks take over. That seems to have worked fine the past few months; hopefully it'll work out in the long run as well. This side of the ocean, my current customers have come to appreciate the way I work. And taking Sundays off for relaxing and reflecting, I'm much more at ease. So everyone is better off now. So long and thanks for all the fish, Sascha Hi Sascha, Thanks for letting us know about your future availability. That is an important part to make sure that other people can fill in the gaps. Thanks for your contributions in the last years and good luck with your future projects. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-datastore] Port to gi and gtk3 toolkit
On 11/13/2012 03:57 PM, Simon Schampijer wrote: Thanks Daniel for those patches! Like discussed on irc, I pushed the first two. The datastore port I moved to the next cycle. We can branch early and land it. Cheers, Simon Branched off and pushed, thanks. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
