Re: [Sugar-devel] #2963 UNSP: Sugar telepathy code does not take into account presence status of buddies
On Mon, Jul 18, 2011 at 03:00:54AM -0700, Sameer Verma wrote: On Sat, Jul 16, 2011 at 6:24 AM, Aleksey Lim alsr...@activitycentral.org wrote: On Sat, Jul 16, 2011 at 01:34:21PM +0100, Daniel Drake wrote: On 16 July 2011 12:44, Aleksey Lim alsr...@activitycentral.org wrote: Since jabber.sl.o is targeiting for dev use cases and the fact that everyday resetting (/usr/share/ejjaberd) ejabberd data is not enough to prevent kernel killing apps due to lack of memory, I installed prosody for jabber.sl.o. Both events were announced on sugar-devel@. I must have missed the announcements then. Apologies. (I still can't find them after searching the archives) hmm, it seems to be in school server related threads and not all posts are on ML, sorry then. Though, in my mind jabber.sl.o was in semi-productoin state (after not working for a couple of weeks and every day crashes) and I wasn't thinking about announcing its development process except urgent maitaining cases. So, it is a good reason to start doing that. I am in full support of experimenting with alternative jabber implementations, I think that's great and am excited by your work. I just don't think you should do it so quietly, uncollaboratively, and on the server that sugar connects to by default. I also think that your arguments against ejabberd are shallow and uninformed - suggesting that it can't handle thousands of users just shows ignorance in the face of the large ejabberd servers that are out their in production. you missed my words about sugar server workflow (it is exactly targeting to up to 1K users by design), and that amount of users is ok for jabber.sl.o as well (we don't hanve more than 30-40 online users there). I know it can be hard to get to grips with the unconventional design, but time and code investment in solving the issues that you are facing with ejabberd would be a much less intrusive fix for our existing users. (not that I want to discourage experimentation with alternative servers which of course may turn out to be better in the long run. it may even be less mind-boggling, which would be great.) once more, prosody related work started exactly for limited usecase (1K users and as less maintaning as possible, both reasons ok for current jabber.sl.o), and I don't see any reasons why not having tools (that are work best-of-all) for one particular use case and having several of them for 1K (prosody) and 1K (ejabberd). I don't see the point in having two different server implementations for two different use cases, where the only difference is volume. If ejabberd works for 1K, it should be a good candidate for 1K as well. I have ejabberd running on a XO-1 via XS 0.6 (running on a class 6 SD card) and for a small pool of users (25 to 30) it works just fine. Well, actually I'm not sure what we are arguing about. Though, I personally didn't had such intention, ie, I didn't have intention to say Lets, ie, every developer/supporter switch to Prosody from ejabberd or Lets, ie, every developer/supporter support also Prosody, just said that I see benefits for Prosody against ejabberd for me (see below)). The point is simple, if people use/do something, they see benefits for that (people who do the same in different way, see benefits for that as well). My own benefits for using Prosody are: * being not familiar w/ lua or erlang and not familiar w/ codebase of Prosody and ejjaberd, I found that: * learning the code of Prosody is easier than ejjaberd * for sugar server (up to 1K scenario), Prosody is more preferable (regardless sugar support): * Lua/C vs. erlang * sugar server scenario assumes as less as possible of any maintaning needs; just an example, having fedora packages prepared by olpc people and instructions from olpc wiki + 0.9x code, I got on jabber.sl.o the situation when kernel started killing process on 6G system, just installing Prosody and adding jabber setting from ejjaberd olpc wiki, for the same amount of time it took 1G (thats not an indicative example but just a glimpse of how two servers treating free resources); before intensive 0.9x usage, I had to reset ejabberd (remove all users) because having 2K of fake users tended ejabberd to eat 100+% of cpu and 4G of memory, at the same time current Prosody (w/ the same 0.9x clients) took 300M and much less cpu for 2 weeks; btw about how many server eats, it depends on the use case, ie, right after start, Prosody take 5M :) So, for me Prosody shows that it much humble (in potential) for consuming resources and more bullet proof for maintaning to start thinking about using it, thus I did it. * for now, I don't see critical problems w/ adding sugar support to Prosody - it took a week to implement initial support (that is running on jabber right now, if you are getting problem like dups in F1 view, swee
[Sugar-devel] Bare JIDs on jabber.sugarlabs.org
Hi all, Please help to figure out sugar collaboration related issues. There are several buddies on jabber.sugarlabs.org that have no nicks (you can see them if your server in My Settings/Network is jabber.sugarlabs.org) associated with them on the server. If you are using jabber.sl.o, and your JID is from the following list, what your sugar version? d2d0c6ad6fb3590888f265aacd9a2f858222a...@jabber.sugarlabs.org 2c2210870152c0424cfa1962f007e4ccd0844...@jabber.sugarlabs.org 7663e716f145bbf41c731920a7a9e144a9bd9...@jabber.sugarlabs.org To know what your JID is: * remove # symbol from debug file[1] * restart sugar * open ~/.sugar/default/logs/telepathy-gabble.log file * look for using specified value for account: line [1] http://wiki.sugarlabs.org/go/BugSquad/Get_Logs#Enabling_Sugar_debug_logging -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bare JIDs on jabber.sugarlabs.org
On Mon, Jul 18, 2011 at 05:40:14PM +0200, Sascha Silbe wrote: Excerpts from Aleksey Lim's message of Mon Jul 18 16:28:00 +0200 2011: If you are using jabber.sl.o, and your JID is from the following list, what your sugar version? d2d0c6ad6fb3590888f265aacd9a2f858222a...@jabber.sugarlabs.org 2c2210870152c0424cfa1962f007e4ccd0844...@jabber.sugarlabs.org 7663e716f145bbf41c731920a7a9e144a9bd9...@jabber.sugarlabs.org Have you tried contacting them via Jabber? Chances are rather slim they a) read sugar-devel, b) find your subject interesting and c) are willing to do the work of figuring our what their JID is. I've emailed exactly because I didn't have luck w/ pinggin them via jabber and there is an issue w/ gabble crashing on restoring shared objects in 0.9x (#2973). So, thats my last resort :) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Update of heart icon for denoting pulse
On Wed, Aug 03, 2011 at 01:28:05AM -0300, Manuel Quiñones wrote: This patch adds two curved lines on the sides of the heart icon, like parentheses, for denoting pulse. Signed-off-by: Manuel Quiñones ma...@laptop.org --- icons/heart.svg | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) thanks, pushed -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] for today's meeting: certificate program proposal
On Fri, Aug 05, 2011 at 09:13:53AM -0400, Walter Bender wrote: Following up on a thread begun in mid July (http://lists.sugarlabs.org/archive/iaep/2011-July/013736.html) I would like to discuss the following proposal this morning: Sugar Labs will award certificates to developers to acknowledge and celebrate their contributions to the Sugar Learning Platform. Several certificates will be made available: Sugar X Contributor; Sugar Activity Developer; and Sugar Core Developer. The Sugar X Contributor certificate will be given to an individual who over the course of a sustained effort of at least 6 months contributes to some Sugar community team, e.g., Sugar Translation Contributor. (The teams are listed on the wiki). The specific criteria for certification will be determined by the team coordinators, but in general, it would involve a repeated effort on behalf of the team's goals at a high level of quality (e.g., of quality sufficient to be incorportated into our offerings). The Sugar Activity Developer certificate will be given to an individual who develops at least one Sugar activity that is subsequently posted on the Sugar activity portal and be of sufficient quality to be approved for public release. The activity must also include internationalization, including the submission of a POT file to the Translation Team, and documentation, including the creation of a page in the wiki under the Activity category. As will the Contributor certificates, sign off will be made by the associated team coordinators, in this case the Activity team. The Sugar Core Developer certificate will be given to an individual who over the course of one year makes significant contributions to the Sugar core libraries, e.g., sugar-toolkit or sugar. Sign off will be made by the Developer team coordinators. s/Sugar Core Developer/Sugar Platform Developer/ imho, thats really bad way to assume that sugar software might be only activities (made mostly in decentrilized manner, ie, w/o obligation to support all glucose/fructose bureaucratic procedures) and core software (w/ obligation to support all glucose/fructose bureaucratic procedures). Sugar related software might not only activities and glucose/fructose (or software that might be sometime included to glucose/fructose). In other words, it is about having low borders for possible contributors that can't/wan't follow core bureaucratic procedures but create something that are not sugar activities. (in that case I'm also -1 for having Code Developer and Platform Developer at the same time because separating code and non-core Platform developers is also about high borders). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Sugar Commander for review, creates Journal entry
On Sat, Aug 06, 2011 at 08:24:06AM -0500, James Simmons wrote: I have a new version of Sugar Commander which leaves a Journal entry behind. In addition to solving the problem that Tony Forster reported, it also makes a log of the activity done by the child (adding files to the Journal, updating metadata, resizing images, deleting Journal entries) and puts this log in the Description. This log is appended to whatever is already there, so if the child makes a Description the first time he runs the Activity the log will go under that, and if the Journal entry is resumed the new log will be appended to the existing log. In more or less recent 0.92, it works fine for me (doesn't fail and can't reproduce #3013) http://dl.dropbox.com/u/8919415/SugarCommander-8.xo in that case, what do you think about having stability levels for activities, ie, if people prefer stable versions, they will use them all time. But, developer is free to relese development/testing versions as frequently as he prefer to let some users a chance to test them (by following the same launching scenario if only addition is explicitly allowing run non-stable versions). I'd like some feedback before I post to ASLO. I think the Journal entry I create is at least somewhat useful. For the record, I still think stateless Activities should be possible in future versions of Sugar. +1 sugar should not restrict doers creating such activities (especially when it makes sence like in a la Journal activities). In any other cases doers might create statefull activities (but sugar is not perfect for that case right now, eg, we have resume-by-default but we have the Home view when users can start spaming journal by new jobjects). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Sugar Commander for review, creates Journal entry
On Sat, Aug 06, 2011 at 11:10:22AM -0500, James Simmons wrote: Aleksey, ... Did you check out the log entry in the Journal? yup, it added a log entry to the SugarCommander object's description Did it look useful to you? no comments, I guess I'm not from the targeted users group of this activity... just checked for errors in my env -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 07, 2011 at 08:04:47AM +0500, Sebastian Silva wrote: In general I'd propose avoiding 1.0 as long as we haven't implemented the full HIG. I think 1.0 tells users we are comfortable with a finished, generally not buggy product and should not be used for signifying a technology change, which in its first iteration is bound to not be perfect. +1, if during the process of moving to GTK3 sugar will be matured in all directions that it will be ready for 1.0, then switch to 1.0 is obvious. But not sure if it is a good idea to mix switching to gtk3 and trying to be 1.0 (as a well matured platform) at the same time. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 07, 2011 at 10:14:57AM +0100, Daniel Drake wrote: On Sun, Aug 7, 2011 at 9:53 AM, Aleksey Lim alsr...@activitycentral.org wrote: +1, if during the process of moving to GTK3 sugar will be matured in all directions that it will be ready for 1.0, then switch to 1.0 is obvious. But not sure if it is a good idea to mix switching to gtk3 and trying to be 1.0 (as a well matured platform) at the same time. 1.0 doesn't have to indicate mature product - it could just indicate new underlying technologies - but you're right in that some people could/would interpret it with the mature product meaning. It will be interesting to see what happens with Linux 3.0. This major version change means far less than ours would (they didn't change *anything* from normal release cycles), and so far it has not caused any misunderstanding/turmoil, as far as I can see. well, it might make sense but see the following paragraph.. But this view does raise a few questions: Do you think Sugar would ever be mature? To me, its one of those things that will always have major areas for improvement around the corner. In the case of the HIG, have we seen much movement on compliance in the last 2 years? Would the design team even regard it as something that should be aspired to for a mature release? (I suspect it's quite out of date, as Sugar is a moving target) It obviously depends on how someone is seeing sugar. * If sugar is just a python based window manager with some library toolkit to code python applications for this shell, then sugar is pretty ready to do Linux-3.0 shift (and having bunch of very cool ideas to make horizons wider, e.g., web based approach, integration with other DEs, etc.) * For me sugar is more a social phenomenon when things like python based window manager are just tools to support this phenomenon. The sugar phenomenon for me is an ecosystem for doing (e.g., not only using). One of aspects of such doing (which is closer to me) is creating/changing software (ie, not only creating python based applications for particular python based window manager). And I don't see several (major for me) features implemented: - decent sharing/distribution method of software peaces Once more, it is not about well skilled devs who do it for years and have theirs software well packaged for all major distros. It is about sharing/distributing not-well-matured/one-day-hack/etc software that was done by not skilled devs (ie, sugar doers) as a part of theirs learning while doing process. It is also about that current .xo model is *too* ineffective in several ways: - lack of dependencies when activity devs need to bundle (with all related minuses) or rely on particular sugar distributor that it will include some software (initiatives like Sugar Platform are fixes only in short time period) - it supports only python (or script based in general) software taking into account the lack of dependencies, ie, if activity is ruby based, there is no any guarantee that it will run on sugar box as-is - no official sdk/toolkit to support non-python software/activities but there is what Etoys did, ie, using low level dbus access but no way to create sugar looking UI library, but there is Polyol library that is vala based and can be used (and used in GCompris and Tuxpaint) for wrapping all dbus internals to high level API + gtk UI toolkit instead of python based sugar-toolkit - another way to avoid only-python doing, is reusing web technologies like what was done in Gnome3 and KDE4 eg, WebSDK (or any other SDKs) are the things that need to be introduced in Sugar-1.0 I just mentioned the major points for me, maybe other people have different ones. So, sugar is not ready for 1.0 for me. Of course switching to gtk3 will make it closer but thats not enough. In the end it is only a number, and there isn't anything wrong with sticking with the current scheme, even if the discussion did go in the 1.0 direction last time - see http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/25094/focus=25156 - but how would the existing scheme work? What release comes after 0.98? 0.100? Then 0.102? Well, it is a matter of taste... For me 1.0 should have at least initial implementations for what , at least, I mentioned in previous paragraph. For me having 0.102 sounds better then 1.0 w/o features I talked about. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Attn maintainers Re:Pootle and POT files
On Sun, Aug 07, 2011 at 10:40:28PM -0400, Chris Leonard wrote: All, There is a widely held belief that Pootle takes care of updating the POT files in git and updating the Templates on Poolte. This is not entirely accurate. The fact is that there is nothing in the Pootle code itself that does this automatically. This automagical updating used to occur, but it was handled by scripts that Sayamindu had created to make it occur. These scripts have not been functioning for some time, probably since the last Pootle upgrade. We will look at re-establishing this functionality in conjunction with an upcoming upgrade of the Pootle version, but for now, if a developer makes UI string changes it is necessary for them to regenerate the POT file and commit it to git and then notify the Translation Team (me) to pull the changes up to Pootle with a Template Upgrade from VCS where they can then be distributed to languages with an Update from templates. That might be too messy.. ie, if pootle was handling this sort of things in auto mode, then, for sometime, all activity devs need to take care on theirs own, then pootle will back to processing in auto mode.. It sounds more problematically especially for honey (fructose is more centralized but even there we might have problems with in-time .pot updates). What about handling these .pot updates out-of-pootle and do not bother activity devs? If you give me a list of repos (I guess some kind of pootle config), I can setup regular .pot updates for git repos. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] New doc.sugarlabs.org domain
Hi all, We had api.sugarlabs.org for (looks like) glucose API documentation, but it is really useful to host any sugar related autogenerated documentation as well. So, there is doc.sugarlabs.org accessible (the old api.sl.o is being redirected to doc.sl.o). Please, update your links. If there is a need to host sugar related documentation, create a ticked on bugs.sugarlabs.org for doc.sugarlabs.org component. All SL resources that have a bar with SL links are in the process of updating. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] i18n improvement experiment
On Thu, Aug 11, 2011 at 01:55:57AM -0400, Chris Leonard wrote: Dear Activity developers, I'm not 100% sure if this will work, but I'd like to try it out with one activity to test it. Generally, the first line of any POT file is the Actviity name, which is typically picked up from the activity.info file (specifically activity/activity.info:2), although it sometimes also appears elsewhere in the activity's code . e.g. #: activity/activity.info:2 exporthtml.py:96 PortfolioActivity.py:295 msgid Portfolio msgstr #: activity/activity.info:2 msgid Calculate msgstr What I am wondering is if it is possible to insert a TRANS comment in the activity.info file that would contain the link to the Activity's homepage on the Sugar Labs wiki. #. TRANS: http://wiki.sugarlabs.org/go/Activities/Portfolio #. TRANS: http://wiki.sugarlabs.org/go/Activities/Calculate What I am basically getting at is a way to associating the wiki homepage information with the Actvity name string in the PO file in order to give localizers additional textual context to review before doing the localization. In an ideal world, localizers would play around with the actifvity itself before localizing to get context, but until we get a better SOAS version available, we have to accept that not all localizers will have an XO laptop at hand or be Linux gurus pulling Sugar packages from their distros. As an example of a truly informative activity.info file, see the activity.info file of the TamTamSuite: http://git.sugarlabs.org/tamtam/tamtam/blobs/master/activity/activity.info Walter, you may want to do something like this if/when you roll multiple TurtleArt-related components into one PO file the way Aleksey did with TamTamSuite. I don't see the homepage field described on the page below, but it doesn't seem to break anything, but I wouldn't know how to parse it int oa translators' comment. http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles If anyone can describe a better way of accomplishing the same goal, I would love to hear about it, otherwise, I would like to collaborate with an activty developer to experiment with attempting to insert a developer's comment for translators into an acitvity.info file to see if we can provide an enhanced reference link in the PO file for localizers. Testing to include making hte edits, regenerating the POT, pulling to Poolte, refreshing langs in Pootle and testing rebuilt activity to make sure this insertion doesn't have unintended side-effects. Any volunteers? If we can make this work, I'd like to make this an i18n best practice for activity.info files. The first line in .pot files is being generated by setup.py (activitybundler.py) and will be regenerated by pootle's script (that's doing the same), ie, it can be improved to add home page. The problem is that existed activity.info spec doesn't have home page info. The format that was used for TamTam is a new sweets recipe specification [1] that extends currnet one to make it useful in Sugar Packaging Management System (sweets). In any case, we can ask activity developers to add homepage key to current acitvity.info files. And, like with license key (still in progress), ASLO can check upoaded activities for that key to be sure that it exists. So, we can speed up adopting this key by activity developers and improve i18n. [1] http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] i18n improvement experiment
On Thu, Aug 11, 2011 at 08:11:08AM -0400, Walter Bender wrote: On Thu, Aug 11, 2011 at 7:59 AM, Aleksey Lim alsr...@activitycentral.orgwrote: On Thu, Aug 11, 2011 at 01:55:57AM -0400, Chris Leonard wrote: Dear Activity developers, I'm not 100% sure if this will work, but I'd like to try it out with one activity to test it. Generally, the first line of any POT file is the Actviity name, which is typically picked up from the activity.info file (specifically activity/activity.info:2), although it sometimes also appears elsewhere in the activity's code . e.g. #: activity/activity.info:2 exporthtml.py:96 PortfolioActivity.py:295 msgid Portfolio msgstr #: activity/activity.info:2 msgid Calculate msgstr What I am wondering is if it is possible to insert a TRANS comment in the activity.info file that would contain the link to the Activity's homepage on the Sugar Labs wiki. #. TRANS: http://wiki.sugarlabs.org/go/Activities/Portfolio #. TRANS: http://wiki.sugarlabs.org/go/Activities/Calculate What I am basically getting at is a way to associating the wiki homepage information with the Actvity name string in the PO file in order to give localizers additional textual context to review before doing the localization. In an ideal world, localizers would play around with the actifvity itself before localizing to get context, but until we get a better SOAS version available, we have to accept that not all localizers will have an XO laptop at hand or be Linux gurus pulling Sugar packages from their distros. As an example of a truly informative activity.info file, see the activity.info file of the TamTamSuite: http://git.sugarlabs.org/tamtam/tamtam/blobs/master/activity/activity.info Walter, you may want to do something like this if/when you roll multiple TurtleArt-related components into one PO file the way Aleksey did with TamTamSuite. I don't see the homepage field described on the page below, but it doesn't seem to break anything, but I wouldn't know how to parse it int oa translators' comment. http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles If anyone can describe a better way of accomplishing the same goal, I would love to hear about it, otherwise, I would like to collaborate with an activty developer to experiment with attempting to insert a developer's comment for translators into an acitvity.info file to see if we can provide an enhanced reference link in the PO file for localizers. Testing to include making hte edits, regenerating the POT, pulling to Poolte, refreshing langs in Pootle and testing rebuilt activity to make sure this insertion doesn't have unintended side-effects. Any volunteers? If we can make this work, I'd like to make this an i18n best practice for activity.info files. The first line in .pot files is being generated by setup.py (activitybundler.py) and will be regenerated by pootle's script (that's doing the same), ie, it can be improved to add home page. The problem is that existed activity.info spec doesn't have home page info. The format that was used for TamTam is a new sweets recipe specification [1] that extends currnet one to make it useful in Sugar Packaging Management System (sweets). In any case, we can ask activity developers to add homepage key to current acitvity.info files. And, like with license key (still in progress), ASLO can check upoaded activities for that key to be sure that it exists. So, we can speed up adopting this key by activity developers and improve i18n. [1] http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification +1 to adding both keys to activity.info, but I am not sure that this will help the translators as it won't be in a form that would get picked up by gettext. The process is that pootle (like bundlebuilder.py) just places activity name directly to .pot files. So, it will do the same for home page hint. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH chat] Remove the KeepButton due to deprecation
On Sat, Aug 13, 2011 at 03:27:27PM +0200, Simon Schampijer wrote: Hi Aleksey, can you push this if you are ok with it? Thanks, pushed. Would be useful to add project maintianers (as HACKING file asks) to original email, to pop up patches in maintianers' email queue. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removal of Activity Keep button
On Sun, Jul 31, 2011 at 02:43:42PM +0200, Simon Schampijer wrote: On 07/31/2011 05:17 AM, Gonzalo Odiard wrote: On Sat, Jul 30, 2011 at 7:30 PM, Rafael Ortizraf...@activitycentral.comwrote: On Fri, Jul 29, 2011 at 6:34 PM, Gonzalo Odiardgonz...@laptop.orgwrote: Hi James, There are no problem, the KeepButton class is not removed, but is not added by default in the toolbar. The activities will work ok. James, +1. You can remove the code w/o problem, if you don't remove it, the activity won't work but only for sugar=0.94 (as I understand it from Simon) , this is only for activities that have the keepbutton ''hardcoded'' in the activity toolbar code. Rafael: This is not correct. The activity will continue working, because the class KeepButton was not removed (there are two proposed patches, look at the second) In most of the activities, the default Activity Tolbar is used, and in sugar 0.94, the KeepButton will not be displayed. In a few activities, the developer hidden the button, or used a custom toolbar, and we provided patches to resolve them. Of course, we did not checked the hundred of activities in ASLO, but only the activities included by default in OLPC image, then if another activity use the button (or the user is using a old version of the activity) the only difference will be the KeepButton will be present, but the activity will works ok. Gonzalo Right, so the button is only deprecated for now, and usage is discouraged. It will be removed in a later version. That actually is not right, the patch that was landed to sugar-toolkit removes keep member from ActivityToolbarButton. Thus, activities like Terminal stops working. Also that commit says that keep button will be removed another cycle. Does it mean the next one? imho, there is no strong reason to break backwards compatibility and rehash all activities (not only fructose, ie, no way to fix all of them at once). The right way for me is declaring good practices on wiki and having warnings in logs. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removal of Activity Keep button
On Wed, Aug 17, 2011 at 09:03:55AM -0500, James Simmons wrote: Simon, All my Activities hide the Keep button. I would like to be able to have fully backward compatible Activities for as long as possible. Everything I wrote should work in anything from .82 to the present. Hiding the button by default would be better than just getting rid of it. That is exactly my concern for not removing Keep button as long as we do have sugars that have Keep button and not declared as deprecated. In other words, we do not need to rehash all activities (it sounds too useless since sugar is not only fructose and activity development process is/should-be decentralized). If all sugar 0.94 will be declared as deprecated, we can just forget (taking into account that Keep button is declared as deprecated in 0.94) about Keep button w/o asking activity developers to support several sugar APIs. The another question is that we don't have such practice, afaik, to state some sugars unsupported (having only stable sugar development sugar is not enough in my mind, since it is about 6 months cycle and it is too short for using sugar in the field). James Simmons On Wed, Aug 17, 2011 at 7:44 AM, Simon Schampijer si...@schampijer.dewrote: On 08/17/2011 02:12 PM, Aleksey Lim wrote: On Sun, Jul 31, 2011 at 02:43:42PM +0200, Simon Schampijer wrote: On 07/31/2011 05:17 AM, Gonzalo Odiard wrote: On Sat, Jul 30, 2011 at 7:30 PM, Rafael Ortizrafael@activitycentral.** com raf...@activitycentral.comwrote: On Fri, Jul 29, 2011 at 6:34 PM, Gonzalo Odiardgonz...@laptop.org** wrote: Hi James, There are no problem, the KeepButton class is not removed, but is not added by default in the toolbar. The activities will work ok. James, +1. You can remove the code w/o problem, if you don't remove it, the activity won't work but only for sugar=0.94 (as I understand it from Simon) , this is only for activities that have the keepbutton ''hardcoded'' in the activity toolbar code. Rafael: This is not correct. The activity will continue working, because the class KeepButton was not removed (there are two proposed patches, look at the second) In most of the activities, the default Activity Tolbar is used, and in sugar 0.94, the KeepButton will not be displayed. In a few activities, the developer hidden the button, or used a custom toolbar, and we provided patches to resolve them. Of course, we did not checked the hundred of activities in ASLO, but only the activities included by default in OLPC image, then if another activity use the button (or the user is using a old version of the activity) the only difference will be the KeepButton will be present, but the activity will works ok. Gonzalo Right, so the button is only deprecated for now, and usage is discouraged. It will be removed in a later version. That actually is not right, the patch that was landed to sugar-toolkit removes keep member from ActivityToolbarButton. Thus, activities like Terminal stops working. Also that commit says that keep button will be removed another cycle. Does it mean the next one? imho, there is no strong reason to break backwards compatibility and rehash all activities (not only fructose, ie, no way to fix all of them at once). The right way for me is declaring good practices on wiki and having warnings in logs. Thanks for catching this. When writing the patch description I was not thinking of any activity that does access the keep-button of the toolbar directly (terminal does set the short cut for it). I would suggest the following: I will put the button there without inserting it in the toolbar. So if an activity accesses it like: activity_button.page.keep.**props.accelerator = 'CtrlShiftS' activity_button.page.keep.**hide() it won't fail but will not have any effect neither. The button would then be removed completely in 0.96. diff --git a/src/sugar/activity/widgets.**py b/src/sugar/activity/widgets. **py index 0c34a1f..e5c4063 100644 --- a/src/sugar/activity/widgets.**py +++ b/src/sugar/activity/widgets.**py @@ -265,6 +265,9 @@ class ActivityToolbar(gtk.Toolbar): self.share.show() self.insert(self.share, -1) +# DEPRECATED +self.keep = KeepButton(activity) + self.stop = StopButton(activity) self.insert(self.stop, -1) self.stop.show() And of course I will note this in the release notes. Regards, Simon __**_ 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 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SERVER] [ANNOUNCE] Sugar Server Kit v1.0 initial release
The original url to these notes is http://wiki.sugarlabs.org/go/Sugar_Server_Kit/1.0/Notes This is an initial release of the project that was previously anounced as Sugar Server. Obviously, Sugar Server Kit sounds more appropriate. == Summary == This is the initial release of Sugar Server Kit project. It states the fact that basic ideas and core implementations are settled down. This release should not be treated as a release that is ready to use in the field, but see the #Looking forward|Looking forward section. == Conception == Sugar Server Kit is not a final solution for school servers in the filed but rather a set of components that do its work on its own. They might be composed to the final solution basing on particular needs of deployments of distributors. Read the following documents to know more: * Architecture http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Architecture * Statement of purpose for releases http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Release_plan == Components == The components that were initiated at that time: * sugar-server http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server The deamon that provides basic sugar related services, like anti-thief support or Journal backup. * mace http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Mace The mace is a tool to make final configuration using source templates. Mace is supposed to help with configuration of services on Server based school servers. * sugar-server-templates http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server-templates This component contains configuration templates of basic services that need to be installed and configured on bare servers at school. It is possible to peek at some of these services in a downstream solution to apply using the mace utility. See the demoxo demonstration project for example. * sugaroid http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugaroid It is a library and application that mimics regular sugar client behaviour to help with testing Sugar Server Kit components and Sugar Server Kit based solutions. * prosody-sugar http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Prosody Sugar specific plugins for [http://prosody.im/ Prosody], lightweight Jabber/XMPP server. * sugar-server-demoxo http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server-demoxo This is a demonstration of a Sugar Server Kit based school server solution. It is intended to be run on XO-1 laptops to demonstrate how a Sugar Server Kit based downstream solution might look, but that's only Sugar Server Kit/Architecture#Black_box_model|one of the possible ways it might be applied. == Getting the release == There are no source tarballs released since it is not production targeted release and it is not yet clear what deployment model will be eventually useful. For now there are only version tags in [http://git.sugarlabs.org/server git repositories]. In any case, the easiest way to try new project is setting up school server on a XO-1 laptop using demoxo. There is also instructions http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server-demoxo#Install_from_yum_repository how to setup it in Fedora-14 environment on a XO-1. This [http://download.sugarlabs.org/packages/Server:/1/Fedora-14/ Fedora-14 binary repository] might be also used to install particular component for singular usage. Binaries were built only for Fedora-14 distribution because current usage is only Fedora-14. Sugar Server Kit is distribution agnostic project and new distribution builds will be supported on purpose. == Looking forward == The next minor, 1.1, release should: * be the first release that will follow the releasing plan, * have reliable set internal automatic tests of all Sugar Server Kit components, * reliable set of system integration automatic tests of Sugar Server Kit components using sugar_Server_Kit/sugaroid|sugaroid application, * documented on development and deployment levels, * have at least one production deployment. == Credits == * David Farning for an initial push to have community level project for school server. * OLPC School server (XS) project that was used as a prototype for sugar-server, mace and sugar-server-templates components. * People from Nepalese, Paraguayan and Australian deployments for sharing their experience. * Especial thanks to [http://www.paraguayeduca.org/ Paraguay Educa] for their interest and contribution to Sugar Server Kit project. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SERVER] [ANNOUNCE] Sugar Server Kit v1.0 initial release
On Wed, Aug 24, 2011 at 03:34:54AM +, Aleksey Lim wrote: ... == Credits == * David Farning for an initial push to have community level project for school server. Needs to be read: * [http://activitycentral.com/ Activity Central] for an initial push to have community level project for school server and for supporting during the work on 1.0 release. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SERVER] [ANNOUNCE] Sugar Server Kit v1.0 initial release
On Wed, Aug 24, 2011 at 03:34:54AM +, Aleksey Lim wrote: == Credits == * David Farning for an initial push to have community level project for school server. * OLPC School server (XS) project that was used as a prototype for sugar-server, mace and sugar-server-templates components. * People from Nepalese, Paraguayan and Australian deployments for sharing their experience. * Especial thanks to [http://www.paraguayeduca.org/ Paraguay Educa] for their interest and contribution to Sugar Server Kit project. * The [[Wiki Team]] for continuous polishing [[Sugar Server Kit]] wiki pages. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SERVER] [ANNOUNCE] Sugar Server Kit v1.0 initial release
On Wed, Aug 24, 2011 at 12:06:03AM -0500, Jerry Vonau wrote: On Wed, 2011-08-24 at 03:34 +, Aleksey Lim wrote: * sugar-server-demoxo http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server-demoxo This is a demonstration of a Sugar Server Kit based school server solution. It is intended to be run on XO-1 laptops to demonstrate how a Sugar Server Kit based downstream solution might look, but that's only Sugar Server Kit/Architecture#Black_box_model|one of the possible ways it might be applied. Any plans to release a XO-1.5 version? I'd be interested in the os-builder ini file you used to create this image. I didn't manage to build kernel for XO-1.5 in my fedora-14 VM... The os-builder ini file is: [global] fedora_release=14 olpc_version_major=11 olpc_version_minor=2 olpc_version_release=0 target_platform=XO-1 langs=en_US modules= base, demoxo, buildnr_from_file, ubifs_image, repos, custom_packages [repos] fedora=fedora,fedora-updates olpc_publicrpms_1=1,f14 olpc_publicrpms_2=1,f14-xo1 custom_repo_1=1,schoolserver,http://download.sugarlabs.org/packages/Server:/1/Fedora-14/ custom_repo_2=2,kernel,http://people.sugarlabs.org/~alsroot/demoxo/rpms/xo1/ add_excludes_to=fedora,fedora-updates [custom_packages] add_packages = sugar-server-demoxo, rsync [buildnr_from_file] path=latestbuild The only difference between demoxo and xo1 modules is that it changes init level # No need in X sed -i 's/^id:5/id:3/' /etc/inittab (but olpc-os-builder magically stopped work in my VM due to lack of sugar-(base,datastore) deps) == Getting the release == There are no source tarballs released since it is not production targeted release and it is not yet clear what deployment model will be eventually useful. For now there are only version tags in [http://git.sugarlabs.org/server git repositories]. In any case, the easiest way to try new project is setting up school server on a XO-1 laptop using demoxo. There is also instructions http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server-demoxo#Install_from_yum_repository how to setup it in Fedora-14 environment on a XO-1. This [http://download.sugarlabs.org/packages/Server:/1/Fedora-14/ Fedora-14 binary repository] might be also used to install particular component for singular usage. I take it we can drop-in the .repo file and yum install on any stock F14 installation? yup, but keeping in mind that if sugar-server-demoxo will be used, its /etc/init.d/schoolserver contains XO specific instructions. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Simplification help request
On Tue, Aug 23, 2011 at 03:27:22PM -0400, Art Hunkins wrote:
In my current activity (SamplePlay), I've got 26 buttons that allow a user
to select (from the Journal) up to 26 audio samples/loops to play. AFAIK,
the filename must be sent to Csound as a discrete variable, on its own
channel (see below).
As a result, I've 26 iterations(!) (0-25) of the same basic code. I'd like
to simplify it if possible (the code itself works fine). Any suggestions are
very much welcomed.
self.path0 = 0
.
self.path25 = 0
self.jobject0 = None
.
self.jobject25 = None
def choose0(self, widget):
chooser = ObjectChooser(parent=self, what_filter=mime.GENERIC_TYPE_AUDIO)
result = chooser.run()
if result == gtk.RESPONSE_ACCEPT:
self.jobject0 = chooser.get_selected_object()
self.path0 = str(self.jobject0.get_file_path())
else:
self.jobject0 = None
self.path0 = 0
.
def choose25(self, widget):
chooser = ObjectChooser(parent=self, what_filter=mime.GENERIC_TYPE_AUDIO)
result = chooser.run()
if result == gtk.RESPONSE_ACCEPT:
self.jobject25 = chooser.get_selected_object()
self.path25 = str(self.jobject25.get_file_path())
else:
self.jobject25 = None
self.path25 = 0
def send_data(self):
self.w.set_filechannel(file0, self.path0)
self.w.set_filechannel(file1, self.path1)
.
self.w.set_filechannel(file24, self.path24)
self.w.set_filechannel(file25, self.path25)
Hoping (as a Python novice) to be shown a better way -
starting from the code you posted, the optimization might look like:
MAX_EXAMPLES = 26
class ...:
def __init__(self):
...
self._examples = []
for num in range(MAX_EXAMPLES):
widget = ...
widget.connect('...', self.__choose_cb, num)
def __choose_cb(self, widget, num):
chooser = ObjectChooser(parent=self,
what_filter=mime.GENERIC_TYPE_AUDIO)
result = chooser.run()
if result == gtk.RESPONSE_ACCEPT:
self._examples[num] = chooser.get_selected_object()
else:
self._examples[num] = None
def send_data(self):
for num in range(MAX_EXAMPLES):
if self._examples[num] is not None:
self.w.set_filechannel('file%s' % num,
self._examples[num].get_file_path())
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] tamtam-branch project on git.sugarlabs.org renamed to tamtam
Hi all, tamtam-branch project on git.sugarlabs.org was created to collect patches for existed repository on http://dev.laptop.org/git/projects/tamtam/. But there wasn't any activity (except pootle commits) and tamtam-branch became the place to land several minor features. Recently, TamTam sources was switched to the singular sources tree to simplify supporting and improve i18n integration. So, it is the right time to rename tamtam-branch to tamtam. The new urls are: http://git.sugarlabs.org/tamtam git://git.sugarlabs.org/tamtam/tamtam.git All HTTP urls will be redirected to the new location, git access won't work since old project will be removed. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SERVER] Sugar Server Kit v1.1 Roadmap
Hi all, The original url to that Todo is http://wiki.sugarlabs.org/go/Sugar_Server_Kit/1.1/Todo == New components == * http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-server-blacklist * http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-client == Documentation == * in-code documentation for sugar-server and sugar-server-templates == Testing == * more system tests of SSK infra using sugaroid to cover various deployment workflows * using sugaroid bots, stress test prosody to compare with ejabberd * the basis for regression tests to keep 1.x branch out of regressions == New templates == * squidGuard * Monitoring (?) Munin == Roadmap == 2011-10-09 Start pilot program in Paraguay using SSK-1.1 based solution. http://wiki.paraguayeduca.org/index.php/School_Server 2011-12-01 Successful pilot program. SSK-1.1 release. == Looking forward == The key features of http://wiki.sugarlabs.org/go/Sugar_Server_Kit/1.2/Todo will be (at least): * Collect statistics of XO usage on school servers -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Add 0.94 version field to ALSO
On Tue, Sep 13, 2011 at 12:33:48PM +0200, Simon Schampijer wrote: Hey, just tried to add the 0.94 version field in ALSO (admin) but could not find it. Can someone point me to it or do it quickly? I've added 0.94. Would be useful to point such requests to ASLO administrative contact[1] or to bugs.sl.o' activities.sugarlabs.org component to ping ASLO maintainers. [1] http://wiki.sugarlabs.org/go/Service/activities#Administrative_contact -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Regarding my OLPC XS Wishlist
On Fri, May 27, 2011 at 09:14:10PM +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Hi, There was a talk on #sugar 3 months ago about an idea to monitor school servers in Nepal. Is there any progress? I'm thinking about how to monitor school servers in Paraguay, the connectivity here is not too bad and using tools like Munin is possible but if you managed to find solution for offline monitoring, it should be useful for Paraguay as well. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Regarding my OLPC XS Wishlist
On Wed, Sep 14, 2011 at 08:08:44PM +0200, Tony Anderson wrote: Hi, Munin looks like it would be useful. Since many of the routers are running dd-wrt, I am wondering if this package (or something similar) could be used to monitor the load on the routers. The routers are the probable bottleneck. In fact, the plan in Paraguay is having Munin nodes on school servers (and on APs as well), i.e., they will send statistics to the mothership (I guess that won't work for Nepal since connectivity is a problem there, thats why I asked about offline solution). I suspect one of the unknowns is how much load is the result of avahi and ejabberd and other packages polling the network. Actually, it would be useful to have such stress tests before going to production (of course it might not precise test but at least it will get a level of loading). It is in the plan for SSK-1.1[1]. For example, it might reduce this significantly be having ejabberd subdivide the users in groups rather than try to include all XOs in one. Incidentally, I was told at the Paris meeting that there is an ejabberd or ejabberd-like version implemented in Java. This may be worth exploring as a replacement for ejabberd. Incidentally, I followed the quite opposite way in case of replacing ejabberd for [possibly] smaller resources consumption [2] :) It just works for 0.88 clients and there are glitches w/ 0.9x clients (but it is hard to investigate since 0.9x collab code is not mature). Also, at the Paris meeting, I was told that OLPC Australia has reimplemented 0.6 using a current Fedora release. Yours, Tony On 09/13/2011 08:17 PM, Aleksey Lim wrote: On Fri, May 27, 2011 at 09:14:10PM +0545, Abhishek Singh wrote: Dear All, I've put down my OLPC XS wishlist at http://asingh.com.np/blog/olpc-xs-my-wishlist/ . Please comment upon it. Thank You. Hi, There was a talk on #sugar 3 months ago about an idea to monitor school servers in Nepal. Is there any progress? I'm thinking about how to monitor school servers in Paraguay, the connectivity here is not too bad and using tools like Munin is possible but if you managed to find solution for offline monitoring, it should be useful for Paraguay as well. [1] http://wiki.sugarlabs.org/go/Sugar_Server_Kit/1.1/Todo#Testing [2] http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Prosody -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Regarding my OLPC XS Wishlist
On Wed, Sep 14, 2011 at 09:47:09PM +0200, Tony Anderson wrote: ... There have been many stress tests, but sadly they have not represented the actual load. That is why it needs to be installed on production systems in a deployment. What was the methodology for these tests, could you share it? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release XoScope-9
On Fri, Sep 23, 2011 at 12:55:49AM +0530, Anish Mangal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2011 12:44 AM, Sascha Silbe wrote: Excerpts from Sugar Labs Activities's message of Wed Sep 21 17:22:59 +0200 2011: Activity Homepage: http://activities.sugarlabs.org/addon/4481 [...] It's worth mentioning that there's another project called xoscope that's quite useful on XOs. Most kids probably won't use it, but you should still consider changing the name of your activity while it's not in widespread use yet, so the confusion resulting from the rename is limited. Oh! Thanks for pointing it out. I'll rename it. Suggestions? Should I just rename it to 'Telescope'? Also, should I just change the activity name (but keep the GUID same) or upload a new activity altogether to ASLO? If you want to change name, there is not need to change GUID/bundle_id, only activity name (on ASLO level and changing it in activity.info and uploading new version). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Translations: We need help from activity maintainers
On Fri, Sep 23, 2011 at 07:24:48AM -0300, Gonzalo Odiard wrote: Hello maintainers, In fact, it should be more useful to file tickets on bugs.sl.o. Not all activity devs might track sugar-devel@ on regular basis and it is mostly hard to track bugs on ML. You know pootle server is creating the pot files again, now a few activities have errors and need your help to enable the translators to do his work properly. The activities involved are Record, Browse, Distance, Speak, hmouse, Kandid, jigsaw-puzzle, slider puzzle, mateton Will file tickets (for not CCed devs) and fix issues in activities I'm maintaining... -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] jhbuild improvement?
On Wed, Sep 28, 2011 at 10:35:55PM -0400, Bernie Innocenti wrote: I was reading in the Gnome 3.2 release notes: GNOME's build tool JHBuild does not build a module anymore if the version installed on your system is recent enough. This is controlled by the configuration option partial_build and it is enabled by default. The command jhbuild sysdeps lists which system modules have been found as well as the modules that are going to be build. If you start to build GNOME from scratch with a recent distribution, this can easily drop 50 modules from the list of modules to compile. This feature could potentially reduce the complexity for setting up a new development environment. What do you think? To reduce jhbuild complexity, maybe. But not sure if jhbuild will be more useful than: * install PackageKit * install Sweets: wget http://download.sugarlabs.org/sweets/sweets/installer.sh sh installer.sh * clone sources (that have sweets.recipe) you need to code: git clone git://git.sugarlabs.org/sdk/sugar.git sugar/ * make your changes in sugar/ code * launch your changes: sweets sugar/:emulator -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] jhbuild improvement?
On Thu, Sep 29, 2011 at 06:21:53PM -0400, Bernie Innocenti wrote: On Thu, 2011-09-29 at 12:07 +, Aleksey Lim wrote: On Wed, Sep 28, 2011 at 10:35:55PM -0400, Bernie Innocenti wrote: I was reading in the Gnome 3.2 release notes: GNOME's build tool JHBuild does not build a module anymore if the version installed on your system is recent enough. This is controlled by the configuration option partial_build and it is enabled by default. The command jhbuild sysdeps lists which system modules have been found as well as the modules that are going to be build. If you start to build GNOME from scratch with a recent distribution, this can easily drop 50 modules from the list of modules to compile. This feature could potentially reduce the complexity for setting up a new development environment. What do you think? To reduce jhbuild complexity, maybe. But not sure if jhbuild will be more useful than: * install PackageKit * install Sweets: wget http://download.sugarlabs.org/sweets/sweets/installer.sh sh installer.sh * clone sources (that have sweets.recipe) you need to code: git clone git://git.sugarlabs.org/sdk/sugar.git sugar/ * make your changes in sugar/ code * launch your changes: sweets sugar/:emulator Ok, I tried this out. Here are a few observations: Firstly, the difference I pointed is that a flexibility of using Sweets in comparing jhbuild to code sugar, i.e., jhbuild is a black box supported in a separate project that covers the full sugar related infra at once. At the same time Sweets is a PMS, and sugar/ here is a package in this pms. You clone the sugar sources (not ask jhbuild to clone sugar somewhere). Code it. And run it (right from the place you cloned it before). The second point, Sweets is a PMS. It is not an initiative to replace jbuild (but for me it is more useful than jhbuild), but rather to have on-top-of-distro PMS that support Sugar way for development, i.e., learning via doing(coding), share results of experiments (because it is cirtical for learning process), etc. 1. The sweet binary was symlinked to ~/.local/bin/sweets. Why not ~/bin, which would be already in the path for most distros? ~/.local seems to be a common place for such stuff, If ~/bin is also being used in several distros (I don't have it in mine), then it will be a good candidate to replace ~/.local. I saw it only on Debian/Ubuntu. 2. On my Ubuntu Lucid desktop, PackageKit is a little too dumb: it bails out because of a minor dependency problem on my system. I solved it by running apt-get manually, which offered me to downgrade a couple of packages. If it works better on more recent distros, we don't have to worry too much about this. PK is a critical component in Sweets. It is pretty simple, if Sugar ecosystem is not about only-one-distro(put here your favorite), then we either need to reuse existed PK or reinvent it. There is a good progress in pushing PK to several distros, I even have it on Gentoo, on recent Distros it just works. 3. Sweets tried to build csound-python from sources even though there's a distro package for it. Moreover, the build fails on x86_64 due to a missing -fPIC. Installing the package manually with apt fixed the issue. 4. Same thing for pybox2d, which isn't even available in Lucid :-( 5. Why are things like csound and box2d specified as dependencies of the sugar package? If I'm doing development on Sugar core, I don't care whether TamTam and Physics work. Thats not a fail of Sweets but a fail of particular sweet (ie package). And there is a reasong for that: for now, there is no GUI to run activities from Sweets (but on low level, it is possible), thus sugar sweet needs to include such deps (the good point in comparing w/ jhbuild, is that if you don't like it, you need to change sugar sources, not jhbuild's - edit sugar/sweets.recipe). In the end, my newbie experience with sweets is not much better than jhbuild. Both these build systems seem too aggressive in pulling in dependencies and building things from source, Deps issue was already covered in prev. paragraph. The building from sources, thats another not trivial issue. And Sweets is designed to solve it using another tool - OBS. Here you got building from sources for all deps because there are no binaries built exactly for you distro/arch, e.g., for now there are only blobs for Fedora-14 and Ubuntu-10.10: http://download.sugarlabs.org/sweets/sdk/csound-python/. These binaries were built on OBS in automatic manner - dev only uploaded sources to obs.sugarlabs.org. leading to fragility and complexity for the user. There is no magic (and here problem in particular sweets, not in Sweets), the entirely Sweet initiative is not about Click the one button it is about having a tool (that does
Re: [Sugar-devel] jhbuild improvement?
On Thu, Sep 29, 2011 at 11:17:42PM -0400, Bernie Innocenti wrote: On Thu, 2011-09-29 at 23:30 +, Aleksey Lim wrote: PK is a critical component in Sweets. It is pretty simple, if Sugar ecosystem is not about only-one-distro(put here your favorite), then we either need to reuse existed PK or reinvent it. There is a good progress in pushing PK to several distros, I even have it on Gentoo, on recent Distros it just works. Yes, agreed. It's a necessary evil if we are to support multiple distros. However, it shouldn't be necessary to deal with PK just to build Sugar from sources. A simple shell script like the one that Michael (or Marco?) hacked together for sugar-core should suffice. Such script could break, but it won't fail in confusing and obscure ways like PackageKit and jhbuild often do. Here I'm looking at addressing only the needs of a specific workflow: the wanna-be Sugar developer who tries to build the code for the first time. I personally helped a good number of them and I shared their frustration every time jhbuild breaks in a new interesting way. Actually, I don't see any principal difference between Sweets approach and using sudo ./install-deps.sh. To have bulletproof Install-deps.sh, we either need to support only one distro (and maybe only one its release), or I don't see any difference in possible issues (w/ missed deps, wrong package names, wrong dep version, etc) that might be popped up while using install-deps.sh or sugar sweet. If something goes wrong, just open install-deps.sh or sugar/sweets.recipe and changes it to make it useful in your system. The difference is, for sweets.recipe, you have to change the string: requires = dep-1; dep-2 0.4 but for Install-deps.sh, you have to change the code in Install-deps.sh with bunch of ifs (for all supported native PMS and bunch of package name mappings). All these issues are covered out of usage workflow. Yes, there are downsides, because it is a possible breakage point. But all these issues (not directly related to packaged software) might be solved by skilled people (who support all these deps on Sweets level) or every user have to solve it on his own (and so for every user). 3. Sweets tried to build csound-python from sources even though there's a distro package for it. Moreover, the build fails on x86_64 due to a missing -fPIC. Installing the package manually with apt fixed the issue. 4. Same thing for pybox2d, which isn't even available in Lucid :-( 5. Why are things like csound and box2d specified as dependencies of the sugar package? If I'm doing development on Sugar core, I don't care whether TamTam and Physics work. Thats not a fail of Sweets but a fail of particular sweet (ie package). And there is a reasong for that: for now, there is no GUI to run activities from Sweets (but on low level, it is possible), thus sugar sweet needs to include such deps Couldn't we move these fructose deps into a separate recipe that isn't needed when all you want to do is bring up the Sugar emulator? These are regular packages within Sweets, so np. The cumulative sweet might be named, e.g., sdk/platform. (the good point in comparing w/ jhbuild, is that if you don't like it, you need to change sugar sources, not jhbuild's - edit sugar/sweets.recipe). That's a lot better than tweaking jhbuild's ugly xml files, but it's still a domain-specific language that I'd rather not have to learn. http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification The good point, it is inherited from activity.info format. Deps issue was already covered in prev. paragraph. The building from sources, thats another not trivial issue. And Sweets is designed to solve it using another tool - OBS. Here you got building from sources for all deps because there are no binaries built exactly for you distro/arch, e.g., for now there are only blobs for Fedora-14 and Ubuntu-10.10: http://download.sugarlabs.org/sweets/sdk/csound-python/. These binaries were built on OBS in automatic manner - dev only uploaded sources to obs.sugarlabs.org. Most (maybe all) of the deps being built from source stuff that exist already as native distro packages! Well, thats a quality of particular sweets and needs specific investigation.. If we support multiple distributions by dumping dozens binary componentes in ~/.local, we'll end up recreating something like Red Carpet or Zope. Such abominations resemble an operating system of their own which takes a HUGE engineering effort to maintain and makes users quite unhappy with the end result. The only multiple distro support in Sweets, is having a map between Sweets level dep, e.g., base/gtk and names of native packages in particular distro https://packages.sugarlabs.org/project/monitor?project=base ie, Sweets/0install need to decide what native packages needs to be used/installed instead of base/gtk. I already mentioned this issue
Re: [Sugar-devel] jhbuild improvement?
On Fri, Sep 30, 2011 at 06:04:29PM -0400, Bernie Innocenti wrote: On Fri, 2011-09-30 at 13:33 +, Aleksey Lim wrote: Actually, I don't see any principal difference between Sweets approach and using sudo ./install-deps.sh. To have bulletproof Install-deps.sh, we either need to support only one distro (and maybe only one its release), or I don't see any difference in possible issues (w/ missed deps, wrong package names, wrong dep version, etc) that might be popped up while using install-deps.sh or sugar sweet. If something goes wrong, just open install-deps.sh or sugar/sweets.recipe and changes it to make it useful in your system. The difference is, for sweets.recipe, you have to change the string: requires = dep-1; dep-2 0.4 but for Install-deps.sh, you have to change the code in Install-deps.sh with bunch of ifs (for all supported native PMS and bunch of package name mappings). All these issues are covered out of usage workflow. Yes, there are downsides, because it is a possible breakage point. But all these issues (not directly related to packaged software) might be solved by skilled people (who support all these deps on Sweets level) or every user have to solve it on his own (and so for every user). This is what the install-deps.sh looks like: http://git.sugarlabs.org/sugar-core/mainline/blobs/master/install-deps.sh So, it is only for lucid, what about other debian/ubuntu. There are a chance that the same software might have different package names. Also, what about other distros. And, e.g., if there is a wrong package name for not well used Mandriva, you need to change this mapping bug in all projects that use this wrong names. The same for new distro releases. There is also dependency restrictions, eg, recent sugar might require recent TP but recent ubuntu LTS might don't have them (and upgrade your distro, is not pretty fair). As you can see, it's quite low-tech: those who can't make sense of this are probably unable to hack on the Sugar codebase either. I opened sweets.recipe, but I couldn't immediately figure out where the python-box2d dependency was coming from. Of course I could have spent more time learning about zeroconf and digging into the inter-dependencies... that should be unpredictable if particular package will contain full deps tree. for the deps tree, there is a status command: sweets status sdk/sugar -d Instead of investigating further, I stopped there. By that time I had already determined that the learning curve for a new Sugar developer is a lot steeper than it had to be. I heard the same from people (especially from people who are used to other VCS) when they tried git at first (though, for me Sweets is simpler), i.e., lack of knowledge of basic things for tools they are using :). Look, there are other veteran programmers who seem to be frustrated by our current build system: http://marcopg.org/2011/09/06/building-sugar-from-git-on-f15/ And, generally, it is exactly the content of sugar* recipes. The whole reason of Sweets (as a pms), it is to replace bunch of wiki/how-to/INSTALL by having specs and a decent pms. That's a lot better than tweaking jhbuild's ugly xml files, but it's still a domain-specific language that I'd rather not have to learn. http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification The good point, it is inherited from activity.info format. Nice documentation and nice design! I'm just unsure what the values of requires= are supposed to be: native packages? zeroconf packages? or sweets? Where can I find a full list of them? http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Interfaces wiki.sugarlabs.org/go/Platform_Team/Sweets/Glossary The only multiple distro support in Sweets, is having a map between Sweets level dep, e.g., base/gtk and names of native packages in particular distro https://packages.sugarlabs.org/project/monitor?project=base ie, Sweets/0install need to decide what native packages needs to be used/installed instead of base/gtk. Super nice. I think we could make things easier to understand by increasing the verbosity on stdout. Something like building base/gtk from source because $EXPLANATION. Simply failing in case of missing dependencies would also be acceptable (actually, it's a lot less confusing than being too clever). Sure, it would be helpful. The question only is How to do. For now there is: sweets status sdk/sugar -ddv Well, there is no magic. For skilled people, there is no need in anything except glucose sources (no need in jhbuild or sweets). For not so skilled people, we either need to ask them to be skilled, or put some magic somewhere. In ideal situation, all deps will be in native packages and will be installed mostly in a sustainable way My claim is that we're *already* living in this ideal situation: the mayor distros already include everything we
Re: [Sugar-devel] jhbuild improvement?
On Thu, Sep 29, 2011 at 06:21:53PM -0400, Bernie Innocenti wrote: ... 3. Sweets tried to build csound-python from sources even though there's a distro package for it. Moreover, the build fails on x86_64 due to a missing -fPIC. Installing the package manually with apt fixed the issue. 4. Same thing for pybox2d, which isn't even available in Lucid :-( btw, on newly installed Lucid-x86_64, I can't reproduce faild build for csound-python and pybox2d, could you post your build output: sweets make -v sugar/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] jhbuild improvement?
On Fri, Sep 30, 2011 at 06:04:29PM -0400, Bernie Innocenti wrote: Look, there are other veteran programmers who seem to be frustrated by our current build system: http://marcopg.org/2011/09/06/building-sugar-from-git-on-f15/ btw, if you will extend this example taking care about several glucose versions (dunno for others, but I all time work eith several of them, e.g., as an activity developer to make sure that my activities work well on all deployed sugars), add native packages related issues, you will reproduce the way I passed to come to Sweets :) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sweets, Zero Install based Package Management System for Sugar
Hi all!
The original page for these release notes is
http://wiki.sugarlabs.org/go/Platform_Team/Sweets/1.0/Notes
== Retrospection ==
Two years ago, Michael Stone
[http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/2728 rolled]
the first try to get the folks at Sugar Labs excited about Zero Install
software. Several people from both communities showed their interest,
e.g., Bernie Innocenti, Thomas Leonard, Rene Lopez, and Anders F Björklund.
As a result, a meeting occurred on the #sugar-meeting IRC channel.
That meeting was organized by Michael Stone to exchange knowledge and
to learn whether Zero Install might be a good fit for use in Sugar activity
installation. Thomas Leonard wrote a
[http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/2776
summary]
and Michael Stone
[http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/2776/focus=18807
forwarded]
it to the sugar-devel mailing list.
The idea of using Zero Install in the Sugar ecosystem passed several mutations
and,
eventually, it seems that the core ideas have settled down and are ready to be
presented widely in the community.
== The pillars ==
=== Learning by doing ===
The preeminent core idea behind Sugar is learning by doing. Thus,
it is critical to Sugar to have the tools that support the doing
metaphor well, doing not only within regular activities and project teams,
but also by individuals who tweak the software in the process of learning.
And not the least of options is sharing the results of doer/learner
experiments. Sweets is intended to make these aspects less annoying being
based on the [http://0install.net/why.html Zero Install] system.
=== To not reinvent the wheels ===
It will be useful to let people in the Sugar community to concentrate only
on software they are developing, and to reuse existing efforts of GNU/Linux
distributions as underlying dependencies for developing software.
The [http://www.packagekit.org/ PackageKit] project provides this possibility.
=== Infrastructure does matter ===
The core difference of the final Sweets approach with previous evolutions
is the idea that a successful model should cover the full life cycle of
software,
from developing by creators to using by the community.
Another project, the [http://openbuildservice.org/ Open Build System],
was chosen for that.
== What is Sweets ==
So, Sweets is a
[[http://en.wikipedia.org/wiki/Package_management_system |Package Management
System]]
entirely based on [http://0install.net/ Zero Install], a decentralized,
cross-distribution, software installation system. It might be treated as a tools
and infrastructure wrapper around Zero Install. Sweets is intended to distribute
various software projects created in the Sugar ecosystem, such as libraries,
sugar itself, and sugar activities.
This new distribution method is initiated assuming that:
* The method to share software projects should be as convenient as possible.
* It is important to stimulate users into becoming doers, to modify existing
activities, and to share the results of their experiments with other people,
i.e., a distribution method should handle different variants
of the same project.
* This distribution method is not intended to be the only one, but is targeted
more towards direct distributionmdash;from software creators
to software users.
The purpose is to create a new distribution method instead of reusing:
#
[[http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles|''.xo
bundles'']]
#* Work smoothly only for pure python activities, and only if all
(and the same) dependencies are installed on all systems. They stop working
smoothly if activities use non-standard dependencies or contain binaries.
#* But, are not effective in supporting the use of multiple versions of
software,
e.g., the results of experiments (the work) of different doers,
simultaneously.
Users must manually handle the variety of activity versions, e.g., sort out
all the local bundles or directories in {{Code|~/Activities}}.
# ''native packages''
#* Not the shortest way to connect developers with users.
#* In most cases, they don't support multiple versions of the same project.
#* They don't work at all for sharing results of experiments.
At the same time, existing distribution methods are reused in Sweets:
#
[[http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles|''.xo
bundles'']]
is a subset of the Sweets workflow, from usage point of view
#* It is possible to bundle an entire directory as a sweet project
to use it as a regular .xo file.
# ''native packages''
#* Sweets is not intended to create one more GNU/Linux distribution.
It distributes only projects that people create within the Sugar
community; all other software, i.e., dependencies, will be reused
from native packages.
#* For cases like Sugar deployments, using the more centralized, regular
repositories (third party or official
[Sugar-devel] [SWEETS] Glucose-0.84 and testing activtities
Hi all! There are several activities that support 0.84 toolbars (including TamTam). There is a possibility to run Glucose-0.84 via Sweets to make sure that this code works well. Since data format for sugar-datastore was changed since that time, would be useful to run sugar from different profiles: SUGAR_PROFILE=84 sweets sdk/sugar:emulator = 0.84 SUGAR_PROFILE=88 sweets sdk/sugar:emulator = 0.88 sweets sdk/sugar:emulator = 0.94 The detailed instructions how to run Sugar from Sweets: http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Sugar_via_Sweets -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SamplePlay-2.xo in Sandbox
On Mon, Oct 10, 2011 at 10:19:56PM -0400, Walter Bender wrote: On Mon, Oct 10, 2011 at 9:33 PM, Art Hunkins abhun...@uncg.edu wrote: I hate to bother someone again to reclaim my new version of SamplePlay from the sandbox. It's been there for 5 or more days. Anything I should be doing to ring my bell louder? Or should I just wait quietly? The problem -- at least for me -- it that ASLO doesn't notify tha things are in the queue. I don't check regularly enough. You need to subscribe to http://lists.sugarlabs.org/listinfo/aslo mailing list. If something goes to pending queue, it will be notified to this list. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [query]: changing the application status of SocialCalc set to experimental at a.s.l.o
On Mon, Oct 10, 2011 at 06:10:33PM +0530, Manusheel Gupta wrote: Team, Wish to ask you on whom we should contact for changing the application status of SocialCalc (http://activities.sugarlabs.org/en-US/sugar/addon/4084) set to experimental at a.s.l.o. Kindly let us know. Thats entirely up to developers to decide when activity is stable enough (because only developers are responsible for what they are releasing). Developers need to change SocialCalc status in Activity Library and it will got to pending queue for Editors. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TuxPaint
On Fri, Oct 14, 2011 at 11:09:58PM +, Alan Jhonn Aguiar Schwyn wrote: Hi, today I maked an activity with 5 years old childrens..First, make a collage of an airplane...After.. paint it in the TuxPaint activity... When I want to make new (to select an pre-existed images, like the airplane) the activityshow the little clock for some minutes! The childrens, and I, lose the patience... What happend? Is for the type of that images? (there are .png, but there are some .svg)The activity have much time in re-scale or processing it? Is important report this like an bug? I use an XO 1.0 from Uruguay with Dextrosa (Sugar 0.88.1) Unfortunatelly, TuxPaint is not fast on XO (especially on XO-1) while opening New dialog. It tooks some noticeable time even on my Core2 Duo 1.8Ghz machine. You can file a bug report to upstream http://sourceforge.net/tracker/?group_id=66938 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] TuxPaint
On Sat, Oct 15, 2011 at 12:36:23PM +, Aleksey Lim wrote: On Fri, Oct 14, 2011 at 11:09:58PM +, Alan Jhonn Aguiar Schwyn wrote: Hi, today I maked an activity with 5 years old childrens..First, make a collage of an airplane...After.. paint it in the TuxPaint activity... When I want to make new (to select an pre-existed images, like the airplane) the activityshow the little clock for some minutes! The childrens, and I, lose the patience... What happend? Is for the type of that images? (there are .png, but there are some .svg)The activity have much time in re-scale or processing it? Is important report this like an bug? I use an XO 1.0 from Uruguay with Dextrosa (Sugar 0.88.1) Unfortunatelly, TuxPaint is not fast on XO (especially on XO-1) while opening New dialog. It tooks some noticeable time even on my Core2 Duo 1.8Ghz machine. You can file a bug report to upstream http://sourceforge.net/tracker/?group_id=66938 Though, I just found that the gallerty for New dialog comes without thumbs. Will upload new TuxPaint activity with thumbs created, that should speed up New dialog noticeably. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] jita.sugarlabs.org planned maintenance downtime, 2011-10-18 03:00 UTC
Hi all! The following services will be inaccessible for planned maintenance. For one hour starting from 2011-10-18 03:00 UTC. cas.sugarlabs.org cgit.sugarlabs.org git.sugarlabs.org chat.sugarlabs.org obs.sugarlabs.org jabber.sugarlabs.org meeting.sugarlabs.org sweets.sugarlabs.org Sorry for inconveniences. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sugar Labs instance of Open Build System
Hi all! During the work on Sweets[1], openSUSE project, Open Build System[2] was choosen as build farm and hosting server for software managed by Sweets. This is a [http://git.sugarlabs.org/0sugar/build-service patched] Sugar Labs instance of OBS that is intended to be a: * Hosting sources and making binaries, if there is need, for [[Platform_Team/Sweets|Sweets]]. * Convenient instrument to create 3rd party repositories with native packages for all [[#Supported_platforms|supported]] GNU/Linux distributions. For detailed information, read the original Open Build System [http://openbuildservice.org/documentation.html documentation]. For more details about Sugar Labs instance, see http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System It is ready to be used via Sweets[3] as well as for creating 3rd party repositories with native packages[4]. [1] http://wiki.sugarlabs.org/go/Platform_Team/Sweets [2] http://openbuildservice.org/ [3] http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Releasing [4] http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System#Usage -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Single sign-on for Sugar Labs resources
Hi all! This case was already popped up from community point of view by Pablo Flores in Tools for the community threads. So, this is a try from Infrastructure Team side. This is about Single sing-on feature for all Sugar Labs resources, such as: * http://wiki.sugarlabs.org * http://git.sugarlabs.org * http://bugs.sugarlabs.org * http://activities.sugarlabs.org * http://translate.sugarlabs.org * https://packages.sugarlabs.org * http://patchwork.sugarlabs.org Basing on Infrastructure Team discussion in systems@ mailing list (it is open, but for some time in the past it was used for discussing secure things like passwords and its history is not public), there is a wiki page http://wiki.sugarlabs.org/go/Infrastructure_Team/Central_Login and a motion: * Centralized database of all users; * Support Single sign-on on as many as possible Sugar Labs sites; * Having users friendly (not only for geeks) Account management application; * Use OpenID, if particular site support it, as a spare authentication method (but OpenID does not conform to Single sign-on); * Push this new infra to production usage; * Look for more authentication methods, like certificate based one from Sugar Shell, that might be useful in addition to the existing system. This is an invitation to broad discussion and pointing out possible down sides of this decision (in addition to [1]). This is also a call for doers to implement [2], we need it in any case. Or, pointing to the existing implementation that might be reused. [1] http://wiki.sugarlabs.org/go/Infrastructure_Team/Central_Login#Costs_.26_Risks [2] http://wiki.sugarlabs.org/go/Infrastructure_Team/Central_Login#Account_management_application -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding git to Sugar platform?
On Fri, Oct 21, 2011 at 08:28:57AM -0400, Walter Bender wrote: On Fri, Oct 21, 2011 at 8:17 AM, Aleksey Lim alsr...@activitycentral.orgwrote: On Fri, Oct 21, 2011 at 11:02:58AM +0200, Simon Schampijer wrote: Hi, the bundlebuilder uses git to package the tarballs and xo-bundles [1]. I would therefore say, the git should be a dependency for the sugar-toolkit and should be added to the Platform components. Any objections about that? I personally treated SP as a runtime dependencies stack. Making bundles is a development workflow and it will be useless in pure runtime environment. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Maybe what we need is a git activity that kids interested in developing can download??? Ideally for me, git is the right dependency for SDK stringSoftware/strikeSugar strikeDevelopment/strikeDoers' Kit we don't have right now. Using activity, in current state of .xo format, will mean either bundling git (sounds weird) or not working in defualt Sugar environment (but making it working, will mean blowing SP all time w/o the limit). The right way for me, is adding PackageKit dependency to SP, that might be used directly (e.g, using PK DBus in the bundler) or indirectly in Sweets (that might be added to SP as well). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding git to Sugar platform?
On Fri, Oct 21, 2011 at 02:31:54PM +, Aleksey Lim wrote: On Fri, Oct 21, 2011 at 08:28:57AM -0400, Walter Bender wrote: On Fri, Oct 21, 2011 at 8:17 AM, Aleksey Lim alsr...@activitycentral.orgwrote: On Fri, Oct 21, 2011 at 11:02:58AM +0200, Simon Schampijer wrote: Hi, the bundlebuilder uses git to package the tarballs and xo-bundles [1]. I would therefore say, the git should be a dependency for the sugar-toolkit and should be added to the Platform components. Any objections about that? I personally treated SP as a runtime dependencies stack. Making bundles is a development workflow and it will be useless in pure runtime environment. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Maybe what we need is a git activity that kids interested in developing can download??? Ideally for me, git is the right dependency for SDK stringSoftware/strikeSugar strikeDevelopment/strikeDoers' Kit we don't have right now. Using activity, in current state of .xo format, will mean either bundling git (sounds weird) or not working in defualt Sugar environment (but making it working, will mean blowing SP all time w/o the limit). The right way for me, is adding PackageKit dependency to SP, that might be used directly (e.g, using PK DBus in the bundler) or indirectly in Sweets (that might be added to SP as well). For indirect usage in Sweets, I meant something like subrocess.check_call(['sweets', 'git', ...]) i.e, hight level call to lauch git with installing it from PackageKit if there is such need. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SWEETS] Pristine glucose in sdk/ and dextrose in dextrose/
Hi all! There was sdk/sugar sweet that supported some Dextrose patches. For now, there are two sweets: sdk/sugar, pristine Glucose 0.95developer 0.94.1 stable 0.92.4 stable 0.88.1 stable 0.84.11 stable dextrose/sugar, pristine Glucose with Dextrose patches 0.94.1 testing 0.88.1 stable As usual, all of these versions might be launched just by mentioning needed version, e.g.: sweets dextrose/sugar = 0.94 These sweets were tested only on several Ubuntu and Fedora releases, if it doesn't work in your environment, please file a bug http://bugs.sugarlabs.org/newticket?component=sweets More information about Sweets usage http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities packaging and l10n
On Fri, Oct 21, 2011 at 04:06:48PM -0300, Gonzalo Odiard wrote: In a few activities now (Terminal and ImageViewer) but has happened before many times, the .po files are updated but the activity doesn't have the translation available to the user in the .mo files. This is because, is needed with sugar 0.94 do: ./setup.py build before ./setup.py dist_xo The problem w/ ImageViewer is in setup.py, it uses `sweets dist_xo` instead, will fix this issue in sweets (it skipped locale/ directory because it was mentioned in the .gitignore file) and reupload all activities. btw, I didn't get bugs.sl.o notification because component's owner contained several accounts. For now, it is fixed for all components. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Tux Paint - Save and new
On Fri, Oct 21, 2011 at 09:12:31PM +, Alan Jhonn Aguiar Schwyn wrote: This was the comments from an Uruguayab teacher.. I tell you why it is important for teachers to have the option within the program. When the teacher proposes to use will likely be to put together a sequence of something, having to close the program and reopen it for every film set, is somewhat cumbersome, especially with children in the early stages (initial, 1 and 2). Other: is very useful image file of the seals, especially when there are difficult to get them on the internet connection to be used in creating games of memory, for example, and any other proposal in which images are needed, especially if we consider that many of these are photos. Another advantage: the sheets are created within the program and open the option can be viewed all at once, allowing you to quickly eliminate those that do not serve us. Surely other teachers on the list you can add some more ... So, it's very good that can be saved in the journal and take pictures of him but would also be good to have the option to slide within the program. Last, I think what is more complicated obstacle of having to always open new business from home. Viewed from the standpoint of you, developers, avoid useless files Viewed from the perspective of teachers, we complicate our lives, we risk losing ongoing work in process if you do not remember to tell children marked start again when it comes to class assignments. It would be very interesting that we could ever make the proper connection and teacher developers to implement changes that are really useful for classroom use. I add another tip. My daughter draws very well and loves to draw. With 10 years I will not sit or Inkscape use The Gimp, I feel that use Tuxpaint. Okay, it's for his age, and really nice stuff out. But ups! draw something new means losing the previous job. Is that fair? No. No one uses a single sheet to draw, using multiple, and nobody thinks you delete a picture but perfect for another. It makes no sense. But I ask you a child has no right to be creative, draw a long and well? Why assume a priori that children draw more or less, to hang out and you're not cleared to occupy space? That is the other utility Tuxpaint slides. And please do not tell me that there is another program to do the same. Children are not graphic designers! They'll learn to use other programs. Resuming: she think that the slides view is necessary, maintenance the integration with the jounal... But make it is can be complicated, or not optimized function... A slow process: for each entry in the journal... if it's an image... scale to show.. show in the tuxpaint Tux Paint will behave like regular activity but preserving useful features like Load/New. I think that is good idea.. Another activitys have and dialog.. You can re-use it.. Like the Read activity... hehe, not sure. TuxPaint is written in C. Though, it is more a problem w/ time, I CCed Rafael who started something, afaik. If there are other people who can help w/ adding New/Open startup dialog (at the end, it shouldn't be hard, the dialog is already importanted in Tuxpaint, the only thing that is needed is popping it up on startup). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sweets Distribution
Hi all!
The Sweets Distribution is already mentioned on SL wiki, but it wasn't
publicly announced. So, that's it
== Summary ==
The major purposes for this distribution:
* If [[Platform_Team/Guide/Sweets_Usage#Sugar_via_Sweets|Sweets]] is
more appropriate for personal usage, Sweets Distribution might be
useful for Sugar distributors, e.g., special GNU/Linux distributions
targeted on Sugar usage;
** Some times, it is mostly impossible to have recent Sugar release in
not recent GNU/Linux distributions, e.g., LTS releases, and Sweets
Distribution will be helpful in that case;
* Sweets Distribution is only about packaging
[[Platform_Team/Guide/Sweets_Usage#Sugar_via_Sweets|Sugar sweets]],
thus, it is zero-cost effort; the downside, it is impossible to add
Sweets Distribution's packages to official repositories of GNU/Linux
distributions.
This is a special, only Sugar, distribution. The key points that make
Sweets Distribution different to the rest of
[[Community/Distributions|Distributions]] are:
* Sweets Distribution is formed as a 3rd party repository, i.e., it is
not regular GNU/Linux distribution;
* It [[#Releases|supports]] several GNU/Linux distributions at the same
time;
* Packages from these repositories do not interfere with the rest of the
system, e.g., it is possible to use Sugar from Sweets Distribution and
Sugar from official repositories at the same time.
== Content ==
Sweets Distribution contains only Glucose, Fructose and Sugar Platform
dependencies. The reason to not include more activities:
* people can install activities at any time,
* it is easy to support Sweets Distribution based Sugar distribution
with including activities that are more appropriate for the current
use case.
== Releases ==
All releases are based on {{Code|dextrose/sugar}} sweet and contain
pristine Glucose and [[Dextrose]] patches.
The following list is a list of Sweets Distribution releases and
GNU/Linux repositories they support. The list of supported GNU/Linux
distributions is populated entirely on purpose, e.g., Ubuntu packages
are being used in [[Community/Distributions/Trisquel|Trisquel]]. Please,
[[Platform_Team/Sweets/Feedback|submit]] a request if you need more.
=== Sweets Distribution 0.88 ===
Stable [[Dextrose/2|Dextrose 2]] based releases:
*
[http://download.sugarlabs.org/packages/SweetsDistribution:/0.88/Ubuntu-10.04/
Ubuntu-10.04]
*
[http://download.sugarlabs.org/packages/SweetsDistribution:/0.88/Ubuntu-10.10/
Ubuntu-10.10]
=== Sweets Distribution 0.94 ===
Testing [[Dextrose/2|Dextrose 3]] based releases:
*
[http://download.sugarlabs.org/packages/SweetsDistribution:/0.94/Ubuntu-11.04/
Ubuntu-11.04]
== Installation ==
=== Ubuntu ===
Import repository gpg key. For example for
[http://download.sugarlabs.org/packages/SweetsDistribution:/0.94/Ubuntu-11.04/
Ubuntu-11.04]
repository, type in a terminal:
curl
http://download.sugarlabs.org/packages/SweetsDistribution:/0.94/Ubuntu-11.04/Release.key
| sudo apt-key add -
Refresh information about repositories:
sudo apt-get update
Install full Sweets Distribution, i.e., Sugar Shell and Fructose
activities:
sudo apt-get install sweets-distribution
Install only Sugar Shell:
sudo apt-get install sweets-sugar
== Usage ==
To run Sugar in emulator mode, select ''Education/Sugar''
application menu item or type in a terminal:
sweets-sugar-emulator
To login into Sugar session, choose ''Sweets Distribution'' session
type.
== Feedback ==
* [http://bugs.sugarlabs.org/newticket?component=sweets Submit] your bug
report or feature request.
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sweets Distribution
On Sun, Oct 23, 2011 at 03:39:06PM +, Aleksey Lim wrote: Hi all! The Sweets Distribution is already mentioned on SL wiki, but it wasn't publicly announced. So, that's it The home page for Sweets Distribution http://wiki.sugarlabs.org/go/Community/Distributions/Sweets_Distribution -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Tux Paint - Save and new
On Sun, Oct 23, 2011 at 05:36:06PM -0300, Gonzalo Odiard wrote: What you need in Paint activity not available today? Well, it depends on a purpose... ;) If purpose is exactly to paint something, then for sure, Paint is just works. But imagine for a bit that you are not a developer but a person [maybe young person] who is just opening this feature. From this perspective, what we will get after opening two these applications: * Paint, all-grey screen with standard set of painting primitives * Tuxpaint, colorful screen when even standard painting primitives contain something special, but there are bunch of another places to explore and get excited I guess, the winner is obvious. I don't mean, do nothing, use what already exists but that the difference should be clear between these two examples. And, if someone is willing to test his strength and create another painting application (ie, sugar idea is exactly about learning by doing) because his favorite PL is not C, why not using best the example (Tuxpaint) and create something better. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Tux Paint - Save and new
On Sun, Oct 23, 2011 at 07:47:01PM -0300, Gonzalo Odiard wrote: On Sun, Oct 23, 2011 at 7:01 PM, Aleksey Lim alsr...@activitycentral.orgwrote: On Sun, Oct 23, 2011 at 05:36:06PM -0300, Gonzalo Odiard wrote: What you need in Paint activity not available today? Well, it depends on a purpose... ;) If purpose is exactly to paint something, then for sure, Paint is just works. But imagine for a bit that you are not a developer but a person [maybe young person] who is just opening this feature. From this perspective, what we will get after opening two these applications: * Paint, all-grey screen with standard set of painting primitives * Tuxpaint, colorful screen when even standard painting primitives contain something special, but there are bunch of another places to explore and get excited Hmm, then we need re-think sugar ui at all! :) For example, I prefer to have a flat and rectangular table to work at. But that doesn't mean that all things I'm creating sitting at this table are all time flat and rectangular. In other words, having simple and clean UI for the Shell, basic/common tools/activities, and optional widgets to use in other activities (for people who prefer following Shell's UI), thats good. For me, trying to make all activities (not Shell and Fructose) all gray, well is a kind of overkill. I am trying to improve Paint, but without loosing a simple and integrated experience. Manuel is planning add different pencils (most of the backend work is alreday done to support stamps) and add to the pencils the possibility to follow the movement direction. About adding clip art, I think would be better if we can found a solution to share resources, and add media useful to many activities. Fine, if purpose is not only making grey activities. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SWEETS] Sweets v1.0.1 release and Sugar sweets updates
Hi all! == Sweets-1.0.1 == Major features in this release: * Suggested dependencies. These are recommended dependencies that will be used only if -S|--force-suggested sweets command-line argument was specified. There is new recipe option, suggests for these dependencies http://wiki.sugarlabs.org/go/Platform_Team/Recipe_Specification#Common_options * Optional dependencies. If there are no implementations to use for these dependencies, they will be discarded without errors. Optional dependencies need to be wrapped to square brackets http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Dependencies Use the http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Upgrade instructions to upgrade your Sweets. == Sugar sweets == As a result of new Sweets' features, Sugar sweets can be launched in recent Fedora 16 environment that contains evince without pygtk binding and doesn't have hal (need for not recent Sugar versions). Also, sdk/sugar and dextrose/sugar were changed to keep Fructose as suggested dependencies instead of using :shell command. To refresh local feeds, run sweets with -R command-line argument for the first time. For example to start sugar in emulator mode without fetching Fructose dependencies, use: sweets -R sdk/sugar:emulator to fetch Fructose dependencies, e.g., xulrunner-1.9.2 to start Browse in Fedora-16, use: sweets -RS sdk/sugar:emulator All Sugar sweets depends on custom telepathy-mission-control to avoid gnome-keyring usage from telepathy-mission-control versions that come with distributions. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Multi-lingual relaying on Sugar IRC channles is stopped
Hi all! Starting from the recent times, translation[1] on Sugar IRC channels stopped working properly (messages started being skipped). This feature is disabled entirely for now, since missed IRC posts on translated channels might lead to many confusions. Infrastructure Team is working on the problem to fix this issue as soon as possible. Sorry for inconveniences. [1] http://wiki.sugarlabs.org/go/Service/meeting/Usage#Multi-lingual_relaying -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Sweets, Zero Install based Package Management System for Sugar
On Sun, Oct 02, 2011 at 05:14:47PM +, Aleksey Lim wrote: Hi all! The original page for these release notes is http://wiki.sugarlabs.org/go/Platform_Team/Sweets/1.0/Notes There is an ongoing discussion[1][2] about synergy between Sugar and Zero Install communities and Policy draft[3] for SL's instance of Open Build System[4]. [1] http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/4627 [2] http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/4695 [3] http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System/Policy [4] http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Multi-lingual relaying on Sugar IRC channles is stopped
On Sun, Oct 30, 2011 at 06:26:33PM +, Aleksey Lim wrote: Hi all! Starting from the recent times, translation[1] on Sugar IRC channels stopped working properly (messages started being skipped). This feature is disabled entirely for now, since missed IRC posts on translated channels might lead to many confusions. Infrastructure Team is working on the problem to fix this issue as soon as possible. Sorry for inconveniences. [1] http://wiki.sugarlabs.org/go/Service/meeting/Usage#Multi-lingual_relaying The problem is that Sugar Labs infrastructure used Google translation API, but Google stopped providing translation API as a free (free-as-a-beer) service[1]. So need a replacement. In fact, the original problem is that Google API, as a free-as-a-beer solution that doesn't have, as an API, handles to accept contribution to improve the quality of translation or customize it for people needs, was used as a translation backend for Sugar Labs IRC channels (thanks to the author of these lines). Because, it is obvious that just translation is not the right final goal that should be taken within the Sugar Labs. The purpose should be to let people teach new languages, do it in cooperation with another people and contribute to the free (free-as-a-speech) database that might be reused by another learners. Obviously, using another, as a replacement of Google API, free-as-a-beer translation API is the wrong way to go. There is the Apertium[2] project that might be a good candidate to achieve goals mentioned above. Apertium is a free/open-source platform for developing rule-based machine translation systems. There are 28 language pairs [3] that are stated as stable in Apertium, and there are a bunch of them in development stage. It supports less languages than Google does but it might be the right basis to start, i.e., * Looks like our most need is en-es/es-en, Apertium can provide it right now; * Having a Web application, a la translate.sugarlabs.org, we can accept contributions from the community to customize current language pairs and add new ones. The current plan is setting up en-es/es-en translation on Sugar IRC channels to let people try it. [1] http://code.google.com/apis/language/translate/overview.html [2] http://www.apertium.org/ [3] http://wiki.apertium.org/wiki/Main_Page -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Multi-lingual relaying on Sugar IRC channles is stopped
On Tue, Nov 01, 2011 at 12:44:55PM +, Aleksey Lim wrote: On Sun, Oct 30, 2011 at 06:26:33PM +, Aleksey Lim wrote: Hi all! Starting from the recent times, translation[1] on Sugar IRC channels stopped working properly (messages started being skipped). This feature is disabled entirely for now, since missed IRC posts on translated channels might lead to many confusions. Infrastructure Team is working on the problem to fix this issue as soon as possible. Sorry for inconveniences. [1] http://wiki.sugarlabs.org/go/Service/meeting/Usage#Multi-lingual_relaying Apertium is a free/open-source platform for developing rule-based machine translation systems. There are 28 language pairs [3] that are stated as stable in Apertium, and there are a bunch of them in development stage. It supports less languages than Google does but it might be the right basis to start, i.e., Sorry, I didn't attach the Apertium mailing list discussion url http://sourceforge.net/mailarchive/message.php?msg_id=28303600 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] Multi-lingual relaying on Sugar IRC channles is stopped
On Tue, Nov 01, 2011 at 08:57:26AM -0400, Chris Leonard wrote: Another possible option is to look into what kind of API might be available to Microsoft Translator http://www.microsofttranslator.com/ I know there must be something as this is called and used as a source of suggestions by Virtaal ( a PO editor produced by the makers of Pootle). fwolff over on #pootle might have some more info on how he implemented this in code. I'm writing in PM because don't want to take part in free-as-a-speech vs. free-as-a-beer discussion. But my another reason to not following another free-as-a-beer solution is that most likely, the original purpose of Sugar (literally) has much less meaning than possible success in joining several free-as-a-speech communities in a synergy, i.e., here Sugar and Apertium. Using another, free-as-a-beer, translation API will be less useful in that case. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] [IAEP] Multi-lingual relaying on Sugar IRC channles is stopped
On Tue, Nov 01, 2011 at 12:44:56PM +, Aleksey Lim wrote: On Sun, Oct 30, 2011 at 06:26:33PM +, Aleksey Lim wrote: Hi all! Starting from the recent times, translation[1] on Sugar IRC channels stopped working properly (messages started being skipped). This feature is disabled entirely for now, since missed IRC posts on translated channels might lead to many confusions. Infrastructure Team is working on the problem to fix this issue as soon as possible. Sorry for inconveniences. [1] http://wiki.sugarlabs.org/go/Service/meeting/Usage#Multi-lingual_relaying The problem is that Sugar Labs infrastructure used Google translation API, but Google stopped providing translation API as a free (free-as-a-beer) service[1]. So need a replacement. In fact, the original problem is that Google API, as a free-as-a-beer solution that doesn't have, as an API, handles to accept contribution to improve the quality of translation or customize it for people needs, was used as a translation backend for Sugar Labs IRC channels (thanks to the author of these lines). Because, it is obvious that just translation is not the right final goal that should be taken within the Sugar Labs. The purpose should be to let people teach new languages, do it in cooperation with another people and contribute to the free (free-as-a-speech) database that might be reused by another learners. Obviously, using another, as a replacement of Google API, free-as-a-beer translation API is the wrong way to go. There is the Apertium[2] project that might be a good candidate to achieve goals mentioned above. Apertium is a free/open-source platform for developing rule-based machine translation systems. There are 28 language pairs [3] that are stated as stable in Apertium, and there are a bunch of them in development stage. It supports less languages than Google does but it might be the right basis to start, i.e., * Looks like our most need is en-es/es-en, Apertium can provide it right now; * Having a Web application, a la translate.sugarlabs.org, we can accept contributions from the community to customize current language pairs and add new ones. The current plan is setting up en-es/es-en translation on Sugar IRC channels to let people try it. Unfortunately, I'm really busy in Paraguay these days before traveling to Lima. Help from volunteers to setup Apertium instance on jita.sugarlabs.org (there are useful hints on [4) is welcome. [1] http://code.google.com/apis/language/translate/overview.html [2] http://www.apertium.org/ [3] http://wiki.apertium.org/wiki/Main_Page [4] http://sourceforge.net/mailarchive/message.php?msg_id=28303600 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Story Builder-19
On Thu, Nov 03, 2011 at 07:19:54AM +0530, Kalpa Welivitigoda wrote: On Thu, Nov 3, 2011 at 12:23 AM, Sugar Labs Activities activit...@sugarlabs.org wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4073 Sugar Platform: 0.82 - 0.94 Download Now: http://activities.sugarlabs.org/downloads/file/27714/story_builder-19.xo If you can direct me to the tar ball I may be able to package this for fedora Sorry, I'm busy these days and track regular only emails directly sent to my address. http://download.sugarlabs.org/sources/honey/StoryBuilder/StoryBuilder-19.tar.bz2 Release notes: * Workaround Sugar's PYTHONPATH setting behaviour #3224 Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Best Regards, Kalpa Pathum Welivitigoda http://about.me/callkalpa ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SWEETS] Sweets v1.0.2 release
== Sweets-1.0.2 == Major features in this release: * Self-contained binary bundles http://wiki.sugarlabs.org/go/Platform_Team/Sweets/Architecture#Self-contained_binary_bundles Use the http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Upgrade instructions to upgrade your Sweets. The funny usage: sweets bindist sdk/sugar:emulator that will bundle Sugar Shell and Sugar Platform dependencies (provided via Sweets) to one tarball. To run such sugar, after extracting to the current directory: sugar/emulator ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SWEETS] Sweets v1.0.2 release
On Wed, Nov 23, 2011 at 04:54:01PM -0300, Gonzalo Odiard wrote: On Wed, Nov 23, 2011 at 4:00 PM, Rafael Ortiz raf...@activitycentral.comwrote: Hi Aleksey On Tue, Nov 22, 2011 at 8:31 PM, Aleksey Lim alsr...@activitycentral.orgwrote: == Sweets-1.0.2 == I tested this version using dextrose and experienced no problems :). Major features in this release: * Self-contained binary bundles http://wiki.sugarlabs.org/go/Platform_Team/Sweets/Architecture#Self-contained_binary_bundles What means this? I like many of the ideas in sweets (like adding more metadata to activity.info) but as isolated does not reach its full potential. This is exactly what wiki page says, ie, for special cases only. On the same wiki page this is the 3rd delivery way from 4 existing for now. For example, I need a way to run some software w/ not trivial dependencies in foreign environment only once, and setting up Zero Install/Sweets/PackageKit is an overkill. Using a self-contained bundle is exactly the way. I'm not sure that it might be useful for binary based activities (even as an intermediate solution), as Rafael, mentioned. Because such self contained binary bundles should be launched exactly in the same environment (for now, people who provide bundles that tends to be self contained need to support bunch of distro releases and platform arches). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Error i some activities in debian (possibly telepathy problem)
On Wed, Nov 16, 2011 at 02:20:03PM -0300, Alvar Maciel wrote: Hi to all, I can compile without problems sugar form jhbuild (I'm in the early stage of testing) but wen I run suga, some activities fail. I was looking the logs I think that is a problem with some library of thelepaty what do you think? I post here the logs of: Write Terminal web read Write activity log 1321463507.910492 DEBUG root: datastore.get 1321463507.947327 DEBUG root: Calling GetActivity on /org/freedesktop/Telepathy/Account/salut/local_xmpp/account0 Traceback (most recent call last): File /home/debian/sugar-jhbuild/install/bin/sugar-activity, line 21, in module main.main() File /home/debian/sugar-jhbuild/install/lib/python2.6/site-packages/sugar/activity/main.py, line 158, in main create_activity_instance(activity_constructor, activity_handle) File /home/debian/sugar-jhbuild/install/lib/python2.6/site-packages/sugar/activity/main.py, line 37, in create_activity_instance activity = constructor(handle) File /opt/sugar-jhbuild/install/share/sugar/activities/Write.activity/AbiWordActivity.py, line 59, in __init__ activity.Activity.__init__(self, handle) File /home/debian/sugar-jhbuild/install/lib/python2.6/site-packages/sugar/activity/activity.py, line 335, in __init__ warn_if_none=False) File /home/debian/sugar-jhbuild/install/lib/python2.6/site-packages/sugar/presence/presenceservice.py, line 89, in get_activity dbus_interface=CONN_INTERFACE_ACTIVITY_PROPERTIES) File /usr/lib/pymodules/python2.6/dbus/proxies.py, line 68, in __call__ return self._proxy_method(*args, **keywords) File /usr/lib/pymodules/python2.6/dbus/proxies.py, line 140, in __call__ **keywords) File /usr/lib/pymodules/python2.6/dbus/connection.py, line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method GetActivity with signature s on interface org.laptop.Telepathy.ActivityProperties doesn't exist Could you check if telepathy-gabble wasn't restarted (eg, its pid before and after launching an activity). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Usage statistics gathering
On Tue, Nov 22, 2011 at 08:23:49AM +0500, Sebastian Silva wrote: Hi Sugar Community, /* En castellano más abajo */ I would like to propose this feature for inclusion in the next Sugar release: / To gather usage statistics in separate logs from error logs (up to a storage limit). The software improvement process requires usage statistics data to learn from our users./ http://wiki.sugarlabs.org/go/Features/Statistics_gathering /* Castellano */ Me gustaría proponer la siguiente característica para inclusión en la próxima versión de Sugar: /La recolección de estadísticas de uso en registros separados de los registros de error (hasta un límite de almacenamiento). El proceso de mejoramiento de software require de estadísticas de uso para aprender de nuestros usuarios. / http://wiki.sugarlabs.org/go/Features/Statistics_gathering Regards, Sebastian INHO, the same data might be gathered w/o any sugar shell coding at all, i.e., using things like DBus and X11 events sniffing. That should let keepping shell code more clear (not monitoring code messing w/ regular one) and gathering feature more localized (if someone needs it, just run the monitor, if you don't need it, do not bother about possible sniffing in sugar code at all). http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Usage_Statistics#Monitor As it was announced in SSK-1.0 release notes, this feature will be a part of SSK-1.2 release. http://wiki.sugarlabs.org/go/Sugar_Server_Kit/1.2/Todo -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SWEETS] Sweets v1.0.3 release
== Sweets-1.0.3 == Major features in this release: * Do not let PackageKit fail on Fedora-11 before installing new packages * Workaround for #3245 * Reusing SUGAR_LOGGER_LEVEL is not useful for running sweets command from Terminal activity Use the http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Upgrade instructions to upgrade your Sweets. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Usage statistics gathering
On Mon, Nov 28, 2011 at 10:15:06AM +1100, James Cameron wrote: On Mon, Nov 28, 2011 at 09:43:46AM +1100, Sridhar Dhanapalan wrote: I'm confused - there seem to be two implementations of what looks to be the same thing! http://wiki.sugarlabs.org/go/Sugar_Server_Kit/Usage_Statistics#Monitor http://wiki.sugarlabs.org/go/Features/Statistics_gathering No, they appear to be entirely different implementations with similar names, possibly misusing the term statistics. What they both lack is any detailed requirements from a statistician or researcher. Perhaps you could engage your respected researchers to provide a list of data that would be meaningful to capture? Reasoning behind each data would be useful. The background, is: Sebastian was working on the initial implementation using the model of having statistics code in the shell sources. The new model should be more reliable and useful from several points of view (I already posted reasons to this thread). The 1st step on this way is (which doesn't relate to possible implementations): 1) pure technical implementation 2) fulfil the needs of reserchers who will uswe statistics To accomplish this step: * Sridhar is working on 2) for Australia, Peru might need some special options for 2) and that will be solved on the way, since all devs of this feature are in Peru right now * SSK's implementation for 1) is pretty low level by design, ie, blocks that will be composed to the full picture to fullfil any possible 2) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Usage statistics gathering
On Mon, Nov 28, 2011 at 04:33:44PM +1100, Sridhar Dhanapalan wrote: We face similar challenges - we only have a few XS-AU servers out there. We'll have to cache information and sync it back to the server once Internet connectivity is re-established. For that reason, I'm planing to work on a pilot program for school server on a XO for Peru, as you said, it is similar to Australian needs and will be useful to try to cover bother regions to learn about needed functionality. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Usage statistics gathering
On Tue, Nov 29, 2011 at 10:56:50AM -0800, Sameer Verma wrote: On Tue, Nov 29, 2011 at 9:18 AM, Aleksey Lim alsr...@activitycentral.org wrote: On Mon, Nov 28, 2011 at 04:33:44PM +1100, Sridhar Dhanapalan wrote: We face similar challenges - we only have a few XS-AU servers out there. We'll have to cache information and sync it back to the server once Internet connectivity is re-established. For that reason, I'm planing to work on a pilot program for school server on a XO for Peru, as you said, it is similar to Australian needs and will be useful to try to cover bother regions to learn about needed functionality. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel FWIW, we used a school server late into the process in Jamaica. We gave out the XOs unregistered, but with their GNOME switching icon removed. At the end of the term, we got all the XOs registered with the school server and backed up all the journals on the server over the next few days. Once we got all the journals, we wiped the XOs for the next term/batch of children. We've been looking at ParaguayEduca's scripts to gather data from the journals and process them, but not much has come of it as yet. http://wiki.paraguayeduca.org/index.php/Analisis_de_Uso_de_Actividades The scripts do not work out of the box (or we don't know how to use them). I agree that in instances where a school server is missing, there needs to be a way to gather logs on the XO/in Sugar, but by taking a school server and registering all XOs with it, it is possible to gather Journals much later in the process. Will ping pyeduca people. That will be useful to have a parser for journals as an option for getting some stats. Though, realtime monitor seems to be the 1st option by default, since it can take more info. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proxy Control Panel (Was: New Dextrose-3...)
On Tue, Nov 29, 2011 at 02:59:07PM -0500, Bernie Innocenti wrote: On Tue, 2011-11-29 at 23:21 +0530, Anish Mangal wrote: That patch was posted on @dx mailing list and is under review. https://patchwork.sugarlabs.org/patch/1041/ Could someone please post a screenshot of the proxy control panel? http://wiki.sugarlabs.org/go/Features/Proxy_Settings#UI_Design Also, has anyone considered merging this with the Network control panel? If we don't contain the growth, we'll soon have more control panel items than Vista (-: My points to not doing that from beginning, were: * it is sepparate dialog in Gnome-2 (dunno about Gnome-3) and Firefox * we don't have tabs in CP components and having all Network related stuff in one CP component will make it huge * we already have separate CP components for Network and Modem In any case, this is the exact question to people who are skilled in GUI usability field, not to developers. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proxy Control Panel (Was: New Dextrose-3...)
On Tue, Nov 29, 2011 at 08:26:46PM +, Peter Robinson wrote: On Tue, Nov 29, 2011 at 8:14 PM, Aleksey Lim alsr...@activitycentral.org wrote: On Tue, Nov 29, 2011 at 02:59:07PM -0500, Bernie Innocenti wrote: On Tue, 2011-11-29 at 23:21 +0530, Anish Mangal wrote: That patch was posted on @dx mailing list and is under review. https://patchwork.sugarlabs.org/patch/1041/ Could someone please post a screenshot of the proxy control panel? http://wiki.sugarlabs.org/go/Features/Proxy_Settings#UI_Design Also, has anyone considered merging this with the Network control panel? If we don't contain the growth, we'll soon have more control panel items than Vista (-: My points to not doing that from beginning, were: * it is sepparate dialog in Gnome-2 (dunno about Gnome-3) and Firefox Its a separate tab in the Network dialog * we don't have tabs in CP components and having all Network related stuff in one CP component will make it huge It would be too big without tabs. * we already have separate CP components for Network and Modem If we had tabs I would suggest merging them all but we don't so I think they're best separate for the time being. In any case, this is the exact question to people who are skilled in GUI usability field, not to developers. I would put the automatic config option above the manual option. It was implemented that way, because it exactly mimics the Proxy settings dialog in Gnome/Mozilla. Not sure if it makes sense to invent new usage workflow for people who will use it. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SSK] Sugar Server Kit 1.1 release
== Summary ==
This is the first Sugar Server Kit release that is being positioned as
ready for using in the field, thanks to the
[[Sugar_Server_Kit/Solutions/Paraguay_Educa_Server|Paraguayan pilot
program]]. This release should fulfill needs similar to that were faced
in Paraguay. The next step will be proving this system in restricted
environments within the
[[Sugar_Server_Kit/Solutions/Server_on_an_XO|Server on an XO]] project
for SSK-1.2.
This is also the first release that is following the
[[Sugar_Server_Kit/Release_plan|Sugar Server Kit releasing plan]].
== Design changes ==
Changes made from the initial,
[[Sugar_Server_Kit/1.0/Notes#Components|1.0]], Sugar Server Kit
implementation.
'''Unified API for sugar-server'''
:: The major way to interact with sugar-server for now, is a
[[Sugar_Server_Kit/sugar-server#Services|RESTfull API]]. The API
inherited from the OLPC XS is preserved when it is possible, e.g.,
except Journal backups that were implemented differently from the
begining.
'''sugar-client'''
:: [[Sugar_Server_Kit/sugar-client|sugar-client]] project is intended to
be the only one on a client side to cover all possible interactions with
a school server.
'''Clients are identified by profile UIDs on a server'''
:: In comparing with 1.0 implementation, and OLPC XS as well,
sugar-server-1.1
[[Sugar_Server_Kit/sugar-server#User_identity_models|identifies]]
clients by UID that is unique for particular user's profile, i.e., not
by XO's UUIDs. That was done to cover usecases when the same hardware is
being used for several users.
See the [[Sugar_Server_Kit/Architecture|design overview]] for more
details.
== Final solution ==
This release is entirely based on experience gotten during the work on
Paraguayan pilot program, i.e., the functionality of Sugar Server Kit
was improved and proven by using it in a school. As a result, the
[[Sugar_Server_Kit/Solutions/Paraguay_Educa_Server|paraguayeduca-server]],
the final Sugar Server Kit based solution, was created.
It covers the full life cycle of using school servers in environments
similar to Paraguay, i.e.:
* Install Kit on USB stick to:
** install new server,
** migrate from existing installation,
** migrate from existing OLPC XS installation;
* Post-install school server automated tests;
* Initial setup for the Mothership to support new school servers;
* New client side behaviour based on sugar-client.
== Supported platforms ==
* LTS versions of Trisquel-4.1 (Ubuntu-10.04) GNU/Linux distributions.
Fedora-14 will be added to supported platforms in
[[Sugar_Server_Kit/1.2/Todo|1.2]] to provide
[[Sugar_Server_Kit/Solutions/Server_on_an_XO|Server on an XO]] solution.
== Components ==
In comparing with [[Sugar_Server_Kit/1.0/Notes#Components|1.0]] release,
there are the following changes:
* [[Sugar_Server_Kit/sugar-client|sugar-client]]
new component to interact with a school server on a client side;
* ''sugaroid''
was renamed to [[Sugar_Server_Kit/sugar-unit|sugar-unit]] to expose more
general purpose of this project;
* ''sugar-server-demoxo''
was removed as an Sugar Server Kit component and will be back as
a supported [[Sugar_Server_Kit/Solutions/Server_on_an_XO|final solution]]
in [[Sugar_Server_Kit/1.2/Todo|1.2]].
See also the [[Sugar_Server_Kit#Components|full list]] of Sugar Server
Kit components.
== Getting the release ==
Sources in tarballs can be found on
[https://packages.sugarlabs.org/project/show?project=Server%3A1
package.sugarlabs.org] and in {{Code|master-1.1}} branches in
repositories on [http://git.sugarlabs.org/server git.sugarlabs.org].
Binaries for supported distributions can be found on
[http://download.sugarlabs.org/packages/Server:/1/
download.sugarlabs.org].
== Looking forward ==
The next, [[Sugar_Server_Kit/1.2|1.2]], release should contain the
following major features:
* collecting [[Sugar_Server_Kit/Usage_Statistics|usage statistics]],
* return sugar-server-demoxo as a full featured Sugar Server Kit
* [[Sugar_Server_Kit/Solutions/Server_on_an_XO|based solution]].
See the [[Sugar_Server_Kit/1.2/Todo|1.2 TODO list]] for more details.
== Credits ==
* [http://activitycentral.com/ Activity Central] for supporting during
the work on 1.1 release.
* [http://www.paraguayeduca.org/ Paraguay Educa] for supporting during
the work on 1.1 release, sharing deployment experience and needs,
making it possible to have a pilot program in one of Caacupe schools.
* The [[Wiki Team]] for continuous polishing [[Sugar Server Kit]] wiki
pages.
* The [[Infrastructure Team]] to support servers and services that are
being used within the [[Sugar Server Kit]] project.
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What should be the best set in order to develop for Sugar in Ubuntu, today ?
On Fri, Dec 02, 2011 at 10:24:24AM +0100, laurent bernabe wrote: Hello everyone, I have a laptop computer that can run both windows 7 and ubuntu linux. My question is : - what is the best way to be prepeared to develop in linux, as it is the best paltform for programming ? - Should i install sugar ubuntu package ? Should i use Fedora instead ? Thats up to you, ie, your preferences regarding the GNU/Linux distributions. In some cases distributions have well packaged Sugar (Fedora), and you can just install these packages, in other cases might not. In any case, there is a distribution agnostic solution, Sweets[1]. It is designed to work on top of major GNU/Linux distributions to provide to same Sugar software versions for all of them. For example, it should work on Ubuntu-11.10, providing recent (and a couple of other verisons) Sugar. Moreover, Sweets is designed to be useful[3] in development process as well. For example for Sugar Shell sweets, it looks like: * checkout sources * launch sources using, e.g., `sweets PATH` command [1] http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage [2] http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Sugar_via_Sweets [3] http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Development_with_Sweets -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What should be the best set in order to develop for Sugar in Ubuntu, today ?
On Mon, Dec 05, 2011 at 11:48:40AM +0100, laurent bernabe wrote: Hello, Sorry for the late answer, I had to reinstall my Linux partition I've came back to Xubuntu Oenreric Ocelot (11.10), unfortunately before an advice has been given to this mailing list for Fedora 16 and Gnome 3. So i'm not able to follow it right now. So, in Xubuntu, I tried to install Sweet, but it tells me that = sweets-evince-python and sweets-hulaop dependencies could not be resolved So, should I come back to a Fedora distribution or go back to a Ubuntu 11.04 or lower ? Yeah, in case of evince, projects are migrating to gtk3 but sugar/activities doesn't support it for now. You can try to avoud using -S command line parameter, eg: sweets sdk/sugar:emulator or sweets dextrose/sugar:emulator Will see how to avoid confusion when sweets breakes w/ error... In any case, if need only Sugar Shell to run your activities and ones w/o hard system dependencies, it should be enough. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar emulator][Ubuntu 11.04] I can't install an activity (with the setup.py)
On Mon, Dec 05, 2011 at 06:28:15PM +0100, laurent bernabe wrote: Hello everyone, I am following the ActivitiesGuideSugar pdf from august 2010. - I've fetched tutorial source code for etext activity (chapter 5 : inheriting from Activity.activity) - I've modified, carefully i think, the svg picture with Inkscape and edited the xml structure - I installed the Sugar Sweets distribution But when I try to setup the activity from the emulator terminal, I get an error saying that there is no module called sugar.activity (the line in fault : from sugar.activity import bundlebuilder. Have I forgotten an important step in my sugar environment ? The downside of using Sweets Distribution (and Sweets) is that you are getting all libraries enabled only being in Sugar session. If you are not in Sugar, the most useful setup.py's command are duplicated in sweets command, e.g.: sweets dist_xo sweets dist_source sweets genpot -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar emulator][Ubuntu 11.04] I can't install an activity (with the setup.py)
On Mon, Dec 05, 2011 at 10:49:21PM +, Aleksey Lim wrote: On Mon, Dec 05, 2011 at 06:28:15PM +0100, laurent bernabe wrote: Hello everyone, I am following the ActivitiesGuideSugar pdf from august 2010. - I've fetched tutorial source code for etext activity (chapter 5 : inheriting from Activity.activity) - I've modified, carefully i think, the svg picture with Inkscape and edited the xml structure - I installed the Sugar Sweets distribution But when I try to setup the activity from the emulator terminal, I get an error saying that there is no module called sugar.activity (the line in fault : from sugar.activity import bundlebuilder. Have I forgotten an important step in my sugar environment ? The downside of using Sweets Distribution (and Sweets) is that you are getting all libraries enabled only being in Sugar session. If you are not in Sugar, the most useful setup.py's command are duplicated in sweets command, e.g.: sweets dist_xo sweets dist_source sweets genpot The reasons to have this functionality in sweet command are: * w/ Sweets, you have several versions of Sugar (and sugar-toolkit) * this functionality is common for all sugars * it will be easier to keep it in one place (not in every sugar version w/ possible chnages between versions and having a mess if you are switching between them) * the sweets command is exactly about development process, it is more obvious to have this functionality in development related command rather in sugar itself -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar emulator][Ubuntu 11.04] I can't install an activity (with the setup.py)
On Tue, Dec 06, 2011 at 12:02:02AM +0100, laurent bernabe wrote: Do you think an installation of Trisquel-Gnome-Sugar5.0-Alpha instead of Xubuntu will solve my problems ? Well, the whole purpose for Sweets is to avoid situation when people need to install the whole GNU/Linux distribution only to try/use/code Sugar. Becuase it is ridiculous overkill: * to change your favorite distro only for Sugar purpose, * Sugar Shell is only 5, mostly, Python based projects, * mostly, it is possible to handle a couple of non-Python based rependencies in your current distro. The sumary :) * do not switch distro to use sugar, * let's improve Sugar (maybe w/ Sweets, maybe w/ native packages in your favorite distro) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Multi-lingual relaying on Sugar IRC channles is stopped
On Sun, Oct 30, 2011 at 06:26:33PM +, Aleksey Lim wrote: Hi all! Starting from the recent times, translation[1] on Sugar IRC channels stopped working properly (messages started being skipped). This feature is disabled entirely for now, since missed IRC posts on translated channels might lead to many confusions. Infrastructure Team is working on the problem to fix this issue as soon as possible. Sorry for inconveniences. [1] http://wiki.sugarlabs.org/go/Service/meeting/Usage#Multi-lingual_relaying The multi-lingual relaying started functioning in testing mode. It is only Spanish language. Translation is provided by Apertium[1] project. If it is not good, please consider possibility to improve[2] it. Use meeting-test channel[3] for testing. [1] http://apertium.org [2] http://wiki.apertium.org/wiki/Contributing_to_an_existing_pair [3] http://chat.sugarlabs.org:9090/?channels=meeting-test -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar as a Green Design Pattern
On Mon, Dec 05, 2011 at 04:19:44PM +0100, Lionel Laské wrote: (sorry for cross posting, not sure that Support-gang was the best place, hope to have more luck here :-) Hi all, A friend of mine works on a book on Green Design Patterns: It means how a good software design could help to reduce the carbon footprint of a computer. In my opinion, Sugar is a good sample of that: the goal of reducing power consummation was include from the beginning to the design of the OS. In my mind, it is mostly nothing about Sugar [learning environment], but about OLPC's efforts of creating XO laptops. Moreover, Sugar [learning environment] might be considered as a bad example for Green Design Patterns, because is not all time efficient in case of computer's resources consumption :). So, I proposed to my friend to write a 2 pages contribution to the book. It could be a good way to talk to the OLPC project in a different approach. What do you think ? Do you have some links, story or anecdote that can help me to write on this subject ? Thank in advance. Best regards from France. Lionel. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SWEETS] Sweets v1.0.4/5 releases
== Sweets-1.0.4 == * Fix 'status -d' command == Sweets-1.0.5 == * Implement all, useful, setup.py's commands http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Developing_activities * Contine polishing the help messages Use the http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Upgrade instructions to upgrade your Sweets. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar emulator][Ubuntu 11.04] I can't install an activity (with the setup.py)
On Tue, Dec 06, 2011 at 01:04:18AM +0100, laurent bernabe wrote: Ok, that answer make really sense to me : particularly the distro changing avoidment ^^ I'll make all tests you want me too, if it can help to find what is wrong. (I've saved my system in a ghost image on last morning ^^) Since I can help only w/ Sweets (and can't w/ native packages).. Are you still on Ubuntu-11.04? If yes, the `sweets -S sdk/sugar:emulator` should work and I even can run Pippy w/o errors (though, I can't test camers example). For setup.py command, you need to upgrade your sweets to 1.0.5 http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage#Upgrade and use these installations http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Developing_activities 2011/12/6 Aleksey Lim alsr...@activitycentral.org On Tue, Dec 06, 2011 at 12:02:02AM +0100, laurent bernabe wrote: Do you think an installation of Trisquel-Gnome-Sugar5.0-Alpha instead of Xubuntu will solve my problems ? Well, the whole purpose for Sweets is to avoid situation when people need to install the whole GNU/Linux distribution only to try/use/code Sugar. Becuase it is ridiculous overkill: * to change your favorite distro only for Sugar purpose, * Sugar Shell is only 5, mostly, Python based projects, * mostly, it is possible to handle a couple of non-Python based rependencies in your current distro. The sumary :) * do not switch distro to use sugar, * let's improve Sugar (maybe w/ Sweets, maybe w/ native packages in your favorite distro) -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar emulator][Ubuntu 11.04] I can't install an activity (with the setup.py)
On Tue, Dec 06, 2011 at 09:53:51PM +0100, laurent bernabe wrote: Finally sweets sdk installation aborded : -- PackageKit install failed: The following packages have unmet dependencies: python-abiword: Depends: libabiword-2.8 (= 2.8.6-0.3) but 2.8.6-0.3build1 is to be installed (dep-resolution-failed) -- Use -D argument for debug info, -DD for full debuging output and tracebacks Yeah, that's ubuntu-11.04's long standing bug that was reported, fixed in proposed-updates but not in updates. You need to add proposed updates, and upgrade from them: sudo apt-add-repository 'deb http://us.archive.ubuntu.com/ubuntu/ natty-proposed main universe' sudo apt-get update sudo apt-get upgrade -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SWEETS] Sweets v1.0.4/5 releases
On Tue, Dec 06, 2011 at 05:43:42PM -0500, Rafael Ortiz wrote: On Tue, Dec 6, 2011 at 3:31 PM, Aleksey Lim alsr...@activitycentral.orgwrote: == Sweets-1.0.4 == * Fix 'status -d' command == Sweets-1.0.5 == * Implement all, useful, setup.py's commands http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Developing_activities * Contine polishing the help messages Tested the new setup.py commands great!. I always use the sugar-install-bundle command to install the modified .xo into the system, setup.py also does this with the -install append. I have to do this inside the emulator, any chances that sweets can have a similar feature ?. Having in mind that: ''install - function installs the activity to the root system. Sweets avoid, by design, any global changes during its regular behaviour''. I think, we can rethink the checkout command. For now it is: checkout [RECIPE|SWEET [PATH]] register PATH as a valid RECIPE|SWEET's implementation but originally idea was to exactly getting the source of a sweet, ie: sweets checkout dextrose/sugar should get (somehow) dextrose/sugar sources to place it to he local fs (and after that, register it). So, it migh be sweets checkout XO_FILE [DST_PATH] and XO_FILE will be unzipped to DST_PATH (to ~/Activities by default) and registered (when Sweets will have a GUI to run activities) as an implementation for the sweet it implements. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar emulator][Ubuntu 11.04] I can't install an activity (with the setup.py)
On Wed, Dec 07, 2011 at 12:34:16AM +0100, laurent bernabe wrote: I've - lauched command sweets -S sdk/sugar:emulator - updated sweets But which path must I precise to command sweets build [PATH] ? The path to your activity, or cd there and type only sweets build. In fact, there is no need in this command until you need translation of your activity. To run your activity, follow http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Packaging#Launch_activity instructions. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Multi-lingual relaying on Sugar IRC channles is stopped
On Sun, Dec 11, 2011 at 05:20:12AM -0500, Stefan Unterhauser wrote: good job :) can we test this new translation feature in #treehouse It is the same bot, so it works for #treehouse as well. ... so Claudia can see cu dogi On Mon, Dec 5, 2011 at 7:01 PM, Aleksey Lim alsr...@activitycentral.orgwrote: On Sun, Oct 30, 2011 at 06:26:33PM +, Aleksey Lim wrote: Hi all! Starting from the recent times, translation[1] on Sugar IRC channels stopped working properly (messages started being skipped). This feature is disabled entirely for now, since missed IRC posts on translated channels might lead to many confusions. Infrastructure Team is working on the problem to fix this issue as soon as possible. Sorry for inconveniences. [1] http://wiki.sugarlabs.org/go/Service/meeting/Usage#Multi-lingual_relaying The multi-lingual relaying started functioning in testing mode. It is only Spanish language. Translation is provided by Apertium[1] project. If it is not good, please consider possibility to improve[2] it. Use meeting-test channel[3] for testing. [1] http://apertium.org [2] http://wiki.apertium.org/wiki/Contributing_to_an_existing_pair [3] http://chat.sugarlabs.org:9090/?channels=meeting-test -- Aleksey ___ Systems mailing list syst...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/systems -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Multi-lingual relaying on Sugar IRC channles is stopped
On Sun, Dec 11, 2011 at 11:39:57AM -0500, Chris Leonard wrote: On Sun, Dec 11, 2011 at 5:20 AM, Stefan Unterhauser ste...@unterhauser.name wrote: good job :) can we test this new translation feature in #treehouse ... so Claudia can see Excellent! Well done. I know you have been busy, but that's a nice piece of work. Maybe we can get Australian translation going next? :-) The problem here is not in adding but in having Aussie translation in Apertium[1], but the good thing is that it is possible to add Aussie language[2]. [1] http://wiki.apertium.org/wiki/Language_and_pair_maintainer [2] http://wiki.apertium.org/wiki/Contributing_to_an_existing_pair cjl [Aussie] ˙ɐʞʞɐʎ ɟo ʇıq ɯnʞuıp ɹıɐɟ ɐ s,ʇɐɥʇ ʇnq `ƃuıʞuıɹp pɹɐzıl ɐ ǝʞıl ʇno ʇɐlɟ uǝǝq ǝʌ,noʎ ʍouʞ ı ˙ɐʎuo pooƃ ˙ǝɔɐ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] slackware 13.37 and sugar
On Wed, Dec 14, 2011 at 04:55:35PM +, andrew wrote: I have been using Soas-2-blueberry.iso installed on a usb ,which has been working well.However I keep having to go to an internet cafe running windows to use it, this is because my pc is running Slackware 13.37 and I have not manged to configure lilo to boot the usb. Also there doesn't seem to be a capacity on this pc to set bios to boot from usb. The ideal would be to install sugar as packages on slackware 13.37 system I have had a look at : http://wiki.sugarlabs.org/go/0.82/Source_Code etoys is self explanatory -thats the choice of game apps whats the difference between sugar-0.82.9 sugar-base-0.82.2 ? using src2pkg I have managed to create slackware packages sugar-base-0.82.2-i486-1.txz and sugar-toolkit-0.82.11-i486-1 .txz both of these have installed ok i tried creating a sugar build with : sugar-0.82.9.tar.bz2 sugar.SlackBuild (based on alien bobs template) sugar.info http://sugar.info slack-desc I got a fail quoting no man page anybody into slackware out there who can help? 0.82 is really old... There is a distro agnostic tool, Sweets[1]. It is a PMS like wrapper around Zero Install, but it's reusing local distro packages via another distro agnostic tool, PackageKit. If you are interesting to have Sugar via Sweets[2], could you take a look into https://packages.sugarlabs.org/project/packages?project=base and post the Slackware package names for analogs of all these packages. So, you can run Sugar sweets (after installing PackageKit) in Slackware. [1] http://wiki.sugarlabs.org/go/Platform_Team/Sweets [2] http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sugar_via_Sweets -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] The Sugar Network technical implementation overview
(The iaep@ discussion started on http://thread.gmane.org/gmane.comp.education.sugar.discuss/11943) Hi all! == Background == The two questions, regarding collaborative/social activity withing the Sugar community, that the following solution tries to solve: 1. What I need to do to interact with people, who are not just around me, if I'm off-line? 2. Even if I'm online, Sugar native collaborative tools are too limited. (even if particular activities support collaboration (but generally not most of them), it is specific to this activity workflow.) That's generally not a problem and not bad at all, there many of collaborative services in the Internet. But, why not having tools especially designed to handle Sugar specific workflows (see bellow)? The non-tech introduction to Sugar Network concepts: * http://wiki.sugarlabs.org/go/Sugar_Network * http://wiki.sugarlabs.org/go/Sugar_Network/Concept In addition the above summary, Sugar Network should be a solution for all community members (not only for people who are off-line) to: * be a place to share Sugar activity objects; * easy feedback/report about problems in Sugar activity; * make Sweets useful for Sugar activity users: ** powerful browsing among all accessible activities ** not explicit download/install, just click to launch ** easy select any version you prefer * make Sweets useful for Sugar activity doers: ** support development/testing/stable versions of the same activity ** support experiments (in Gitorious terms, forks) of existing activities, eg, the GUI to make these experiments easy to start/work/use, let other Network participants launch your experiment == Server == Implementation does not exist yet, the following notes explain the intention: * http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network the home page * http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture overview * http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/API API * http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Server initial ideas regarding server implementation The initial (maybe too initial) implementation has a Roadmap, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/0.1/Roadmap == Client == For [default] client implementation, please, contact: * Sebastian Silva sebast...@somosazucar.org * Laura Vargas la...@somosazucar.org == Feedback == Any improvements, feedback and suggestions are welcome. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The Sugar Network technical implementation overview
On Mon, Dec 19, 2011 at 04:12:59PM -0300, Gonzalo Odiard wrote: Can you explain what is your idea about implementation? If it is about technical implementation (not about the initial purpose), and about the server side: http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Server About the [default] client: http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Client (but it is the question to Sebastian and Laura). Is a web application in the school server? Is a client activity and software in the server? http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Overview Is a social network? It is exactly what http://wiki.sugarlabs.org/go/Sugar_Network#Summary says, ie, share various types of content (http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Resources) between Network participants. In might be treated as a distributed social network, but it not only about this, see the purpose section on http://wiki.sugarlabs.org/go/Sugar_Network#Summary, ie, * Provide technical and educational support to students and teachers; * Support social activity of student and teachers with possibility of close integration with learning process; * Connect student and teachers with the rest of Sugar community for, e.g., getting a feedback from the field. How is resolved the communication if there are not connectivity? http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Synchronisation -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The Sugar Network technical implementation overview
On Mon, Dec 19, 2011 at 09:49:44PM +, Marco Pesenti Gritti wrote: On 19 December 2011 19:34, Aleksey Lim alsr...@activitycentral.org wrote: Is a social network? It is exactly what http://wiki.sugarlabs.org/go/Sugar_Network#Summary says, ie, share various types of content (http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Resources) between Network participants. In might be treated as a distributed social network, but it not only about this, see the purpose section on http://wiki.sugarlabs.org/go/Sugar_Network#Summary, ie, IMHO, you will need to get a lot more concrete than that if you want anyone to understand what you are trying to do. The brief info, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Functioning In any case, the server is only what it provides via API, ie, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/API and the same from conceptual point of view http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Resources -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The Sugar Network technical implementation overview
On Mon, Dec 19, 2011 at 11:19:06PM +, Aleksey Lim wrote: On Mon, Dec 19, 2011 at 09:49:44PM +, Marco Pesenti Gritti wrote: On 19 December 2011 19:34, Aleksey Lim alsr...@activitycentral.org wrote: Is a social network? It is exactly what http://wiki.sugarlabs.org/go/Sugar_Network#Summary says, ie, share various types of content (http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Resources) between Network participants. In might be treated as a distributed social network, but it not only about this, see the purpose section on http://wiki.sugarlabs.org/go/Sugar_Network#Summary, ie, IMHO, you will need to get a lot more concrete than that if you want anyone to understand what you are trying to do. The brief info, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Functioning In any case, the server is only what it provides via API, ie, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/API and the same from conceptual point of view http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Resources But, as I already menitoned, on top of this low level [server] implementation, it might be a good chance (the real one, becuase there are not many options to support off-line schools) to try to make social network like methods closer to Sugar workflow. For example: 1) Sharing Activity objects across community. There is TA gallery. * To use it, people need to * go to TA home page * find there a like * bookmark it somehow * open the Browser * click the object you like and Browser will ask you to download * switch to Journal and activate it * To upload new object: * Create TA object * open the browser * and found there TA site * login there * upload TA object (it works only if you on-line) Making it close, will mean: * To use it, people need to: * Sugar Network Browser is open from the beginning (somewhere), go there * select TA/Gallery to browse only TA objects * click the object you like to activate it * To upload new object: * click Share button in Journal or * somewhere on post-creation dialog, click Share (and thats not only for TA) 2) Feedback report on activity fails. It was implemented in Dextrose but reports go to jita.sl.o and accessible only for people who have account there. Not because it was designed this way, but because the reports representer needs to be created. Making it close, will mean that Sugar Network has this functionality by design. To see these reports, particular developer (who cares about exactly this particular activity report, i.e., not someone else who need to sort out all reports to share it w/ developers) can see them. 3) The idea w/ http://getsatisfaction.com/sugarlabs died, but I guess not only because people who use sugar (not developers or experienced users who know what ML and IRC are) don't have questions/ideas/problems with sugar. If the same functionality will be closer * find the activity project in the GUI * switch to it * type your question/idea/problem instead of: * be on-line * know/remember http://getsatisfaction.com/sugarlabs url * open the Browser * login (you need to be registered and remember the password) * type your question/idea/problem to people who are the targeting audience, we will have more feedback for sure. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The Sugar Network technical implementation overview
On Tue, Dec 20, 2011 at 10:04:55AM +, Marco Pesenti Gritti wrote: On 19 December 2011 23:19, Aleksey Lim alsr...@activitycentral.org wrote: IMHO, you will need to get a lot more concrete than that if you want anyone to understand what you are trying to do. The brief info, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Functioning Hi Aleksey, unfortunately you have lost me much earlier than that. I have read and reread the Concept page and still I have absolutely no idea of what you are trying to accomplish. Perhaps you started from concrete deployment needs but, when designing and documenting the system, you brought it up to such an high level of abstraction that it's impossible to understand what you are talking about (for my little, unimaginative brain at least!). For example http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Overview Is that describing a video game, a social network, or maybe even... human life? :) == Well.. == Well, Sugar_Network/Concept might look too abstract.. The problem here is that page created exactly for non-tech people (and maybe for people who populated it, it is hard to write such pages). == Background == In any case, the whole idea of Sugar Network was started not from tech side but to fix particular deployment needs, here off-line schools and bunch of related problems, e.g., the links from its home page http://wiki.sugarlabs.org/go/Deployment_Team/Peru/Puno#The_problem (and http://somosazucar.org/2010/11/20/informe-sobre-la-investigacion-de-las-laptop-xo/ in particular). The point in this idea is, instead of doing thigs like: * package wikipedia to open it on students' XOs (or on teachers' XOs) somehow * the same for any other content in .xol * the same for .xo activity bundles * paper (because it is off-line, the option is creating new system and teach teachers how to use it) work when teachers need to ask tech/edu people about how this system work and how to teach students to use it. All these points seem to be doable from tech pov, but it is more about handling similar issues one-by-one, ie, solving the same problems several times. For example: * is it ok to package wikipedia, can students' XOs handle it, but they don't have additional space like bunch of USB sticks * the same for .xol * the same for .xo == A way to solve it that was chosen == Instead, the idea is about providing basic possibility to share exactly different types of resources (really, can't find more appropriate words). These resources (mentioned on wiki pages from different povs), are: * feedback related resources (questions, ideas, problems) * wiki, for all content, even for the same .xol that can be attached to the wiki * Releases (in terms of Concept page, more appropriate workding is wellcome), that's about activities to launch, ie, .xo Concentrate this sharing on teachers' XOs (ie, they are servers), provide sufficient storage space for all these teachers' XOs (to hadle as much content as possible). Make students's XOs as a thin clients (no need in keeping all .xol/.xo on every XO) for the Sugar Network. Support additional workflow for server-less case, ie, when students go home and teachers' server is not accessible. This server-less workflow should not be like read out wiki to know how to reuse your SD card (btw, maybe absent) to make your life easier (really?) if you want to work with content that doesn't feet to your XO. In term of Sugar_Network/Concept, it should be, there are private and not private Projects, make it private (if you have enought storage space, to work on it at home. == Not only off-line == The implementation with having basic sharing functionality and close integration it with regular sugar behaviour, is exactly what Sugar (from my pov) just doesn't have. There is such possibility, but it starts from Browse and related fun like managing bunch of accounts, not shortest way to do things related to your Sugar env (see the example of sharing TA project vs. Click Share button in Journal. == Feedback == The Sugar Network was named such exactly because of it affects really all levels of Sugar behaviour. And it is really hard to answer to: * general questions about concept, it is possible to answer only in general * general questions about impl, the universal general answer is sharing different types of resources So, regarding impl, more concrete questions are welcome. And it is the Wiki, if you feel you think the same as the text on Sugar_Network pages (if not, there are discussion pages that all interesting in people are subscribed to), and this text has ugly wording/not-full, improve it. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Network discussion group
(Texto en Español está por debajo de) Hi all! The brief info about Sugar Network: This work was initially started by the Peru Local Lab[1] to address the needs[2] identified during work on Puno pilot program[3]. In short, making teachers and students behaviour more productive in off-line environment. In potential, this effort might useful for on-line Sugar community as well. More details might be found on Sugar Network home page[4]. This project is in an initial stage when even basic design ideas might be changed in the process of initial implementation. That's why it is important to have public discussion place: * it is critically important to involve as many as possible non-tech people, educators and researchers because Sugar Network is less technical project and more social and education related one (it is explicit intention to make Sugar Network useful in learning process in pilot schools); * not all people who work on the project are in the same place. This discussion place is started as a Google group instead of reusing existing (or new) Sugar Labs mailing lists because: * to avoid spamming on these lists with posts that relate to implementation details, moreover, some posts might require cross posting to sugar-devel@ and ieap@; * mailing lists are less useful for non-technical people than Google groups; Google groups have much more useful default web interface and it is possible to take part in discussions using only web browser (and avoid receiving any emails). To start using Sugar Network Google group: * To browse discussions http://groups.google.com/group/sugar-network * To join the group (you need to have Google account) http://groups.google.com/group/sugar-network/subscribe you can select the No Email option to avoid getting emails and reuse only web browser to take part in discussions. * New posts are allowed from all users but messages from not joined people will be postponed for moderation. The default group language is English (Sugar Network is an international project), but since most of involved people are Spanish speaking, messages in Spanish is welcome as well. (Texto en Español) Hola a todos! La información breve acerca de la red de azúcar: Este trabajo fue iniciado por el Laboratorio de Perú Local [1] para hacer frente a las necesidades [2] identificadas durante el trabajo en el programa piloto de Puno [3]. En breve los maestros, por lo que los estudiantes y un comportamiento más productivo en off-line el medio ambiente. En el potencial, este esfuerzo podría útiles para comunidad en línea de azúcar. Más detalles se pueden encontrar en la página de la red doméstica de azúcar [4]. Este proyecto se encuentra en una etapa inicial, cuando aún las ideas de diseño básico puede ser cambiado en el proceso de implementación inicial. Es por eso que es importante tener lugar la discusión pública: * Es de vital importancia de implicar al mayor número posible de personas no técnicas, educadores e investigadores, porque la red de azúcar es menos técnico del proyecto y más social y una educación relacionada (es la intención explícita de hacer Red de azúcar útil en el proceso de aprendizaje en las escuelas piloto); * No todas las personas que trabajan en el proyecto están en el mismo lugar. Este lugar es el debate que comenzó como un grupo de Google en lugar de reutilizar existentes (o nuevos) Sugar Labs, porque las listas de correo: * Para evitar el correo basura en estas listas con los mensajes que se relacionan con detalles de implementación, por otra parte, algunos puestos puede requerir cruz publicación de azúcar-devel @ y @ IEAP; Listas de correo * son menos útiles para personas sin conocimientos técnicos de Google grupos, grupos de Google tienen interfaz mucho más útiles en la Red por defecto y es posible tomar parte en las discusiones utilizando simplemente un navegador web (y dejar de recibir mensajes de correo electrónico). Para empezar a utilizar azúcar red de Google grupo: * Para ver algunos de los debates http://groups.google.com/group/sugar-network * Para formar parte del grupo (es necesario tener cuenta de Google) http://groups.google.com/group/sugar-network/subscribe usted puede seleccionar la opción Sin correo electrónico opción para evitar que los correos electrónicos y su reutilización sólo navegador web para participar en los debates. * Mensajes nuevos se les permite a todos los usuarios, pero no se unió a los mensajes de la gente se pospondrá a la moderación. El lenguaje de grupo por defecto es Inglés (Red de azúcar es una organización internacional proyecto), pero como la mayoría de las personas involucradas son de habla española, los mensajes en español es bienvenido también. [1] http://somosazucar.org/ [2] http://wiki.sugarlabs.org/go/Deployment_Team/Peru/Puno#The_problem [3] http://wiki.sugarlabs.org/go/Deployment_Team/Peru/Puno
Re: [Sugar-devel] Sugar Network discussion group
Hi all! (Texto en Español está por debajo de) One useful feature I found in Google groups web interface, you can click Translate to.. for messages that are not in your language. (Texto en Español) Una característica útil que he encontrado en Google grupos de la interfaz web, puede hacer clic en Traducir al .. para los mensajes que no están en su idioma. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removing hippo from Chat
On Thu, Jan 05, 2012 at 10:47:33AM -0300, Gonzalo Odiard wrote: Hi Aleksey, I have addressed the pending issues, and will send the patches to sugar-devel. Below comments to every issue: Thanks, will take a look these weekends. On Thu, Nov 17, 2011 at 3:22 PM, Gonzalo Odiard gonz...@laptop.org wrote: I was working i removing the use of hippo in Chat activity. I have implemented a HBox type container to substitute the RoundBox, and used TextView to display the text. There are a few pending issues: * If the text writen in a message is longer than the horizontal space in one row, the box is widen, and the text is not sent to another row. I have tried using textview.set_wrap_mode(gtk.WRAP_WORD), but this cut every row with one word. Solved * There are issue with the repainting of the cairo based RoundBox. The first row, after the activity alert is hidden, is not repainted. I think this was a error testing in 1.75 with the old video driver. Now I can't reproduce it. * The smiley images are aligned at bottom with the text. In the old Chat were aligned at middle and looked better. This is the only pending issue, but I think is no so bad. * After changing to another activity and come back, the palette asociated to a url, show a error message Cannot update the palette position. and is not displayed. The pallete is ok. I wait your review. Gonzalo -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Removing hippo from Chat
On Thu, Jan 05, 2012 at 10:47:33AM -0300, Gonzalo Odiard wrote:
Hi Aleksey,
I have addressed the pending issues, and will send the patches to
sugar-devel.
Thanks, I've pushed your commits w/ lint polishing (see HACKING file).
http://git.sugarlabs.org/chat/mainline/commit/148d0d6fd47d8eb6b3bf42d21828222ee4693082
Also, there are a couple of issues:
diff --git a/chat/box.py b/chat/box.py
index bfc8156..b639037 100644
--- a/chat/box.py
+++ b/chat/box.py
@@ -69,9 +69,11 @@ class TextBox(gtk.TextView):
self._empty = True
self.palette = None
self._mouse_detector = MouseSpeedDetector(self, 200, 5)
-self._mouse_detector.connect('motion-slow', self._mouse_slow_cb)
+# TODO There is a mess with having sugar palette and TextView popup
+#self._mouse_detector.connect('motion-slow', self._mouse_slow_cb)
self.modify_base(gtk.STATE_NORMAL, bg_color.get_gdk_color())
-self.connect(event-after, self.event_after)
+# TODO There is a mess with having sugar palette and TextView popup
+#self.connect(event-after, self.event_after)
self.motion_notify_id = self.connect(motion-notify-event, \
self.motion_notify_event)
self.connect(visibility-notify-event,
self.visibility_notify_event)
For example,
* in self.event_after, the commented block references to unknow `tag`
* having two popups (sugar palette and TextBox popup) looks messy.
* url palette pops up even for TextBox widgets that don't have urls
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ImageViewer] Changes in the toolbar according to design team review
On Thu, Jan 12, 2012 at 10:44:11AM -0300, godi...@sugarlabs.org wrote: From: Gonzalo Odiard godi...@gmail.com Change order in the full screen button Hi, whats the reason to swap fullscreen and rotate buttons? Afaik, mostly all activities have fullscreen button as a leftmost. That will be confusing to have ImageViewer unique (and change existing users experience for ImageViewer itself. , and icons in rotate buttons. Well, I'm not a designer and specialist of users experience, but new buttons: - look similar to each other and similar to Refresh functionality button + old ones are more distinct - all image viewers I managed to find screenshots for, do not use circles for rotate buttons + old buttons look similar to the majority on image viewers -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ImageViewer] Changes in the toolbar according to design team review
On Thu, Jan 12, 2012 at 11:39:14AM -0300, Gonzalo Odiard wrote: On Thu, Jan 12, 2012 at 11:30 AM, Aleksey Lim alsr...@activitycentral.orgwrote: On Thu, Jan 12, 2012 at 10:44:11AM -0300, godi...@sugarlabs.org wrote: From: Gonzalo Odiard godi...@gmail.com Change order in the full screen button Hi, whats the reason to swap fullscreen and rotate buttons? Afaik, mostly all activities have fullscreen button as a leftmost. That will be confusing to have ImageViewer unique (and change existing users experience for ImageViewer itself. The idea is have all the View operations in the same order than in other activities. And yes, Full Screen is the last of the View buttons. , and icons in rotate buttons. Well, I'm not a designer and specialist of users experience, but new buttons: - look similar to each other and similar to Refresh functionality button + old ones are more distinct - all image viewers I managed to find screenshots for, do not use circles for rotate buttons + old buttons look similar to the majority on image viewers Well, I am not an expert. We wanted use the same icons to rotate in Paint, ImageViewer and Fototoon. I have asked to Gary what icons should we use, and he said the Paint icons are the better. I cc to Gary to see if he can explain better . I see only one useful way here: * for icons, create rotate buttons for sugar-artwork and trying to switch all activities to these icons * for fullscreen button, have a section in HIG regarding this button (it is useless to have it in different places for different activities). And only after that, patch ImageViewer and other activities. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Chat] Enable palette over urls
On Thu, Jan 12, 2012 at 05:15:54PM -0300, godi...@sugarlabs.org wrote: From: Gonzalo Odiard godi...@gmail.com This patch solves the problems pointed by Aleksey in the last patch, disable the standard menu in the textview, reorganize the event_after method and stop the mouse_slow detector when the palette popup. Signed-by: Gonzalo Odiard gonz...@laptop.org Thanks, pushed. Though, the problem w/ showing url palette on url-less posts still remains: * create new Chat instance * post 1st message, foo * close Chat * restore it * post 2nd message, http://foo.bar; * move cursor to the 2nd message and wait for the palette * move cursor to the 1st message, the same palette will pop up -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Chat] Enable palette over urls
On Fri, Jan 13, 2012 at 05:00:20PM -0300, Gonzalo Odiard wrote: Trying to reproduce the problem, I think the reason is different. If I move the mouse to the first post, but without going over the second, the palette does not popup. I think the problem is the palette is displayed in the second post, but moving only a little the mouse drag the same palette to the other post. I send you a patch where I have added a method to stop the mouse detector when the mouse leaves the textview. In the second patch I cleanup the names of the callback methods and remove unused signals definitions. Confirmed and pushed. Though, found another minor issue: double click (immediate and the one after getting primary palette) doesn't show secondary palette at once. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
