Re: [Sugar-devel] Testing 0.90 on an XO
On 10/05/2010 04:24 AM, James Cameron wrote: On 05/10/2010, at 12:39 PM, fors...@ozonline.com.au wrote: How do I tell what an integration issue is? There's a few methods, but they require either experience or knowledge of the software components and how they interface. If in doubt, just log the issue and let the developer analyse and reject it. Hi Tony, sorry for the unclear request. Let's put it this way: Focus on issues that are in Sugar. For example I am not interested in things like idle suspend does not work or I can not use olpc-update, or the camera does not work, or sreen rotate does not work. I would say best is to start with testing the 0.90 Features. And then do test if Sugar has regressed: connecting to an AP, sharing an activity, correct entries in the Journal... I hope this explains it a bit better. And yes, like James said, if in doubt file it and we can figure it out. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1169 NORM: Drop down menus give no indication of their existence, also are too slow to load.
On Sat, Oct 2, 2010 at 09:46, Shanjit Singh Jajmann shan...@dev.seeta.in wrote: Hi, Appropriate changes have now been made to the issue and the patches have also been uploaded. Changes have been made as suggested by FGrose in his comment. I see lots of related information in the bug tracker about this and other proposals. Can you make explicit why you have chosen to implement this particular solution? Also, would be good to have a ticket for each issue that needs to be addressed. Maybe we could have one for the general problem as perceived by the user and then several subtickets for each of the actions that can be taken to improve it. For the others, please chime into this thread if you have any insight on what the consensus is. Thanks, Tomeu Wish if the patch could be reviewed. Suggestions are welcome. regards Shan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 10/05/2010 01:16 AM, Tim McNamara wrote: On 5 October 2010 10:25, James Cameronqu...@laptop.org wrote: I agree with the proposal. -- James Cameron System Test Coordinator One Laptop per Child I tentatively agree. My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. It also adds to the pressure to maintain several versions of the software concurrently. While I agree that maintainence releases are important, I would prefer that community etiquette is developed that discourages version numbers that look like 2.4.12. Developers should be strongly encouraged to migrate to a new integer release when practical. Most activities are quite discrete. They tend not to add many features once they have reached a desired level of maturity. Tim. Hi Tim, I think most of the activities will keep on just using integer numbers. The new proposal does address only the need where this is not possible or where we would have to find even uglier solutions (like described in the original mail). I think the most complex version number we will ever see is 10.2. Btw, the current scheme resulted in activity numbers like 108 for Browse. This is the case since we had many development iterations. When we would have used the versioning scheme with minor major release we would probably be at 8.0 by now, which I tend to think might be easier for young learners (if they will ever look at the version numbers). Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
Hi Gary, thanks for your feedback. On 10/05/2010 04:31 AM, Gary Martin wrote: On 5 Oct 2010, at 00:30, James Cameronqu...@laptop.org wrote: On 05/10/2010, at 10:16 AM, Tim McNamara wrote: My strong preference is for Activities to rapidly increase their integer numbers, rather than creating a complex tree of point releases. My feeling is that a tree of three or more levels deep adds complexity to new Learners. It goes against the 'low floor, no ceiling' philosophy by requiring that Learners learn a new counting system, on top of integer increments. Tentative +0.25 as well if others think this is really, really necessary - but I personally never want to have to maintain two or more versions of any activity (what the doted version support is really all about). When we hit a show stopping api break, consider the last working release the end of line, or upgrade to a newer Sugar that is supported by a newer activity release. Fair enough. Personally I think the new scheme is used in the following cases: * platform dependent activities like Browse or Read * I want to do several small releases (for example for people for testing, 1.2, 1.3, 1.4) before I get to a new major release (2). Yes. Better than the current situation though. Only if the change does not break 0.82 and 0.84 integer based updates/installs. Or are we saying that as of 0.92 every activity will have to fork and break with past versions of Sugar anyway? If so I can see little motivation as an activity developer to move to 0.92 for quite some time, who wants to write activities almost no deployment will use for likely 6 to 18 months at best? I guess if this is the case, moving to a new versioning scheme in 0.92 is fine even if it breaks 0.82 and 0.84, as no activities for 0.92 will run anyway on past Sugar versions :( Of course we don't break backwards compatibility. Integer versions will work as they did before. Ideally, instead of presenting a version number to a learner, a graph describing the history of the activity source and dependencies could be displayed. Ouch. Alternatively, separate the Learner visible numbering from the software release numbering, and leave the visible numbering within the scope of a deployment. Then one deployment's Browse-190 may be different to another deployment's Browse-190. Oh please for the love of maintenance no, how will we ever deal with bug reports. If a deployment decides to fork, say Physics, and introduces their own bugs and/or breaks Journal entry compatibility by adding some feature, I do not want to burn up any more of my life dealing with tickets reported with ambiguous version information, it's bad enough dealing with tickets from folks not testing against the current release. If you fork you are on your own. Period. And I would encourage everyone to always upstream changes. But in some cases it is good and desired to fork for a moment (trying something out, or the change is just not interesting to upstream at all). Those cases would be supported by the new scheme. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: making patches and sending email using git-email
On Sat, Oct 2, 2010 at 10:50, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Ishan Bansal's message of Fri Oct 01 19:58:23 +0200 2010: 2. To do the git email configuration for your system refer to http://paste.ubuntu.com/488777/ Could we improve what we have in the wiki and refer people there? I would add some more recommendations: 1. Introduce yourself to the community. 2. Don't leave questions without a reply. 3. Whenever you take a task that someone else was doing, mention it explicitly so others aren't concerned about wasting efforts. 4. Ask when you don't understand. 5. Answer other people's questions when you can. Regards, Tomeu From there: 17 git send-email --to sugar-devel@lists.sugarlabs.org patchname.patch FWIW, you don't need to create the patch (using format-patch) first, git-send-email can do that for you: git send-email HEAD^..HEAD You can configure the destination address so you don't need to specify it manually every time: git config sendemail.to sugar-devel sugar-devel@lists.sugarlabs.org You need to do this for each of the repositories you are working on (e.g. sugar + sugar-toolkit). 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] coping with the traffic in sugar-devel (was Re: Replacing Illegal character ':' in username (SL #2152))
On Sun, Oct 3, 2010 at 21:23, Bernie Innocenti ber...@codewiz.org wrote: If you want to ensure that I read a message intended for me, you'd better keep me on cc. I don't read every single post sent to sugar-devel. What about marking in some way those incoming emails that belong to a thread that has included the word 'bernie'? There's also the option of just going through the subjects, read the threads that look interesting then marking all of them as read when finished. I'm starting a new thread about this because I often hear from people who have missed important developments because cannot cope with the traffic. I'm also on way more lists that I can read, but with a bit of automatic labelling and organization I think I manage to miss little of the relevant info. Any other tips? Regards, Tomeu On Sun, 2010-10-03 at 00:12 +0530, Dipankar Patro wrote: I am currently facing some problem with XS setup. I downloaded the image and installed it on VMware. But that did not work. What failed exactly? Bernie, Since the school server setup may take up a day or two, I can definitely work on the bug #1976 in the meantime. I will send the patch as soon as it is ready and tested. Thanks. Please make sure that, in the default case when nothing is configured, the behavior on the XO-1 stays the same as before. Sascha, I agree with you, there should be ready-made Live CD kind of thing for XS. Just plug and test! :-) The current installation CD is supposed to perform an almost 100% automated installation. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Pointers required for SL#1742 (after adding a friend the palette doesn't change) ,
On Fri, Oct 1, 2010 at 20:06, Anurag Chowdhury anu...@seeta.in wrote: What I figured out for this bug is that the bug could be solved only if the shell service has a D-Bus API for buddies. Untill then even the present scenario of one time update during system restart has also been applied through a hack place in sync_friends () in the jarabe.model.friends.py module this bug will get wrapped itself when the said api for shell service will get designed then even this sync_friends function would be removed. But I would need some pointers on how to create this dbus api for the present scenario and how will that work through the process to solve this defect. Replied in the ticket, I'm curious about why you have reached the conclusion that D-Bus is needed. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing 0.90 on an XO
On 10/05/2010 03:39 AM, fors...@ozonline.com.au wrote: Please use these builds only for reporting back 0.90 issues. There are surely issues that are due to integration issues. Leave them for now. How do I tell what an integration issue is? Do you only want bugs on new features and not regressions? Tony Tony, thanks for filing the bugs. They are all great and 'valid'! I have followed up on them. Thanks as well for following the instructions and indicating the version number and setting the keyword, this does help a lot. Have a nice day, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Bug #630:Modal Dialog Fix and Journal Memory Full Alert added
On Fri, Sep 24, 2010 at 16:46, Mukul Gupta mu...@seeta.in wrote:
Modal Dialog should be displayed only once at startup if free
memory is less than 50MB but greater than 10MB. Instead, for every
redundant Modal Dialog Display, an Alert in the Journal signifying
Low Memory is displayed.But when free memory reaches a critical
limit(ie. 10MB) Modal Dialog is displayed repeatedly asking the
user to delete some data in the Journal along with an alert in the
Journal
How can I know if this change is desired? The comments in #630 suggest
a different approach.
Or maybe you are addressing another issue instead of #630?
Regards,
Tomeu
---
src/jarabe/journal/journalactivity.py | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/src/jarabe/journal/journalactivity.py
b/src/jarabe/journal/journalactivity.py
index 44cc018..aa4001b 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -49,7 +49,7 @@ J_DBUS_SERVICE = 'org.laptop.Journal'
J_DBUS_INTERFACE = 'org.laptop.Journal'
J_DBUS_PATH = '/org/laptop/Journal'
-_SPACE_TRESHOLD = 52428800
+_SPACE_THRESHOLD = 52428800
_BUNDLE_ID = 'org.laptop.JournalActivity'
class JournalActivityDBusService(dbus.service.Object):
@@ -116,7 +116,7 @@ class JournalActivity(Window):
self._main_toolbox = None
self._detail_toolbox = None
self._volumes_toolbar = None
-
+ self.modal_already_shown=False
self._setup_main_view()
self._setup_secondary_view()
@@ -139,7 +139,7 @@ class JournalActivity(Window):
self._critical_space_alert = None
self._check_available_space()
-
+
def __volume_error_cb(self, gobject, message, severity):
alert = ErrorAlert(title=severity, msg=message)
alert.connect('response', self.__alert_response_cb)
@@ -337,11 +337,17 @@ class JournalActivity(Window):
return
stat = os.statvfs(env.get_profile_path())
free_space = stat[statvfs.F_BSIZE] * stat[statvfs.F_BAVAIL]
- if free_space _SPACE_TRESHOLD:
- self._critical_space_alert = ModalAlert()
- self._critical_space_alert.connect('destroy',
- self.__alert_closed_cb)
- self._critical_space_alert.show()
+ if free_space _SPACE_THRESHOLD:
+ if self.modal_already_shown==False or free_space
_SPACE_THRESHOLD/5:
+ self._critical_space_alert = ModalAlert()
+ self._critical_space_alert.connect('destroy',
+ self.__alert_closed_cb)
+ self._critical_space_alert.show()
+ self.modal_already_shown=True
+ alert = ErrorAlert(title=Journal Almost Full, msg=Please
delete some data from journal)
+ alert.connect('response', self.__alert_response_cb)
+ self.add_alert(alert)
+ alert.show()
def __alert_closed_cb(self, data):
self.show_main_view()
--
1.7.0.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v3 sugar] Run Sugar-Emulator in fullscreen by default if the screen is =800x600 (SL #2180)
On Mon, Sep 27, 2010 at 20:35, Dipankar Patro dipan...@seeta.in wrote: Previously some bottom part of sugar emulator window was pushed out of viewing area at 800x600 system resolution. The patch opens Sugar-emulator in fullscreen mode by default for resolutions = 800x600 to avoid the above mentioned situation. Thanks, will push once we branch, please ping if I forget about it. Regards, Tomeu --- src/jarabe/util/emulator.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) v2 was Reviewed-By Tomeu Vizoso to...@sugarlabs.org v2-v3 : Changed commit message for proper description of patch. diff --git a/src/jarabe/util/emulator.py b/src/jarabe/util/emulator.py index 6a43044..cc112c9 100644 --- a/src/jarabe/util/emulator.py +++ b/src/jarabe/util/emulator.py @@ -42,7 +42,7 @@ def _run_xephyr(display, dpi, dimensions, fullscreen): screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height()) if (not dimensions) and (fullscreen is None) and \ - (screen_size default_dimensions) : + (screen_size = default_dimensions) : # no forced settings, screen too small = fit screen fullscreen = True elif (not dimensions) : -- 1.7.0.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: making patches and sending email using git-email
On Tue, Oct 5, 2010 at 11:09, Tomeu Vizoso to...@sugarlabs.org wrote: On Sat, Oct 2, 2010 at 10:50, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Ishan Bansal's message of Fri Oct 01 19:58:23 +0200 2010: 2. To do the git email configuration for your system refer to http://paste.ubuntu.com/488777/ Could we improve what we have in the wiki and refer people there? I would add some more recommendations: 1. Introduce yourself to the community. 2. Don't leave questions without a reply. 3. Whenever you take a task that someone else was doing, mention it explicitly so others aren't concerned about wasting efforts. 4. Ask when you don't understand. 5. Answer other people's questions when you can. Just one more :) 6. Don't take things off-list unless it's a personal matter. Well, the last: 7. Read all messages sent to the mailing list. Regards, Tomeu Regards, Tomeu From there: 17 git send-email --to sugar-devel@lists.sugarlabs.org patchname.patch FWIW, you don't need to create the patch (using format-patch) first, git-send-email can do that for you: git send-email HEAD^..HEAD You can configure the destination address so you don't need to specify it manually every time: git config sendemail.to sugar-devel sugar-devel@lists.sugarlabs.org You need to do this for each of the repositories you are working on (e.g. sugar + sugar-toolkit). 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] coping with the traffic in sugar-devel
On Tue, 2010-10-05 at 11:19 +0200, Tomeu Vizoso wrote: What about marking in some way those incoming emails that belong to a thread that has included the word 'bernie'? That's really hard... Procmail, my email sorting software, is stateless. There's also the option of just going through the subjects, read the threads that look interesting then marking all of them as read when finished. That's better, but it adds delay: I open my mailing list folders to check for new mail only once in a while, when I'm done with everything else. I'm starting a new thread about this because I often hear from people who have missed important developments because cannot cope with the traffic. I'm also on way more lists that I can read, but with a bit of automatic labelling and organization I think I manage to miss little of the relevant info. Any other tips? Cc'ing people conservatively is standard practice on many high-traffic lists. Today the old arguments of wasted bandwidth are just ridiculous. Occasionally someone complains for receiving dupes, but all modern MUAs provide ways to suppress them. Sascha elegantly solved the issue by setting the Mail-followup-to header to exclude himself from replies (if the remote MUA supports it). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: making patches and sending email using git-email
On Tue, Oct 5, 2010 at 5:09 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sat, Oct 2, 2010 at 10:50, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Ishan Bansal's message of Fri Oct 01 19:58:23 +0200 2010: 2. To do the git email configuration for your system refer to http://paste.ubuntu.com/488777/ Could we improve what we have in the wiki and refer people there? I've expanded http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ#How_do_I_send_a_patch_to_the_Sugar_developers.3F to incorporate this and Sascha's amendments. I would add some more recommendations: 1. Introduce yourself to the community. 2. Don't leave questions without a reply. 3. Whenever you take a task that someone else was doing, mention it explicitly so others aren't concerned about wasting efforts. 4. Ask when you don't understand. 5. Answer other people's questions when you can. Good idea. -walter Regards, Tomeu From there: 17 git send-email --to sugar-devel@lists.sugarlabs.org patchname.patch FWIW, you don't need to create the patch (using format-patch) first, git-send-email can do that for you: git send-email HEAD^..HEAD You can configure the destination address so you don't need to specify it manually every time: git config sendemail.to sugar-devel sugar-devel@lists.sugarlabs.org You need to do this for each of the repositories you are working on (e.g. sugar + sugar-toolkit). 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] any patches for 0.90.1?
On Mon, Oct 4, 2010 at 1:48 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, there are several patches awaiting commit and review, but I don't think all of them are intended to go into 0.90. Can submitters reply to their own messages for those that are intended to go in before we branch? There are two patches attached to http://bugs.sugarlabs.org/ticket/2235 that missed the review window for 0.90. regards. -walter Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1169 NORM: Drop down menus give no indication of their existence, also are too slow to load.
On Tue, Oct 05, 2010 at 10:14:58AM +0200, Tomeu Vizoso wrote: On Sat, Oct 2, 2010 at 09:46, Shanjit Singh Jajmann shan...@dev.seeta.in wrote: Hi, Appropriate changes have now been made to the issue and the patches have also been uploaded. Changes have been made as suggested by FGrose in his comment. I see lots of related information in the bug tracker about this and other proposals. Can you make explicit why you have chosen to implement this particular solution? Also, would be good to have a ticket for each issue that needs to be addressed. [...] For the others, please chime into this thread if you have any insight For major / broad UI changes like this I'd like to see 1) summaries of the opposing views by the patch author (so they know what they're doing and its import, and can help others have a useful discussion on it); and 2) manifest consensus for the change. I see neither in this patch. Thanks, Tomeu Martin pgpD1ct0mvQ7z.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v3 sugar] Run Sugar-Emulator in fullscreen by default if the screen is =800x600 (SL #2180)
Thanks Tomeu for the acceptance. On Tue, Oct 5, 2010 at 3:02 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 27, 2010 at 20:35, Dipankar Patro dipan...@seeta.in wrote: Previously some bottom part of sugar emulator window was pushed out of viewing area at 800x600 system resolution. The patch opens Sugar-emulator in fullscreen mode by default for resolutions = 800x600 to avoid the above mentioned situation. Thanks, will push once we branch, please ping if I forget about it. Regards, Tomeu --- src/jarabe/util/emulator.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) v2 was Reviewed-By Tomeu Vizoso to...@sugarlabs.org v2-v3 : Changed commit message for proper description of patch. diff --git a/src/jarabe/util/emulator.py b/src/jarabe/util/emulator.py index 6a43044..cc112c9 100644 --- a/src/jarabe/util/emulator.py +++ b/src/jarabe/util/emulator.py @@ -42,7 +42,7 @@ def _run_xephyr(display, dpi, dimensions, fullscreen): screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height()) if (not dimensions) and (fullscreen is None) and \ - (screen_size default_dimensions) : + (screen_size = default_dimensions) : # no forced settings, screen too small = fit screen fullscreen = True elif (not dimensions) : -- 1.7.0.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing 0.90 on an XO
On 10/04/2010 05:22 PM, Simon Schampijer wrote: Hi, I have been doing 0.90-F14 builds for the XO-1 and XO-1.5. You can grab the latest build from [1]. I provide these builds that people that do have XO-hardware can start helping testing 0.90. So far, we did not have much testing yet. We just released 0.90.0 and want to do a bug fix release at the end of the month [2]. So testing and filing good bug reports is highly welcome. Please use these builds only for reporting back 0.90 issues. There are surely issues that are due to integration issues. Leave them for now. When you report bugs at [3] with these builds please set the Version to 0.90 and add the keyword olpc-0.90 to be able differentiate those bugs. A good first start would be to test the Features [4] that have landed in 0.90. Each page does contain a test case. As well the release notes at [5] might be of help. And of course, testing different languages and smoke tests of all different fashions are welcome. Regards, Simon I added the olpc-0.90 keyword to all the bugs that are present in the builds [1]. Thanks to Tony Forster a few new ones could be identified. If you have an XO one can can make sure that the latest xorg-x11-drv-geode package does work fine for you and indicate that in bodhi [2] that would be great - so the driver will get into the stable repository. The Final Change Deadline for Fedora 14 is the 18th of October [3]. Would be great to get as many bugs as possible present in Sugar 0.90 on F14 fixed and pushed until then. Thanks, Simon [1] http://bugs.sugarlabs.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentkeywords=~olpc-0.90 [2] https://admin.fedoraproject.org/updates/xorg-x11-drv-geode-2.11.9-1.fc14?_csrf_token=fa12d11a38d93c2c6c1c817bd4390413b87db316 [3] https://fedoraproject.org/wiki/Releases/14/Schedule ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Fix running multiple instances of Browse by adapting to API changes #2404
* sugar/presence/presenceservice.py: Specify the D-Bus interface when
calling ActivityProperties.GetActivity
* sugar/activity/main.py: Set a default for the --invite option and
make the create() D-Bus method accept a{sv} so we can pass the
boolean value.
---
src/sugar/activity/main.py|7 ---
src/sugar/presence/presenceservice.py |6 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/sugar/activity/main.py b/src/sugar/activity/main.py
index 3a3950d..c04257a 100644
--- a/src/sugar/activity/main.py
+++ b/src/sugar/activity/main.py
@@ -56,7 +56,7 @@ class SingleProcess(dbus.service.Object):
object_path = get_single_process_path(name_service)
dbus.service.Object.__init__(self, bus_name, object_path)
-@dbus.service.method(org.laptop.SingleProcess, in_signature=a{ss})
+@dbus.service.method(org.laptop.SingleProcess, in_signature=a{sv})
def create(self, handle_dict):
handle = activityhandle.create_from_dict(handle_dict)
create_activity_instance(self.constructor, handle)
@@ -76,7 +76,7 @@ def main():
action='store_true',
help='start all the instances in the same process')
parser.add_option('-i', '--invited', dest='invited',
- action='store_true',
+ action='store_true', default=False,
help='the activity is being launched for handling an '
'invite from the network')
(options, args) = parser.parse_args()
@@ -146,7 +146,8 @@ def main():
SingleProcess(service_name, activity_constructor)
else:
single_process = sessionbus.get_object(service_name, service_path)
-single_process.create(activity_handle.get_dict())
+single_process.create(activity_handle.get_dict(),
+ dbus_interface='org.laptop.SingleProcess')
print 'Created %s in a single process.' % service_name
sys.exit(0)
diff --git a/src/sugar/presence/presenceservice.py
b/src/sugar/presence/presenceservice.py
index 862d6d0..51d8625 100644
--- a/src/sugar/presence/presenceservice.py
+++ b/src/sugar/presence/presenceservice.py
@@ -42,6 +42,8 @@ _logger = logging.getLogger('sugar.presence.presenceservice')
ACCOUNT_MANAGER_SERVICE = 'org.freedesktop.Telepathy.AccountManager'
ACCOUNT_MANAGER_PATH = '/org/freedesktop/Telepathy/AccountManager'
+CONN_INTERFACE_ACTIVITY_PROPERTIES = 'org.laptop.Telepathy.ActivityProperties'
+
class PresenceService(gobject.GObject):
Provides simplified access to the Telepathy framework to activities
__gsignals__ = {
@@ -80,7 +82,9 @@ class PresenceService(gobject.GObject):
continue
logging.debug(Calling GetActivity on %s, account_path)
try:
-room_handle =
connection.connection.GetActivity(activity_id)
+room_handle = connection.connection.GetActivity(
+activity_id,
+dbus_interface=CONN_INTERFACE_ACTIVITY_PROPERTIES)
except dbus.exceptions.DBusException, e:
name = 'org.freedesktop.Telepathy.Error.NotAvailable'
if e.get_dbus_name() == name:
--
1.7.2.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Home button in Browse
On 09/30/2010 07:38 PM, Gary Martin wrote: On 30 Sep 2010, at 17:58, Simon Schampijer wrote: I'm still not clear on the toolbar positioning for adding yet another button, unless we can move the reload/stop button inside the far right of the address bar (like we do with the Sugar search fields and the clear field widget). Regards, --Gary I like version 11 a lot. I would go with that one. Thanks a lot Gary for providing us with so much dog (not related to kennel) food, No problem – but thank goodness you didn't need an icon for a bike shed ;) Regards, --Gary Thanks! We are there finally! Thanks for all your sketches and ideas. Pushed the icon to master of sugar-artwork after branching off 0.90. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] any patches for 0.90.1?
On Mon, Oct 4, 2010 at 21:05, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Mon Oct 04 19:48:36 +0200 2010: Can submitters reply to their own messages for those that are intended to go in before we branch? This patch of mine is a bug fix and should go into 0.90.1: [sugar] fix recognition of JEBs outside of data store [1] These patches fix breakages on a HAL-free system (does F14 still ship HAL?): [sugar] battery frame device: replace HAL with UPower [2] [Read] don't break if HAL is not available [3] We don't have tickets for any of these? I think at this point we should be still focusing on fixing regressions. If they are enhancements or fixes for things that had already been broken, then I think they could land in 0.90 just after we make the first bugfix release. If you'd like I can bump the threads, but maybe you like Patchwork even better. ;) Actually, the value I saw in Patchwork was submitters (and others) helping me manage my queue by assigning me patches to review, but that doesn't seem going to happen :( Regards, Tomeu All other patches I posted are for 0.92. Sascha [1] https://patchwork.sugarlabs.org/patch/169/ [2] https://patchwork.sugarlabs.org/patch/134/ [3] https://patchwork.sugarlabs.org/patch/27/ -- 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Fix running multiple instances of Browse by adapting to API changes #2404
On 10/05/2010 04:54 PM, Tomeu Vizoso wrote:
* sugar/presence/presenceservice.py: Specify the D-Bus interface when
calling ActivityProperties.GetActivity
* sugar/activity/main.py: Set a default for the --invite option and
make the create() D-Bus method accept a{sv} so we can pass the
boolean value.
Patch looks good to me - and as well fixes the issue. Please go ahead.
Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Don't emit buddy-removed if we don't know yet its contact-id #2402
On 10/04/2010 07:50 PM, Tomeu Vizoso wrote: On Mon, Oct 4, 2010 at 19:42, Tomeu Vizosotomeu.viz...@collabora.co.uk wrote: Otherwise the owner icon is removed from the neighborhood view Requesting inclusion in 0.90. Thanks, Tomeu Looks good, please go ahead. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Adding a test case for 0.90.1 fixes
Hi, I would like to ask submitters of a patch for a fix targeted at 0.90.1 [1] to add a simple test case to the ticket with the following format: |test case| * open Browse * go to page sugarlabs.org --- the page is rendered in yellow at the top Please use a comment field for the test case. We think that this will help testers to verify a fix in a build. After a fix is in git the submitter can still close the ticket. Testers are encouraged to leave a positive comment when verified as working or reopen the ticket if it did not work for them. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] coping with the traffic in sugar-devel
On 5 Oct 2010, at 12:05, Bernie Innocenti wrote: On Tue, 2010-10-05 at 11:19 +0200, Tomeu Vizoso wrote: What about marking in some way those incoming emails that belong to a thread that has included the word 'bernie'? That's really hard... Procmail, my email sorting software, is stateless. There's also the option of just going through the subjects, read the threads that look interesting then marking all of them as read when finished. That's better, but it adds delay: I open my mailing list folders to check for new mail only once in a while, when I'm done with everything else. I'm starting a new thread about this because I often hear from people who have missed important developments because cannot cope with the traffic. I'm also on way more lists that I can read, but with a bit of automatic labelling and organization I think I manage to miss little of the relevant info. Any other tips? Just mucking around with a quick hack, how about this? It's a SOM for the month of Sept of every email from iaep, dextrose, and sugar-devel that mentioned bernie (including emails from bernie). That's about ~1171 emails filtered down to ~171 that mentioned bernie and mapped. I dialled up the number of top features from the usual 200 terms to 400 for a little more textual depth: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-bernie.png And just for comparison and so I'm not picking on Bernie, here's the same thing for gary: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-gary.png I could do this for any keyword (the more unique the better), so it would be easy to perhaps map etoys or some other term a summary map might be of interest, also easy to include more mail-lists into the data set. Regards, --Gary Cc'ing people conservatively is standard practice on many high-traffic lists. Today the old arguments of wasted bandwidth are just ridiculous. Occasionally someone complains for receiving dupes, but all modern MUAs provide ways to suppress them. Sascha elegantly solved the issue by setting the Mail-followup-to header to exclude himself from replies (if the remote MUA supports it). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] coping with the traffic in sugar-devel
On Tue, Oct 5, 2010 at 12:01 PM, Gary Martin garycmar...@googlemail.com wrote: On 5 Oct 2010, at 12:05, Bernie Innocenti wrote: On Tue, 2010-10-05 at 11:19 +0200, Tomeu Vizoso wrote: What about marking in some way those incoming emails that belong to a thread that has included the word 'bernie'? That's really hard... Procmail, my email sorting software, is stateless. There's also the option of just going through the subjects, read the threads that look interesting then marking all of them as read when finished. That's better, but it adds delay: I open my mailing list folders to check for new mail only once in a while, when I'm done with everything else. I'm starting a new thread about this because I often hear from people who have missed important developments because cannot cope with the traffic. I'm also on way more lists that I can read, but with a bit of automatic labelling and organization I think I manage to miss little of the relevant info. Any other tips? Just mucking around with a quick hack, how about this? It's a SOM for the month of Sept of every email from iaep, dextrose, and sugar-devel that mentioned bernie (including emails from bernie). That's about ~1171 emails filtered down to ~171 that mentioned bernie and mapped. I dialled up the number of top features from the usual 200 terms to 400 for a little more textual depth: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-bernie.png And just for comparison and so I'm not picking on Bernie, here's the same thing for gary: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-gary.png I could do this for any keyword (the more unique the better), so it would be easy to perhaps map etoys or some other term a summary map might be of interest, also easy to include more mail-lists into the data set. Regards, --Gary Cc'ing people conservatively is standard practice on many high-traffic lists. Today the old arguments of wasted bandwidth are just ridiculous. Occasionally someone complains for receiving dupes, but all modern MUAs provide ways to suppress them. Sascha elegantly solved the issue by setting the Mail-followup-to header to exclude himself from replies (if the remote MUA supports it). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel fun!! when will be be able to click on the words and go to the email message in the archive :) -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.90.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.90.1.tar.bz2 == News == * Fix running multiple instances of Browse by adapting to API changes #2404 (Tomeu Vizoso) * Cast floats to ints before calling cairo.ImageSurface() #2291 (Tomeu Vizoso) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.90.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.90.2.tar.bz2 == News == * Don't emit buddy-removed if we don't know yet its contact-id #2402 (Tomeu Vizoso) * Don't emit buddy-removed and activity-removed before they have announced #2401 (Tomeu Vizoso) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] coping with the traffic in sugar-devel
On 5 Oct 2010, at 17:05, Walter Bender wrote: On Tue, Oct 5, 2010 at 12:01 PM, Gary Martin garycmar...@googlemail.com wrote: On 5 Oct 2010, at 12:05, Bernie Innocenti wrote: On Tue, 2010-10-05 at 11:19 +0200, Tomeu Vizoso wrote: What about marking in some way those incoming emails that belong to a thread that has included the word 'bernie'? That's really hard... Procmail, my email sorting software, is stateless. There's also the option of just going through the subjects, read the threads that look interesting then marking all of them as read when finished. That's better, but it adds delay: I open my mailing list folders to check for new mail only once in a while, when I'm done with everything else. I'm starting a new thread about this because I often hear from people who have missed important developments because cannot cope with the traffic. I'm also on way more lists that I can read, but with a bit of automatic labelling and organization I think I manage to miss little of the relevant info. Any other tips? Just mucking around with a quick hack, how about this? It's a SOM for the month of Sept of every email from iaep, dextrose, and sugar-devel that mentioned bernie (including emails from bernie). That's about ~1171 emails filtered down to ~171 that mentioned bernie and mapped. I dialled up the number of top features from the usual 200 terms to 400 for a little more textual depth: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-bernie.png And just for comparison and so I'm not picking on Bernie, here's the same thing for gary: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-gary.png I could do this for any keyword (the more unique the better), so it would be easy to perhaps map etoys or some other term a summary map might be of interest, also easy to include more mail-lists into the data set. Here's one for the Etoys keyword: http://people.sugarlabs.org/garycmartin/2010-Sept-dev-dex-iaep-som-etoys.png Cc'ing people conservatively is standard practice on many high-traffic lists. Today the old arguments of wasted bandwidth are just ridiculous. Occasionally someone complains for receiving dupes, but all modern MUAs provide ways to suppress them. Sascha elegantly solved the issue by setting the Mail-followup-to header to exclude himself from replies (if the remote MUA supports it). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel fun!! when will be be able to click on the words and go to the email message in the archive :) I'm procrastinating on the implementation :) but now that the wiki supports image maps, that is likely the easy, if not most graceful/elegant, route**. Clicking on a word would link to the N emails where the term was used. ** really this should be a nice dynamic/interactive map web app, where the text labels are added dynamically over the contour map images, with panning/zooming/search/filter type features... And the ability for admins to add in new data resources to be mapped :) Regards, --Gary -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] sugar-0.90.2
https://admin.fedoraproject.org/updates/sugar-0.90.2-1.fc14,sugar-toolkit-0.90.1-1.fc14 Submitted the usual call for testers please :-) Peter On Tue, Oct 5, 2010 at 5:14 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.90.2.tar.bz2 == News == * Don't emit buddy-removed if we don't know yet its contact-id #2402 (Tomeu Vizoso) * Don't emit buddy-removed and activity-removed before they have announced #2401 (Tomeu Vizoso) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH v4 sugar] Shutdown (and Logout) menuitems should activate
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() +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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home button in browse - toolbar images
The house icon was a mistake, I didn't used the last, but to see the distribution it's the same. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Home button in browse - toolbar images
On Tue, Oct 5, 2010 at 3:32 PM, Gonzalo Odiard gonz...@laptop.org wrote: Gary: Here are the screenshots. I comented a check of cairo version to add the tabs button. toolbar-browse-0.90.png and toolbar-browse-0.84.png are with the emulator at 1200x900 browse-90-in-sugar-emulator.png and browse-90-in-emulator-without-tabs.png are the worst case, sugar-emulator by default. I don't know if is a real case. Regards Gonzalo Perhaps the view sub-toolbar icons could be transferred to left side on the Activity sub-toolbar to make more space on the primary toolbar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] fix #2383 - Browse: history not right when resuming
From: Gonzalo Odiard godi...@sugarlabs.org
Previously Browse does not saved the current tabs opened, saved
the history and assumes the last url in the history is the current.
V1 - V2 : load_urls is a private method now, and create a function
to eliminate duplicated code
---
browser.py | 16 ++--
webactivity.py | 25 +
webtoolbar.py |4 +---
3 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/browser.py b/browser.py
index ece81d1..8e1dab5 100644
--- a/browser.py
+++ b/browser.py
@@ -252,12 +252,7 @@ class TabLabel(gtk.HBox):
browser.connect('notify::title', self.__title_changed_cb)
def __location_changed_cb(self, progress_listener, pspec):
-uri = progress_listener.location
-cls = components.classes['@mozilla.org/intl/texttosuburi;1']
-texttosuburi = cls.getService(interfaces.nsITextToSubURI)
-ui_uri = texttosuburi.unEscapeURIForUI(uri.originCharset, uri.spec)
-
-self._label.set_text(ui_uri)
+
self._label.set_text(self._browser.get_url_from_nsiuri(progress_listener.location))
def __title_changed_cb(self, browser, pspec):
self._label.set_text(browser.props.title)
@@ -300,6 +295,15 @@ class Browser(WebView):
self.emit('is-setup')
+
+def get_url_from_nsiuri(self, uri):
+
+get a nsIURI object and return a string with the url
+
+cls = components.classes['@mozilla.org/intl/texttosuburi;1']
+texttosuburi = cls.getService(interfaces.nsITextToSubURI)
+return texttosuburi.unEscapeURIForUI(uri.originCharset, uri.spec)
+
def get_session(self):
return sessionstore.get_session(self)
diff --git a/webactivity.py b/webactivity.py
index bba1032..1bc0439 100644
--- a/webactivity.py
+++ b/webactivity.py
@@ -423,6 +423,19 @@ class WebActivity(activity.Activity):
'list of multiple uris by now.')
else:
self._tabbed_view.props.current_browser.load_uri(file_path)
+self._load_urls()
+
+def _load_urls(self):
+if self.model.data['currents'] != None:
+first = True
+for current_tab in self.model.data['currents']:
+if first:
+browser = self._tabbed_view.current_browser
+first = False
+else:
+browser = Browser()
+self._tabbed_view._append_tab(browser)
+browser.load_uri(current_tab['url'])
def write_file(self, file_path):
if not self.metadata['mime_type']:
@@ -439,6 +452,13 @@ class WebActivity(activity.Activity):
self.model.data['history'] = self._tabbed_view.get_session()
self.model.data['current_tab'] =
self._tabbed_view.get_current_page()
+self.model.data['currents'] = []
+for n in range(0, self._tabbed_view.get_n_pages()):
+n_browser = self._tabbed_view.get_nth_page(n)
+if n_browser != None:
+ui_uri =
browser.get_url_from_nsiuri(browser.progress.location)
+
self.model.data['currents'].append({'title':browser.props.title,'url':ui_uri})
+
f = open(file_path, 'w')
try:
logging.debug('## writing %s' % self.model.serialize())
@@ -491,10 +511,7 @@ class WebActivity(activity.Activity):
''' take screenshot and add link info to the model '''
browser = self._tabbed_view.props.current_browser
-uri = browser.progress.location
-cls = components.classes['@mozilla.org/intl/texttosuburi;1']
-texttosuburi = cls.getService(components.interfaces.nsITextToSubURI)
-ui_uri = texttosuburi.unEscapeURIForUI(uri.originCharset, uri.spec)
+ui_uri = browser.get_url_from_nsiuri(browser.progress.location)
for link in self.model.data['shared_links']:
if link['hash'] == sha.new(ui_uri).hexdigest():
diff --git a/webtoolbar.py b/webtoolbar.py
index 69a3c8e..032ca96 100644
--- a/webtoolbar.py
+++ b/webtoolbar.py
@@ -366,9 +366,7 @@ class PrimaryToolbar(ToolbarBox):
def _set_address(self, uri):
if uri is not None:
-cls = components.classes['@mozilla.org/intl/texttosuburi;1']
-texttosuburi = cls.getService(interfaces.nsITextToSubURI)
-ui_uri = texttosuburi.unEscapeURIForUI(uri.originCharset, uri.spec)
+ui_uri = self._browser.get_url_from_nsiuri(uri)
else:
ui_uri = None
self.entry.props.address = ui_uri
--
1.7.2.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
If you're going to use something other than simple integers, I suggest either: a) a string of dotted integers. You should *always* be able to subdivide a release if necessary. Strings like peru belong (in my opinion) in release notes or the name of the activity or anywhere else. They don't tell you anything about version ordering. If the problem is that you can't put a new release between 0 and 1, why are you creating a system that causes the same problem, except between 0.0.0 and 0.0.1? b) use the debian version numbering system *exactly*. It has been shown to work in the real world, and it is well documented. The current proposal is neither (yet). We do not need to burden the world with yet another ad-hoc numbering system. Please build on other people's work instead of re-inventing the wheel. Just because the debian system has features you don't *think* you need (yet) is not a reason to bypass it. There are great benefits to sharing a commons. Of course, my preference is to keep the existing simple integers and solve the version precedence problem in other ways. Perhaps important activities should be encouraged to count by ten when increasing verson numbers -- or perhaps the tight dependency of Browse on a given Sugar version should be fixed. A truely forward-thinking replacement would replace the integer version numbers with a git-style version tree. Just say, this activity replaces the activity bundle with manifest hash abcdef. That is more decentralized, and more accurate. Each activity could/should contain a list of URLs describing the canonical source for both itself (authoritative) and its (say) 10 immediate parents (non-authoritative). This proposal could be elaborated -- and it paves the way for a truely decentralized activity repository, where activities are created *and hosted* by children *on their own machines*. (Isn't this stil the vision of Sugar?) --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
