[Sugar-devel] [RELEASE] sugar-datastore-0.89.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.89.2.tar.bz2 == News == * sl#2132: reduce _FLUSH_TIMEOUT to 5 seconds * Set index_updated flag on ds shutting down #2095 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Wed, Aug 04, 2010 at 08:05:06PM +0100, pbrobin...@gmail.com wrote: On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Thats right, and all PackageKit benefits will be reused within 0sugar/0install (but mostly for non-sugar dependencies, it will be possible to reuse native packages for sugar application as well but see below). But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Sun, Aug 08, 2010 at 07:18:51AM -0700, Jon Nettleton wrote: But the one of core ideas to not use only regular packaging systems (via PackageKit or directly) is having this, natural and desired, scenario for sugar ecosystem: * there is an activity, * several users might decide to experiment w/ this activity (i.e. change its code) and share this results * third user wants to try all these experiments (including pristine activity) This scenario is pretty undoable (by design) in native packaging systems but 0install is designed to support scenarios like that (all activity implementation are stored in separate directories in user's home and can be launched in any time and even at the same time). This doesn't sound like a package management system scenario. Really this sounds like a revision control system is needed. Wouldn't it make the most sense to integrate bzr or git into sugar to handle code sharing like this? Then you could continue to have all the Activities in a single directory with multiple branches to can be switched between on the fly through a sugar interface. Well, I thought also about vcs but came to decision that it sounds like misusing of vcs: * vcs is all about sources (storing binaries is possible but is misusing), * all sugar related code will be shared only in sources, which is not bad in general (especially as an option) but sounds overkill for binary-based activities * all dependencies should be stored in vcs and deployed via vcs as well (otherwise system should be not pure vcs and will look pretty ugly) Also there is no need in storing results of experiments in vcs at all, e.g., doer just tweaks his local code and let 0sugar share it w/o commiting to vcs server(which should be used to fetch sources on client side), supporting per doer vcs servers would sound pretty overkill. Some kind of binding vcs repos with packaging/distribution stuff is possible and afaik many GNU/Linux distribution do packaging from, e.g., git repos (we can do similar things on our OBS), but they don't mix vcs and distribution. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: How about creating addons.gnome.org
On Sun, Aug 08, 2010 at 04:11:38PM +0200, Tomeu Vizoso wrote: Hi, the GNOME people are having an interesting discussion about AMO. Regards, Tomeu -- Forwarded message -- From: Johannes Schmid j...@jsschmid.de Date: Sun, Aug 8, 2010 at 15:28 Subject: Re: How about creating addons.gnome.org To: Jose Aliste jose.ali...@gmail.com Cc: Tomeu Vizoso to...@sugarlabs.org, foundation-l...@gnome.org Hi! Also, there should be a clear distinction whether an addon is Gnome approved (meaning it is reviewed, translated, probably hosted in the gnome git somewhere) or the work of a freelance dev. Distributions are welcome to keep packaging any of the addons, as they do now, but normally the maintainer's cost of distributing 100 or more addons would be too high (in my opinion). In this sense, I would love to have an easy way of installing add-ons that does not require you to copy files to some hidden directories. We should have a command line gnome-addon install add-on-name, which will download and install the add-on. That would be really neat in my opinion. While I would rather vote for a more complete GNOME Appstore solution in the far future (possibly based on OpenSuSE build service), some points to note: * This will only work for scripted plugins Python, Javascript, Ruby * All compiled languages will suffer depedency problems * It would mean that we install executable things into the user's home directory. Some admins might not like this though of course mozilla does the same. Security is an important point here. It is also a rather huge maintaince burden to check that the plugin works with the installed version of an application. But nevertheless, go for it if you have the time, it sounds like a good idea! Especially for the upcoming gnome-shell addons it could be a perfect place. Johannes I can share my own experience in code sharing case. There is a problem w/ AMO. AMO, as filesharing tool, works well only for one-file bundles w/ anyarch data, trying to reuse AMO for not trivial cases like binaries, e.g. different ABIs etc., sound overkill for AMO. Right now, I'm working on different model - Zero Sugar [1]. The core things are: * everything starts with spec file of the package - recipe file [2] * it will be possible to local launch application only having this spec file and sources tarball/vcs-checkout (in noarch case, or build application locally and start it) * keeping in mind variety of users environments and things like ABI breakages (or even different build flags on different distros), it would be useful to just build application in this particular environment. So, using [2] recipe file, on patched OBS (in progress), it will be possible to create native packages for bunch of deb/rpm distros. It sounds like meta packaging but it is not [3]. * The important thing, installing applications from OBS repos is not primary distribution method (it will work fine in case of centralized repo of applications on OBS, but attaching repositories from individuals(in my mind, regular behaviour in sugar ecosystem), i.e., from home projects on OBS, will be really overkill). The first distribution method will be 0install [4]. So, OBS will create not only native packages but 0install feeds as well (for nonarch applications, only 0install feeds, for binary based, 0install will reuse native packages). * 0install is/should-be fully integrated into GNU/Linux distributions ecosystem e.g. it is not about creating yet another distro, 0install will reuse PackageKit to install already packaged software. * OBS will be used as only one place for all file sharing/packaging stuff. Sites like AMO will be used only as catalogs (users driven, e.g., reviews, ratings etc.) of applications - they will contain only 0install links (of files stored on OBS). Even more, OBS will be auto publish info about new versions/packages on AMO. [1] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar [2] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification [3] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Native_Packages [4] http://0install.net/goals.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Speak.Activity v16 on Build 802 - Problem
On Mon, Aug 09, 2010 at 10:19:23AM -0500, Rafael Enrique Ortiz Guerrero wrote: Forwarding this to sugar-devel -- Forwarded message -- From: Tony Rizos tri...@pacbell.net Date: Sun, Aug 8, 2010 at 9:44 PM Subject: Speak.Activity v16 on Build 802 - Problem To: de...@lists.laptop.org Hi, I upgraded my OLPC XO from Build 656 to 802. Having not used the XO for the last 2 years, I was pleased with the changes. I am planning to give it to my niece who asked if she could have it. All works well except the Speak activity. After running correctly the first time, it will not start up on subsequent attempts. I thought this may have been caused by my attempt to install Skype when the problem seemed to have started. I erased Speak and reinstalled it with no luck. I first tried going back to 656 and upgrading again to 802. No luck. I should say I also tried Speak v9 which worked with no problems whatsoever. The problem is associated with the Speak v16 activity that comes with 802. I asked the forums if anyone had seen this problem and was recommended to do a no-fail update. After wiping the XO clean and installing 802, Speak v16 seemed to work again with no problems. However, when I closed it and restarted it, I got an error and would not start. I then erased it and reinstalled it. It started up okay with no problems but I get the same result when I close it and restart it. The error detail included the following messages: gst-plugins-based failed to resolve due to Unknown gstreamer failed to resolve due to Unknown gst-plugins-good failed to resolve due to Unknown Processed: 1; skipped: 0 Cancelled Is there a problem with Speak v16? Have you seen this problem before? Is there any more information I can provide? Can this be fixed? Heh, these are remains of my expriments with smart bundles, Try this one http://activities.sugarlabs.org/en-US/sugar/addon/4038. Thanx, Tony ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Feature Freeze exception request: Journal Sort
Hi all, Implement sorting in the Journal UI. Also adds support for the two new properties (filesize and ctime). Feature page: http://wiki.sugarlabs.org/go/Features/Journal_Sort Implementations: http://git.sugarlabs.org/projects/sugar-datastore/repos/journal_sort http://git.sugarlabs.org/projects/sugar/repos/journal_sort -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature Freeze exception request: Journal Sort
On Mon, Aug 23, 2010 at 08:59:10AM +0200, Tomeu Vizoso wrote: On Sat, Aug 21, 2010 at 01:24, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Implement sorting in the Journal UI. Also adds support for the two new properties (filesize and ctime). Feature page: http://wiki.sugarlabs.org/go/Features/Journal_Sort Hi, is there anything we could have done so this feature doesn't arrive so late in the release cycle? As an aside, maybe we should ask in the freeze exception process to give some explanation of why it got past schedule. Aleksey, as the journal maintainer, can you give an assessment of how much risk it would bring to accept this feature? In my mind, only ds part could be risky (need to test it more close). Journal part is risky only in common, i.e., how new UI is useful, but it can be checked only in the field. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature Freeze exception request: Journal Sort
On Mon, Aug 23, 2010 at 01:08:30PM -0300, Andrés Ambrois wrote: On Monday, August 23, 2010 04:25:48 am Tomeu Vizoso wrote: - creation time will be always displayed as '%Y-%m-%dT%H:%M:%S' ? What about those countries where they expect the fields being ordered in a different way? (may be good to format the string in listview.py instead of in listmodel.py, so we keep UI decisions out from the model). I agree with that separation of concerns. In fact it was initially that way, but the format is required by activities such as Etoys, that break unless we use it. Other activities may also be depending on it, as it is documented in [0]. If are talking about UI representaion, then it is ok (ago format). About internal representaion, Andrés, for what readon we store ctime in ISO, what about int value (to keep it in the same format as timestamp)? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature Freeze exception request: Journal Sort
On Mon, Aug 23, 2010 at 11:58:01AM +0200, Simon Schampijer wrote: Hi Aleksey, On 08/23/2010 09:25 AM, Tomeu Vizoso wrote: On Sat, Aug 21, 2010 at 01:24, Aleksey Limalsr...@member.fsf.org wrote: Hi all, Implement sorting in the Journal UI. Also adds support for the two new properties (filesize and ctime). thanks for proposing this Feature. Thanks as well to Andres for working on it! I know that this Feature has a high value for learners (seen it myself in class already - especially the addition of the creation date), so I would not like this Feature to miss the boat. If all the issues are addressed I would consider it. Remember that today is UI Freeze so it really has to be in today's tarballs! So the reviewer has to be convinced, too. Feature page: http://wiki.sugarlabs.org/go/Features/Journal_Sort Implementations: http://git.sugarlabs.org/projects/sugar-datastore/repos/journal_sort http://git.sugarlabs.org/projects/sugar/repos/journal_sort Some questions: - what with hard links? Aren't users going to expect that if they delete an entry of 50MB that their available space will be increased by 50MB? - creation time will be always displayed as '%Y-%m-%dT%H:%M:%S' ? What about those countries where they expect the fields being ordered in a different way? (may be good to format the string in listview.py instead of in listmodel.py, so we keep UI decisions out from the model). - if we are not interested in sorting by title, we should remove that field from the index, because makes the index bigger and also slows queries down a bit. - seems like this feature is still in dicussion in http://bugs.sugarlabs.org/ticket/1915 so I don't think it makes sense to accept it for inclusion in 0.90 at this stage. Also would be good to have the feature first accepted in the release set before eventually merging it. Regards, Tomeu Does your patch address the issue with ctime? Can the list be filtered by creation date now? There are new icons as well. Is there a patch for those? I had the following error when running the first time: 1282556253.679258 DEBUG root: Updating entry 'e603b6df-2b82-4917-8f86-c948fc4dc24f' in index. 93 to go. 1282556253.704024 ERROR root: Error processing 'e603b6df-2b82-4917-8f86-c948fc4dc24f' Traceback (most recent call last): File /home/erikos/sugar-jhbuild-master/install/lib/python2.6/site-packages/carquinyol/datastore.py, line 125, in __update_index_cb self._index_store.store(uid, props) File /home/erikos/sugar-jhbuild-master/install/lib/python2.6/site-packages/carquinyol/indexstore.py, line 261, in store term_generator.index_document(document, properties) File /home/erikos/sugar-jhbuild-master/install/lib/python2.6/site-packages/carquinyol/indexstore.py, line 75, in index_document xapian.sortable_serialise(int(properties['filesize']))) KeyError: 'filesize' Andrés: It would be better to not rely on having new feilds in ds requests (sugar, that operates w/ ds, could be old and not support new fields) I could not see any list after applying the Feature, I had the no entries message. Regards, Simon -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature Freeze exception request: Journal Sort
On Mon, Aug 23, 2010 at 04:48:33PM +, Aleksey Lim wrote: On Mon, Aug 23, 2010 at 01:08:30PM -0300, Andrés Ambrois wrote: On Monday, August 23, 2010 04:25:48 am Tomeu Vizoso wrote: - creation time will be always displayed as '%Y-%m-%dT%H:%M:%S' ? What about those countries where they expect the fields being ordered in a different way? (may be good to format the string in listview.py instead of in listmodel.py, so we keep UI decisions out from the model). I agree with that separation of concerns. In fact it was initially that way, but the format is required by activities such as Etoys, that break unless we use it. Other activities may also be depending on it, as it is documented in [0]. If are talking about UI representaion, then it is ok (ago format). About internal representaion, Andrés, for what readon we store ctime in ISO, what about int value (to keep it in the same format as timestamp)? Sorry, didn't see [0] (was thinking that we dind't expose any ctime fields before), what about renaming ctime ds field and using int value. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.89.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.89.3.tar.bz2 == News == * New metadata fields, creation_time and filesize to support sorting in the Journal #1915 * Create target directory before importing previews (carrott) #2149 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New IRC channel for newby questiones regarding sugar development
Hi all, I think it should be useful to have #sugar-newbies IRC channel on freenode. The reasons to have one more channel in addition to #sugar: * one of useful things during teaching sugar development tricks is keeping IRC logs (not all #sugar members agree with having such logs on #sugar). Decent search (xapian based) will be added later (any contributions are welcome). * channel is intended primarily for development related questions (though it's hard to say where sugar using stops and sugar development starts) * its topic says Ask your nub question about sugar development here. so, it will help with making incoming borders lower. Logs will be stored here http://jita.sugarlabs.org/freenode/%23sugar-newbies/index.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New IRC bot
Hi all, FIY, To keep IRC logs, I've setup IRC bot - supybot[1]. It supports many useful plugins[2] including meetings (so, we can replace meetbot with more powerful one). Full irc logs and meeting logs will be stored on [4] (each channel has link to meetings page). [1] http://sourceforge.net/projects/supybot/ [2] http://ubottu.com/stdin/supydocs/plugins.html [3] http://meetbot.debian.net/Manual.html [4] http://jita.sugarlabs.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New IRC channel for newby questiones regarding sugar development
On Sat, Sep 04, 2010 at 12:31:16PM +0200, Sascha Silbe wrote: Excerpts from Aleksey Lim's message of Sat Sep 04 02:49:05 +0200 2010: * its topic says Ask your nub question about sugar development here. so, it will help with making incoming borders lower. We should state clearly that a) the channel is logged and b) questions are equally welcome in #sugar, which isn't logged. ok, lets hope everyone will see entirely channel title :) Especially as a newbie I would (or do, in other channels) not feel very comfortable with everything I ask in IRC (which is informal, casual communication to me) getting logged on virtually eternal, world-readable storage. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Review of patch submitted by Martin for bug #2087
On Sat, Sep 04, 2010 at 05:13:03PM +0200, Sascha Silbe wrote:
Excerpts from Kandarp Kaushik's message of Sat Sep 04 16:16:57 +0200 2010:
[data/sugar.schemas.in]
+ locale name=C
+shortProtected Activities Bundle Indentifiers/short
Typo. Also a bit hard to understand. Something along the lines of
Bundle IDs of protected activities might be better.
+longUsers will not be allowed to erase these
+activities through the list view./long
[src/jarabe/desktop/activitieslist.py]
+if activity_info.is_user_activity() and \
+not registry.is_activity_protected(self._bundle_id):
+menu_item = MenuItem(_('Erase'), 'list-remove')
+menu_item.connect('activate', self.__erase_activate_cb)
+self.menu.append(menu_item)
+menu_item.show()
+
+if not os.access(activity_info.get_path(), os.W_OK):
+menu_item.props.sensitive = False
This is getting convoluted. Please factor it out and turn your condition
into one or several guards [1]. E.g.:
def _add_erase_option(self, activity_info):
if not activity_info.is_user_activity():
return
if registry.is_activity_protected(self._bundle_id):
return
# show menu item etc.
A suitable docstring is left as an exercise for the reader. ;)
[src/jarabe/model/bundleregistry.py]
+client = gconf.client_get_default()
+self._protected_activities =
client.get_list('/desktop/sugar/protected_activities',
+ gconf.VALUE_STRING)
I have a feeling this will break badly if the GConf value is not set.
See #1147 [2] for a similar case.
I've found that there is no way to call has() method(all sugar code
calls get_* methods w/o any checks). If everything is installed, we
will get key value in any case (default from shcheme), but if
installation is inproper... I've managed to coredump python for unknow
keys.
And please don't indent this much for a continuation. Personally I'd use
regular indentation (i.e. four spaces); maybe Tomeu can state his
preference so we can agree on some guideline.
PS: Please use git-send-email or some equivalent method of sending
patches. Your message has had at least one line of the patch
wrapped; I would have been unable to try out the patch (because
it wouldn't apply).
Sascha
[1] http://en.wikipedia.org/wiki/Guard_(computing)
[2] https://bugs.sugarlabs.org/ticket/1147
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New IRC bot
On Sun, Sep 05, 2010 at 11:55:00AM +0200, David Van Assche wrote: funny, I offered and set this up about a year ago, and my bot got banned from the channel because people were paranoid their conversations were being recorded... Yeah, I've realized usefulness of irc logs only after keeping several discussions with new developers (it would be useful if people can search though already happened such discussions to pickup useful information). Did you setup any search functionality in your environment? (grin/lol) D On Sat, Sep 4, 2010 at 2:57 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, FIY, To keep IRC logs, I've setup IRC bot - supybot[1]. It supports many useful plugins[2] including meetings (so, we can replace meetbot with more powerful one). Full irc logs and meeting logs will be stored on [4] (each channel has link to meetings page). [1] http://sourceforge.net/projects/supybot/ [2] http://ubottu.com/stdin/supydocs/plugins.html [3] http://meetbot.debian.net/Manual.html [4] http://jita.sugarlabs.org/ -- Aleksey ___ 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
Re: [Sugar-devel] New IRC bot
On Sun, Sep 05, 2010 at 12:15:36PM +0200, Bert Freudenberg wrote: On 04.09.2010, at 02:57, Aleksey Lim wrote: Hi all, FIY, To keep IRC logs, I've setup IRC bot - supybot[1]. It supports many useful plugins[2] including meetings (so, we can replace meetbot with more powerful one). Full irc logs and meeting logs will be stored on [4] (each channel has link to meetings page). [1] http://sourceforge.net/projects/supybot/ [2] http://ubottu.com/stdin/supydocs/plugins.html [3] http://meetbot.debian.net/Manual.html [4] http://jita.sugarlabs.org/ Nice! Would you mind logging #etoys, too? Thanks! :) done -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Chat-67
== Source == http://download.sugarlabs.org/sources/sucrose/fructose/Chat/Chat-67.tar.bz2 == News == * Remove access to a private member (Tomeu Vizoso) * Update translations for hi, nl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.89.4
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.89.4.tar.bz2 == News == * metadata-only update sets filesize property to 0 #2229 * commit 3644fac reintroduced race condition, broke test suite #2104 * autogen.sh: pass --enable-maintainer-mode to configure ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar-news] Sugar Digest 2010-09-12
On Sun, Sep 12, 2010 at 02:52:08PM -0400, Walter Bender wrote: ===Tech Talk === 5. Aleksey Lim has set up an IRC channel for newbie developers: #sugar-newbies on freenode. The channel is logged so that we can archive newbie questions and answers ([http://jita.sugarlabs.org/freenode/%23sugar-newbies/index.html]). After switching to the new webui, it is http://jita.sugarlabs.org/sugar-newbies (but will be http://meetings.sugarlabs.org/sugar-newbies after updating DNS records) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] sugar-datastore-0.89.4
On Tue, Sep 14, 2010 at 12:14:36PM +0200, Simon Schampijer wrote: On 09/11/2010 07:52 PM, Aleksey Lim wrote: == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.89.4.tar.bz2 == News == * metadata-only update sets filesize property to 0 #2229 * commit 3644fac reintroduced race condition, broke test suite #2104 * autogen.sh: pass --enable-maintainer-mode to configure Hi Aleksey, thanks for your release in time! Would be great if you could use the release script in sugar tools [1] so that we get formatted release messages. It is easier for me to construct the release pages then. Ok, got it. If it is about convenient way to create release pages, will use [1]. Regards, Simon [1] http://git.sugarlabs.org/projects/sugar-tools ___ 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
Re: [Sugar-devel] http://bugs.sugarlabs.org/ticket/1742
On Sat, Sep 18, 2010 at 11:57:59PM +0530, Ishan Bansal wrote: hi I am working on the bug http://bugs.sugarlabs.org/ticket/1742. The check to see if the person is a friend in buddymeny.py is working fine for friends view but it still shows Make Friend when we right click in neighborhood view even if the person is a friend. I have been trying to find the difference between the codes for the above files but havent been able to do so. Please provide me some pointers on the above issue. You can follow regular way like - add debug output in all critical places. For example, after logging from place where palette is being filled with items 'Remove friend' and 'Make friend' and opening in sugar palette before adding new friend and after, I got that logging happens only once - in 1st case. Thus, after adding a friend palette contains outdated items. regards ishan -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: SL bug#630
On Mon, Sep 20, 2010 at 07:46:13PM +0530, Mukul Gupta wrote: Copying sugar-devel on this memo Regards, Mukul Gupta -- Forwarded message -- From: Mukul Gupta mu...@seeta.in Date: Mon, Sep 20, 2010 at 7:38 PM Subject: SL bug#630 To: alsr...@member.fsf.org Cc: Manusheel Gupta m...@seeta.in, David Farning dfarn...@gmail.com Aleksey, This mail is with reference to the Sugarlabs bug #630 regarding Full Memory in Journal. There were some of my queries and some clarifications that I wanted to be sorted out. It would be great if you could look into some of these. These are some of my findings after reproducing the error by assigning a dummy value to free_space. 1. The Modal Dialog appears at startup and asks us to go to the Journal. The dialog appears again whenever I perform any action in the Journal including when I erase some data,mark as favorites or exit an activity.However I am able to open up different entities present in the Journal. Even transfer to favorites view takes place. Problem: The Dialog appears repetitively. Resolution: When the function ModalAlert() is being called ie at check_available_space. I intend to display the Modal Dialog only once. Hence, I require to store a temporary variable that will count the the Modal Dialog appears. For this I made the following changes to the code. http://paste.ubuntu.com/497021/ I suspect that when i variable that I have used here is always initialised to be 1 and thus it doesn't give the desired output. Please suggest a method so that I can declare a static/extern type of variable. In my mind, scheme could be simpler: * if min free space check was triggered, setting flag to True and do not show alert anymore * after the first not triggering for this check, reset flag 2. In the Modal Dialog I was trying to get a provision for a Continue button which would exit the modal dialog and would lead me to the current view/favorites view. However, I was stuck up with its coding. Please check. http://paste.ubuntu.com/496530/ If I got it right, the problem that code which creates ModalAlert() switch to journal in any case, so you need to tweak this part not ModalAlert class itself. 3. Next thing, what I wanted to implement was to give a small alert/notification instead of the modal dialog indicating the % free memory or a warning. I am also attaching the screenshots.The image 1 is the output when I make the changes listed in 1 while 2 is the output for Point No. 2. Waiting for your valuable inputs, Regards, Mukul Gupta Research Engineer, SEETA -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Hard Code Freeze exception #2362
Hi all, http://bugs.sugarlabs.org/ticket/2362 Issue was introduced by selecting non-ds entries in ObjectChooser (it creates symlinks to not break existed practice in activities that assume that all ds files are on the same fs and can be hard linking) but the same problem might happen while trying to store symlinks directly. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SL Bug #484: Successful file transfer: offer to open Journal and to open activity
On Tue, Sep 28, 2010 at 12:28:19AM +0530, Mukul Gupta wrote: Hi, I was looking at Bug #484 relating to Successful File Transfer: Offer to open journal and to Open activity. I realised that 'Dismiss' button was added in Sugar 0.88 I wish to ask you whether we have arrived at a conclusion on implementing the options Show Journal and Open an activity as suggested by Eben. Didn't find it at the comments in the ticket. Moreover, I tried to reproduce the error but I fail to understand why there is no invitation to the user when a file is transferred to him. Did you get any errors while transferring session on both sides? Further, how do we get to know whether the file has been transferred. Please clarify. All file transferring related code is concentrated in /src/jarabe/model/filetransfer.py file in sugar project, see how it is being used in the rest sugar code. But you need to understand how Telepathy[1] work at first. [1] http://telepathy.freedesktop.org/wiki/ Regards, Mukul Gupta -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introduction
On Tue, Sep 28, 2010 at 06:46:00AM -0400, Steven Parrish wrote: Some of you may have already heard that I have accepted a position with ActivityCentral to be the project manager for Dextrose. Great to hear! It feels like I have come full circle as I started out as a volunteer maintaining the F11 for the XO-1 builds for the past 18 months. That work was very rewarding and I was glad to see OLPC step in and release official builds based on my work. The F11 for the XO-1 was also a starting point for the original Dextrose system, which Bernie Innocenti brought to fruition. Now we will be taking the original Dextrose and expanding upon it. Dextrose2 will be the result. Based on Fedora11 and Sugar 0.88 it will strive for stability, while providing deployments with a customizable product. I have already started creating builds for the new system with additional language support, and they can be found at http://wiki.sugarlabs.org/go/Dextrose . The builds will be for both the XO-1 and XO-1.5 and will be available both with Gnome and without. What about reusing bazaar.sl.o as Dextrose repository for all sugar packages (it could be only sugar, other packages like hw maybe reused directly from upstream, attached after bazaar repo or even build on bazaar)? I'm planing to have 0.88 Sugar Platform run on f11 at the end of this week. The benefits I see here is that we can reuse Dextrose efforts(regarding to sugar itself) in other sugar distros directly (just building for particular distro). Also, we can have the same repo of activities on bazaar (w/o repacking it for several distros). We have a team of developers at SEETA who will be working on this with us. Many of them are already known to the community and more will become known as they join the effort. I have already started going over the outstanding issues and know that with everyone's help we can make Dextrose the Premier system for XO deployments. The issues that need to be worked on can be found at: http://bugs.sugarlabs.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentkeywords=$love and http://bugs.sugarlabs.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=componentcol=statuscol=typecol=prioritycol=milestonekeywords=$extrose If you are already working on any of these tickets please send me a quick note as to which tickets you are working on and what the status is. I look forward to working with everyone. Steven Parrish smparr...@gmail.com ___ 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
Re: [Sugar-devel] wordgroupz ( A vocabulary building app) ported to sugar
On Wed, Sep 29, 2010 at 03:45:01PM +0100, Gary Martin wrote: On 26 Sep 2010, at 08:36, Ratnadeep Debnath wrote: Hi, Lexicology is the word that means studying words. It includes collecting words, classifying them, researching, learning how to spell it, etc. wordGroupz helps one do such things. On a general note, rather than trying to make an .xo bundle out of all this (bundles should be self contained with all needed resources/dependancies inside), I think your best bet is to try and get it packaged somehow for distros, or perhaps speak with alsroot about his 0install work. The idea I've came is that there are no silver bullets and issues like this can't be effectively and obviously solved within heterogeneous environments (like where sugar is using, e.g. several distros and several releases of the same distro) just by e.g. bundling all time. The way I'm implementing right now is supporting full life cycle of activities. So, it is not obvious and fast. But what I've already done(it will be ready to test at the end of this week) could be used in some way. It will looks like, you are add additional keys to your activity.info file including requires = nltk-python and using sweets push command, send it to bazaar.sl.o. If everything is ok, users can attach repositories (for at least for fedora and debian/ubuntu) from bazaar.sl.o and install your activity (and all deps) from native packages. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.90.0
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.90.0.tar.bz2 == News == * Do not store symlinks #2362 (Aleksey Lim) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Chat-68
== Source == http://download.sugarlabs.org/sources/sucrose/fructose/Chat/Chat-68.tar.bz2 == News == * Update translations for de and ta ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Downgrading activities not allowed. (#2164)
On Thu, Oct 07, 2010 at 07:30:36PM +0530, shan...@seeta.in wrote:
From: Shanjit Singh Jajmann shan...@seeta.in, Anubhav Aggarwal
anub...@seeta.in
Downgrading an activity is now made possible. When a .xo file of a version
older than the currently installed version is clicked, a downgrading option
is made available, by popping up of a confirmation alert. Depending upton the
choice selected you can downgrade the activity.
---
src/jarabe/journal/journalactivity.py | 36 +++--
src/jarabe/journal/listview.py|7 +++-
src/jarabe/journal/misc.py| 56
-
src/jarabe/model/bundleregistry.py| 18 +++---
4 files changed, 91 insertions(+), 26 deletions(-)
mode change 100644 = 100755 src/jarabe/journal/misc.py
mode change 100644 = 100755 src/jarabe/model/bundleregistry.py
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..2af55d3 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -28,6 +28,7 @@ import os
from sugar.graphics.window import Window
from sugar.graphics.alert import ErrorAlert
+from sugar.graphics.alert import ConfirmationAlert
from sugar.bundle.bundle import ZipExtractException, RegistrationException
from sugar import env
@@ -128,7 +129,7 @@ class JournalActivity(Window):
self.connect('window-state-event', self.__window_state_event_cb)
self.connect('key-press-event', self._key_press_event_cb)
self.connect('focus-in-event', self._focus_in_event_cb)
-
+
model.created.connect(self.__model_created_cb)
model.updated.connect(self.__model_updated_cb)
model.deleted.connect(self.__model_deleted_cb)
@@ -136,7 +137,6 @@ class JournalActivity(Window):
self._dbus_service = JournalActivityDBusService(self)
self.iconify()
-
self._critical_space_alert = None
self._check_available_space()
@@ -145,7 +145,29 @@ class JournalActivity(Window):
alert.connect('response', self.__alert_response_cb)
self.add_alert(alert)
alert.show()
-
+
+def __activity_alert1_cb(self):
+ if misc.check_previous_install() == 1 and misc.return_checked()==0:
+ alert1 = ConfirmationAlert()
+ logging.debug('value of misc is %d',
misc.check_previous_install())
+ alert1.props.title=_('Previous Version Found')
+ alert1.props.msg = _('A previous version of an installed
activity was found. Are you sure you want to continue with installation ?
If Yes click
Ok and the activity icon of the older .xo file in the Journal')
+ alert1.connect('response', self.__alert1_response_cb)
+ self.add_alert(alert1)
+ alert1.show()
+
+def __alert1_response_cb(self, alert1, response_id):
+if response_id is gtk.RESPONSE_OK:
+logging.debug('value of checked initial %d',
misc.return_checked())
+logging.debug('Installing previous version')
+self.remove_alert(alert1)
+misc.checked = 1
+logging.debug('value of checked final %d', misc.return_checked())
+
+elif response_id is gtk.RESPONSE_CANCEL:
+logging.debug('Cancelled by user')
+self.remove_alert(alert1)
+
def __alert_response_cb(self, alert, response_id):
self.remove_alert(alert)
@@ -166,6 +188,8 @@ class JournalActivity(Window):
self._list_view = ListView()
self._list_view.connect('detail-clicked', self.__detail_clicked_cb)
self._list_view.connect('clear-clicked', self.__clear_clicked_cb)
+self._list_view.connect('icon-clicked', self.__icon_clicked_cb)
+logging.debug('icon clicked in main')
self._main_view.pack_start(self._list_view)
self._list_view.show()
@@ -195,7 +219,11 @@ class JournalActivity(Window):
keyname = gtk.gdk.keyval_name(event.keyval)
if keyname == 'Escape':
self.show_main_view()
-
+
+def __icon_clicked_cb(self,a):
+ logging.debug('value of misc is %d',
misc.check_previous_install())
+ self.__activity_alert1_cb()
+
def __detail_clicked_cb(self, list_view, object_id):
self._show_secondary_view(object_id)
diff --git a/src/jarabe/journal/listview.py b/src/jarabe/journal/listview.py
index 3d6281a..3dbcc2d 100644
--- a/src/jarabe/journal/listview.py
+++ b/src/jarabe/journal/listview.py
@@ -466,8 +466,12 @@ class ListView(BaseListView):
__gsignals__ = {
'detail-clicked': (gobject.SIGNAL_RUN_FIRST,
gobject.TYPE_NONE,
- ([object]))
Re: [Sugar-devel] [PATCH] Downgrading activities not allowed. (#2164)
On Wed, Oct 13, 2010 at 07:28:51PM +0530, shan...@seeta.in wrote:
Downgrading an activity is now made possible. When a .xo file of a version
older than the currently installed version is clicked, a downgrading option
is made available, by popping up of a confirmation alert. Depending upton the
choice selected you can downgrade the activity.
v1 - v2. Named according to the nomenclature suggested,inline function
used,signal emission condition revised,global variables removed.
As I was talking while IRC discussion, I don't think that processing
downgrade hook in every misc.resume invocation place (you missed
misc.resume call in expandedentry.py, journaltoolbox.py and
palettes.py) is useful, more apriproate is keeping it in one place
(whatevery it will be).
Signed-off-by: Shanjit Singh Jajmann shan...@seeta.in, Anubhav Aggarwal
anub...@seeta.in
---
src/jarabe/journal/journalactivity.py | 15 +++
src/jarabe/journal/listview.py| 22 ++
src/jarabe/journal/misc.py|8 +---
src/jarabe/model/bundleregistry.py| 11 ++-
4 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..d0af20a 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -28,6 +28,7 @@ import os
from sugar.graphics.window import Window
from sugar.graphics.alert import ErrorAlert
+from sugar.graphics.alert import ConfirmationAlert
from sugar.bundle.bundle import ZipExtractException, RegistrationException
from sugar import env
@@ -166,6 +167,7 @@ class JournalActivity(Window):
self._list_view = ListView()
self._list_view.connect('detail-clicked', self.__detail_clicked_cb)
self._list_view.connect('clear-clicked', self.__clear_clicked_cb)
+self._list_view.connect('older-version-clicked',
self.__older_version_clicked_cb)
self._main_view.pack_start(self._list_view)
self._list_view.show()
@@ -204,6 +206,19 @@ class JournalActivity(Window):
def __go_back_clicked_cb(self, detail_view):
self.show_main_view()
+def __older_version_clicked_cb(self,a):
+alert1=ConfirmationAlert()
+alert1.props.title = _('Newer Version Found')
+alert1.props.msg = _('Newer version of the chosen activity is
available do you still want to continue with the installation?
If Yes click Ok
and the activity icon of the older .xo file in the Journal')
+alert1.connect('response',self.__downgrade_alert_response_cb)
+self.add_alert(alert1)
+alert1.show()
+def __downgrade_alert_response_cb(self, alert1, response_id):
+if response_id is gtk.RESPONSE_OK:
+self.remove_alert(alert1)
+self._list_view.downgrade_confirmation()
+elif response_id is gtk.RESPONSE_CANCEL:
+self.remove_alert(alert1)
def _query_changed_cb(self, toolbar, query):
self._list_view.update_with_query(query)
diff --git a/src/jarabe/journal/listview.py b/src/jarabe/journal/listview.py
index 3d6281a..653f400 100644
--- a/src/jarabe/journal/listview.py
+++ b/src/jarabe/journal/listview.py
@@ -27,6 +27,7 @@ import pango
from sugar.graphics import style
from sugar.graphics.icon import CanvasIcon, Icon, CellRendererIcon
from sugar.graphics.xocolor import XoColor
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar import util
from jarabe.journal.listmodel import ListModel
@@ -466,12 +467,17 @@ class ListView(BaseListView):
__gsignals__ = {
'detail-clicked': (gobject.SIGNAL_RUN_FIRST,
gobject.TYPE_NONE,
- ([object]))
+ ([object])),
+'older-version-clicked': (gobject.SIGNAL_RUN_FIRST,
+ gobject.TYPE_NONE,
+ ([]))
}
+
def __init__(self):
BaseListView.__init__(self)
self._is_dragging = False
+self.downgrade = False
self.tree_view.connect('drag-begin', self.__drag_begin_cb)
self.tree_view.connect('button-release-event',
@@ -522,12 +528,20 @@ class ListView(BaseListView):
def __detail_clicked_cb(self, cell, uid):
self.emit('detail-clicked', uid)
-
+def downgrade_confirmation(self):
+self.downgrade = True
def __icon_clicked_cb(self, cell, path):
row = self.tree_view.get_model()[path]
metadata = model.get(row[ListModel.COLUMN_UID])
-misc.resume(metadata)
-
+if not self.downgrade:
+try:
+misc.resume(metadata)
+except AlreadyInstalledException :
+
Re: [Sugar-devel] [PATCH] Disable Start menu item for entries that can't be opened(Bug#328)
On Thu, Oct 14, 2010 at 11:32:34PM +0530, Mukul Gupta wrote:
The patch disables the Start and Start With menu items for files
which can't be opened by any installed activity and instead
replace it with a hover dropdown with a menu item 'No activity
installed to start entry'
You need to pass your code through pylint and pep8 (the rest of sugar
code might not confirm pylint/pep8 but you need to leave it as is,
it will be fixed by separate patch later).
---
src/jarabe/journal/palettes.py | 99 +--
1 files changed, 53 insertions(+), 46 deletions(-)
diff --git a/src/jarabe/journal/palettes.py b/src/jarabe/journal/palettes.py
index 7c3e5ff..56df595 100644
--- a/src/jarabe/journal/palettes.py
+++ b/src/jarabe/journal/palettes.py
@@ -62,51 +62,59 @@ class ObjectPalette(Palette):
Palette.__init__(self, primary_text=title,
icon=activity_icon)
-if metadata.get('activity_id', ''):
-resume_label = _('Resume')
-resume_with_label = _('Resume with')
-else:
-resume_label = _('Start')
-resume_with_label = _('Start with')
-menu_item = MenuItem(resume_label, 'activity-start')
-menu_item.connect('activate', self.__start_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
-
-menu_item = MenuItem(resume_with_label, 'activity-start')
-self.menu.append(menu_item)
-menu_item.show()
-start_with_menu = StartWithMenu(self._metadata)
-menu_item.set_submenu(start_with_menu)
-
-client = gconf.client_get_default()
-color = XoColor(client.get_string('/desktop/sugar/user/color'))
-menu_item = MenuItem(_('Copy'))
-icon = Icon(icon_name='edit-copy', xo_color=color,
-icon_size=gtk.ICON_SIZE_MENU)
-menu_item.set_image(icon)
-menu_item.connect('activate', self.__copy_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
-
-menu_item = MenuItem(_('Send to'), 'document-send')
-self.menu.append(menu_item)
-menu_item.show()
-
-friends_menu = FriendsMenu()
-friends_menu.connect('friend-selected', self.__friend_selected_cb)
-menu_item.set_submenu(friends_menu)
-
-if detail == True:
-menu_item = MenuItem(_('View Details'), 'go-right')
-menu_item.connect('activate', self.__detail_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
-
-menu_item = MenuItem(_('Erase'), 'list-remove')
-menu_item.connect('activate', self.__erase_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
+ if misc.get_activities(metadata):
+ if metadata.get('activity_id', ''):
+ resume_label = _('Resume')
+ resume_with_label = _('Resume with')
+ else:
+ resume_label = _('Start')
+ resume_with_label = _('Start with')
+ menu_item = MenuItem(resume_label, 'activity-start')
+ menu_item.connect('activate', self.__start_activate_cb)
+ self.menu.append(menu_item)
+ menu_item.show()
+
+ menu_item = MenuItem(resume_with_label, 'activity-start')
+ self.menu.append(menu_item)
+ menu_item.show()
it seems redundant
+ start_with_menu = StartWithMenu(self._metadata)
+ menu_item.set_submenu(start_with_menu)
+
+ else:
+ resume_label = _('No activity installed to start entry')
+ menu_item = MenuItem(resume_label)
+ menu_item.set_sensitive(False)
+ self.menu.append(menu_item)
+ menu_item.show()
+
+ client = gconf.client_get_default()
+ color = XoColor(client.get_string('/desktop/sugar/user/color'))
+ menu_item = MenuItem(_('Copy'))
+ icon = Icon(icon_name='edit-copy', xo_color=color,
+ icon_size=gtk.ICON_SIZE_MENU)
+ menu_item.set_image(icon)
+ menu_item.connect('activate', self.__copy_activate_cb)
+ self.menu.append(menu_item)
+ menu_item.show()
+
+ menu_item = MenuItem(_('Send to'), 'document-send')
+ self.menu.append(menu_item)
+ menu_item.show()
+
+ friends_menu = FriendsMenu()
+ friends_menu.connect('friend-selected', self.__friend_selected_cb)
+ menu_item.set_submenu(friends_menu)
+
+ if detail == True:
+ menu_item = MenuItem(_('View Details'), 'go-right')
+ menu_item.connect('activate', self.__detail_activate_cb)
+ self.menu.append(menu_item)
+ menu_item.show()
+
+ menu_item = MenuItem(_('Erase'), 'list-remove')
+ menu_item.connect('activate', self.__erase_activate_cb)
+ self.menu.append(menu_item)
+ menu_item.show()
def __start_activate_cb(self, menu_item):
Re: [Sugar-devel] [PATCH v2 sugar] Disable Start menu item for entries that can't be opened(Bug#328)
On Fri, Oct 15, 2010 at 04:19:43PM +0530, Mukul Gupta wrote:
The patch disables the Start and Start With menu items for files
which can't be opened by any installed activity and instead
replace it with a hover dropdown with a menu item 'No activity
installed to start entry'
---
src/jarabe/journal/palettes.py | 38 +++---
1 files changed, 23 insertions(+), 15 deletions(-)
v1-v2: Patch remade as per pep8 standards
diff --git a/src/jarabe/journal/palettes.py b/src/jarabe/journal/palettes.py
index 7c3e5ff..2ab93fe 100644
--- a/src/jarabe/journal/palettes.py
+++ b/src/jarabe/journal/palettes.py
@@ -62,22 +62,30 @@ class ObjectPalette(Palette):
Palette.__init__(self, primary_text=title,
icon=activity_icon)
-if metadata.get('activity_id', ''):
-resume_label = _('Resume')
-resume_with_label = _('Resume with')
-else:
-resume_label = _('Start')
-resume_with_label = _('Start with')
-menu_item = MenuItem(resume_label, 'activity-start')
-menu_item.connect('activate', self.__start_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
+if misc.get_activities(metadata):
There is an issue. For bundles, it will change existed beahviour
(click on bundles, .xo and .xol, sugar install/start it), you need to
check for bundles as well (misc.is_*_bundle).
+if metadata.get('activity_id', ''):
+resume_label = _('Resume')
+resume_with_label = _('Resume with')
+else:
+resume_label = _('Start')
+resume_with_label = _('Start with')
+menu_item = MenuItem(resume_label, 'activity-start')
+menu_item.connect('activate', self.__start_activate_cb)
+self.menu.append(menu_item)
+menu_item.show()
-menu_item = MenuItem(resume_with_label, 'activity-start')
-self.menu.append(menu_item)
-menu_item.show()
-start_with_menu = StartWithMenu(self._metadata)
-menu_item.set_submenu(start_with_menu)
+menu_item = MenuItem(resume_with_label, 'activity-start')
+self.menu.append(menu_item)
+menu_item.show()
+start_with_menu = StartWithMenu(self._metadata)
+menu_item.set_submenu(start_with_menu)
+
+else:
+resume_label = _('No activity installed to start entry')
+menu_item = MenuItem(resume_label)
+menu_item.set_sensitive(False)
+self.menu.append(menu_item)
+menu_item.show()
client = gconf.client_get_default()
color = XoColor(client.get_string('/desktop/sugar/user/color'))
--
1.7.0.4
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v2 sugar] Disable Start menu item for entries that can't be opened(Bug#328)
On Sat, Oct 16, 2010 at 05:29:35PM +0530, Mukul Gupta wrote: Team, Thank you. Appreciate your feedback. I have revised the patch which restores its existing behavior for bundles and have incorporated Frederick's idea of having a common and an understandable English wording. http://lists.sugarlabs.org/archive/sugar-devel/2010-October/027925.html hint: there is --in-reply-to (the value should be something like Message-ID: tag in existed ML post) git argument to attach new `git send-email` emails to already exsited ML thread, it will help peopel to track pacthces for the same issue) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v3 sugar] Disable Start menu item for entries that can't be opened(Bug#328)
On Sat, Oct 16, 2010 at 05:16:31PM +0530, Mukul Gupta wrote:
The patch disables the Start and Start With menu items for files
which can't be opened by any installed activity and instead
replace it with a hover dropdown with a menu item 'No activity
installed to start entry'
---
src/jarabe/journal/palettes.py | 42 +++
1 files changed, 25 insertions(+), 17 deletions(-)
v1-v2: Patch remade as per pep8 standards
v2-v3: Revised English wording and optimised behaviour for bundles
diff --git a/src/jarabe/journal/palettes.py b/src/jarabe/journal/palettes.py
index 7c3e5ff..aa09cf0 100644
--- a/src/jarabe/journal/palettes.py
+++ b/src/jarabe/journal/palettes.py
@@ -62,22 +62,30 @@ class ObjectPalette(Palette):
Palette.__init__(self, primary_text=title,
icon=activity_icon)
-if metadata.get('activity_id', ''):
-resume_label = _('Resume')
-resume_with_label = _('Resume with')
-else:
-resume_label = _('Start')
-resume_with_label = _('Start with')
-menu_item = MenuItem(resume_label, 'activity-start')
-menu_item.connect('activate', self.__start_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
+if misc.get_activities(metadata) or misc.is_bundle(metadata):
+if metadata.get('activity_id', ''):
+resume_label = _('Resume')
+resume_with_label = _('Resume with')
+else:
+resume_label = _('Start')
+resume_with_label = _('Start with')
+menu_item = MenuItem(resume_label, 'activity-start')
+menu_item.connect('activate', self.__start_activate_cb)
+self.menu.append(menu_item)
+menu_item.show()
-menu_item = MenuItem(resume_with_label, 'activity-start')
-self.menu.append(menu_item)
-menu_item.show()
-start_with_menu = StartWithMenu(self._metadata)
-menu_item.set_submenu(start_with_menu)
+menu_item = MenuItem(resume_with_label, 'activity-start')
+self.menu.append(menu_item)
+menu_item.show()
+start_with_menu = StartWithMenu(self._metadata)
+menu_item.set_submenu(start_with_menu)
+
+else:
+resume_label = _('No activity is available to start entry')
+menu_item = MenuItem(resume_label)
+menu_item.set_sensitive(False)
+self.menu.append(menu_item)
+menu_item.show()
client = gconf.client_get_default()
color = XoColor(client.get_string('/desktop/sugar/user/color'))
@@ -204,9 +212,9 @@ class StartWithMenu(gtk.Menu):
if not self.get_children():
if metadata.get('activity_id', ''):
+1 for the rest but not sure about this one:
-resume_label = _('No activity to resume entry')
+resume_label = _('No activity is available to resume entry')
else:
-resume_label = _('No activity to start entry')
+resume_label = _('No activity is available to start entry')
we will break translators work w/o the reason (new wording leaves meaning
the same), afaik it is not common practice, better will be changing en
translation via translate.sl.o rather than in code.
menu_item = MenuItem(resume_label)
menu_item.set_sensitive(False)
self.append(menu_item)
--
1.7.0.4
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Downgrading activities not allowed. (SL#2164)
On Sat, Oct 16, 2010 at 01:31:02PM +0530, shan...@seeta.in wrote:
Downgrading an activity is now made possible. When a .xo file of a version
older than the currently installed version is clicked, a downgrading option
is made available, by popping up of a confirmation alert. Depending upton the
choice selected you can downgrade the activity.
Do we have designers feedback about should downgrade alert be a window
or regular alert in Journal (didn't find something in ML).
(btw I got noting while trying to resume older versin .xo)
v1 - v2. Named according to the nomenclature suggested,inline function
used,signal emission condition revised,global variables removed.
v2 - v3. Taking care of all calling of misc.resume.
Signed-off-by: Shanjit Singh Jajmann shan...@seeta.in, Anubhav Aggarwal
anub...@seeta.in
---
src/jarabe/journal/misc.py | 29 +---
src/jarabe/journal/versionalert.py | 121
src/jarabe/model/bundleregistry.py |9 ++-
3 files changed, 145 insertions(+), 14 deletions(-)
create mode 100644 src/jarabe/journal/versionalert.py
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..99ea2d4 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -30,6 +30,7 @@ from sugar.graphics.xocolor import XoColor
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
from sugar.bundle.contentbundle import ContentBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar import util
from jarabe.view import launcher
@@ -150,6 +151,7 @@ def get_activities(metadata):
def resume(metadata, bundle_id=None):
registry = bundleregistry.get_registry()
+version_downgrade = False
if is_activity_bundle(metadata) and bundle_id is None:
@@ -159,20 +161,25 @@ def resume(metadata, bundle_id=None):
bundle = ActivityBundle(file_path)
if not registry.is_installed(bundle):
logging.debug('Installing activity bundle')
-registry.install(bundle)
+try:
+registry.install(bundle)
+except AlreadyInstalledException:
+v_alert = VersionAlert()
+v_alert.give_bundle(bundle)
+version_downgrade= True
else:
logging.debug('Upgrading activity bundle')
registry.upgrade(bundle)
-
-logging.debug('activityfactory.creating bundle with id %r',
-bundle.get_bundle_id())
-installed_bundle = registry.get_bundle(bundle.get_bundle_id())
-if installed_bundle:
-launch(installed_bundle)
-else:
-logging.error('Bundle %r is not installed.',
- bundle.get_bundle_id())
-
+if not version_downgrade:
+logging.debug('activityfactory.creating bundle with id %r',
+bundle.get_bundle_id())
+installed_bundle = registry.get_bundle(bundle.get_bundle_id())
+if installed_bundle:
+launch(installed_bundle)
+else:
+logging.error('Bundle %r is not installed.',
+ bundle.get_bundle_id())
+
elif is_content_bundle(metadata) and bundle_id is None:
logging.debug('Creating content bundle')
diff --git a/src/jarabe/journal/versionalert.py
b/src/jarabe/journal/versionalert.py
new file mode 100644
index 000..2f27a2f
--- /dev/null
+++ b/src/jarabe/journal/versionalert.py
@@ -0,0 +1,121 @@
+
+# Copyright (C) 2008 One Laptop Per Child
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+import gtk
+from gettext import gettext as _
+
+from sugar.graphics import style
+from jarabe.model import bundleregistry
+from sugar.activity import activityfactory
+
+class VersionAlert(gtk.Window):
+
+def __init__(self):
+gtk.Window.__init__(self)
+
+self.set_border_width(style.LINE_WIDTH)
+offset = style.GRID_CELL_SIZE
+width = gtk.gdk.screen_width() - offset * 3
+height = gtk.gdk.screen_height() - offset * 8.5
+self.set_size_request(width, height)
+
Re: [Sugar-devel] [PATCH 0/3 sugar-datastore] PEP8 / pylint cleanups
On Fri, Oct 15, 2010 at 05:36:09PM +, Sascha Silbe wrote: Make sugar-datastore as PEP8 / pylint clean as possible (again). All remaining complaints are pylint bugs (doesn't recognise keyword arguments in decorators) resp. shortcomings in pep8 (cannot selectively disable a warning for a specific piece of code). Sascha Silbe (3): PEP8 cleanups datastore, migration: remove unused import traceback indexstore: disable pylint warning W0221 for parse_query src/carquinyol/datastore.py |1 - src/carquinyol/filestore.py |3 ++- src/carquinyol/indexstore.py|2 +- src/carquinyol/layoutmanager.py |1 + src/carquinyol/migration.py |1 - 5 files changed, 4 insertions(+), 4 deletions(-) Commited, with edditional patches and HACKING file w/ instruction to use sugar-lint in git pre-commit hook. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ticket #2318 display free journal space in volume toolbar
On Sun, Oct 17, 2010 at 12:58:27AM +0530, Ishan Bansal wrote:
Hi Aleksey
I had submitted the patch for the http://bugs.sugarlabs.org/ticket/2318
You can check the patch at
http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg16721.html
Wish if you could review it and provide me feedback on any improvement
required.
You need to check your patch (only your patch, the rest of code does not
conform all checks) w/ pylint/pep8 (eg using sugar-lint[1]).
+label = 'Journal'
string needs to be kept gettextized ie _('Journal')
[1] http://wiki.sugarlabs.org/go/Activity_Team/Sugar_Lint
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v4 sugar] Downgrading activities not allowed. (#2164)
On Sun, Oct 17, 2010 at 01:55:00AM +0530, anub...@seeta.in wrote:
Downgrading an activity is now made possible. When a .xo file of a version
older
than the currently installed version is clicked, a downgrading option is made
available, by popping up of a confirmation alert. Depending upton the choice
selected you can downgrade the activity.
So we are in agreement to not use special window for downgrade alert
(we have at least one response from Garry), so downgarade alert
should be just regular alert(alert.py from sugar-toolkit)
in Journal window.
(and you didn't pass your patch though sugar-lint)
v1 - v2. Named according to the nomenclature suggested,inline function
used,signal emission condition revised,global variables removed.
v2 - v3. Taking care of all calling of misc.resume.
v3 - v4. Changes in the copyright of the new file
Signed-off-by: Anubhav Aggarwal anub...@seeta.in , Shanjit Singh Jajmann
shan...@seeta.in
---
src/jarabe/journal/misc.py | 29 ++---
src/jarabe/journal/versionalert.py | 122
src/jarabe/model/bundleregistry.py |9 ++-
3 files changed, 148 insertions(+), 12 deletions(-)
create mode 100644 src/jarabe/journal/versionalert.py
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..f060bb2 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -30,12 +30,14 @@ from sugar.graphics.xocolor import XoColor
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
from sugar.bundle.contentbundle import ContentBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar import util
from jarabe.view import launcher
from jarabe.model import bundleregistry, shell
from jarabe.journal.journalentrybundle import JournalEntryBundle
from jarabe.journal import model
+from jarabe.journal.versionalert import VersionAlert
def _get_icon_for_mime(mime_type):
generic_types = mime.get_all_generic_types()
@@ -150,6 +152,7 @@ def get_activities(metadata):
def resume(metadata, bundle_id=None):
registry = bundleregistry.get_registry()
+version_downgrade = False
if is_activity_bundle(metadata) and bundle_id is None:
@@ -159,19 +162,27 @@ def resume(metadata, bundle_id=None):
bundle = ActivityBundle(file_path)
if not registry.is_installed(bundle):
logging.debug('Installing activity bundle')
-registry.install(bundle)
+try:
+registry.install(bundle)
+except AlreadyInstalledException:
+v_alert = VersionAlert()
+v_alert.give_bundle(bundle)
+version_downgrade= True
+logging.debug('done')
+
else:
logging.debug('Upgrading activity bundle')
registry.upgrade(bundle)
-logging.debug('activityfactory.creating bundle with id %r',
-bundle.get_bundle_id())
-installed_bundle = registry.get_bundle(bundle.get_bundle_id())
-if installed_bundle:
-launch(installed_bundle)
-else:
-logging.error('Bundle %r is not installed.',
- bundle.get_bundle_id())
+if not version_downgrade:
+logging.debug('activityfactory.creating bundle with id %r',
+bundle.get_bundle_id())
+installed_bundle = registry.get_bundle(bundle.get_bundle_id())
+if installed_bundle:
+launch(installed_bundle)
+else:
+logging.error('Bundle %r is not installed.',
+ bundle.get_bundle_id())
elif is_content_bundle(metadata) and bundle_id is None:
diff --git a/src/jarabe/journal/versionalert.py
b/src/jarabe/journal/versionalert.py
new file mode 100644
index 000..b0e30b0
--- /dev/null
+++ b/src/jarabe/journal/versionalert.py
@@ -0,0 +1,122 @@
+#Copyright (C) 2010 Software for Education, Entertainment and Training
Activities
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+import gtk
+from gettext import gettext as _
+
+from sugar.graphics import style
+from jarabe.model import
Re: [Sugar-devel] [PATCH v4 sugar] Disable Start menu item for entries that can't be opened(Bug#328)
On Sun, Oct 17, 2010 at 11:11:41PM +0530, Mukul Gupta wrote:
The patch disables the Start and Start With menu items for files
which can't be opened by any installed activity and instead
replace it with a hover dropdown with a menu item 'No activity
installed to start entry'
Commited, thanks.
---
src/jarabe/journal/palettes.py | 38 +++---
1 files changed, 23 insertions(+), 15 deletions(-)
v1-v2:Patch remade as per pep8 standards
v2-v3:Revised English wording and optimised behaviour for bundles
v3-v4:Revised English wordings
diff --git a/src/jarabe/journal/palettes.py b/src/jarabe/journal/palettes.py
index 7c3e5ff..5005655 100644
--- a/src/jarabe/journal/palettes.py
+++ b/src/jarabe/journal/palettes.py
@@ -62,22 +62,30 @@ class ObjectPalette(Palette):
Palette.__init__(self, primary_text=title,
icon=activity_icon)
-if metadata.get('activity_id', ''):
-resume_label = _('Resume')
-resume_with_label = _('Resume with')
-else:
-resume_label = _('Start')
-resume_with_label = _('Start with')
-menu_item = MenuItem(resume_label, 'activity-start')
-menu_item.connect('activate', self.__start_activate_cb)
-self.menu.append(menu_item)
-menu_item.show()
+if misc.get_activities(metadata) or misc.is_bundle(metadata):
+if metadata.get('activity_id', ''):
+resume_label = _('Resume')
+resume_with_label = _('Resume with')
+else:
+resume_label = _('Start')
+resume_with_label = _('Start with')
+menu_item = MenuItem(resume_label, 'activity-start')
+menu_item.connect('activate', self.__start_activate_cb)
+self.menu.append(menu_item)
+menu_item.show()
-menu_item = MenuItem(resume_with_label, 'activity-start')
-self.menu.append(menu_item)
-menu_item.show()
-start_with_menu = StartWithMenu(self._metadata)
-menu_item.set_submenu(start_with_menu)
+menu_item = MenuItem(resume_with_label, 'activity-start')
+self.menu.append(menu_item)
+menu_item.show()
+start_with_menu = StartWithMenu(self._metadata)
+menu_item.set_submenu(start_with_menu)
+
+else:
+resume_label = _('No activity to start entry')
+menu_item = MenuItem(resume_label)
+menu_item.set_sensitive(False)
+self.menu.append(menu_item)
+menu_item.show()
client = gconf.client_get_default()
color = XoColor(client.get_string('/desktop/sugar/user/color'))
--
1.7.0.4
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v4 sugar] Shutdown (and Logout) menuitems should activate
On Wed, Oct 06, 2010 at 04:42:41AM +0530, Anurag Chowdhury wrote: We changed the cursor in home window to a busy cursor when the shutdown menu is activated and used glib.idle_add( ) to call the shut funtion when pygtk is idle to shutdown or logout the sugar session properly , hence letting the user know the validity of the shutdown process going on in the backend. --- src/jarabe/view/buddymenu.py | 26 -- 1 files changed, 20 insertions(+), 6 deletions(-) v1 was Reviewed-By: James Cameron quozl at laptop.org v2 was Reviewed-By: Tomeu Vizosoto...@sugarlabs.org v3 was Reviewed-By: James Cameron quozl at laptop.org v3-v4 : Removed redundant function calls like glib.timeout_add() and gtk.main() diff --git a/src/jarabe/view/buddymenu.py b/src/jarabe/view/buddymenu.py index 0ba6cc1..78cdeb4 100644 --- a/src/jarabe/view/buddymenu.py +++ b/src/jarabe/view/buddymenu.py @@ -21,6 +21,8 @@ from gettext import gettext as _ import gtk import gconf import dbus +import glib +import jarabe from sugar.graphics.palette import Palette from sugar.graphics.menuitem import MenuItem @@ -98,16 +100,28 @@ class BuddyMenu(Palette): item.show() def __logout_activate_cb(self, menu_item): -session_manager = get_session_manager() -session_manager.logout() +def shut(self, menu_item): +session_manager = get_session_manager() +session_manager.logout() +window = jarabe.desktop.homewindow.get_instance() +window.get_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH)) +glib.idle_add(shut,self,menu_item) def __reboot_activate_cb(self, menu_item): -session_manager = get_session_manager() -session_manager.reboot() +def shut(self, menu_item): +session_manager = get_session_manager() +session_manager.reboot() +window = jarabe.desktop.homewindow.get_instance() +window.get_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH)) +glib.idle_add(shut,self,menu_item) def __shutdown_activate_cb(self, menu_item): -session_manager = get_session_manager() -session_manager.shutdown() +def shut(self, menu_item): +session_manager = get_session_manager() +session_manager.reboot() s/reboot/shutdown/ +window = jarabe.desktop.homewindow.get_instance() +window.get_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH)) +glib.idle_add(shut,self,menu_item) def __controlpanel_activate_cb(self, menu_item): panel = ControlPanel() -- 1.7.2.3 shut method name seems to be misusing, btw what about code: def _quit(self, method): journal = jarabe.desktop.homewindow.get_instance() journal.get_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH)) gobject.idle_add(method) def __logout_activate_cb(self, menu_item): self._quit(get_session_manager().logout) def __reboot_activate_cb(self, menu_item): self._quit(get_session_manager().reboot) def __shutdown_activate_cb(self, menu_item): self._quit(get_session_manager().shutdown) Also, there are several places w/ redundant spaces, use sugar-lint to fix it. ___ 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
Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On Mon, Oct 18, 2010 at 12:43:49AM +0530, Anurag Chowdhury wrote: Team I had submitted the patch for the http://bugs.sugarlabs.org/ticket/2080 You can check the patch at http://lists.sugarlabs.org/archive/sugar-devel/2010-October/027748.html Wish if you could review it and provide me feedback on any improvement required. Not sure if we are doing right thing by trying to fight w/ consequences, what about pulsing by alpha channel (ie w/o re-rendering svg). It might be used only on restricted systems like XO (though I don't see problems to do the same in all cases). Regards Anurag -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Bazaar glucose packages
Hi all, Background. The one of core parts of Zero Sugar is Bazaar[1]. It is patched version of OBS, openSUSE distribution/development platform. It is intended to be a full functional development backend for sugar doers/developers. Starting from just uploading sources tarballs (for pure python based activities), via building binary based activities and finising with creating sugar distributions. It is not replacement of ASLO, just moving development related stuff from ASLO to Bazaar and keep ASLO only as catalog of activities that will be download (somehow) from Bazaar. How it might useful right now. While working on Zero Sugar, I've mostly finished native packages part. It might be useful for others right now. On Bazaar, there are major projects[3]: Platformdependencies of sugar components (aliased to upstream packages or built from sources) Coregit version of glucose that is(will) be built on daily basis Core:release stable glucose versions built on purpose eg 0.88 for Ubuntu-10.04 for Trisqule since it is not well supported in upstream Right now, Platfom and Core* projects might be used just by attaching their repositories to native packaging system and installing particular packages. Supported distros are [4]. It is also possible to add other rpm/deb based distros (and their releases) and might be done on purpose. Not rpm or deb releases might be covered by further 0install implementation. Easy usage of Bazaar packages. Install sweets command: wget http://download.sugarlabs.org/packages/0sugar/sweets-1.sh sh sweets-1.sh (relogin from X session to take into account new PATH) Add Bazaar repos (your-distro is a name of distro mentioned on particular Bazaar project page): sweets repo_add Platform/your-distro sweets repo_add Core/your-distro Install sugar packages: sweets download sugar sugar/emulator Run sugar: sweets sugar sweets sugar/emulator For example, activity developers who need recent glucose version can just install Core packages and keep it up-to-date and do not use jhbuild. Close plans. * In-place usage of glucose projects (not only). It will be full jhbuild replacement (not only using packaged Core). For example, developer might install Core and git clone e.g. sugar-toolkit and start using newly cloned code w/ the rest from Core packages. * Core:Lab, the laboratory of sugar core code. It will be intended to easy check new sugar features like rainbow or new Journal. [1] https://bazaar.sugarlabs.org/ [2] https://build.opensuse.org/ [3] https://bazaar.sugarlabs.org/project/list_public [4] https://bazaar.sugarlabs.org/project/repositories?project=Platform -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Re-initiate Packaging Team
Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 08:02:40AM +, Aleksey Lim wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar * take care of Bazaar (as developers/doers backend) and ASLO (as users frontend) for activities BTW, maybe Packaging is not appropriate name, any ideas? -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 03:45:58PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 1:32 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? Account Services team is the preferred trade name for small size teams engaged in support work (answering questions, or communicating with the development team, maintaining builds and their timely releases). Some companies use Internal System Architect nomenclature too. When team sizes grew bigger, this work comes under the umbrella of Members of Technical Staff. Well, I personally prefer something less official/corporate, e.g., Bazaar Team :) Regards, Manu -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 04:31:49PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 4:13 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Oct 21, 2010 at 03:45:58PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 1:32 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? Account Services team is the preferred trade name for small size teams engaged in support work (answering questions, or communicating with the development team, maintaining builds and their timely releases). Some companies use Internal System Architect nomenclature too. When team sizes grew bigger, this work comes under the umbrella of Members of Technical Staff. Well, I personally prefer something less official/corporate, e.g., Bazaar Team :) Bazaar in Hindi refers to market. Suspect that many people would confuse it with the marketing team :-) Though Bazaar is referring more to The Cathedral and the Bazaar in FOSS world (afaik) rather to marketing (which sounds, in some meaning, quite opposite thing :). What about Sweet Team then, i.e., sweet is an id of packages on bazaar.sl.o and sweets is the main command-line tool. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 11:26:49AM +, Aleksey Lim wrote: On Thu, Oct 21, 2010 at 04:31:49PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 4:13 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Oct 21, 2010 at 03:45:58PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 1:32 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? Account Services team is the preferred trade name for small size teams engaged in support work (answering questions, or communicating with the development team, maintaining builds and their timely releases). Some companies use Internal System Architect nomenclature too. When team sizes grew bigger, this work comes under the umbrella of Members of Technical Staff. Well, I personally prefer something less official/corporate, e.g., Bazaar Team :) Bazaar in Hindi refers to market. Suspect that many people would confuse it with the marketing team :-) Though Bazaar is referring more to The Cathedral and the Bazaar in FOSS world (afaik) rather to marketing (which sounds, in some meaning, quite opposite thing :). What about Sweet Team then, i.e., sweet is an id of packages on bazaar.sl.o and sweets is the main command-line tool. Of course it might be something neutral like Distribution Team. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On Fri, Oct 22, 2010 at 04:19:26AM +0530, Manusheel Gupta wrote: Team, Any further inputs? Please share. Anurag did discuss with Aleksey at IRC, and he seems to agree with his approach. Aleksey, am I right? I'm ok w/ having a hack like proposed patch. Though it is not solving original issue. Bernie, Please us know if the patch meets the requirements. If yes, can we add the documentation of the approach followed by us at the wiki? Regards, Manu On Mon, Oct 18, 2010 at 11:40 PM, Aleksey Lim alsr...@member.fsf.orgwrote: On Mon, Oct 18, 2010 at 12:43:49AM +0530, Anurag Chowdhury wrote: Team I had submitted the patch for the http://bugs.sugarlabs.org/ticket/2080 You can check the patch at http://lists.sugarlabs.org/archive/sugar-devel/2010-October/027748.html Wish if you could review it and provide me feedback on any improvement required. Not sure if we are doing right thing by trying to fight w/ consequences, what about pulsing by alpha channel (ie w/o re-rendering svg). It might be used only on restricted systems like XO (though I don't see problems to do the same in all cases). Regards Anurag -- Aleksey ___ 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
Re: [Sugar-devel] Activity updates
On Tue, Oct 19, 2010 at 07:28:45PM -0200, Bernie Innocenti wrote: Quoting you from IRC: garycmartin 09:36:21 bernie: Was it you that mentioned that deployments did not want to point to ASLO for update as version were not being flagged correctly for Sugar release compatibility? garycmartin 09:45:09 bernie: FWIW, I've just been through 60+ activities testing ASLO installs on a clean XO-1 0.82 build (0.84 is next on my todo list). I only found 4 activities that didn't have an old enough past version uploaded for that release of Sugar, and only one activity that failed to launch due to a trivial file permission error in the bundle (SL#2464). Indeed, almost all activities are compatible across 0.84-0.88. Probably also 0.90. But the point is that deployments really need to ensure that the activity works with their lesson plans. For example, Turtle Art's sensors support has been broken for a while in ASLO. At any time someone could upload a new version of an activity that breaks some feature that deployments were relying upon. Without interposing an interim QA stage, possibly done by the deployment's education team, ASLO cannot be relied upon for updates. My proposed solution consits in reviving the microformat protocol for activity updating (already done by Anish) and then augment the existing concept of collections in ASLO to let deployments specify a particular bundle version. Just a couple of problem that can't be solved in such way: * problem is not only in activities itself but also in dependencies (some sugar distributions might have them but other don't) the only way for ASLO is bundling them all * binary based activities that are strictly depends on particular distro version (eg TuxPaint being built against fc9 crashes on fc9+updates) it is nightmare to try cover such questions on ASLO * collections are more users' method, so if one user decided to create new collection, he will break any QA efforts because can add arbitrary activity/version The way I have in mind is using Bazaar to cover all technical questions (development and QA related) and keep ASLO as a frontend for Bazaar packages. At the end, ASLO might have all activities hosted on Bazaar (for effectively solving issues w/ dependencies and binaries). Each ASLO activity will have a source, i.e., Bazaar project. (We should have a possibility to have bunch of versions of the same activity at the same time, eg, results of experiments of doers.) So, users can filter all activities (not only in plain list but in their collections as well) by source project. If sugar deployment created New Deployment project on Bazaar and linked/branched/created-new activities there, all their users can download only these activities (if they want to get QAed stuff). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Easy development process of core sugar components
Hi all, This is a trying to replace jhbuild. For example, for me it was all time needless obscured, i.e., it somewhat `git clone` to somewhere, somehow built it and somehow run it, and all this only for 4-5 core projects (its deps might be installed from official or custom repos). New workflow is inspired of evidence and simplicity (in workflow, not in how it works under-the-hood) by activity development workflow. What you need are: * in most cases (except fc14) you need additional run-time dependencies, attach Platform and Core repositories and install sugar `sweets download sugar/emulator` (to install all required deps and glucose for usage by default) from Bazaar * git clone glucose project to ~/sweets (or to ~/Activities) * check what will happen while building by looking to spec file - sweets.recipe[2] (i.e., an analog of activity.info) * run `sweets build` being within git cloned directory to build it * from any place in fs, call `sweets sweet-value-from-recipe` to launch it (build phase might be omitted, sweets will check if build already happened and start building otherwise) * you can change python code in cloned projects w/o need to run build command (the same .py files are used to run sugar, see implement option in Build section in recipe file), of course sugar itself should be restarted to take into account new .py code * the same for all glucose project (if component was not cloned, installed version will be used) Current limitations: * to use new scheme, glucose needs to be patched. It is not in master, so use bazaar branches[3] that any synced w/ trunk * dependency solving is inefficient and temporary, it will be replaced by invoking 0install in further implementation * build time dependencies need to be installed manually, auto-install will be supported later, by 0install (here 0install means not only fetching custom builds but, most likely, ask 0install what native packages should be installed by PackageKit) * fedora based systems: autoconf automake libtool make intltool pygtk2-devel gtk2-devel GConf2-devel gnome-common icon-slicer icon-naming-utils xorg-x11-apps libSM-devel alsa-lib-devel * debian based systems: build-essential intltool python-gtk2-dev libgtk2.0-dev libgconf2-dev icon-slicer icon-naming-utils x11-apps libsm-dev libasound2-dev libtool gnome-common [1] http://lists.sugarlabs.org/archive/sugar-devel/2010-October/028108.html [2] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Recipe_Specification#.5BBuid.5D [3] git://git.sugarlabs.org/sugar-base/bazaar.git git://git.sugarlabs.org/sugar/bazaar.git git://git.sugarlabs.org/sugar-toolkit/bazaar.git git://git.sugarlabs.org/sugar-presence-service/bazaar.git git://git.sugarlabs.org/sugar-artwork/bazaar.git -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Support isolated start
Running process is based on injection (how 0install works) of evironment
variables to final application process, e.g., via PYTHONPATH. Patch will let
bazaar.sugarlabs.org build sugar packages, also runnning from git cloned
directories will be supported (i.e., without jhbuild).
---
.gitignore |3 +-
bin/Makefile.am|2 +-
bin/sugar | 91
bin/sugar-session |1 -
bin/sugar.in | 82
configure.ac |1 -
src/jarabe/config.py.in| 17 ---
src/jarabe/model/bundleregistry.py |7 ++-
sweets.recipe | 49 +++
9 files changed, 156 insertions(+), 97 deletions(-)
create mode 100755 bin/sugar
mode change 100644 = 100755 bin/sugar-activity
mode change 100644 = 100755 bin/sugar-control-panel
mode change 100644 = 100755 bin/sugar-install-bundle
mode change 100644 = 100755 bin/sugar-launch
mode change 100644 = 100755 bin/sugar-ui-check
delete mode 100644 bin/sugar.in
create mode 100644 sweets.recipe
diff --git a/.gitignore b/.gitignore
index 047a849..0f7dc7f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,8 @@ Makefile.in
.*.sw?
*.service
stamp-*
+*.tar.*
+.sweets
# Absolute
@@ -51,7 +53,6 @@ m4/intltool.m4
sugar/browser/_sugarbrowser.c
browser/sugar-marshal.c
browser/sugar-marshal.h
-bin/sugar
shell/extensions/_extensions.c
data/sugar.gtkrc
data/sugar.xml
diff --git a/bin/Makefile.am b/bin/Makefile.am
index 05a9215..bf66dbd 100644
--- a/bin/Makefile.am
+++ b/bin/Makefile.am
@@ -11,4 +11,4 @@ bin_SCRIPTS = \
sugar \
$(python_scripts)
-EXTRA_DIST = $(python_scripts) sugar.in
+EXTRA_DIST = $(python_scripts)
diff --git a/bin/sugar b/bin/sugar
new file mode 100755
index 000..9d079ed
--- /dev/null
+++ b/bin/sugar
@@ -0,0 +1,91 @@
+#!/bin/sh
+
+if [ $(id -u) -eq 0 -o $(id -ru) -eq 0 ] ; then
+ echo Refusing to run as root.
+ exit 3
+fi
+
+usage() {
+cat EOF
+Usage: sugar [OPTION]..
+
+Start Sugar window manager.
+
+Optional arguments.
+ -d, --display DISPLAY Display to start sugar
+ -s, --scaling SCALING Scale Sugar theme
+Supported values: 72, 100
+EOF
+exit 0
+}
+
+while [ $# -ne 0 ] ; do
+case $1 in
+ -d | --display)
+shift
+export DISPLAY=$1
+;;
+ -s | --scaling)
+shift
+export SUGAR_SCALING=$1
+;;
+ -h | --help)
+usage
+;;
+esac
+shift
+done
+
+# Set default profile dir
+if test -z $SUGAR_PROFILE; then
+export SUGAR_PROFILE=default
+fi
+
+if test $SUGAR_SHELL_PREFIX; then
+include=include \\$(HOME)/.sugar/gconf.path\
+grep $include ~/.gconf.path /dev/null 21 || \
+echo $include ~/.gconf.path
+mkdir -p ~/.sugar
+echo xml:readonly:$SUGAR_SHELL_PREFIX/gconf.xml ~/.sugar/gconf.path
+gconftool-2 --shutdown
+fi
+
+if test -z $SUGAR_SCALING; then
+export SUGAR_SCALING=72
+fi
+
+export GTK2_RC_FILES=$(dirname $(dirname
$0))/share/sugar/data/sugar-$SUGAR_SCALING.gtkrc
+
+# Needed for executing wpa_passphrase
+export PATH=$PATH:/sbin:/usr/sbin
+
+if ! test -f $GTK2_RC_FILES; then
+echo sugar: ERROR: Gtk theme for scaling $SUGAR_SCALING not available in
path $GTK2_RC_FILES
+exit 1
+fi
+
+# Set default language
+export LANG=${LANG:-en_US.utf8}
+export LANGUAGE=${LANGUAGE:-${LANG}}
+
+# Set Sugar's telepathy accounts directory
+export MC_ACCOUNT_DIR=$HOME/.sugar/$SUGAR_PROFILE/accounts
+
+# Workaround until gnome-keyring-daemon lets dbus activate it
+# https://bugzilla.gnome.org/show_bug.cgi?id=628302
+if test $SUGAR_EMULATOR = yes -a $(type gnome-keyring-daemon); then
+gnome-keyring-daemon --components=secrets
+fi
+
+# Source language settings and debug definitions
+if [ -f ~/.i18n ]; then
+. ~/.i18n
+fi
+if [ -f ~/.sugar/debug ]; then
+. ~/.sugar/debug
+fi
+
+echo Xcursor.theme: sugar | xrdb -merge
+metacity --no-force-fullscreen -d $DISPLAY
+
+exec sugar-session
diff --git a/bin/sugar-activity b/bin/sugar-activity
old mode 100644
new mode 100755
diff --git a/bin/sugar-control-panel b/bin/sugar-control-panel
old mode 100644
new mode 100755
diff --git a/bin/sugar-install-bundle b/bin/sugar-install-bundle
old mode 100644
new mode 100755
diff --git a/bin/sugar-launch b/bin/sugar-launch
old mode 100644
new mode 100755
diff --git a/bin/sugar-session b/bin/sugar-session
index 91ebf6f..e2157ba 100755
--- a/bin/sugar-session
+++ b/bin/sugar-session
@@ -218,7 +218,6 @@ def main():
# strings in the module scope.
from jarabe import config
gettext.bindtextdomain('sugar', config.locale_path)
-gettext.bindtextdomain('sugar-toolkit', config.locale_path)
gettext.textdomain('sugar')
from jarabe.desktop import
[Sugar-devel] [PATCH] Support isolated start
Running process is based on injection (how 0install works) of evironment variables to final application process, e.g., via PYTHONPATH. Patch will let bazaar.sugarlabs.org build sugar packages, also runnning from git cloned directories will be supported (i.e., without jhbuild). --- .gitignore|2 ++ sweets.recipe | 29 + 2 files changed, 31 insertions(+), 0 deletions(-) create mode 100644 sweets.recipe diff --git a/.gitignore b/.gitignore index 9acb07c..4ad2f8c 100644 --- a/.gitignore +++ b/.gitignore @@ -38,3 +38,5 @@ test/exported_* .DS_Store gtk/theme/sugar-100.gtkrc gtk/theme/sugar-72.gtkrc +*.tar.* +.sweets diff --git a/sweets.recipe b/sweets.recipe new file mode 100644 index 000..5e39563 --- /dev/null +++ b/sweets.recipe @@ -0,0 +1,29 @@ +[DEFAULT] +sweet = sugar-artwork +summary = Themes and icons +license = LGPLv2.1+ +homepage = http://git.sugarlabs.org/projects/sugar-artwork + +version = 0.90.0 +stability = testing + +depends = gtk; pygobject; cairo = 0.1.1 + +[Component] +requires = %(depends)s +binding = GTK_PATH lib/gtk-2.0 +replace GTK_DATA_PREFIX +XDG_DATA_DIRS share +XCURSOR_PATH share/icons +arch = any + +[Build] +requires = %(depends)s; icon-slicer; icon-naming-utils; xcursorgen +pkg-config; make; gcc-c +cleanup = make distclean; ./autogen.sh +configure = ./configure --prefix=%(PREFIX)s CFLAGS=%(CFLAGS)s +make = make +install = make DESTDIR=%(DESTDIR)s install + +[Source] +exec = ./autogen.sh make dist -- 1.7.2.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Support isolated start
Running process is based on injection (how 0install works) of evironment
variables to final application process, e.g., via PYTHONPATH. Patch will let
bazaar.sugarlabs.org build sugar packages, also runnning from git cloned
directories will be supported (i.e., without jhbuild).
---
.gitignore |4
src/Makefile.am|3 +++
src/__init__.py| 20
src/sugar/Makefile.am |4 ++--
src/sugar/__init__.py | 13 -
src/sugar/dispatch/Makefile.am |2 +-
sweets.recipe | 33 +
7 files changed, 63 insertions(+), 16 deletions(-)
create mode 100644 src/__init__.py
create mode 100644 sweets.recipe
diff --git a/.gitignore b/.gitignore
index 25cb6e9..8285052 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,6 +5,10 @@
*.lo
*.la
stamp-*
+m4/*
+*.so
+*.tar.*
+.sweets
# Absolute
diff --git a/src/Makefile.am b/src/Makefile.am
index 4fa44db..c399f12 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1 +1,4 @@
SUBDIRS = sugar
+
+sugardir = $(pythondir)/sugar_base
+sugar_PYTHON = __init__.py
diff --git a/src/__init__.py b/src/__init__.py
new file mode 100644
index 000..3ff9423
--- /dev/null
+++ b/src/__init__.py
@@ -0,0 +1,20 @@
+# Copyright (C) 2010, Aleksey Lim
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+import gettext
+from os.path import join, dirname
+
+locale_path = join(dirname(__file__), '..', '..', 'share', 'locale')
+gettext.bindtextdomain('sugar-base', locale_path)
diff --git a/src/sugar/Makefile.am b/src/sugar/Makefile.am
index 871871e..3db2eda 100644
--- a/src/sugar/Makefile.am
+++ b/src/sugar/Makefile.am
@@ -2,13 +2,13 @@ SUBDIRS = dispatch
INCLUDES = -DXDG_PREFIX=sugar_mime
-sugardir = $(pythondir)/sugar
+sugardir = $(pythondir)/sugar_base/sugar
sugar_PYTHON = \
__init__.py \
logger.py \
mime.py
-pkgpyexecdir = $(pythondir)/sugar
+pkgpyexecdir = $(pythondir)/sugar_base/sugar
pkgpyexec_LTLIBRARIES = _sugarbaseext.la
diff --git a/src/sugar/__init__.py b/src/sugar/__init__.py
index d24d665..2683bc6 100644
--- a/src/sugar/__init__.py
+++ b/src/sugar/__init__.py
@@ -15,16 +15,3 @@
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
-
-import os
-import gettext
-
-
-if 'SUGAR_PREFIX' in os.environ:
-prefix = os.environ['SUGAR_PREFIX']
-else:
-prefix = '/usr'
-
-locale_path = os.path.join(prefix, 'share', 'locale')
-
-gettext.bindtextdomain('sugar-base', locale_path)
diff --git a/src/sugar/dispatch/Makefile.am b/src/sugar/dispatch/Makefile.am
index eb44a32..ad0f69d 100644
--- a/src/sugar/dispatch/Makefile.am
+++ b/src/sugar/dispatch/Makefile.am
@@ -1,4 +1,4 @@
-sugardir = $(pythondir)/sugar/dispatch
+sugardir = $(pythondir)/sugar_base/sugar/dispatch
sugar_PYTHON = \
__init__.py \
dispatcher.py \
diff --git a/sweets.recipe b/sweets.recipe
new file mode 100644
index 000..581c774
--- /dev/null
+++ b/sweets.recipe
@@ -0,0 +1,33 @@
+[DEFAULT]
+sweet = sugar-base
+summary = Helpers for the development of services and activities
+license = LGPLv2.1+
+homepage = http://git.sugarlabs.org/projects/sugar-base
+
+version = 0.90.1
+stability = testing
+
+depends = pygtk; pygobject = 2.15
+
+[Component]
+requires = %(depends)s; decorator
+binding = PYTHONPATH python
+arch = any
+
+[Build]
+requires = %(depends)s; pkg-config; intltool = 0.33; make; gcc-c
+cleanup = make distclean; ./autogen.sh
+configure = ./configure
+--prefix=%(PREFIX)s
+am_cv_python_pythondir=%(PREFIX)s/python
+am_cv_python_pyexecdir=%(PREFIX)s/python
+CFLAGS=%(CFLAGS)s
+make = make
+install = make DESTDIR=%(DESTDIR)s install
+implement = %(install)s
+rm -rf %(DESTDIR)s/%(PREFIX)s/python/sugar_base/sugar
+ln -s %(BUILDDIR)s/src/sugar
%(DESTDIR)s/%(PREFIX)s/python/sugar_base/
+ln -fs .libs/_sugarbaseext.so src/sugar/
+
+[Source]
+exec = ./autogen.sh make dist
--
1.7.2.2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Support isolated start
Running process is based on injection (how 0install works) of evironment
variables to final application process, e.g., via PYTHONPATH. Patch will let
bazaar.sugarlabs.org build sugar packages, also runnning from git cloned
directories will be supported (i.e., without jhbuild).
---
.gitignore |3 +++
configure.ac |1 +
src/sugar/Makefile.am|8 ++--
src/sugar/__init__.py| 20
src/sugar/_sugarbaseext.py | 16
src/sugar/activity/main.py |1 -
src/sugar/dispatch/Makefile.am |6 ++
src/sugar/dispatch/__init__.py | 16
src/sugar/dispatch/dispatcher.py | 16
src/sugar/dispatch/saferef.py| 16
src/sugar/logger.py | 16
src/sugar/mime.py| 16
sweets.recipe| 34 ++
13 files changed, 166 insertions(+), 3 deletions(-)
create mode 100644 src/sugar/__init__.py
create mode 100644 src/sugar/_sugarbaseext.py
create mode 100644 src/sugar/dispatch/Makefile.am
create mode 100644 src/sugar/dispatch/__init__.py
create mode 100644 src/sugar/dispatch/dispatcher.py
create mode 100644 src/sugar/dispatch/saferef.py
create mode 100644 src/sugar/logger.py
create mode 100644 src/sugar/mime.py
create mode 100644 sweets.recipe
diff --git a/.gitignore b/.gitignore
index fe4cc56..a28347a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,6 +4,7 @@
*~
.deps
.libs
+*.so
py-compile
Makefile
@@ -22,3 +23,5 @@ libtool
ltmain.sh
missing
compile
+*.tar.*
+.sweets
diff --git a/configure.ac b/configure.ac
index 41798ea..5b21a51 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,5 +44,6 @@ src/sugar/bundle/Makefile
src/sugar/graphics/Makefile
src/sugar/presence/Makefile
src/sugar/datastore/Makefile
+src/sugar/dispatch/Makefile
po/Makefile.in
])
diff --git a/src/sugar/Makefile.am b/src/sugar/Makefile.am
index 236e337..584edde 100644
--- a/src/sugar/Makefile.am
+++ b/src/sugar/Makefile.am
@@ -1,4 +1,4 @@
-SUBDIRS = activity bundle graphics presence datastore
+SUBDIRS = activity bundle graphics presence datastore dispatch
sugardir = $(pythondir)/sugar
sugar_PYTHON = \
@@ -7,7 +7,11 @@ sugar_PYTHON = \
profile.py \
session.py \
util.py \
- wm.py
+ wm.py \
+ _sugarbaseext.py \
+ logger.py \
+ mime.py \
+ __init__.py
pkgpyexecdir = $(pythondir)/sugar
diff --git a/src/sugar/__init__.py b/src/sugar/__init__.py
new file mode 100644
index 000..b4fdb9a
--- /dev/null
+++ b/src/sugar/__init__.py
@@ -0,0 +1,20 @@
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2 of the License, or (at your option) any later version.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the
+# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+
+import gettext
+from os.path import join, dirname
+
+locale_path = join(dirname(__file__), '..', '..', 'share', 'locale')
+gettext.bindtextdomain('sugar-toolkit', locale_path)
diff --git a/src/sugar/_sugarbaseext.py b/src/sugar/_sugarbaseext.py
new file mode 100644
index 000..6602314
--- /dev/null
+++ b/src/sugar/_sugarbaseext.py
@@ -0,0 +1,16 @@
+# Copyright (C) 2010, Aleksey Lim
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as published by
+# the Free Software Foundation, either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+from sugar_base.sugar._sugarbaseext import *
diff --git a/src/sugar/activity/main.py b/src/sugar/activity/main.py
index c04257a..5b0a87d 100644
--- a/src/sugar/activity/main.py
+++ b/src/sugar/activity/main.py
@@ -111,7 +111,6 @@ def main():
locale_path = i18n.get_locale_path(bundle.get_bundle_id())
gettext.bindtextdomain(bundle.get_bundle_id(), locale_path)
-gettext.bindtextdomain('sugar-toolkit', sugar.locale_path
[Sugar-devel] [PATCH] Support isolated start
Running process is based on injection (how 0install works) of evironment
variables to final application process, e.g., via PYTHONPATH. Patch will let
bazaar.sugarlabs.org build sugar packages, also runnning from git cloned
directories will be supported (i.e., without jhbuild).
---
.gitignore|2 ++
src/sugar-presence-service.in |4 +++-
sweets.recipe | 27 +++
3 files changed, 32 insertions(+), 1 deletions(-)
create mode 100644 sweets.recipe
diff --git a/.gitignore b/.gitignore
index 89e441e..7b18edf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,6 +11,8 @@ Makefile.in
*.loT
.*.sw?
*.service
+*.tar.*
+.sweets
# Absolute
diff --git a/src/sugar-presence-service.in b/src/sugar-presence-service.in
index ff8d66a..96c9757 100644
--- a/src/sugar-presence-service.in
+++ b/src/sugar-presence-service.in
@@ -16,8 +16,10 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import sys
+from os.path import join, dirname
-sys.path.append('@prefix@/share/sugar-presence-service')
+path = join(dirname(__file__), '..', 'share', 'sugar-presence-service')
+sys.path.append(path)
import main
diff --git a/sweets.recipe b/sweets.recipe
new file mode 100644
index 000..bde72a5
--- /dev/null
+++ b/sweets.recipe
@@ -0,0 +1,27 @@
+[DEFAULT]
+sweet = sugar-presence-service
+summary = Interfaces between Sugar and Telepathy Connection Managers
+license = LGPLv2.1+
+homepage = http://git.sugarlabs.org/projects/sugar-presence-service
+
+version = 0.90.1
+stability = testing
+
+[Component]
+requires = sugar-toolkit; telepathy-python
+telepathy-salut = 0.4; telepathy-gabble = 0.10
+binding = PATH bin; XDG_DATA_DIRS share
+arch = any
+
+[Build]
+requires = make
+cleanup = make distclean; ./autogen.sh
+configure = ./configure --prefix=%(PREFIX)s
+make = make
+install = make DESTDIR=%(DESTDIR)s install
+implement = %(install)s
+rm -rf %(DESTDIR)s/%(PREFIX)s/share/sugar-presence-service
+ln -s %(BUILDDIR)s/src
%(DESTDIR)s/%(PREFIX)s/share/sugar-presence-service
+
+[Source]
+exec = ./autogen.sh make dist
--
1.7.2.2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 04:28:18PM +0200, Bert Freudenberg wrote: On 21.10.2010, at 04:59, Aleksey Lim wrote: On Thu, Oct 21, 2010 at 11:26:49AM +, Aleksey Lim wrote: On Thu, Oct 21, 2010 at 04:31:49PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 4:13 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Oct 21, 2010 at 03:45:58PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 1:32 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? Account Services team is the preferred trade name for small size teams engaged in support work (answering questions, or communicating with the development team, maintaining builds and their timely releases). Some companies use Internal System Architect nomenclature too. When team sizes grew bigger, this work comes under the umbrella of Members of Technical Staff. Well, I personally prefer something less official/corporate, e.g., Bazaar Team :) Bazaar in Hindi refers to market. Suspect that many people would confuse it with the marketing team :-) Though Bazaar is referring more to The Cathedral and the Bazaar in FOSS world (afaik) rather to marketing (which sounds, in some meaning, quite opposite thing :). What about Sweet Team then, i.e., sweet is an id of packages on bazaar.sl.o and sweets is the main command-line tool. Of course it might be something neutral like Distribution Team. Working with distro packagers is really important. Getting Sugar to work on distros that do not have current Sugar packages is important, too. And running Sugar in emulation on Macs and Windows machines should also be part of the Let people start sugar in any environment mission. Possibly platform team would be more appropriate? +1 for all options I guess we don't have many options for naming and Platform Team sounds best of all. For example, there is Sugar Platform (and Platform project on Bazaar for the same purpose) that should be an area of responsibility for the new team. I'll start to copypaste Platform Team (keeping in mind original purpose I stated in initial email) related resources on wiki to Platform_Team/ sub region on wiki.sl.o. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Clipboard menu off screen fixed for long text strings(SL #2201)
On Fri, Oct 22, 2010 at 11:52:26PM +0530, Mukul Gupta wrote: Changing maximum text length to a suitable value so that it fits into the screen --- src/jarabe/frame/clipboardmenu.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/jarabe/frame/clipboardmenu.py b/src/jarabe/frame/clipboardmenu.py index b998110..1f5259e 100644 --- a/src/jarabe/frame/clipboardmenu.py +++ b/src/jarabe/frame/clipboardmenu.py @@ -38,7 +38,7 @@ from jarabe.model import bundleregistry class ClipboardMenu(Palette): def __init__(self, cb_object): -Palette.__init__(self, text_maxlen=100) +Palette.__init__(self, text_maxlen=80) I think better to calc number of chars according to the current screen width w/ something like this: layout = any_gtk_widget.create_pango_layout(...) print 'width =', layout.get_pixel_size()[0] -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v5 sugar] Downgrading activities not allowed. (#2164)
On Sat, Oct 23, 2010 at 01:11:18AM +0530, anub...@seeta.in wrote:
Downgrading an activity is now made possible. When a .xo file of a version
older
than the currently installed version is clicked, a downgrading option is made
available, by popping up of a confirmation alert. Depending upton the choice
selected you can downgrade the activity.
Co-authored-by: Anubhav Aggarwal anub...@seeta.in, Shanjit Singh Jajmann
shan...@seeta.in
---
v1 - v2. Named according to the nomenclature suggested,inline function used
,signal emission condition revised,global variables removed.
v2 - v3. Taking care of all calling of misc.resume.
v3 - v4. Changes in the copyright of the new file
v4 - v5. showing the alert in the same window as the journal
To be hones, I'm not happy with this way. It seems to be needless
tricky, i.e, keeping journal window in alert class and storing it
all time. What about more clean way, i.e., using journal window
only on purpose and keep it out of journal activity logic, so any
code in Journal that needs main window to to do something (e.g.,
popping up an alert) can call journalwindow.get_activity_window(),
use it and do not keep in static variable.
src/jarabe/journal/journalactivity.py |1 +
src/jarabe/journal/misc.py| 56 ++--
src/jarabe/model/bundleregistry.py|7 +++-
3 files changed, 51 insertions(+), 13 deletions(-)
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..8ab6a2e 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -106,6 +106,7 @@ class JournalActivity(Window):
def __init__(self):
logging.debug(STARTUP: Loading the journal)
Window.__init__(self)
+misc.get_journal_window(self)
self.set_title(_('Journal'))
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..b8d8d3a 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -27,8 +27,10 @@ from sugar.activity import activityfactory
from sugar.activity.activityhandle import ActivityHandle
from sugar.graphics.icon import get_icon_file_name
from sugar.graphics.xocolor import XoColor
+from sugar.graphics.alert import ConfirmationAlert
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar.bundle.contentbundle import ContentBundle
from sugar import util
@@ -148,8 +150,9 @@ def get_activities(metadata):
return activities
-def resume(metadata, bundle_id=None):
+def resume(metadata, bundle_id=None, force_to_downgrade=False):
I think better to have force_to_downgrade hidden because it is being
used only from resume() itlsef...
registry = bundleregistry.get_registry()
+version_downgrade = False
if is_activity_bundle(metadata) and bundle_id is None:
@@ -159,19 +162,26 @@ def resume(metadata, bundle_id=None):
bundle = ActivityBundle(file_path)
if not registry.is_installed(bundle):
logging.debug('Installing activity bundle')
-registry.install(bundle)
+if not force_to_downgrade:
+try:
+registry.install(bundle)
+except AlreadyInstalledException:
+older_version_clicked(metadata)
+version_downgrade = True
+if force_to_downgrade:
+registry.install(bundle, force_downgrade=True)
else:
logging.debug('Upgrading activity bundle')
registry.upgrade(bundle)
...it could be done, eg, by moving this part to separate function and
call it from here and from downgrade alert callback
-
-logging.debug('activityfactory.creating bundle with id %r',
-bundle.get_bundle_id())
-installed_bundle = registry.get_bundle(bundle.get_bundle_id())
-if installed_bundle:
-launch(installed_bundle)
-else:
-logging.error('Bundle %r is not installed.',
- bundle.get_bundle_id())
+if not version_downgrade:
+logging.debug('activityfactory.creating bundle with id %r',
+bundle.get_bundle_id())
+installed_bundle = registry.get_bundle(bundle.get_bundle_id())
+if installed_bundle:
+launch(installed_bundle)
+else:
+logging.error('Bundle %r is not installed.',
+ bundle.get_bundle_id())
elif is_content_bundle(metadata) and bundle_id is None:
@@ -239,6 +249,30 @@ def launch(bundle, activity_id=None, object_id=None,
uri=None, color=None,
object_id=object_id, uri=uri, invited=invited)
activityfactory.create(bundle, activity_handle)
Re: [Sugar-devel] Fwd: [Sur] [ASLO] Nueva version flash games-2
On Fri, Oct 22, 2010 at 06:33:48PM -0300, Gonzalo Odiard wrote: Who can review the activity flash games-2 in ASLO Activity is already downgraded in its status, and ASLO admins try to contact w/ uploader. Mails from teachers from Uruguay in the list olpc-sur: From: *Cristina Yiansens* crisyi...@gmail.com Date: 2010/10/22 To: olpc-...@lists.laptop.org Hola lista: con respecto a este enlace me gustaría saber la razón de incluir el juego ¿Qué le harías a tu ex? junto a Adjedrez y otros. Es el primer botón que tiene el niño para comenzar a jugar y la verdad es que no tiene nada de educativo. Sí tiene agresiones al límite. Realmente habría que revisar y colocarlo en juegos para adultos o al menos sacarlo de ese paquete Saludos, -- *Cristina Yiansens - Mtra. Dinamizadora de Plan CEIBAL* Google translation: Hi all: on the link I want to know the reason for including the game What would you do to your ex? with Adjedrez and others. Button is the first child has to start playing and the truth is that there is nothing educational. It does have damage to the limit. It really should be reviewed and put on games for adults or at least out of that package -- From: *Natalia Pizzolanti* marna...@hotmail.com Date: 2010/10/22 To: olpc-...@lists.laptop.org Estoy completamente de acuerdo contigo Cristina!!! Es terrible ver cómo los alumnos juegan a reventar a la mujer o matar al hombre hasta que chorrea SANGRE... - Google translation: I completely agree with you Cristina !!! It is terrible to see how students play to blow the woman or man to kill BLOOD dripping ... Gonzalo ___ 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
Re: [Sugar-devel] Read SD Comics
On Fri, Oct 22, 2010 at 05:04:15PM -0500, James Simmons wrote: On the 19th I posted my new Activity Read SD Comics on ASLO and it's still in the sandbox. Somehow 16 people managed to download it. I believe I had provided everything needed, and usually it doesn't take this long to get something out of the sandbox. Is something needed from me? It wasn't nominated. I've done it and made it public. Thanks, James Simmons ___ 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
Re: [Sugar-devel] Re-initiate Packaging Team
On Fri, Oct 22, 2010 at 04:24:14PM +, Aleksey Lim wrote: On Thu, Oct 21, 2010 at 04:28:18PM +0200, Bert Freudenberg wrote: On 21.10.2010, at 04:59, Aleksey Lim wrote: On Thu, Oct 21, 2010 at 11:26:49AM +, Aleksey Lim wrote: On Thu, Oct 21, 2010 at 04:31:49PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 4:13 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Oct 21, 2010 at 03:45:58PM +0530, Manusheel Gupta wrote: On Thu, Oct 21, 2010 at 1:32 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? Account Services team is the preferred trade name for small size teams engaged in support work (answering questions, or communicating with the development team, maintaining builds and their timely releases). Some companies use Internal System Architect nomenclature too. When team sizes grew bigger, this work comes under the umbrella of Members of Technical Staff. Well, I personally prefer something less official/corporate, e.g., Bazaar Team :) Bazaar in Hindi refers to market. Suspect that many people would confuse it with the marketing team :-) Though Bazaar is referring more to The Cathedral and the Bazaar in FOSS world (afaik) rather to marketing (which sounds, in some meaning, quite opposite thing :). What about Sweet Team then, i.e., sweet is an id of packages on bazaar.sl.o and sweets is the main command-line tool. Of course it might be something neutral like Distribution Team. Working with distro packagers is really important. Getting Sugar to work on distros that do not have current Sugar packages is important, too. And running Sugar in emulation on Macs and Windows machines should also be part of the Let people start sugar in any environment mission. Possibly platform team would be more appropriate? +1 for all options I guess we don't have many options for naming and Platform Team sounds best of all. For example, there is Sugar Platform (and Platform project on Bazaar for the same purpose) that should be an area of responsibility for the new team. I'll start to copypaste Platform Team (keeping in mind original purpose I stated in initial email) related resources on wiki to Platform_Team/ sub region on wiki.sl.o. Hmm.. Platform inclines (what I like) to thinking exactly about Sugar Platform i.e., native platform, running sugar in non-GNU/Linux environments (if I got it right) is all about working in VM, thus using the same Sugar Platform on GNU/Linux. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar 00/21] style cleanup series
On Sat, Oct 23, 2010 at 01:21:06PM +0200, Sascha Silbe wrote: Excerpts from Aleksey Lim's message of Thu Oct 21 00:58:33 +0200 2010: Whats the satatus of pylint patches? I'm waiting for an OK from Simon and you. James was already kind enough to review both pending patch series. I've already applied your patches to ds, and ok w/ the rest. I'm planing to propose another set of patches that are scatered among glucose modules and it would be useful to base them on pylint commits. What are you planning (just so I know where to expect conflicts)? http://lists.sugarlabs.org/archive/sugar-devel/2010-October/028196.html They are based on old code, will tweak them after applying these ones. btw maybe push pylint patches by one commit? Technically possible (and easy enough), but I'm not sure it's a good idea. With split patches it's easy to see what each individual commit changed and repeat the change even in a diverged code base. OTOH git combines all the commits before merging anyway... np, I'm just used to push such patches by one commit. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Re-initiate Packaging Team
On Thu, Oct 21, 2010 at 08:02:40AM +, Aleksey Lim wrote: Hi all, This a request to relaunch Packaging Team by giving it a bit another meaning that it has before. The main idea I see for this new/old team is: Let people start sugar in any environment they have in most convenient way. I've initiated http://wiki.sugarlabs.org/go/Platform_Team with this statement (which is different by meaning w/ previous one): The mission of Platform Team is providing, as unified as possible, runtime and development time environments for all sugar doers. In contrast with Development and Activity teams, Platform Team mission is not about development process itself but about supporting developers by providing the same set of possible dependencies and giving a common distribution method. Platform Team will work closely with GNU/Linux distributions that provide sugar and will try to round all differences between them to make sugar doers' life easier. The team will cover not only questions how sugar is packaged for major GNU/Linux distribution but also: * having Bazaar as a central place of all (out of distro) efforts * building packages that are not(yet/well) packaged * support distros that don't have packaged sugar * run daily snapshot of sugar in as many as possible environments * take care of Sugar Platform dependencies (how many, are they packaged and make custom build otherwise) * support meta sugar distribution ie just a bunch of repositories of sugar packages that can be attached to existed system to run sugar BTW, maybe Packaging is not appropriate name, any ideas? -- Aleksey ___ 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
Re: [Sugar-devel] [PATCH v6 sugar] Downgrading activities not allowed. (SL #2164)
On Sun, Oct 24, 2010 at 12:21:13AM +0530, anub...@seeta.in wrote:
Activity can be downgraded on the availability of an older .xo version of an
activity. An alert pops up on downloading an older .xo file of an activity,
which asks the user to make a selection on whether to move to an older
activity version or not.
Co-authored-by: Anubhav Aggarwal anub...@seeta.in, Shanjit Singh Jajmann
shan...@seeta.in
---
v1 - v2. Inline function used, signal emission condition revised and global
variables removed. Recommendations by James Cameron and Aleksey Lim added.
v2 - v3. Used misc.resume.
v3 - v4. Changes in the copyright of the new file.
v4 - v5. Alert shown in the same window as the journal.
v5 - v6. Static variable removed, name of the functions changed.
Recommendations by James Cameron and Aleksey Lim added.
src/jarabe/journal/journalactivity.py |6 ++--
src/jarabe/journal/journalwindow.py | 33 +++
src/jarabe/journal/misc.py| 56
+++--
src/jarabe/model/bundleregistry.py|7 +++-
4 files changed, 87 insertions(+), 15 deletions(-)
create mode 100644 src/jarabe/journal/journalwindow.py
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..a48063b 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -44,6 +44,7 @@ from jarabe.journal.journalentrybundle import
JournalEntryBundle
from jarabe.journal.objectchooser import ObjectChooser
from jarabe.journal.modalalert import ModalAlert
from jarabe.journal import model
+from jarabe.journal.journalwindow import JournalWindow
J_DBUS_SERVICE = 'org.laptop.Journal'
J_DBUS_INTERFACE = 'org.laptop.Journal'
@@ -102,11 +103,10 @@ class JournalActivityDBusService(dbus.service.Object):
def ObjectChooserCancelled(self, chooser_id):
pass
-class JournalActivity(Window):
+class JournalActivity(JournalWindow):
def __init__(self):
logging.debug(STARTUP: Loading the journal)
-Window.__init__(self)
-
+JournalWindow.__init__(self)
self.set_title(_('Journal'))
self._main_view = None
diff --git a/src/jarabe/journal/journalwindow.py
b/src/jarabe/journal/journalwindow.py
new file mode 100644
index 000..957f1eb
--- /dev/null
+++ b/src/jarabe/journal/journalwindow.py
@@ -0,0 +1,33 @@
+#Copyright (C) 2010 Software for Education, Entertainment and Training
Activities
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+import gtk
+from sugar.graphics.window import Window
+
+
+_journal_window = None
+
+
+class JournalWindow(Window):
+
+def __init__(self):
+global _journal_window
+Window.__init__(self)
+_journal_window = self
+
+
+def get_journal_window():
+return _journal_window
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..388837c 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -27,8 +27,10 @@ from sugar.activity import activityfactory
from sugar.activity.activityhandle import ActivityHandle
from sugar.graphics.icon import get_icon_file_name
from sugar.graphics.xocolor import XoColor
+from sugar.graphics.alert import ConfirmationAlert
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar.bundle.contentbundle import ContentBundle
from sugar import util
@@ -36,6 +38,7 @@ from jarabe.view import launcher
from jarabe.model import bundleregistry, shell
from jarabe.journal.journalentrybundle import JournalEntryBundle
from jarabe.journal import model
+from jarabe.journal import journalwindow
def _get_icon_for_mime(mime_type):
generic_types = mime.get_all_generic_types()
@@ -150,6 +153,7 @@ def get_activities(metadata):
def resume(metadata, bundle_id=None):
registry = bundleregistry.get_registry()
+version_downgrade = False
if is_activity_bundle(metadata) and bundle_id is None:
@@ -159,19 +163,24 @@ def resume(metadata, bundle_id=None):
bundle = ActivityBundle(file_path)
if not registry.is_installed(bundle
Re: [Sugar-devel] [PATCH v6 sugar] Downgrading activities not allowed. (SL #2164)
On Sun, Oct 24, 2010 at 04:23:22PM +, Aleksey Lim wrote:
On Sun, Oct 24, 2010 at 12:21:13AM +0530, anub...@seeta.in wrote:
+alert.props.title = _('Older Version Of ' + bundle.get_name() \
+ + ' Activity')
+alert.props.msg = _('Do you want to downgrade to version ' + \
+ str(bundle.get_activity_version()) + ' ?')
this usage of _() will break translation, text in _() should be a static
string, better to use something like:
alert.props.title = _('Older Version Of %(bundle_name)s Activity') %
bundle.get_name()
oops, sorry
alert.props.title = _('Older Version Of %(bundle_name)s Activity') %
{'bundle_name': bundle.get_name()}
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] stepping down as maintainer
On Tue, Oct 19, 2010 at 06:50:23PM +0200, Tomeu Vizoso wrote: Hi, for personal reasons have to drastically reduce my involvement in the project. Will be leaving maintenance of my modules and unsubscribing from the mailing lists. My place on the board is vacant from now on and I'll be adding to the wiki the new vacancies: http://wiki.sugarlabs.org/go/Vacancies Cheers and good luck, Tomeu I'm just remembering What keeps me going on?... Anyway I guess people, who join Sugar, do it not only because of FOSS is so attractive (there are a bunch of more useful options to join) but because of ideas behind Sugar and community around this ideas. If people leave Sugar they think they can realize the same ideas by different ways (or they just need to take a rest). Though problems are obvious, but it is another topic... -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development Meetings
On Mon, Oct 25, 2010 at 12:09:22PM +, Aleksey Lim wrote: Hi all, Since we don't have team lead (for a long time) there a bunch of questions that need to be fixed. (imho, we might not even need team lead for Development Team, all questions might be solved in process while, weekly/daily on-purpose meetings. Lead is required eg for community relationships or an architect) So, I'm proposing to have weekly on-purpose meetings. if there is an upcomming agenda[1] All people who have questions for Development Team, that might be useful to discuss having a concilium of interested in developers, are welcome. All people who take part in core coding are welcome as well. I've added topics that are important for me[1], add that is important for you. [1] http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Agenda -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development Meetings
On Mon, Oct 25, 2010 at 08:13:24AM -0400, Walter Bender wrote: On Mon, Oct 25, 2010 at 8:09 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Since we don't have team lead (for a long time) there a bunch of questions that need to be fixed. (imho, we might not even need team lead for Development Team, all questions might be solved in process while, weekly/daily on-purpose meetings. Lead is required eg for community relationships or an architect) So, I'm proposing to have weekly on-purpose meetings. All people who have questions for Development Team, that might be useful to discuss having a concilium of interested in developers, are welcome. All people who take part in core coding are welcome as well. I've added topics that are important for me[1], add that is important for you. http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Agenda -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel +1 When is the next meeting? Wednesday? [1] says on Mondays, but I guess we can make an exclusion. Wednesday sounds reasonable for me, I guess it is enough to let people a time to be prepared to announced (current and possibly new) topics. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v7] Downgrading activities not allowed. (SL #2164)
On Mon, Oct 25, 2010 at 02:39:31AM +0530, shan...@seeta.in wrote:
From: Shanjit Singh Jajmann shan...@seeta.in
Activity can be downgraded on the availability of an older .xo version of an
activity. An alert pops up when trying to install an older .xo file of an
activity, which asks the user to make a selection on whether to move to an
older activity version or not.
Co-authored-by: Shanjit Singh Jajmann shan...@seeta.in
Anubhav Aggarwal anub...@seeta.in
---
v1 - v2. Inline function used, signal emission condition revised and global
variables removed. Recommendations by James Cameron and Aleksey Lim added.
v2 - v3. Used misc.resume.
v3 - v4. Changes in the copyright of the new file.
v4 - v5. Alert shown in the same window as the journal.
v5 - v6. Static variable removed, name of the functions changed.
Recommendations by James Cameron and Aleksey Lim added.
v6 - v7. Logic for the alert pop up made simpler.
Recommendations by Aleksay Lim added.
---
src/jarabe/journal/journalactivity.py |5 ++-
src/jarabe/journal/misc.py| 47 ++--
src/jarabe/model/bundleregistry.py|7 +++-
looks like you forgot to add journalwindow.py
(patch posted by anubhav looks different to this one)
3 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..beb0962 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -44,6 +44,7 @@ from jarabe.journal.journalentrybundle import
JournalEntryBundle
from jarabe.journal.objectchooser import ObjectChooser
from jarabe.journal.modalalert import ModalAlert
from jarabe.journal import model
+from jarabe.journal.journalwindow import JournalWindow
J_DBUS_SERVICE = 'org.laptop.Journal'
J_DBUS_INTERFACE = 'org.laptop.Journal'
@@ -102,10 +103,10 @@ class JournalActivityDBusService(dbus.service.Object):
def ObjectChooserCancelled(self, chooser_id):
pass
-class JournalActivity(Window):
+class JournalActivity(JournalWindow):
def __init__(self):
logging.debug(STARTUP: Loading the journal)
-Window.__init__(self)
+JournalWindow.__init__(self)
self.set_title(_('Journal'))
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..1d73fa8 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -27,8 +27,10 @@ from sugar.activity import activityfactory
from sugar.activity.activityhandle import ActivityHandle
from sugar.graphics.icon import get_icon_file_name
from sugar.graphics.xocolor import XoColor
+from sugar.graphics.alert import ConfirmationAlert
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar.bundle.contentbundle import ContentBundle
from sugar import util
@@ -36,6 +38,7 @@ from jarabe.view import launcher
from jarabe.model import bundleregistry, shell
from jarabe.journal.journalentrybundle import JournalEntryBundle
from jarabe.journal import model
+from jarabe.journal import journalwindow
def _get_icon_for_mime(mime_type):
generic_types = mime.get_all_generic_types()
@@ -159,19 +162,16 @@ def resume(metadata, bundle_id=None):
bundle = ActivityBundle(file_path)
if not registry.is_installed(bundle):
logging.debug('Installing activity bundle')
-registry.install(bundle)
+try:
+registry.install(bundle)
+except AlreadyInstalledException:
+_downgrade_option_alert(bundle)
+return
else:
logging.debug('Upgrading activity bundle')
registry.upgrade(bundle)
-logging.debug('activityfactory.creating bundle with id %r',
-bundle.get_bundle_id())
-installed_bundle = registry.get_bundle(bundle.get_bundle_id())
-if installed_bundle:
-launch(installed_bundle)
-else:
-logging.error('Bundle %r is not installed.',
- bundle.get_bundle_id())
+_install_bundle(bundle)
elif is_content_bundle(metadata) and bundle_id is None:
@@ -215,6 +215,17 @@ def resume(metadata, bundle_id=None):
launch(bundle, activity_id=activity_id, object_id=object_id,
color=get_icon_color(metadata))
+def _install_bundle(bundle):
+registry = bundleregistry.get_registry()
+logging.debug('activityfactory.creating bundle with id %r',
+ bundle.get_bundle_id())
+installed_bundle = registry.get_bundle(bundle.get_bundle_id())
+if installed_bundle:
+ launch(installed_bundle)
+else:
+logging.error('Bundle %r is not installed
Re: [Sugar-devel] Development Meetings
On Mon, Oct 25, 2010 at 01:29:07PM +, Walter Bender wrote: On Mon, Oct 25, 2010 at 12:59 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Oct 25, 2010 at 08:13:24AM -0400, Walter Bender wrote: On Mon, Oct 25, 2010 at 8:09 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Since we don't have team lead (for a long time) there a bunch of questions that need to be fixed. (imho, we might not even need team lead for Development Team, all questions might be solved in process while, weekly/daily on-purpose meetings. Lead is required eg for community relationships or an architect) So, I'm proposing to have weekly on-purpose meetings. All people who have questions for Development Team, that might be useful to discuss having a concilium of interested in developers, are welcome. All people who take part in core coding are welcome as well. I've added topics that are important for me[1], add that is important for you. http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Agenda -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel +1 When is the next meeting? Wednesday? [1] says on Mondays, but I guess we can make an exclusion. Wednesday sounds reasonable for me, I guess it is enough to let people a time to be prepared to announced (current and possibly new) topics. I guess I didn't see a date for the upcoming meeting on [1]... I was just guessing Wednesday. What time? #sugar-meeting, I presume. For me, default time is ok Wednesday 2010-10-27, 14:00 UTC irc://irc.freenode.net#sugar-meeting How about other possible attenders? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development Meetings
On Tue, Oct 26, 2010 at 08:39:48AM +1300, Tim McNamara wrote: On 26 October 2010 02:45, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Oct 25, 2010 at 01:29:07PM +, Walter Bender wrote: On Mon, Oct 25, 2010 at 12:59 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Oct 25, 2010 at 08:13:24AM -0400, Walter Bender wrote: On Mon, Oct 25, 2010 at 8:09 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Since we don't have team lead (for a long time) there a bunch of questions that need to be fixed. (imho, we might not even need team lead for Development Team, all questions might be solved in process while, weekly/daily on-purpose meetings. Lead is required eg for community relationships or an architect) For me, default time is ok Wednesday 2010-10-27, 14:00 UTC irc://irc.freenode.net#sugar-meeting 14:00 UTC is 2am for me.. Is it ok for you? 14:00 UTC because it is default time for Development Team meetings assuming that it was convenient for majority of developers in the past. If I have anything to contribute on the agenda items, should I send an email to sugar-devel or the meeting chair? Just add-new/extend-existed topics on http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Agenda (sign it with substring in entered text) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v8] Downgrading activities not allowed. (SL #2164)
On Mon, Oct 25, 2010 at 07:31:27PM +0530, shan...@seeta.in wrote:
From: Shanjit Singh Jajmann shan...@seeta.in, Anubhav Aggarwal
anub...@seeta.in
Activity can be downgraded on the availability of an older .xo version of an
activity. An alert pops up when trying to install an older .xo file of an
activity, which asks the user to make a selection on whether to move to an
older activity version or not.
Co-authored-by: Shanjit Singh Jajmann shan...@seeta.in
Co-authored-by: Anubhav Aggarwal anub...@seeta.in
Thanks, pushed
(with minor renaming tweak,
http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/5490d41ec310543b1819165f5209020e15411863)
---
v1 - v2. Inline function used, signal emission condition revised and global
variables removed. Recommendations by James Cameron and Aleksey Lim added.
v2 - v3. Used misc.resume.
v3 - v4. Changes in the copyright of the new file.
v4 - v5. Alert shown in the same window as the journal.
v5 - v6. Static variable removed, name of the functions changed.
Recommendations by James Cameron and Aleksey Lim added.
v6 - v7. Logic for the alert pop up made simpler.
Recommendations by Aleksay Lim added.
v7 - v8. Missing file added.
---
src/jarabe/journal/journalactivity.py |5 ++-
src/jarabe/journal/journalwindow.py | 34 +++
src/jarabe/journal/misc.py| 47 ++--
src/jarabe/model/bundleregistry.py|7 +++-
4 files changed, 80 insertions(+), 13 deletions(-)
create mode 100644 src/jarabe/journal/journalwindow.py
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..beb0962 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -44,6 +44,7 @@ from jarabe.journal.journalentrybundle import
JournalEntryBundle
from jarabe.journal.objectchooser import ObjectChooser
from jarabe.journal.modalalert import ModalAlert
from jarabe.journal import model
+from jarabe.journal.journalwindow import JournalWindow
J_DBUS_SERVICE = 'org.laptop.Journal'
J_DBUS_INTERFACE = 'org.laptop.Journal'
@@ -102,10 +103,10 @@ class JournalActivityDBusService(dbus.service.Object):
def ObjectChooserCancelled(self, chooser_id):
pass
-class JournalActivity(Window):
+class JournalActivity(JournalWindow):
def __init__(self):
logging.debug(STARTUP: Loading the journal)
-Window.__init__(self)
+JournalWindow.__init__(self)
self.set_title(_('Journal'))
diff --git a/src/jarabe/journal/journalwindow.py
b/src/jarabe/journal/journalwindow.py
new file mode 100644
index 000..3c718c2
--- /dev/null
+++ b/src/jarabe/journal/journalwindow.py
@@ -0,0 +1,34 @@
+#Copyright (C) 2010 Software for Education, Entertainment and Training
+#Activities
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+import gtk
+from sugar.graphics.window import Window
+
+_journal_window = None
+
+
+class JournalWindow(Window):
+
+def __init__(self):
+
+global _journal_window
+Window.__init__(self)
+_journal_window = self
+
+
+def get_journal_window():
+return _journal_window
diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journal/misc.py
index 32a2847..122feca 100644
--- a/src/jarabe/journal/misc.py
+++ b/src/jarabe/journal/misc.py
@@ -27,8 +27,10 @@ from sugar.activity import activityfactory
from sugar.activity.activityhandle import ActivityHandle
from sugar.graphics.icon import get_icon_file_name
from sugar.graphics.xocolor import XoColor
+from sugar.graphics.alert import ConfirmationAlert
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
+from sugar.bundle.bundle import AlreadyInstalledException
from sugar.bundle.contentbundle import ContentBundle
from sugar import util
@@ -36,6 +38,7 @@ from jarabe.view import launcher
from jarabe.model import bundleregistry, shell
from jarabe.journal.journalentrybundle import JournalEntryBundle
from jarabe.journal import model
+from jarabe.journal import journalwindow
def _get_icon_for_mime(mime_type):
generic_types = mime.get_all_generic_types()
@@ -159,19 +162,16 @@ def resume(metadata
Re: [Sugar-devel] Development Meetings
On Tue, Oct 26, 2010 at 07:56:17AM -0700, Tabitha Roder wrote: People UTC - Aleksey Lim alsr...@member.fsf.org any James Cameron qu...@laptop.org-11 Martin Dengler mar...@martindengler.com00 Martin Jose Abente Lahaye martin.abente.lah...@gmail.com -04 Sascha Silbe sascha-ml-reply-to-201...@silbe.org +1 Simon Schampijer si...@schampijer.de +1 Steven Parrish smparr...@gmail.com ? Tim McNamara paperl...@timmcnamara.co.nz -12 Walter Bender walter.ben...@gmail.com -5 -4 What about having [only] upcoming meeting on nearest weekends, something like Saturday, 22:00 UTC? Saturday your time is Sunday for NZ and Australia - if there is anything coming out of these meetings that tells us what to test for you then you might want to consider that we test every Saturday at 11am our time. Also Saturday night your time means no one in your time zone gets to go out for dinner on Saturday night ever again. The Monday to Wednesday idea previously suggested was good. Sorry if it was not clear from my previous posts (it was not clear for me as well:). My idea is about gathering as many as possible developers who are interested in how Development Team should move forward and make a clear statements about organizational procedures within Development Team and core development process (to leverage current, not so funny, situation). During this meeting we can decide what time will be convenient for regular meetings. I hope interested in people will manage to bear one meeting on Saturday, 2010-10-30, 22:00 UTC :). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development Meetings
Hi all, While answering to Michael's questions (though questions are still not fully answered but restructured, since the right question is 51% of an answer), I've composed a document which is a result of my, 2y, being a FOSS contributor and sugar participant: http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture And following David's suggestions, and being sure in premisses (and some of implementation details), I'm going to take part in SLOBs elections to implement these ideas. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GIT.sugarlabs.org changes?
On Sat, Oct 30, 2010 at 07:58:00PM -0400, George Hunt wrote: Hi Aleksey, Thanks for the response. The ssh step fails. Trying ssh -vvv gitori...@git.sugarlabs.org indicates that the negotiation proceeds in what looks to be a normal manner, until the point where the client determines that public key method is authorized, and client is offering my public key, and the next response is connection closed. snip debug1: Next authentication method: publickey debug1: Offering public key: debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Connection closed by 140.211.167.221 /snip Connection closed seems suspiciously. We had problem w/ blacklisting of some IPs. Can you try to ssh connect from different IP? (I'm CCing it to systems@) I guessed that the server has forgotten my public key, so I uploaded it again. I don't know if it is related, but the listserve forgot that I was receiving the digest form of the list on Oct 16 or so. After the upload still no luck -- though there may be some form of authorization required and/or delay built in, since when I first uploaded my public key last year, it didn't work for at least a day. George On Sat, Oct 30, 2010 at 5:53 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Oct 30, 2010 at 05:34:34PM -0400, George Hunt wrote: I have 2 projects that I have been pushing git commits to for almost a year. In one I created a new branch, and was concerned that my local change was preventing the successful git push. But the other project has no structural changes, and still gets the response fatal: the remote end hung up unexpectedly -- which I see has been a source of lots of headaches for the inner circle. Should I just wait for 6 hours, and try again? How to proceed? Check if: * `ssh gitori...@git.sugarlabs.org` outputs PTY allocation request.. * `git config remote.origin.url` output is equal to particular push link on your project web page on git.sl.o -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Appearance Customization
On Tue, Nov 02, 2010 at 04:17:12PM +0800, C. Scott Ananian wrote: I don't think you need to do any studies about whether kids want to customize their computers. This has been a constant message from deployments since day 1. The first thing kids did with the very first XOs fielded was slap stickers all over them to customize them. Unfortunately, kids have no sense of taste or decorum, and so their desire to have a hello kitty home screen (or whatever) is historically countered by NN's desire to be like Apple, all clean and elegant. This was supported by the UX design team, which wants a design which wins awards, not one that is plastered with kids favorite soccer players or whatever. Walter has tried to bridge this divide in the past by presenting it as a teaching opportunity: make one of the first XO lesson how to customize the code to change the XO man in the home screen or change the colors. This gives them incentive to learn how to hack the code. It's a very interesting compromise, and maybe it's even the right thing. Anyway, I think we should let the kids customize their machines easily -- certainly to change the colors. But this discussion is an old one. I wonder how it will turn out this time, maybe we've finally moved past some of the old bugbears. This is exactly the core[one of not many, at least] problem of current situation around sugar core development. After forming SL, nothing principally was changed, the same vertical organizational system was just moved (dunno how it was in OLPC, created otherwise) to another conditions. People in the field need futures, developers are willing to implement them.. nothing happens. In my mind core issue is that no one are willing to take responsibility because people who might take this responsibility are the same developers and that there is always a chance to get Are you have the full picture of needs to make such invasive decision?. In my mind, solution might be: * open minded Core Team[1], to create trends in sugar * open minded development in Universe[2] projects, who might/might-not follow Core Team trends; some development might fork particular Universe projects (only projects, starting sugar-window-manager, not sugar because there is not way to fork a community) * until that, nobody asked themselves, Am I doing right, implementing/designing/thinking-about this, so invasive, feature? implementing/designing/thinking-about is the real core (in comparing with [former] Development Team), preventing that means shooting in the foot^W head. * move all responsibilities about how product[3] (not sugar as a set of Universe projects) looks to Platform Team [4]. It will accumulate all efforts about facing deployment needs and particular implementations that are part of the product[3]. [1] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Core_Team [2] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Sugar_universe [3] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Sugar_distribution [4] http://wiki.sugarlabs.org/go/User:Alsroot/Sugar_Architecture#Platform_Team -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Appearance Customization
On Tue, Nov 02, 2010 at 04:33:35PM +, Martin Dengler wrote: On Tue, Nov 02, 2010 at 12:40:13PM +, Aleksey Lim wrote: On Tue, Nov 02, 2010 at 04:17:12PM +0800, C. Scott Ananian wrote: I wonder how it will turn out this time, maybe we've finally moved past some of the old bugbears. This is exactly the core[one of not many, at least] problem of current situation around sugar core development. After forming SL, nothing principally was changed, the same vertical organizational system was just moved (dunno how it was in OLPC, created otherwise) to another conditions. I'm not sure I understand the problem you see: is it that when you say vertical organization you are saying that SL can't change because the people with access to the code won't commit the necessary changes? Or that they don't (for whatever reason) make the changes people want? Or something else...? Maybe self-invented vertical structure is not right term, I just mean that OLPC (in my mind) creates a product, Sugar (which is right because otherwise OLPC will fail from beginning w/ having sugar w/o any schedules and releases). And moving that paradigm as-is to SL, is wrong idea (see below). In my mind core issue is that no one are willing to take responsibility because people who might take this responsibility are the same developers and that there is always a chance to get Are you have the full picture of needs to make such invasive decision?. Can you clarify this problem? I don't think I understand what you see as the problem (I'm not saying they're aren't any). Are you saying that there are too few developers and none (of those developers) want to propose changes because they get shot down by non-developers? My idea is that mixing [core] developers (that is Development Team), sugar nature of (as I understand it) teaching in [development] process and releasing a product (sucrose) within the same organizational unit as Development Team is wrong thing because it prevents any experiments. Any experimenter(more precisely, reviewer) needs to take responsibility of all levels, committing to particular project and take care about consequence from deployments-users-in-the field. It is not about that developers should not care about users but about personal responsibility when we talking about community that statements [self]teaching in process. In my mind it is exactly how development/releasing related job happened within Development Team. What is wrong w/ that model, I hope to explain more in what I think is right: * clear separation of purposes on Teams level (but not of particular person level, i.e., the same person might contribute to several Teams) 1) Core Team of thinkers, Sugar trends 2) Standard Team (or so), declaring rules, API, DBus interface 3) Platform Team, providing infrastructure to let doers work all this is not about coding itself but about coordination/supporting it. ie it is not about development itself but just do everything to support doers * doers, the variety of Sugar projects (from sugar-base to flash activities) that collaborate using Standard Team's rules. there is obvious separation between core projects and activities but I don't see why we don't need to have several, e.g., Journal implementations (if we have well declared/designed dbus API). doers are not restricted by any schedules, except that they think is important for them. Also except projects that are tracked by Platform Team but this is a talking between the same level structures. ie this a zone of experiments (in wide sense) * Platform Team creates the product, including some of projects from above category. This is the place where experiments are [have to] boiled to something sustainable that might be used for sugar deployments. ie it is not about development itself but about distribution -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New gitorious test request
Hi all, It is a call to help with testing new gitorious. Please take a look to http://jita.sugarlabs.org/. It contains a *copy* or git.sugarlabs.org. This is also a call to test integration of gitorious with a Central Login system[1] that might be used for password based accounts on all SL sites. For now, it looks to wiki-devel.sugarlabs.org account database. To login to git.sl.o, you need to use your git login name and wiki password for the same login (if there is no wiki account, follow Create an account link to create one). [1] http://en.wikipedia.org/wiki/Central_Authentication_Service -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GIT.sugarlabs.org changes?
On Wed, Nov 03, 2010 at 06:22:14AM -0400, George Hunt wrote: I tried the push from another ip address. Same result, so it's probably not the blacklist problem. The literature suggests that I should check for world or group writeability on the path from root to .ssh/known_hosts on the server, and on the client machine. I have double checked my client. Don't have shell access to server. Could you try to push to the new [testing] gitorious http://jita.sugarlabs.org/ To login to jita.sl.o, you need to use your git login name and wiki password for the same login (if there is no wiki account, follow Create an account link to create one) or, if you used OpenID, just login via OpenID link on jita. And what is your login on git.sl.o and project you are trying to push? George On Sun, Oct 31, 2010 at 10:30 AM, Aleksey Lim alsr...@member.fsf.orgwrote: On Sat, Oct 30, 2010 at 07:58:00PM -0400, George Hunt wrote: Hi Aleksey, Thanks for the response. The ssh step fails. Trying ssh -vvv gitori...@git.sugarlabs.orgindicates that the negotiation proceeds in what looks to be a normal manner, until the point where the client determines that public key method is authorized, and client is offering my public key, and the next response is connection closed. snip debug1: Next authentication method: publickey debug1: Offering public key: debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Connection closed by 140.211.167.221 /snip Connection closed seems suspiciously. We had problem w/ blacklisting of some IPs. Can you try to ssh connect from different IP? (I'm CCing it to systems@) I guessed that the server has forgotten my public key, so I uploaded it again. I don't know if it is related, but the listserve forgot that I was receiving the digest form of the list on Oct 16 or so. After the upload still no luck -- though there may be some form of authorization required and/or delay built in, since when I first uploaded my public key last year, it didn't work for at least a day. George On Sat, Oct 30, 2010 at 5:53 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Oct 30, 2010 at 05:34:34PM -0400, George Hunt wrote: I have 2 projects that I have been pushing git commits to for almost a year. In one I created a new branch, and was concerned that my local change was preventing the successful git push. But the other project has no structural changes, and still gets the response fatal: the remote end hung up unexpectedly -- which I see has been a source of lots of headaches for the inner circle. Should I just wait for 6 hours, and try again? How to proceed? Check if: * `ssh gitori...@git.sugarlabs.org` outputs PTY allocation request.. * `git config remote.origin.url` output is equal to particular push link on your project web page on git.sl.o -- Aleksey -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GIT.sugarlabs.org changes?
On Wed, Nov 03, 2010 at 01:05:36PM -0400, George Hunt wrote: Username for git.sl.o: georgejh...@gmail.com projects: pydebug and xophoto The push to jita.sl.o was successful! Ok, we are limited in investigating problem with current git.sl.o instance. These days we are moving it to jita.sl.o, so it will just work for you. George On Wed, Nov 3, 2010 at 8:21 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Nov 03, 2010 at 06:22:14AM -0400, George Hunt wrote: I tried the push from another ip address. Same result, so it's probably not the blacklist problem. The literature suggests that I should check for world or group writeability on the path from root to .ssh/known_hosts on the server, and on the client machine. I have double checked my client. Don't have shell access to server. Could you try to push to the new [testing] gitorious http://jita.sugarlabs.org/ To login to jita.sl.o, you need to use your git login name and wiki password for the same login (if there is no wiki account, follow Create an account link to create one) or, if you used OpenID, just login via OpenID link on jita. And what is your login on git.sl.o and project you are trying to push? George On Sun, Oct 31, 2010 at 10:30 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Oct 30, 2010 at 07:58:00PM -0400, George Hunt wrote: Hi Aleksey, Thanks for the response. The ssh step fails. Trying ssh -vvv gitori...@git.sugarlabs.orgindicates that the negotiation proceeds in what looks to be a normal manner, until the point where the client determines that public key method is authorized, and client is offering my public key, and the next response is connection closed. snip debug1: Next authentication method: publickey debug1: Offering public key: debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Connection closed by 140.211.167.221 /snip Connection closed seems suspiciously. We had problem w/ blacklisting of some IPs. Can you try to ssh connect from different IP? (I'm CCing it to systems@) I guessed that the server has forgotten my public key, so I uploaded it again. I don't know if it is related, but the listserve forgot that I was receiving the digest form of the list on Oct 16 or so. After the upload still no luck -- though there may be some form of authorization required and/or delay built in, since when I first uploaded my public key last year, it didn't work for at least a day. George On Sat, Oct 30, 2010 at 5:53 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Oct 30, 2010 at 05:34:34PM -0400, George Hunt wrote: I have 2 projects that I have been pushing git commits to for almost a year. In one I created a new branch, and was concerned that my local change was preventing the successful git push. But the other project has no structural changes, and still gets the response fatal: the remote end hung up unexpectedly -- which I see has been a source of lots of headaches for the inner circle. Should I just wait for 6 hours, and try again? How to proceed? Check if: * `ssh gitori...@git.sugarlabs.org` outputs PTY allocation request.. * `git config remote.origin.url` output is equal to particular push link on your project web page on git.sl.o -- Aleksey -- Aleksey -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] More new and revised chapters of Make Your Own Sugar Activities! ready for review, feedback
On Wed, Feb 03, 2010 at 10:35:06AM -0600, Jim Simmons wrote: In this latest draft I have added a not quite complete chapter on Making Shared Activities. The part that is missing is on using DBus Tubes to remotely call methods, and it's missing because I've never done it. I do plan to learn how to do this, come up with a decent example program (something fancier than Hello Mesh), and write it up in the book, but it will take awhile. The new draft is at: http://objavi.flossmanuals.net/books/ActivitiesGuideSugar-en-2010.02.03-18.11.39.pdf I found out yesterday that copying code from PDF's, either the OBJAVI! version here or the one the Floss Manuals website produces, does NOT work. In one case you get garbage and in the second you get code with no indents. I have set up a Git repository for the sample code in the book and I will change all the references to copying and pasting code to Open file name in the Git project you downloaded. I actually had to learn things about Activity Sharing to write the new chapter, so I am VERY concerned that what I think I learned is correct. I don't want to lead anyone astray! I have reached the point in the book where the stuff I already know is pretty much done. From now on I'll be learning as I go. If you've been giving this project the benefit of the doubt now is a good time to stop doing that. Thanks, James Simmons I've found minor issue on http://en.flossmanuals.net/ActivitiesGuideSugar/SugarDebugging You can also set the logging level outside your program code using an environment variable. For instance, in Sugar .82 and lower you can start sugar-emulator like this: SUGAR_LOGGER_LEVEL=debug sugar-emulator The way you accomplish the same thing in Sugar .84 and greater is to edit the file ~/.sugar/debug and uncomment the line that sets the SUGAR_LOGGER_LEVEL. SUGAR_LOGGER_LEVEL=debug sugar-emulator will will work in 0.84+ as well if ~/.sugar/debug doesn't reset SUGAR_LOGGER_LEVEL, i.e., ~/.sugar/debug just overrides current values right before launching sugar. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUCE] git.sugarlabs.org migration and downtime
Hi all, Thanks for testing new gitorious instance (if you didn't try yet, go to [1]). Since usual git.sugarlabs.org workflows looks good and since several people have ssh login issues (we are limitied in investigation these issues on current git.sugarlabs.org instance) and keeping im mind that [1] works for them, we are migrating git.sugarlabs.org to the new Gitorios code base and moving it to another host to make users support more responsive. git.sugarlabs.org will be inaccessible starting from 2010-11-09 01:00 UTC, for 2 hours. [1] http://jita.sugarlabs.org/ P.S. Previous request to test common SL login system was just a try to investigate this feature, git.sugarlabs.org will still use regular accounts after migration. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] More new and revised chapters of Make Your Own Sugar Activities! ready for review, feedback
On Mon, Nov 08, 2010 at 11:07:48AM -0600, James Simmons wrote: Aleksey, I've changed the paragraph in http://en.flossmanuals.net/bin/view/ActivitiesGuideSugar/SugarDebugging It is not published yet, but if you use the link above you can see it. If it looks OK to you I'll ask for the changes to be published. Looks fine to me, thanks. Thanks, James Simmons On Sat, Nov 6, 2010 at 9:11 PM, Aleksey Lim alsr...@member.fsf.org wrote: I've found minor issue on http://en.flossmanuals.net/ActivitiesGuideSugar/SugarDebugging You can also set the logging level outside your program code using an environment variable. For instance, in Sugar .82 and lower you can start sugar-emulator like this: SUGAR_LOGGER_LEVEL=debug sugar-emulator The way you accomplish the same thing in Sugar .84 and greater is to edit the file ~/.sugar/debug and uncomment the line that sets the SUGAR_LOGGER_LEVEL. SUGAR_LOGGER_LEVEL=debug sugar-emulator will will work in 0.84+ as well if ~/.sugar/debug doesn't reset SUGAR_LOGGER_LEVEL, i.e., ~/.sugar/debug just overrides current values right before launching sugar. -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUCE] git.sugarlabs.org migration and downtime
On Sun, Nov 07, 2010 at 10:33:03PM +, Aleksey Lim wrote: Hi all, Thanks for testing new gitorious instance (if you didn't try yet, go to [1]). Since usual git.sugarlabs.org workflows looks good and since several people have ssh login issues (we are limitied in investigation these issues on current git.sugarlabs.org instance) and keeping im mind that [1] works for them, we are migrating git.sugarlabs.org to the new Gitorios code base and moving it to another host to make users support more responsive. git.sugarlabs.org will be inaccessible starting from 2010-11-09 01:00 UTC, for 2 hours. [1] http://jita.sugarlabs.org/ P.S. Previous request to test common SL login system was just a try to investigate this feature, git.sugarlabs.org will still use regular accounts after migration. New Gitorios is ready for using from regular http://git.sugarlabs.org. There are found isses that will be fixed soon: * HTTP cloning doesn't work * cgit.sugarlabs.org is useless * http://cia.vc plugin is inactive -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUCE] git.sugarlabs.org migration and downtime
On Tue, Nov 09, 2010 at 05:42:26AM +, Aleksey Lim wrote: On Sun, Nov 07, 2010 at 10:33:03PM +, Aleksey Lim wrote: Hi all, Thanks for testing new gitorious instance (if you didn't try yet, go to [1]). Since usual git.sugarlabs.org workflows looks good and since several people have ssh login issues (we are limitied in investigation these issues on current git.sugarlabs.org instance) and keeping im mind that [1] works for them, we are migrating git.sugarlabs.org to the new Gitorios code base and moving it to another host to make users support more responsive. git.sugarlabs.org will be inaccessible starting from 2010-11-09 01:00 UTC, for 2 hours. [1] http://jita.sugarlabs.org/ P.S. Previous request to test common SL login system was just a try to investigate this feature, git.sugarlabs.org will still use regular accounts after migration. New Gitorios is ready for using from regular http://git.sugarlabs.org. There are found isses that will be fixed soon: * HTTP cloning doesn't work * cgit.sugarlabs.org is useless * http://cia.vc plugin is inactive Since git.sugarlabs.or IP was changed, while trying to interact via ssh, you will be warned about that. You need to tweak ~/.ssh/known_hosts file, delete line with substring git.sugarlabs.org. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] git.sugarlabs.org migration and downtime
On Tue, Nov 09, 2010 at 12:16:45PM +, Aleksey Lim wrote: On Tue, Nov 09, 2010 at 05:42:26AM +, Aleksey Lim wrote: On Sun, Nov 07, 2010 at 10:33:03PM +, Aleksey Lim wrote: Hi all, Thanks for testing new gitorious instance (if you didn't try yet, go to [1]). Since usual git.sugarlabs.org workflows looks good and since several people have ssh login issues (we are limitied in investigation these issues on current git.sugarlabs.org instance) and keeping im mind that [1] works for them, we are migrating git.sugarlabs.org to the new Gitorios code base and moving it to another host to make users support more responsive. git.sugarlabs.org will be inaccessible starting from 2010-11-09 01:00 UTC, for 2 hours. [1] http://jita.sugarlabs.org/ P.S. Previous request to test common SL login system was just a try to investigate this feature, git.sugarlabs.org will still use regular accounts after migration. New Gitorios is ready for using from regular http://git.sugarlabs.org. There are found isses that will be fixed soon: * HTTP cloning doesn't work * cgit.sugarlabs.org is useless * http://cia.vc plugin is inactive Since git.sugarlabs.or IP was changed, while trying to interact via ssh, you will be warned about that. You need to tweak ~/.ssh/known_hosts file, delete line with substring git.sugarlabs.org. For people who need to change known_hosts record manually, info about RSA host key for new git.sugarlabs.org: git.sugarlabs.org ssh-rsa B3NzaC1yc2EDAQABAAABAQCmJXgCnPx+ngxdhXkIXbAy2aGHj9w5udPQDq8e5OX1X8Qvi6+C356OhL8veZDKXbn9B9Aq6HwzoK0ZzDqk9nUeY6qvBNhTNTvDLbY+0+rAskRbscNH7mcuGvp5ygTSfcTkagXK6QCj84jkhDVlPAWfKOw2vzu+7AXkoNknqXnMyHv0No3INJnDDUGM75/4KCVZqiXuojgMA4vsq9yrc1vWRMuJaMg9fvirJTJDjvc8ZOXVsbsx2GjdCyHeMxuOIKlwfkDvuptFGNeWtOS6q/w/xPRxHiwUCfBo+8NvYx8JpIr1IaP2US00oLFE823b4DSVulFXgq6jw2gFrcru7O/3 2048 4f:5e:5c:7f:ca:94:49:9d:2e:77:85:86:7c:de:56:f1 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ObjectChooser() Issue?
On Tue, Nov 09, 2010 at 03:10:56PM -0300, Gonzalo Odiard wrote: On Tue, Nov 9, 2010 at 3:04 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Nov 08, 2010 at 01:01:02PM -0500, Art Hunkins wrote: At Sasha's suggestion, I've arrived at the following code to send the filepath of a soundfile to Csound via its reference in the Journal. The filename (self.filename[0]) is being correctly passed: def choose1(self, widget): chooser = ObjectChooser(parent=self, what_filter=mime.GENERIC_TYPE_AUDIO) result = chooser.run() if result == gtk.RESPONSE_ACCEPT: jobject = chooser.get_selected_object() After destroying jobject object, you will lose /home/olpc/.sugar/default/data/f70f03b1-fe40-44e6-9d75-5ef274cf0ad2.wav file, so either keep this object or move/hard-link file somethere for later usage (but remove it after using). Why is destroyed jobject ? Only curiosity, I have read the mail and don't understand what is the problem with the code. The thing is that after creating sugar.datastore.datastore.DSObject (here jobject variable) and calling file_path, temporary file will be created (in fact, hard link to the file stored in ds), after deleting jobject this file will be removed. Code tries to use file_path after deleting jobject, thus file is already deleted. Gonzalo if jobject and jobject.file_path: self.filename[0] = str(jobject.file_path) # open(jobject.file_path).read() # open(self.filename[0]).read() else: self.filename[0] = 0 The problem is that the file cannot be opened by Csound - either via the above function as it stands, or by the addition of either line that is commented out. I receive this error message (from Csound): diskinfo can't open /home/olpc/.sugar/default/data/f70f03b1-fe40-44e6-9d75-5ef274cf0ad2.wav The filepath and name are correct, and the file can be played fine with either Browse or Jukebox. What must I do to make the referenced soundfile readable? Art Hunkins ___ 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 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] anonymous ASLO messages
On Wed, Nov 10, 2010 at 09:53:18AM +1100, James Cameron wrote: These announcements from activities.sugarlabs.org of new releases are sent without any included identity of the person who did the release. Could activities.sugarlabs.org please be changed to include the releaser in these messages? The problem is that uploaders don't include release notes. The proper fix might be do not accept them (from uploading checks), so patches are welcome :). -- James Cameron http://quozl.linux.org.au/ ___ 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
Re: [Sugar-devel] anonymous ASLO messages
On Wed, Nov 10, 2010 at 10:51:51AM +1100, James Cameron wrote: On Tue, Nov 09, 2010 at 11:23:46PM +, Aleksey Lim wrote: On Wed, Nov 10, 2010 at 09:53:18AM +1100, James Cameron wrote: These announcements from activities.sugarlabs.org of new releases are sent without any included identity of the person who did the release. Could activities.sugarlabs.org please be changed to include the releaser in these messages? The problem is that uploaders don't include release notes. The proper fix might be do not accept them (from uploading checks), so patches are welcome :). No, I think you misunderstand. My observation has nothing to do with whether release notes are present in the mail message. Where's the code? http://git.sugarlabs.org/projects/slo-activities http://wiki.sugarlabs.org/go/Activity_Library/Devel/Installing But keep in mind that current code is php/cake based and new ASLO will be based on new AMO python/django code. So, would be useful if patch is not invasive and might be applied w/o starting new development/testing/production cycle. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] anonymous ASLO messages
On Wed, Nov 10, 2010 at 12:18:48PM +1100, James Cameron wrote: On Wed, Nov 10, 2010 at 12:20:22AM +, Aleksey Lim wrote: On Wed, Nov 10, 2010 at 10:51:51AM +1100, James Cameron wrote: On Tue, Nov 09, 2010 at 11:23:46PM +, Aleksey Lim wrote: On Wed, Nov 10, 2010 at 09:53:18AM +1100, James Cameron wrote: These announcements from activities.sugarlabs.org of new releases are sent without any included identity of the person who did the release. Could activities.sugarlabs.org please be changed to include the releaser in these messages? The problem is that uploaders don't include release notes. The proper fix might be do not accept them (from uploading checks), so patches are welcome :). No, I think you misunderstand. My observation has nothing to do with whether release notes are present in the mail message. Where's the code? http://git.sugarlabs.org/projects/slo-activities http://wiki.sugarlabs.org/go/Activity_Library/Devel/Installing The file site/app/views/editors/email/aslo/release_en_plain.thtml contains what looks like the release messages, but I cannot see where it is used. What is needed is the authenticated user's e-mail address. But keep in mind that current code is php/cake based and new ASLO will be based on new AMO python/django code. So, would be useful if patch is not invasive and might be applied w/o starting new development/testing/production cycle. That says to me, don't do anything, your effort will be wasted, nobody else cares about this problem. Thanks for the warning. I see no way forward. The thing is, we are using not supported AMO code base that have long standing bugs. Upstream has switched to django and we need to do the same. So, if you was thinking about easy hacking, then you was wrong ;) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] anonymous ASLO messages
On Tue, Nov 09, 2010 at 09:36:37PM -0500, Rafael Enrique Ortiz Guerrero wrote: Hi all On Tue, Nov 9, 2010 at 9:15 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Nov 10, 2010 at 12:18:48PM +1100, James Cameron wrote: On Wed, Nov 10, 2010 at 12:20:22AM +, Aleksey Lim wrote: On Wed, Nov 10, 2010 at 10:51:51AM +1100, James Cameron wrote: On Tue, Nov 09, 2010 at 11:23:46PM +, Aleksey Lim wrote: On Wed, Nov 10, 2010 at 09:53:18AM +1100, James Cameron wrote: These announcements from activities.sugarlabs.org of new releases are sent without any included identity of the person who did the release. Could activities.sugarlabs.org please be changed to include the releaser in these messages? The problem is that uploaders don't include release notes. The proper fix might be do not accept them (from uploading checks), so patches are welcome :). No, I think you misunderstand. My observation has nothing to do with whether release notes are present in the mail message. Where's the code? http://git.sugarlabs.org/projects/slo-activities http://wiki.sugarlabs.org/go/Activity_Library/Devel/Installing The file site/app/views/editors/email/aslo/release_en_plain.thtml contains what looks like the release messages, but I cannot see where it is used. What is needed is the authenticated user's e-mail address. But keep in mind that current code is php/cake based and new ASLO will be based on new AMO python/django code. So, would be useful if patch is not invasive and might be applied w/o starting new development/testing/production cycle. That says to me, don't do anything, your effort will be wasted, nobody else cares about this problem. Thanks for the warning. I see no way forward. The thing is, we are using not supported AMO code base that have long standing bugs. Upstream has switched to django and we need to do the same. So, if you was thinking about easy hacking, then you was wrong ;) from AMO's Wiki [1] the migration is not yet complete: ''This project is currently underway, and will take some cycles to complete. Bugs that take too much work to fix will likely be delayed until Zamboni is completed, in order to prevent duplicate work when porting features.'' Zamboni [2] is the code name for the Django project. [1] https://wiki.mozilla.org/AMO:Editors/InfoEditors [2]http://blog.fligtar.com/2010/01/15/amo-zamboni-planning-underway/ Mozilla uses Zamboni in production https://wiki.mozilla.org/AMO:Developers And Remora page says Remora is no longer maintained https://wiki.mozilla.org/Update:Remora I have long running plans about close (but not in launchpad way) integration of SL services, Bazaar + ASLO + ... The first step (during 0.92 release cycle), I'm planing to do, will be switching ASLO to Zamboni (with keeping existed functionality). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] [SOLVED] git.sugarlabs.org migration
Hi all, This is a summary of successful migration of git.sugarlabs.org to different host and new Gitorios code base (which is 1.5 year ahead of previously used on git.sugarlabs.org). Previously mentioned issues were fixed, such as: * http://cgit.sugarlabs.org * http read only access to git repositories * CIA.vc plugin IMPORTANT CHANGES git.sugarlabs.org's IP was changed to 18.85.44.120. New public SSH key fingerprint is 4f:5e:5c:7f:ca:94:49:9d:2e:77:85:86:7c:de:56:f1 (remove line with substring git.sugarlabs.org from your ~.ssh/known_hosts file, try to ssh connect to git.sugarlabs.org and check if ssh-keygen -F git.sugarlabs.org -l output is equal to new git.sugarlabs.org fingerprint). Since merge request workflow was changed in Gitorios (see below), all already existed merges are titled as It appears that the commits in this merge request have already been merged into ..., that might be not right since new Gitorios doesn't have sufficient information about merge. New Gitorios sends fully qualified name of a committer (like it appears in git log) to CIA.vc site. So if you are bothering about CIA stats, check if you own your own name there. (Short introspection of 1.5 years of Gitorios development) MAJOR FEATURES Team support [1] Gitorious now supports the creation of teams. Anyone can create a team, which lets users share repositories, promote their team on the team page and gives custom URLs for projects and their repositories. New merge requests [2] Merge requests lets users make contributions to repositories hosted on Gitorious.org. After all, sharing code is what it’s all about. The new version of Gitorious brings some changes to the way merge requests are handled. Awesome code review [3] How to make review process more convenient within Gitorios. Repository permissions [4] Ever had the need to give someone permissions to triage merge request, but not give them commit access? Well, now you can, thanks to our new finer-grained repository access permissions. Activity watching [5] Track for particular events. MINOR FEATURES Several repositories per project [1] Each project can now have several repositories. The project page lists all repositories belonging to the project, so you can easily see repositories that relate to each other. Improved URLs [1] The URLs generated and recognized by Gitorious has been completely revamped, providing URLs that let you easily recognize what you’re currently looking at. Support for several committers [1] You can now add one or more committers to a repository, the difference being that you can now add a whole team as well and projects and repositories themselves can be now owned by a team. This gives you a way of easily managing multiple project or repository administrators. Support for several email addresses for a user [1] Some users use several email addresses when committing code, and Gitorious now lets you specify several email addresses (“aliases”). When adding a new email address you’re required to confirm the address by clicking a link you’ll receive by email from Gitorious. Check your profile page for the “Manage aliases” link. User and team avatars [1] Users and teams can now upload custom images (avatars). So if you don’t have a Gravatar account (or don’t want one) you can upload a custom image that will be displayed on your profile and next to your commits on the site. [1] http://blog.gitorious.org/2009/05/09/weve-made-a-few-changes/ [2] http://blog.gitorious.org/2009/07/15/new-merge-request-functionality/ [3] http://blog.gitorious.org/2009/11/06/awesome-code-review/ [4] http://blog.gitorious.org/2009/11/26/repository-permissions/ [5] http://blog.gitorious.org/2010/01/22/activity-watching/ -- Aleksey pgpDESCT746EE.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] [SOLVED] git.sugarlabs.org migration
On Thu, Nov 11, 2010 at 11:37:33PM +, Aleksey Lim wrote: Activity watching [5] Track for particular events. The useful feature that was hidden in original Gitorious (dunno why, though it works for me), is sending emails each time something from the favorite was triggered, e.g., new commits were pushed. Click on Email notifications button in your Dashboard. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GeoGebra in XO
On Mon, Nov 15, 2010 at 02:43:26AM -0300, Gonzalo Odiard wrote: If you run GeoGebra [1] in a XO with Sugar in english, does not start with a msg about file javaui_en.properties missing. I can resolve it doing: cd /home/olpc/Activities/GeoGebra.activity/geogebra unzip geogebra_properties.jar cd geogebra/properties/ cp javaui.properties javaui_en.properties cd ../.. mv geogebra_properties.jar geogebra_properties.jar.old Who can modify the file in ASLO? Will fix it. Gonzalo [1] http://activities.sugarlabs.org/en-US/sugar/addon/4284 ___ 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
Re: [Sugar-devel] IRC activity, version 7
On Tue, Nov 16, 2010 at 04:12:12AM -0500, Fran Rogers wrote: Hello folks, I'm pleased to announce a new version of the IRC activity. I've been working on the activity over the past few weeks as part of the Humanitarian FOSS class at RIT; Mel Chua, the current maintainer, was looking for a new maintainer and I decided to take up the task. Version 7 significantly adds Sugar Journal support, allowing your nickname, server, channels joined, and channel and query scrollback to persist between sessions. Proper CTCP support has also been added, so you'll no longer get a gibberish message when Freenode checks your version on login; several other cosmetic bugs have been fixed, as well. The new version should be on ASLO soon (I'm still waiting for upload access), but for now you can download it here: .xo Bundle: http://dl.dropbox.com/u/11458013/IRC/IRC-7.xo Source: http://dl.dropbox.com/u/11458013/IRC/IRC-7.tar.bz2 I've added you to IRC developers on ASLO. Your input is welcome! -Fran Rogers -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Multi-lingual IRC chat
Hi all, This is supybot[1] (meeting nick on sugar IRC channels) plugin implementation of transbot[2] feature (thanks to transbot developers for this idea). = Description = In other words, it is about implicit translation for particular IRC channel into several languages. People being in satellite channels, like #sugar-ru, can type posts in Russian, all theses posts will be translated into English and posted to #sugar. The same works in opposite direction. = Web chat = The easiest way to test it is opening development instance of chat service: http://chat-devel.sugarlabs.org If it [still] doesn't work, try: http://jita.sugarlabs.org On login screen, choose one of sugar channels and the language you want to type posts in. Language might be Default that means that you need to type in default language for IRC channel from the list. After loginning, you can all time open new channel using combo boxes on the leftmost side of upper toolbar. = IRC commands = Being logged in to IRC, you can use meeting's commands to open new translation channels. To list all primal channels that can be translated by meeting bot: /msg meeting lingvo list To open new translation channel: /msg meeting lingvo join [channel] lang If [channel] is omitted, current one will be used. lang is language code, if you typed it wrong, meeting will inform you about all supported languages. [1] http://sourceforge.net/projects/supybot/ [2] https://fedorahosted.org/transbot/wiki/testing -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Engineering Team
Hi all, (Just trying to summarize previous discussions, including recent one on #sugar with some kind of motion) = The problem = Current situation with stuck patches queue is dangerous. Deployments have to support their own big branches (branches, by themselves, is not bad but big ones), at last I know about Dextrose. Such splitting is really bad, e.g., people who test Sugar need to keep in mind that there are upstream, OLPC, Dextrose, etc. Sugars. = Engineering Team = The Engineering Team is maintaining several core projects that influence on the rest of Sugar: * sugar-artwork * sugar-datastore * sugar-toolkit (would be good to merge it with sugar-base) * sugar (Sugar shell, i.e., Sugar Window Manager) The team consist of developers who: * know code of core projects (some of them), * have a time to take part in reviewing process, * ready to close work with all other team members. The area of responsibility of the Engineering Team is: * take care of technical standards (API, DBus interface, etc), * take part in reviewing patches for one of core projects, * acking patches for one of core projects, * take part in reviewing [[Features]]. What Engineering Team is not intended for: * be a core team (in meaning of Sugar core), Sugar is not community around software but around educational ideas, so being a core is more for educators, designers, just open minded people [1] * be a developers team, developing in sugar is not just developing 4 projects, what is ok for these 4 projects might be bad for 99% of sugar - activities (at least activities should be 99%) * would be good to not mix glucose with fructose activities, activities developing process is much obvious than glucose, lets use regular activities workflow for fructose * should be good if Engineering Team will take care only of glucose releasing, not any activities. If SL needs releasing a product, would be better to leave it to Platform Team[2] So, Engineering Team members might not take active part in coding itself (this is more a task for [[Features]] developers) but just do engineering work to support core projects. The only way when creative work appears (for Engineering Team) is [[Features]]. The team members list might not be constant, if members don't have enough time to take active part in regular work of the team, they need request for exclusion to not mislead other participants. = Review process = One of two Engineering Team tasks - reviewing (the another one is technical standards), might look like: * patches that are intended for glucose (the rest of projects can follow the way which is most convenient for them) should be emailed to sugar-devel@ with CCing to engineering@ * to accept the patch, only one ack from Engineering Team is needed (including patches from Engineering Team members) * obvious things should be taken into account like risks and discussing not trivial patches with other Engineering Team members * reviewing [[Features]] is another case, it might require more close work of Engineering Team reviewers with feature developers = Possible candidates to Engineering Team = This is tops 10 of commits to glucose projects starting from 0.83.0 (when SL was formed). sugar-base commit 8282410627141a65d555d4b075497ae76b42a52b Date: Thu Aug 7 15:37:17 2008 +0200 18 Tomeu Vizoso 12 Simon Schampijer 6 Marco Pesenti Gritti 3 Sascha Silbe 2 Aleksey Lim 1 Nirbheek Chauhan 1 Kushal Das 1 Bernie Innocenti sugar-artwork commit 6ca1dddef325dc8a6b0639724dc0def601666c2b Date: Thu Aug 7 10:48:41 2008 +0200 31 Simon Schampijer 14 Tomeu Vizoso 14 Benjamin Berg 11 Eben Eliason 10 Marco Pesenti Gritti 7 C. Scott Ananian 3 Bernie Innocenti 2 Aleksey Lim sugar-datastore commit 721dc4e82515b00856cd591bc5e84bca4979ca76 Date: Thu Aug 7 16:55:10 2008 +0200 99 Tomeu Vizoso 37 Aleksey Lim 14 Sascha Silbe 6 Simon Schampijer 5 Andrés Ambrois 2 Bernie Innocenti 1 Wade Brainerd 1 Bert Freudenberg sugar-toolkit commit c3873bfdcb78bf5e50568b591b3d9deec4d3d9db Date: Fri Aug 22 20:48:59 2008 +0200 160 Tomeu Vizoso 101 Aleksey Lim 85 Simon Schampijer 41 Marco Pesenti Gritti 13 Sayamindu Dasgupta 12 Sascha Silbe 12 Benjamin Berg 8 Daniel Drake 5 David Farning 4 Khaled Hosny sugar commit 546ddf99dece09fcbff4c8730df3f92923d7ef6b Date: Thu Aug 7 17:58:29 2008 +0200 419 Tomeu Vizoso 234 Simon Schampijer 199 Marco Pesenti Gritti 129 Aleksey Lim 36 Sayamindu Dasgupta 24 Daniel Drake 23 Guillaume Desmottes 21 Eben Eliason 14 Sascha Silbe 13 C. Scott Ananian = Motion = This is *not* closed topic or my authoritative decision, just being a sugar-datastore maintainer and a person from commits top, I've: * create engineering team[3] on git.sl.o * added there sugar-datastore project * created engineering@ * will seek for existed sugar-datastore patches to review/accept them People from the commits top (and any
Re: [Sugar-devel] Engineering Team
On Sat, Nov 20, 2010 at 04:27:49AM +, Martin Dengler wrote: On Sat, Nov 20, 2010 at 02:53:06AM +, Aleksey Lim wrote: Hi all, (Just trying to summarize previous discussions, including recent one on #sugar with some kind of motion) = The problem = [...] = Engineering Team [the solution] = [...] I'm not opposed to the discussion. While we (continue to) have it, am I wrong in thinking the de factor situation is that: - anyone who is allowed push to sugar* repos is allowed to approve and / or push a patch or other code (and is trusted to not push contentious things) The practice was (if got it right), only glucose maintainers (discussing with their peers) might say please push http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Glucose When Tomeu stepped aside, we have unmaintained for sugar. Another important module is maintained by Simon, but he is busy with OLPC work. The idea is having several people who can say please push for all glucose modules. Maybe better to have such people per module, but we have only 4 modules (I guess people will manage to work together), moreover there might situations when patches/features affect several core modules eg ds and shell. - people who are not allowed to push to sugar should do this to get code in: http://wiki.sugarlabs.org/go/Development_Team/Code_Review All patch/feature providers need to follow this rule (including glucose maints who need to patch). That was in previous scheme and I think would be useful to keep this way for the new one. I ask because I want to understand what the the current situation is: Current situation with stuck patches queue is dangerous Martin -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On Sat, Nov 20, 2010 at 02:29:13PM +, Daniel Drake wrote: On 20 November 2010 02:53, Aleksey Lim alsr...@member.fsf.org wrote: = The problem = Current situation with stuck patches queue is dangerous. Deployments have to support their own big branches (branches, by themselves, is not bad but big ones), at last I know about Dextrose. Such splitting is really bad, e.g., people who test Sugar need to keep in mind that there are upstream, OLPC, Dextrose, etc. Sugars. OLPC has never shipped a downstream-patched Sugar in an official release in the last few years, and I can only think of a handful of examples where early development versions included downstream patches. To the best of my knowledge, SoaS, Debian, Ubuntu and SuSE do not ship downstream patches in their sugar distributions either. (unverified, but I've never heard of them doing this) Do you have any examples, other than Dextrose, of this problem existing? (I was talking about not packages in GNU/Linux distros but about Sugar developments). If OLPC doesn't shipp downstream patches thats relly good but I guess it is because last stable OLPC sugar is 0.84 and that OLPC people are maints of 0.84 branches. Dextrose has patches that are collected based on responce from the field. This is a real problem to commit them to the trunk. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
