Re: [Sugar-devel] translating MaMaMedia to spanish
On Thu, Feb 19, 2009 at 04:23, Raúl Gutiérrez Segalés r...@paraguayeduca.org wrote: Hi!, I am working on the deployment of 4000 XOs in Paraguay (south america - just in case!). Teachers here , during their training, have found out about MaMaMedia and would like to use it in Spanish. Is there a translation available or on the way? How can we help? I found your emails in the AUTHORS file at http://dev.laptop.org/git?p=mamamedia/story-builder;a=tree Are you the current maintainer of the activity? Hi Raul There are several MaMaMedia activities: Poll Builder and Story Builder were written by me, and there are also Slider Puzzle, Joke Machine, Jigsaw Puzzle, Flipsticks and Cartoon Builder. Some or all of them are in OLPC's Pootle. I'll do a fresh release of Poll Builder and Story Builder in the near future to include some contributed fixes, and if there are any translation updates they will be included. We can arrange releases of most of the others too - which activity in particular are you referring to? Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] translating MaMaMedia to spanish
Hi Morgan, We at OLPC France are as well interested in contributing to the translation effort into French. So, we will welcome any addition to the Pootle server. Thank you in advance Best regards Samy Quoting Morgan Collett morgan.coll...@gmail.com: On Thu, Feb 19, 2009 at 04:23, Raúl Gutiérrez Segalés r...@paraguayeduca.org wrote: Hi!, I am working on the deployment of 4000 XOs in Paraguay (south america - just in case!). Teachers here , during their training, have found out about MaMaMedia and would like to use it in Spanish. Is there a translation available or on the way? How can we help? I found your emails in the AUTHORS file at http://dev.laptop.org/git?p=mamamedia/story-builder;a=tree Are you the current maintainer of the activity? Hi Raul There are several MaMaMedia activities: Poll Builder and Story Builder were written by me, and there are also Slider Puzzle, Joke Machine, Jigsaw Puzzle, Flipsticks and Cartoon Builder. Some or all of them are in OLPC's Pootle. I'll do a fresh release of Poll Builder and Story Builder in the near future to include some contributed fixes, and if there are any translation updates they will be included. We can arrange releases of most of the others too - which activity in particular are you referring to? Regards Morgan ___ 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] Exception for 'View Source' strings in the sugar component
Hi,
the following patch does fix #360 and #365 and fixes the regression of
being able to store the source in the Journal.
Additions:
_('Instance Source')
_('Activity Bundle Source')
_('View Source')
Those two were present before, so we even could copy the translations we
have for them over. I would be willing to help with that.
_('Keep')
_('Source')
I know it is late in the cycle, but I still would like to add this and
therefore ask for an exception.
Thanks,
Simon
diff --git a/extensions/globalkey/viewsource.py b/extensions/globalkey/viewsource.py
index 3afdc29..11b905e 100644
--- a/extensions/globalkey/viewsource.py
+++ b/extensions/globalkey/viewsource.py
@@ -30,9 +30,11 @@ import gconf
from sugar.graphics import style
from sugar.graphics.icon import Icon
from sugar.graphics.xocolor import XoColor
+from sugar.graphics.menuitem import MenuItem
from sugar.graphics.toolbutton import ToolButton
from sugar.graphics.radiotoolbutton import RadioToolButton
from sugar.bundle.activitybundle import ActivityBundle
+from sugar.datastore import datastore
from sugar import mime
from jarabe.model import shell
@@ -199,7 +201,51 @@ class ViewSource(gtk.Window):
self._selected_file = file_path
else:
self._source_display.file_path = None
+
+class DocumentButton(RadioToolButton):
+__gtype_name__ = 'SugarDocumentButton'
+def __init__(self, file_name, document_path, title):
+RadioToolButton.__init__(self)
+
+self._document_path = document_path
+self._title = title
+self.props.tooltip = _('Instance Source')
+
+client = gconf.client_get_default()
+self._color = client.get_string('/desktop/sugar/user/color')
+icon = Icon(file=file_name,
+icon_size=gtk.ICON_SIZE_LARGE_TOOLBAR,
+xo_color=XoColor(self._color))
+self.set_icon_widget(icon)
+icon.show()
+
+menu_item = MenuItem(_('Keep'))
+icon = Icon(icon_name='document-save', icon_size=gtk.ICON_SIZE_MENU,
+xo_color=XoColor(self._color))
+menu_item.set_image(icon)
+
+menu_item.connect('activate', self.__keep_in_journal_cb)
+self.props.palette.menu.append(menu_item)
+menu_item.show()
+
+def __keep_in_journal_cb(self, menu_item):
+mime_type = mime.get_from_file_name(self._document_path)
+if mime_type == 'application/octet-stream':
+mime_type = mime.get_for_file(self._document_path)
+
+jobject = datastore.create()
+title = _('Source') + ': ' + self._title
+jobject.metadata['title'] = title
+jobject.metadata['keep'] = '0'
+jobject.metadata['buddies'] = ''
+jobject.metadata['preview'] = ''
+jobject.metadata['icon-color'] = self._color
+jobject.metadata['mime_type'] = mime_type
+jobject.metadata['source'] = '1'
+jobject.file_path = self._document_path
+datastore.write(jobject)
+
class Toolbar(gtk.Toolbar):
__gtype_name__ = 'SugarViewSourceToolbar'
@@ -217,19 +263,11 @@ class Toolbar(gtk.Toolbar):
self._add_separator()
-client = gconf.client_get_default()
-color = XoColor(client.get_string('/desktop/sugar/user/color'))
activity_bundle = ActivityBundle(bundle_path)
file_name = activity_bundle.get_icon()
if document_path is not None and os.path.exists(document_path):
-document_button = RadioToolButton()
-icon = Icon(file=file_name,
-icon_size=gtk.ICON_SIZE_LARGE_TOOLBAR,
-xo_color=color)
-document_button.set_icon_widget(icon)
-icon.show()
-document_button.props.tooltip = _('Document')
+document_button = DocumentButton(file_name, document_path, title)
document_button.connect('toggled', self.__button_toggled_cb,
document_path)
self.insert(document_button, -1)
@@ -246,7 +284,7 @@ class Toolbar(gtk.Toolbar):
icon.show()
if document_path is not None:
activity_button.props.group = document_button
-activity_button.props.tooltip = _('Activity')
+activity_button.props.tooltip = _('Activity Bundle Source')
activity_button.connect('toggled', self.__button_toggled_cb,
bundle_path)
self.insert(activity_button, -1)
diff --git a/src/jarabe/view/palettes.py b/src/jarabe/view/palettes.py
index 64637a9..66f49e8 100644
--- a/src/jarabe/view/palettes.py
+++ b/src/jarabe/view/palettes.py
@@ -68,6 +68,12 @@ class CurrentActivityPalette(BasePalette):
# TODO: share-with, keep
+accelerator = ' (Alt+Shift+v)'
+menu_item = MenuItem(_('View Source') + accelerator, 'view-source')
+menu_item.connect('activate',
Re: [Sugar-devel] What should we call it? Addons of Activities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 18, 2009 at 10:24:38PM -0500, Mick Weiss wrote: We do need to take into consideration that not every language has activities, some have actividades or Aktivitäten etc. Is this something that we can support through CNAMEs? The config file may have some odd things w/ this -- but we might be able to use super globals ($_SERVER) - or? Nothing should really be hard coded anyhow. I strongly recommend using redirects instead of aliasing for exact same content. Preferably defined in Apache rather than PHP or similar, so that it is most elegantly done (Apache redirects are declared both in http header and as html page, so the actual redirecting happens faster in modern browsers). Alternatively, localized content could be provided - but that's way more work. Also, I have one other idea... how about someone asks a 6 yr old what they would expect it to be called. They should have 3 votes ;) You'd need to more clearly define it first, I guess ;-) To me, at least, favoring activities over addons is tied to my belief of what it actually makes sense to use it for. Asking an outsider about a name out of the blue would make her/him try imagine on their own what kind of place it would actually become. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdI30ACgkQn7DbMsAkQLhvEgCeMw9hBEa/QbTTgKxHx19Ykzm9 moQAn1viYYZXBOVM+2dVzfKmAutKTdm3 =nHAo -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] git.sugarlabs.org difficulties
2009/2/19 Bernie Innocenti ber...@codewiz.org: Martin Langhoff wrote: On Tue, Feb 17, 2009 at 10:01 AM, Bernie Innocenti ber...@codewiz.org wrote: You should be using gitorious@ rather than vepla...@. Yes, it's awkward, but it's explained somewhere on the repository page. Internally, gitorious dispatches individual users by means of ~/.ssh/authorized_keys. Strange. So you cannot have 2 accounts with the same ssh key? Apparently not. And it also doesn't scale that well with thousands of users. The generated authorized_keys file looks like this: ### START KEY 7 ### command=gitorious bernie,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa B3Nz...gJVNrOZuw== ber...@trinity.develer.com ### END KEY 7 ### ### START KEY 9 ### command=gitorious bernie,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa B3N1...91K6xbIWQ== ber...@daneel.codewiz.org ### END KEY 9 ### That no-agent-forwarding may explain why I'm not able to push from sunjammer when I log in there with ssh -A? Though I would swear I was able last week. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What should we call it? Addons of Activities
2009/2/18 Chris Ball c...@laptop.org: Hi, activities.sugarlabs.org +1 to activities here. Makes it clear and straightforward that it's the place to get Sugar activities, which is what it's for. Agreed, +1 to activities in spite of what I will write below. Since an argument against it is that we want the site to host more than activities, could someone enumerate what sort of things we can imagine putting there that shouldn't go under the activities heading? Extensions like control panel modules, device icons, key handlers, favorite layouts, etc. Right now, these are .py files that the user can drop in /usr/share/sugar/extensions/*/, but in the future I can see them being distributed in bundles along with icons and other resources. But anyway, I don't think that that future possibility should tie us to use the addons name instead of activities, when the latter is much more clear from the user POV. Regards, Tomeu Thanks, - Chris. -- Chris Ball c...@laptop.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] [PATCH] Reduce default emulator resolution to 1024x768
On Thu, Feb 19, 2009 at 12:22:50PM +0100, Bernie Innocenti wrote:
if dimensions is not None:
cmd.append('-screen')
cmd.append(dimensions)
-elif gtk.gdk.screen_width() 1200 or gtk.gdk.screen_height()
900:
+elif gtk.gdk.screen_width() DEFAULT_WIDTH or \
+gtk.gdk.screen_height() DEFAULT_HEIGHT:
cmd.append('-fullscreen')
else:
cmd.append('-screen')
-cmd.append('%dx%d' % (1200, 900))
+cmd.append('%dx%d' % (DEFAULT_WIDTH, DEFAULT_HEIGHT))
Is it on purpose that non-default dimensions can be set (see first three
lines) but for determining whether fullscreen will be used the default
dimensions get examined instead?
Yes, that part isn't changed by the patch and I've wondered about it
before, but not bothered to ask. :)
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 19, 2009 at 12:22:50PM +0100, Bernie Innocenti wrote: This patch seems controversial enough to deserve a public flam^Wreview before hitting gitorious. One possible counterargument for this could be that destabilizing changes should wait until after 0.84. But changing the resolution only affects our test environment, not the production environments. A few of those are *already* using a wide range of display resolutions. The sooner we shake these bugs out of activities, the better experience we provide to our users. +DEFAULT_WIDTH = 1024 +DEFAULT_HEIGHT = 768 How about adjusting that patch to keep old values by default, but provide commandline arguments and perhaps let environment variables overrid default too)? That would avoid surprises, while still allow testing alternate sizes without hacking the code. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdRtwACgkQn7DbMsAkQLj32gCfUzsdCq8EbqwJoobgxzeI2XT9 GxsAoJM8poCYQWWVVfYY6pnn3cdZVDhz =JlK3 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] git.sugarlabs.org difficulties
Tomeu Vizoso wrote: ### START KEY 7 ### command=gitorious bernie,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa B3Nz...gJVNrOZuw== ber...@trinity.develer.com ### END KEY 7 ### ### START KEY 9 ### command=gitorious bernie,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa B3N1...91K6xbIWQ== ber...@daneel.codewiz.org ### END KEY 9 ### That no-agent-forwarding may explain why I'm not able to push from sunjammer when I log in there with ssh -A? No, I think it would prevent your agent on sunjammer to be forwarded to the gitorious machine too (a waste of time since you cannot log anywhere else anyway). Though I would swear I was able last week. Check $SSK_AUTH_SOCK from sunjammer, and try ssh-add -l to ensure that your keys are still available. Works for me. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ 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] What should we call it? Addons of Activities
Ok, Then activities it shall be. Due to the complexity of the code, it uses mod_extensively, The move is going to have to be cold turkey. Steps. 1 . Bernie point activities.sugarlab.org, activities-testing.sugarlabs.org, and activities-devel.sugarlabs.org at sunjammer. 2. I will create the virtual hosts as needed 3. I will create user aslo-devel and move the devel code as needed. 4. I will update the config.php to reflect the changes. As this point activities-devel.sugarlabs.org should be stable. Other also team members can start hacking to make the other changes as necessary. Let the changes stabilize for a day. Friday we can move activities-testing. As soon as we are satisfied with the changes, we can move activities.sugarlabs.org. Activity developer are encouraged to continue adding their activities. Their work is stored in the database which will be unaffected by these changes. david On Fri, Feb 20, 2009 at 3:56 AM, Tomeu Vizoso to...@sugarlabs.org wrote: 2009/2/18 Chris Ball c...@laptop.org: Hi, activities.sugarlabs.org +1 to activities here. Makes it clear and straightforward that it's the place to get Sugar activities, which is what it's for. Agreed, +1 to activities in spite of what I will write below. Since an argument against it is that we want the site to host more than activities, could someone enumerate what sort of things we can imagine putting there that shouldn't go under the activities heading? Extensions like control panel modules, device icons, key handlers, favorite layouts, etc. Right now, these are .py files that the user can drop in /usr/share/sugar/extensions/*/, but in the future I can see them being distributed in bundles along with icons and other resources. But anyway, I don't think that that future possibility should tie us to use the addons name instead of activities, when the latter is much more clear from the user POV. Regards, Tomeu Thanks, - Chris. -- Chris Ball c...@laptop.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] [IAEP] addons.sugarlabs.org is starting to work
On Wed, Feb 18, 2009 at 08:56:41PM -0500, Luke Faraone wrote: Since dependancy installation is not something most children can do, If we reach that point, we've already failed (IMO). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
On Thu, Feb 19, 2009 at 8:21 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote:On Wed, Feb 18, 2009 at 08:56:41PM -0500, Luke Faraone wrote: Since dependancy installation is not something most children can do, If we reach that point, we've already failed (IMO).I meant from an administrative perspective. -- Luke Faraonehttp://luke.faraone.cc signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
On Thu, Feb 19, 2009 at 08:42:16AM -0500, Luke Faraone wrote: Since dependancy installation is not something most children can do, If we reach that point, we've already failed (IMO). I meant from an administrative perspective. -v, please? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Running jhbuild on Debian Unstable and Ubuntu Intrepid
On Thu, Feb 19, 2009 at 11:32:46AM -0200, Andrés Ambrois wrote: sudo chrpath -d \ /usr/lib/python-support/python-gnome2/python2.5/gtk-2.0/gconf.so Some other libraries need to be fixed as well. The following invocation did the trick for me: find /usr/lib/python-support/python-gnome2/python2.5/gtk-2.0 -name *.so | sudo xargs chrpath -d CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ugar-Developers meeting REMINDER (19 February, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
Hi, AGENDA: This Friday is 0.84 Release Candidate 2 [1] - look at the state of the release and talk about outstanding issues. [1] http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap#Schedule See you there, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What should we call it? Addons of Activities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 20, 2009 at 07:21:23AM +1800, David Farning wrote: Ok, Then activities it shall be. Due to the complexity of the code, it uses mod_extensively, The move is going to have to be cold turkey. Wauw, mod_extensively. That indeed sounds complex! :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdaGwACgkQn7DbMsAkQLih4gCeP3FYHRTzNOX7X5SB/B0IZqdV rtUAoJAyK2HmmBIUbuIVtVWPmAChUaRL =OPtu -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What should we call it? Addons of Activities
On Fri, Feb 20, 2009 at 8:10 AM, Jonas Smedegaard d...@jones.dk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 20, 2009 at 07:21:23AM +1800, David Farning wrote: Ok, Then activities it shall be. Due to the complexity of the code, it uses mod_extensively, The move is going to have to be cold turkey. Wauw, mod_extensively. That indeed sounds complex! :-) opps, uses mod_rewrite extensively. Add to think I accuse _you_ of making things overly complicated:) david - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdaGwACgkQn7DbMsAkQLih4gCeP3FYHRTzNOX7X5SB/B0IZqdV rtUAoJAyK2HmmBIUbuIVtVWPmAChUaRL =OPtu -END PGP SIGNATURE- ___ 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] Testing Sugar 0.84, Monday 2/23 and Tuesday 2/24
We're getting close to release of 0.84, and we can still use some focused testing. Testing is a lot more fun, and effective, when you do it with friends. (Collaboration testing absolutely requires it.) So if you have time, *please* join us on Monday and Tuesday. The developers will all show up on freenode, #sugar, at 14 UTC (3pm Central Europe time, 9am Eastern US time), and we'll figure out what most needs testing, and how we can best do it together. I personally plan to be around for a few hours each of these days. We will be testing the latest build of Sugar on a Stick, which Simon and Sebastian will make available very soon. If you're planning on coming, shout out with a +1. :) --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing Sugar 0.84, Monday 2/23 and Tuesday 2/24
I can help on Tuesday. I'm also around this weekend if anyone needs new SoaS images smoke tested ahead of time. On Thu, Feb 19, 2009 at 9:44 AM, Greg Dekoenigsberg g...@redhat.com wrote: We're getting close to release of 0.84, and we can still use some focused testing. Testing is a lot more fun, and effective, when you do it with friends. (Collaboration testing absolutely requires it.) So if you have time, *please* join us on Monday and Tuesday. The developers will all show up on freenode, #sugar, at 14 UTC (3pm Central Europe time, 9am Eastern US time), and we'll figure out what most needs testing, and how we can best do it together. I personally plan to be around for a few hours each of these days. We will be testing the latest build of Sugar on a Stick, which Simon and Sebastian will make available very soon. If you're planning on coming, shout out with a +1. :) --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Testing Sugar 0.84, Monday 2/23 and Tuesday 2/24
+1 Tuesday, and I'll do my best to stop by in between meetings on Monday morning. On Thu, Feb 19, 2009 at 9:44 AM, Greg Dekoenigsberg g...@redhat.com wrote: We're getting close to release of 0.84, and we can still use some focused testing. Testing is a lot more fun, and effective, when you do it with friends. (Collaboration testing absolutely requires it.) So if you have time, *please* join us on Monday and Tuesday. The developers will all show up on freenode, #sugar, at 14 UTC (3pm Central Europe time, 9am Eastern US time), and we'll figure out what most needs testing, and how we can best do it together. I personally plan to be around for a few hours each of these days. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
Jonas Smedegaard wrote: +DEFAULT_WIDTH = 1024 +DEFAULT_HEIGHT = 768 How about adjusting that patch to keep old values by default, but provide commandline arguments and perhaps let environment variables overrid default too)? That would avoid surprises, while still allow testing alternate sizes without hacking the code. We already have a command line argument to change the default size, and few activity authors seem to test with anything but the default. The intention of this change is to surprise them a little. We might even change it every once in a while to catch those who have hard-coded or special-cased the new default in their code. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] production aslo update
No new commits for the production instance of aslo. We will be running some clean.sh and build.sh scripts to update the .mo (translation) files. Yep, that is right, Sayamindu Dasgupta should be able to hook aslo to pootle and make them sing. How cool is that? david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] production aslo update
On Thu, Feb 19, 2009 at 15:59, David Farning dfarn...@sugarlabs.org wrote: No new commits for the production instance of aslo. We will be running some clean.sh and build.sh scripts to update the .mo (translation) files. Yep, that is right, Sayamindu Dasgupta should be able to hook aslo to pootle and make them sing. How cool is that? Very! Is upstream ready to accept our translations? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] production aslo update
On Fri, Feb 20, 2009 at 9:06 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Feb 19, 2009 at 15:59, David Farning dfarn...@sugarlabs.org wrote: No new commits for the production instance of aslo. We will be running some clean.sh and build.sh scripts to update the .mo (translation) files. Update complete. Yep, that is right, Sayamindu Dasgupta should be able to hook aslo to pootle and make them sing. How cool is that? Very! Is upstream ready to accept our translations? Upstream is taking a wait and see approach. If the quality of our translations is good, I see no problem with them being accepted. david Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
On 19.02.2009, at 15:53, Bernie Innocenti wrote: Jonas Smedegaard wrote: +DEFAULT_WIDTH = 1024 +DEFAULT_HEIGHT = 768 How about adjusting that patch to keep old values by default, but provide commandline arguments and perhaps let environment variables overrid default too)? That would avoid surprises, while still allow testing alternate sizes without hacking the code. We already have a command line argument to change the default size, and few activity authors seem to test with anything but the default. The intention of this change is to surprise them a little. We might even change it every once in a while to catch those who have hard-coded or special-cased the new default in their code. No, make it run at a random resolution between 800x600 and the screen resolution. In particular, not only 4x3 ratios. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] resume by default
Hi all, as you may know, we recently added a change to the favorites view that makes easier to resume existing instances instead of always launching new ones. This option is disabled by default and users need to go to a palette and guess what that checkbox serves for. We added that option because the feature was experimental, but now some feel it may be appropriate to make it the only option, because if not the naming alert gets quite annoying in some cases. So, who agrees and who disagrees with changing the favorite view to resume activities by default? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] resume by default
On 2/19/09, Tomeu Vizoso to...@sugarlabs.org wrote: Hi all, as you may know, we recently added a change to the favorites view that makes easier to resume existing instances instead of always launching new ones. This option is disabled by default and users need to go to a palette and guess what that checkbox serves for. We added that option because the feature was experimental, but now some feel it may be appropriate to make it the only option, because if not the naming alert gets quite annoying in some cases. So, who agrees and who disagrees with changing the favorite view to resume activities by default? I personally think the change should be made, but after this release; it is too late in development for such major behavioral changes. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] resume by default
Tomeu Vizoso wrote: Hi all, as you may know, we recently added a change to the favorites view that makes easier to resume existing instances instead of always launching new ones. This option is disabled by default and users need to go to a palette and guess what that checkbox serves for. We added that option because the feature was experimental, but now some feel it may be appropriate to make it the only option, because if not the naming alert gets quite annoying in some cases. So, who agrees and who disagrees with changing the favorite view to resume activities by default? Thanks, Tomeu Resume by default - on by default! Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 19, 2009 at 03:53:41PM +0100, Bernie Innocenti wrote: Jonas Smedegaard wrote: +DEFAULT_WIDTH = 1024 +DEFAULT_HEIGHT = 768 How about adjusting that patch to keep old values by default, but provide commandline arguments and perhaps let environment variables overrid default too)? That would avoid surprises, while still allow testing alternate sizes without hacking the code. We already have a command line argument to change the default size, and few activity authors seem to test with anything but the default. The intention of this change is to surprise them a little. We might even change it every once in a while to catch those who have hard-coded or special-cased the new default in their code. Ok. I understood the surprise provocation part, but was not aware that it was already possible to set size at commandline (stupid me - I see now that it is right there in the non-changed parts of your diff!). I have no strong opinion on your intention to provoke. Sounds like fun to change default size of the environment - you could even switch to a radical new size with each new (unstable) release. :-) Anyway, I would like to try again, hopefully more clear this time, with this related thought of mine: It would be nice if the default - whatever it is, was expressed not inside the code but in a way that it could be changed per machine. I mentioned environment, but even better would be to put it in a config file. Then XOs could adjust from the default 200x4 to their odd default of theirs, Debian could have a complex debconf question at install time asking the admins preferred size for this installation, and whatever. Does it make sense? Do you see the benefit of this? Do you see anything bad about this? Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdenEACgkQn7DbMsAkQLiKlQCfRUYi3Z0Sd7BnnFy73rfv9g4P PaMAoJFSTIeh7+KnW2TJaxlF+JRzqR2o =9G9e -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Exception for 'View Source' strings in the sugar component
Yup, would be nice to get those in if translators agree.
Regards,
Tomeu
2009/2/19 Simon Schampijer si...@schampijer.de:
Hi,
the following patch does fix #360 and #365 and fixes the regression of being
able to store the source in the Journal.
Additions:
_('Instance Source')
_('Activity Bundle Source')
_('View Source')
Those two were present before, so we even could copy the translations we have
for them over. I would be willing to help with that.
_('Keep')
_('Source')
I know it is late in the cycle, but I still would like to add this and
therefore ask for an exception.
Thanks,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
On Thu, Feb 19, 2009 at 03:59:22PM +0100, Bernie Innocenti wrote: Since using Sugar in a window does not actually make sense for users, we might as well change the default of sugar-emulator to go full-screen by default, and make sugar-jhbuild invoke it with the 1024x768 window for developers. Sounds fine, though I'm wondering why regular users would want the extra indirection of Xephyr in the first place. But that's actually a different topic. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Feb 19, 2009 at 03:59:22PM +0100, Bernie Innocenti wrote:
Sascha Silbe wrote:
On Thu, Feb 19, 2009 at 12:22:50PM +0100, Bernie Innocenti wrote:
if dimensions is not None:
cmd.append('-screen')
cmd.append(dimensions)
-elif gtk.gdk.screen_width() 1200 or gtk.gdk.screen_height() 900:
+elif gtk.gdk.screen_width() DEFAULT_WIDTH or \
+gtk.gdk.screen_height() DEFAULT_HEIGHT:
cmd.append('-fullscreen')
else:
cmd.append('-screen')
-cmd.append('%dx%d' % (1200, 900))
+cmd.append('%dx%d' % (DEFAULT_WIDTH, DEFAULT_HEIGHT))
Is it on purpose that non-default dimensions can be set (see first three
lines) but for determining whether fullscreen will be used the default
dimensions get examined instead?
Yes, that part isn't changed by the patch and I've wondered about it
before, but not bothered to ask. :)
Looks like a bug, indeed.
After discussing a little with Tomeu on IRC, it seems that we have two
kind of users for sugar-emulator:
- developers who run it from jhbuild
- very few end users who run it from the desktop menu item
Those we want to bother with this change is of course the developers.
It turns out that some users might actually have been relying on the
implicit switch to full-screen that happens if their desktop is
narrower than 1200 or shorter than 900 pixels.
Since using Sugar in a window does not actually make sense for users,
we might as well change the default of sugar-emulator to go
full-screen by default, and make sugar-jhbuild invoke it with the
1024x768 window for developers.
If it seems likea better strategy, I'll come up with a patch to do this.
Suggestion:
1) Extend size logic to support 0 (fullscreen) and -1 (random)
2) Add configfile parsing (gconf?) of (at least) width and height
3) Set internal defaults (both width and height) to -1
4) Provide sample configfile with defaults set to 0
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmdfaoACgkQn7DbMsAkQLhKEACbB+0It8WMBdEEOlbjUAAPegs8
/y8AoIzTB91lQVg7VcXXL6MjRIRbPp+t
=GTcd
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] design team meeting
Hi, no meeting today? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Exception for 'View Source' strings in the sugar component
Given the feature is a long promised one ;-), and given that at least
some of the strings should appear elsewhere, and given that there is
around 10 more days to go for the final release, I think this can go
in.
+1
-sdg-
On Thu, Feb 19, 2009 at 2:01 PM, Simon Schampijer si...@schampijer.de wrote:
Hi,
the following patch does fix #360 and #365 and fixes the regression of being
able to store the source in the Journal.
Additions:
_('Instance Source')
_('Activity Bundle Source')
_('View Source')
Those two were present before, so we even could copy the translations we
have for them over. I would be willing to help with that.
_('Keep')
_('Source')
I know it is late in the cycle, but I still would like to add this and
therefore ask for an exception.
Thanks,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] resume by default
On 19.02.2009, at 16:16, Tomeu Vizoso wrote: Hi all, as you may know, we recently added a change to the favorites view that makes easier to resume existing instances instead of always launching new ones. This option is disabled by default and users need to go to a palette and guess what that checkbox serves for. We added that option because the feature was experimental, but now some feel it may be appropriate to make it the only option, because if not the naming alert gets quite annoying in some cases. So, who agrees and who disagrees with changing the favorite view to resume activities by default? +1 I had no idea about that hidden checkbox, and without it enabled, the save dialogs are annoying as hell (in particular because they still lack a quit-without-saving button). It's a bit cumbersome to make a new instance though. Maybe alt-click could do that for advanced users? And it's unfortunate the activity icons change their position in the ring, the activities with journal entries seem to sort before the ones without. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] resume by default
On Thu, Feb 19, 2009 at 04:40:15PM +0100, Tomeu Vizoso wrote: On Thu, Feb 19, 2009 at 16:22, Luke Faraone l...@faraone.cc wrote: On 2/19/09, Tomeu Vizoso to...@sugarlabs.org wrote: So, who agrees and who disagrees with changing the favorite view to resume activities by default? +0 I personally think the change should be made, but after this release; it is too late in development for such major behavioral changes. Well, not many people have seen the new UI because we don't have yet an easy way for people to try it out. Indeed. Also, if every UI change takes two releases to get into effect, we are going to slow a lot the rate at which we fix the bigger holes in our user experience. Indeed - now is the time to be bold, when things are changing (and SL isn't doing deployments anyway). Regards, Tomeu Martin pgpEbgHYA8AxY.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 19, 2009 at 11:21:03AM -0500, Luke Faraone wrote: div class=gmail_quoteblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;Anyway, I would like to try again, hopefully more clear this time, withbr this related thought of mine: It would be nice if the default - whateverbr it is, was expressed not inside the code but in a way that it could bebr changed per machine. I mentioned environment, but even better would bebr to put it in a config file. Then XOs could adjust from the defaultbr 200x4 to their odd default of theirs, Debian could have a complexbr debconf question at install time asking the admins preferred size forbr this installation, and whatever./blockquotedivbrKeep in mind that we were talking about changing the defaults in sugar-jhbuild, which is used by developers; users (and debian, which uses sugar-emulator) would see no effect.nbsp; br/div/divbr-- brLuke Faraonebrhttp://luke.faraone.ccbr No. We are talking about patching the script bin/sugar-emulator itself! (please change the setup of your MUA, it is a pain to read) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdjQcACgkQn7DbMsAkQLjsEgCfcPNjxkyrmdE+eYWdUz1CQb+S PQIAnR15Gl5AUjYnPLgGOuNKWTbUGC76 =dO37 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
On 19.02.2009, at 17:21, Luke Faraone wrote: Anyway, I would like to try again, hopefully more clear this time, with this related thought of mine: It would be nice if the default - whatever it is, was expressed not inside the code but in a way that it could be changed per machine. I mentioned environment, but even better would be to put it in a config file. Then XOs could adjust from the default 200x4 to their odd default of theirs, Debian could have a complex debconf question at install time asking the admins preferred size for this installation, and whatever. Keep in mind that we were talking about changing the defaults in sugar-jhbuild, which is used by developers; users (and debian, which uses sugar-emulator) would see no effect. Not quite, jhbuild uses sugar-emulator too. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
On Thu, Feb 19, 2009 at 17:47, Bert Freudenberg b...@freudenbergs.de wrote: On 19.02.2009, at 17:21, Luke Faraone wrote: Anyway, I would like to try again, hopefully more clear this time, with this related thought of mine: It would be nice if the default - whatever it is, was expressed not inside the code but in a way that it could be changed per machine. I mentioned environment, but even better would be to put it in a config file. Then XOs could adjust from the default 200x4 to their odd default of theirs, Debian could have a complex debconf question at install time asking the admins preferred size for this installation, and whatever. Keep in mind that we were talking about changing the defaults in sugar-jhbuild, which is used by developers; users (and debian, which uses sugar-emulator) would see no effect. Not quite, jhbuild uses sugar-emulator too. Wasn't at some point proposed to only modify ./sugar-jhbuild run to call sugar-emulator with a smaller resolution? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
On Thu, Feb 19, 2009 at 18:18, Carol Farlow Lerche c...@msbit.com wrote: How does the Mozilla add-on functionality decide if there is a version or platform conflict for browser add-ons? it must be a piece of the browser that does this via some interaction with data on the server. Shouldn't there be a similar process here? It is frustrating to download something (which can be a problem with bad/intermittent connectivity) only to find that you can't use it. Addons allow the uploader to specify for which versions of the platform that addon will work with, and editors do test on those platforms before the addon is available to the general public. Regards, Tomeu On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd wad...@gmail.com wrote: On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso to...@sugarlabs.org wrote: A long time ago, when using bundles was decided as necessary, the idea was that there would be something called the Sugar platform that would specify every component that an activity author can rely on being available for their activities to use. That would include etoys, csound, pygame, glibc, gtk, and any other components on which the sugar shell may not depend but activities can expect to be there. I've been part of this discussion a couple of times now and to me it seems like the original vision is pretty much the right way to go. As an activity author I love the simplicity of activity bundles just being ZIP files. Everything on which an activity depends and isn't part of the platform should be bundled inside the .xo. Aside from this point! Some dependencies are simply too complex to bundle, and can introduce conflicts with the host system. Aleksey proposed adding a simple depencencies line to activity.info. This would be parsed by Sugar in a distribution specific manner by a running 'sugar-check-dependencies' script that could be provided by each distribution. We would define our own set of dependency names and manually map them to each distro that we package for. For example, a 3D activity which used OpenGL could list dependencies = opengl, and then the various distributions could handle that as needed in the script. If the system does not contain the required dependencies for an activity, in my opinion Sugar should prompt the user to install the dependencies and then not launch the activity. Best, Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
On Thu, Feb 19, 2009 at 18:23, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Feb 19, 2009 at 18:18, Carol Farlow Lerche c...@msbit.com wrote: How does the Mozilla add-on functionality decide if there is a version or platform conflict for browser add-ons? it must be a piece of the browser that does this via some interaction with data on the server. Shouldn't there be a similar process here? It is frustrating to download something (which can be a problem with bad/intermittent connectivity) only to find that you can't use it. Addons allow the uploader to specify for which versions of the platform that addon will work with, and editors do test on those platforms before the addon is available to the general public. Oh, also users can review addons and rate then. Tomeu Regards, Tomeu On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd wad...@gmail.com wrote: On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso to...@sugarlabs.org wrote: A long time ago, when using bundles was decided as necessary, the idea was that there would be something called the Sugar platform that would specify every component that an activity author can rely on being available for their activities to use. That would include etoys, csound, pygame, glibc, gtk, and any other components on which the sugar shell may not depend but activities can expect to be there. I've been part of this discussion a couple of times now and to me it seems like the original vision is pretty much the right way to go. As an activity author I love the simplicity of activity bundles just being ZIP files. Everything on which an activity depends and isn't part of the platform should be bundled inside the .xo. Aside from this point! Some dependencies are simply too complex to bundle, and can introduce conflicts with the host system. Aleksey proposed adding a simple depencencies line to activity.info. This would be parsed by Sugar in a distribution specific manner by a running 'sugar-check-dependencies' script that could be provided by each distribution. We would define our own set of dependency names and manually map them to each distro that we package for. For example, a 3D activity which used OpenGL could list dependencies = opengl, and then the various distributions could handle that as needed in the script. If the system does not contain the required dependencies for an activity, in my opinion Sugar should prompt the user to install the dependencies and then not launch the activity. Best, Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
How does the Mozilla add-on functionality decide if there is a version or platform conflict for browser add-ons? it must be a piece of the browser that does this via some interaction with data on the server. Shouldn't there be a similar process here? It is frustrating to download something (which can be a problem with bad/intermittent connectivity) only to find that you can't use it. On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd wad...@gmail.com wrote: On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso to...@sugarlabs.org wrote: A long time ago, when using bundles was decided as necessary, the idea was that there would be something called the Sugar platform that would specify every component that an activity author can rely on being available for their activities to use. That would include etoys, csound, pygame, glibc, gtk, and any other components on which the sugar shell may not depend but activities can expect to be there. I've been part of this discussion a couple of times now and to me it seems like the original vision is pretty much the right way to go. As an activity author I love the simplicity of activity bundles just being ZIP files. Everything on which an activity depends and isn't part of the platform should be bundled inside the .xo. Aside from this point! Some dependencies are simply too complex to bundle, and can introduce conflicts with the host system. Aleksey proposed adding a simple depencencies line to activity.info. This would be parsed by Sugar in a distribution specific manner by a running 'sugar-check-dependencies' script that could be provided by each distribution. We would define our own set of dependency names and manually map them to each distro that we package for. For example, a 3D activity which used OpenGL could list dependencies = opengl, and then the various distributions could handle that as needed in the script. If the system does not contain the required dependencies for an activity, in my opinion Sugar should prompt the user to install the dependencies and then not launch the activity. Best, Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] resume by default
On Thu, Feb 19, 2009 at 12:17 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Feb 19, 2009 at 18:12, Eduardo H. Silva hoboprim...@gmail.com wrote: I agree with this change. And I think it is a good idea to then make the fresh instance alert go away. This way, if a user commonly uses an activitiy which he doesn't bother to name or describe, he keeps using the same activity instance, thus not cluttering the journal. Yup, I expect people to appreciate this effect. +1 - although the sorting should be fixed. I posted a criticism of this feature earlier this year at the link below (which I'd love to have feedback from the DesignTeam about), but I agree that it's better than what exists now. http://wiki.laptop.org/go/User:Wade/Ideas/Activity_Management Cheers, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] resume by default
On Thu, Feb 19, 2009 at 18:29, Wade Brainerd wad...@gmail.com wrote: On Thu, Feb 19, 2009 at 12:17 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Feb 19, 2009 at 18:12, Eduardo H. Silva hoboprim...@gmail.com wrote: I agree with this change. And I think it is a good idea to then make the fresh instance alert go away. This way, if a user commonly uses an activitiy which he doesn't bother to name or describe, he keeps using the same activity instance, thus not cluttering the journal. Yup, I expect people to appreciate this effect. +1 - although the sorting should be fixed. Entered a ticket about it: http://dev.sugarlabs.org/ticket/387 Tomeu I posted a criticism of this feature earlier this year at the link below (which I'd love to have feedback from the DesignTeam about), but I agree that it's better than what exists now. http://wiki.laptop.org/go/User:Wade/Ideas/Activity_Management Cheers, Wade ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
Is it possible to just make the Sugar emulator resizable during runtime? I know I spend a lot of time fixing my activities for the XO's Rotate Screen key which is a bit different than just starting up in a different resolution. Best, Wade On Thu, Feb 19, 2009 at 12:21 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Feb 19, 2009 at 17:47, Bert Freudenberg b...@freudenbergs.de wrote: On 19.02.2009, at 17:21, Luke Faraone wrote: Anyway, I would like to try again, hopefully more clear this time, with this related thought of mine: It would be nice if the default - whatever it is, was expressed not inside the code but in a way that it could be changed per machine. I mentioned environment, but even better would be to put it in a config file. Then XOs could adjust from the default 200x4 to their odd default of theirs, Debian could have a complex debconf question at install time asking the admins preferred size for this installation, and whatever. Keep in mind that we were talking about changing the defaults in sugar-jhbuild, which is used by developers; users (and debian, which uses sugar-emulator) would see no effect. Not quite, jhbuild uses sugar-emulator too. Wasn't at some point proposed to only modify ./sugar-jhbuild run to call sugar-emulator with a smaller resolution? 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] [IAEP] addons.sugarlabs.org is starting to work
After looking around I still can't find an automatic way to determine which distribution/packaging universe a machine is in. /etc/*version gives a somewhat useful but somewhat lying answer on my Ubuntu platform. It seems an obvious thing to have uname report, but no go. What have I missed? On Thu, Feb 19, 2009 at 9:41 AM, David Farning dfarn...@sugarlabs.orgwrote: On Fri, Feb 20, 2009 at 11:18 AM, Carol Farlow Lerche c...@msbit.com wrote: How does the Mozilla add-on functionality decide if there is a version or platform conflict for browser add-ons? it must be a piece of the browser that does this via some interaction with data on the server. Shouldn't there be a similar process here? It is frustrating to download something (which can be a problem with bad/intermittent connectivity) only to find that you can't use it. Your browser reports information on the OS and browser version to aslo. A developer can select which OS and browser version for which they want the activity to work. My guess is that we will either need to pin a specific version of browse to a os release or else have browse report OS information. BTW, amo, which we call aslo, also handles all of the messaging passing for firefox to update itself daily. The hooks are there. We just need to figure out how we want to use them. david On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd wad...@gmail.com wrote: On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso to...@sugarlabs.org wrote: A long time ago, when using bundles was decided as necessary, the idea was that there would be something called the Sugar platform that would specify every component that an activity author can rely on being available for their activities to use. That would include etoys, csound, pygame, glibc, gtk, and any other components on which the sugar shell may not depend but activities can expect to be there. I've been part of this discussion a couple of times now and to me it seems like the original vision is pretty much the right way to go. As an activity author I love the simplicity of activity bundles just being ZIP files. Everything on which an activity depends and isn't part of the platform should be bundled inside the .xo. Aside from this point! Some dependencies are simply too complex to bundle, and can introduce conflicts with the host system. Aleksey proposed adding a simple depencencies line to activity.info. This would be parsed by Sugar in a distribution specific manner by a running 'sugar-check-dependencies' script that could be provided by each distribution. We would define our own set of dependency names and manually map them to each distro that we package for. For example, a 3D activity which used OpenGL could list dependencies = opengl, and then the various distributions could handle that as needed in the script. If the system does not contain the required dependencies for an activity, in my opinion Sugar should prompt the user to install the dependencies and then not launch the activity. Best, Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
On Fri, Feb 20, 2009 at 11:58 AM, Carol Farlow Lerche c...@msbit.com wrote: After looking around I still can't find an automatic way to determine which distribution/packaging universe a machine is in. /etc/*version gives a somewhat useful but somewhat lying answer on my Ubuntu platform. It seems an obvious thing to have uname report, but no go. What have I missed? This is one of the key issues that distribution package maintainers run into with Mozilla products. Talking loosely, Mozilla addons and Mozilla plug-ins are different. An addon implies that the 'thing' will run inside the walls of what Mozilla promises to provide. A plugin needs to interact with bits outside the walled Mozilla garden. As an example 'add-blocker' is an addon, while Flash is a plugin. Linux distributions must package plugins which are installed via the distro package management system because then need to be installed as root. On the other hand, addons can be grabbed and installed via addons.mozilla.org because they are installed in the .mozilla dir by the user. As we move forward we are going to have to establish what is inside the walled garden for sugar and what is outside. But, to be honest, we are probably 3-6 months away from making those decisions. It is going to take a healthy dose of feedback from the distributions about best practices. david On Thu, Feb 19, 2009 at 9:41 AM, David Farning dfarn...@sugarlabs.org wrote: On Fri, Feb 20, 2009 at 11:18 AM, Carol Farlow Lerche c...@msbit.com wrote: How does the Mozilla add-on functionality decide if there is a version or platform conflict for browser add-ons? it must be a piece of the browser that does this via some interaction with data on the server. Shouldn't there be a similar process here? It is frustrating to download something (which can be a problem with bad/intermittent connectivity) only to find that you can't use it. Your browser reports information on the OS and browser version to aslo. A developer can select which OS and browser version for which they want the activity to work. My guess is that we will either need to pin a specific version of browse to a os release or else have browse report OS information. BTW, amo, which we call aslo, also handles all of the messaging passing for firefox to update itself daily. The hooks are there. We just need to figure out how we want to use them. david On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd wad...@gmail.com wrote: On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso to...@sugarlabs.org wrote: A long time ago, when using bundles was decided as necessary, the idea was that there would be something called the Sugar platform that would specify every component that an activity author can rely on being available for their activities to use. That would include etoys, csound, pygame, glibc, gtk, and any other components on which the sugar shell may not depend but activities can expect to be there. I've been part of this discussion a couple of times now and to me it seems like the original vision is pretty much the right way to go. As an activity author I love the simplicity of activity bundles just being ZIP files. Everything on which an activity depends and isn't part of the platform should be bundled inside the .xo. Aside from this point! Some dependencies are simply too complex to bundle, and can introduce conflicts with the host system. Aleksey proposed adding a simple depencencies line to activity.info. This would be parsed by Sugar in a distribution specific manner by a running 'sugar-check-dependencies' script that could be provided by each distribution. We would define our own set of dependency names and manually map them to each distro that we package for. For example, a 3D activity which used OpenGL could list dependencies = opengl, and then the various distributions could handle that as needed in the script. If the system does not contain the required dependencies for an activity, in my opinion Sugar should prompt the user to install the dependencies and then not launch the activity. Best, Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] [PATCH] Reduce default emulator resolution to 1024x768
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 19, 2009 at 12:36:26PM -0500, Wade Brainerd wrote: Is it possible to just make the Sugar emulator resizable during runtime? I know I spend a lot of time fixing my activities for the XO's Rotate Screen key which is a bit different than just starting up in a different resolution. Don't know, but it seems Xephyr supports xrandr. This related discussion might be relevant: http://butterfeet.org/?p=26 - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdpyQACgkQn7DbMsAkQLg31QCaAseUiEUEp4E4tqGeNF4JHeER i7kAoJbj8t4VYbVEvdsno/lnOzB4TAvK =Xjn9 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Testing Sugar 0.84, Monday 2/23 and Tuesday 2/24
On Thu, Feb 19, 2009 at 9:44 AM, Greg Dekoenigsberg g...@redhat.com wrote: We're getting close to release of 0.84, and we can still use some focused testing. Testing is a lot more fun, and effective, when you do it with friends. (Collaboration testing absolutely requires it.) So if you have time, *please* join us on Monday and Tuesday. The developers will all show up on freenode, #sugar, at 14 UTC (3pm Central Europe time, 9am Eastern US time), and we'll figure out what most needs testing, and how we can best do it together. I personally plan to be around for a few hours each of these days. We're going to be testing Ubuntu's Jaunty Sugar packages and fixing bugs this saturday: http://olpclearningclub.org/meetings/learning-learning-on-a-stick/ -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] resume by default
On 19 Feb 2009, at 15:23, Simon Schampijer wrote: Tomeu Vizoso wrote: Hi all, as you may know, we recently added a change to the favorites view that makes easier to resume existing instances instead of always launching new ones. This option is disabled by default and users need to go to a palette and guess what that checkbox serves for. We added that option because the feature was experimental, but now some feel it may be appropriate to make it the only option, because if not the naming alert gets quite annoying in some cases. So, who agrees and who disagrees with changing the favorite view to resume activities by default? Thanks, Tomeu Resume by default - on by default! +1 The icon rollover high-light isn't quite as pretty yet :-p in resume mode, but the utility of the change is otherwise good. I must admit, I do have this underlying urge to be able to create 'new' fresh blank activity from an already instanced activity (I know... this isn't the model)... I noticed it with my 2 nieces 1 nephew (7-10yrs) last month. They would have a go at say painting, then want to paint something new. Trying to: 1) show them how to find the stop button (often hidden in a different tab) 2) get them back to the home view (and not the Journal) 3) get them to start a new paint activity (and wait) Was quite a challenge (I don't think I really succeeded). The two youngest both learnt how to make a large white brush and start painting out their last picture, ready to start again, they didn't managed to get the hang of changing tabs and using 'edit' - 'clear', even though I pointed it out several times. Not being able to use tabs very well to get to the 'stop' button often meant that when I popped over to see how they were getting on they would have just launched many new instances, all left running in the top frame, each with a different painting. I'm assuming the resume by default would help as they were getting to the home screen, and a click would have jumped them back to their previous painting, 'stop' may have then been something they would have realised they needed to do/learn, UNCLE GARY!! How do I make this painting go away? I want to make another... --Gary Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] Write-62
== Source == http://download.sugarlabs.org/sources/sucrose/fructose/Write/Write-62.tar.bz2 == Fixed tickets == * Initialize gthreads at startup (alsroot) #356 * Updated translations ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] TurtleArt-34
== Source == http://download.sugarlabs.org/sources/sucrose/fructose/TurtleArt/TurtleArt-34.tar.bz2 == Fixed tickets == dev.sugarlabs.org #389: defect: TurtleArt with sensors needs special alsaaudio.so on XO (closed: duplicate) #343: defect: TurtleArt doesn't start on amd64 due to 32bit alsaaudio.so in bundle (closed: fixed) #299: enhancement: Permissions for TAPortfolio samples not set correctly? (closed: fixed) #240: defect: [portfolio] named variables cause errors in += (closed: fixed) #194: defect: turtleart: en.po syntax error, breaks build (closed: fixed) #116: defect: Turtle Art does not open on SoaS-5 (closed: fixed) #102: enhancement: turtleart-activity i18n update dev.laptop.org #9027: defect: turtleart does not start in mongolian (and probably other locales) (closed: fixed) #8711: defect: Sugar-shell burning up cumulative 1-2% of CPU resources after every ... #8589: defect: Can't Journal resume more than one TurtleArt-10 activity at a time, it ... == New features == * Sugar toolbar for all buttons * portfolio panel added * nameable stacks and boxes * inline programmable brick * text and image bricks * keyboard input * cjson for saving project to Journal * slow playback option * Logo and HTML export options * sharing enabled * lots of minor clean up NOTE: It is not recommended to use this version of Turtle Art on pre-Sugar 0.82 releases, e.g., pre-OLPC Build 767 -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] design team meeting (And finding a new regular time)
I wasn't available for a meeting today, so that's partially my fault. I'm trying to get back into the swing of things, though, and actually had the chance to meet with Christian today regarding starting up regular design meetings again. As our work on Sugar will be voluntary, we both feel that selecting a time on the weekends (or perhaps late evening, though naturally timezone complicates this) may allow us to attend regularly as we'd like to. Would this work for others with interest? What days/times would be most suitable for everyone? - Eben On Thu, Feb 19, 2009 at 10:47 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, no meeting today? 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] [IAEP] design team meeting (And finding a new regular time)
I talked to a designer named josh who is doing interesting stuff. see http://sugarlabs.org/go/AddonsPortal/Design Sorry, but I don't remember his email. Goes by y0shu on irc. Another design related would be to standardizing the look and feel of the various Sugar Labs web sites. david On Fri, Feb 20, 2009 at 3:18 PM, Eben Eliason e...@laptop.org wrote: I wasn't available for a meeting today, so that's partially my fault. I'm trying to get back into the swing of things, though, and actually had the chance to meet with Christian today regarding starting up regular design meetings again. As our work on Sugar will be voluntary, we both feel that selecting a time on the weekends (or perhaps late evening, though naturally timezone complicates this) may allow us to attend regularly as we'd like to. Would this work for others with interest? What days/times would be most suitable for everyone? - Eben On Thu, Feb 19, 2009 at 10:47 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, no meeting today? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] webactivity: seed the XS cookie at startup
On Thu, Feb 19, 2009 at 10:08 PM, Simon Schampijer si...@schampijer.de wrote: Ok, I pushed to browse git master now. Do you have a way to test if it is working fine against a schoolserver or should I create you the 0.82 xo bundle? I have a git checkout - but on the 8.2.x so master won't work there. I'm rebasing your patch on the sucrose-0.82 branch to test, replacing gconf calls with profile.foo... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] (no subject)
___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Create a HTTP Cookie to authenticate with the Schoolserver (Martin Langhoff)
From: Martin Langhoff mar...@laptop.org
Re-edit of the patch, based on Simon's merge to master.
---
webactivity.py | 66 +++-
1 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/webactivity.py b/webactivity.py
index e17d3b2..4efa470 100644
--- a/webactivity.py
+++ b/webactivity.py
@@ -1,4 +1,5 @@
# Copyright (C) 2006, Red Hat, Inc.
+# Copyright (C) 2009 Martin Langhoff, Simon Schampijer
#
# 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
@@ -26,7 +27,9 @@ import sha
import base64
import time
import shutil
-
+import sqlite3
+import cjson
+
from sugar.activity import activity
from sugar.graphics import style
import telepathy
@@ -60,6 +63,64 @@ if _profile_version PROFILE_VERSION:
f.write(str(PROFILE_VERSION))
f.close()
+def _seed_xs_cookie():
+''' Create a HTTP Cookie to authenticate with the Schoolserver
+'''
+
+prof = profile.get_profile()
+# profile.jabber_registered is old and buggy
+# - check for jabber_server instead
+if not prof.jabber_server:
+_logger.debug('seed_xs_cookie: not registered yet')
+return
+
+jabber_server = prof.jabber_server
+
+pubkey = profile.get_profile().pubkey
+cookie_data = {'color': profile.get_color().to_string(),
+ 'pkey_hash': sha.new(pubkey).hexdigest()}
+
+db_path = os.path.join(_profile_path, 'cookies.sqlite')
+try:
+cookies_db = sqlite3.connect(db_path)
+c = cookies_db.cursor()
+
+c.execute('''CREATE TABLE IF NOT EXISTS
+ moz_cookies
+ (id INTEGER PRIMARY KEY,
+ name TEXT,
+ value TEXT,
+ host TEXT,
+ path TEXT,
+ expiry INTEGER,
+ lastAccessed INTEGER,
+ isSecure INTEGER,
+ isHttpOnly INTEGER)''')
+
+c.execute('''SELECT id
+ FROM moz_cookies
+ WHERE name=? AND host=? AND path=?''',
+ ('xoid', jabber_server, '/'))
+
+if c.fetchone():
+_logger.debug('seed_xs_cookie: Cookie exists already')
+return
+
+expire = int(time.time()) + 10*365*24*60*60
+c.execute('''INSERT INTO moz_cookies (name, value, host,
+ path, expiry, lastAccessed,
+ isSecure, isHttpOnly)
+ VALUES(?,?,?,?,?,?,?,?)''',
+ ('xoid', cjson.encode(cookie_data), jabber_server,
+ '/', expire, 0, 0, 0 ))
+cookies_db.commit()
+cookies_db.close()
+except sqlite3.Error, e:
+_logger.error('seed_xs_cookie: %s' % e)
+else:
+_logger.debug('seed_xs_cookie: Updated cookie successfully')
+
+
import hulahop
hulahop.set_app_version(os.environ['SUGAR_BUNDLE_VERSION'])
hulahop.startup(_profile_path)
@@ -104,6 +165,8 @@ class WebActivity(activity.Activity):
progresslistener.init(self._browser)
filepicker.init(self)
+_seed_xs_cookie()
+
toolbox = activity.ActivityToolbox(self)
self._edit_toolbar = EditToolbar(self._browser)
@@ -482,3 +545,4 @@ class WebActivity(activity.Activity):
downloadmanager.remove_all_downloads()
self.close(force=True)
+
--
1.5.6.6
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Create a HTTP Cookie to authenticate with the Schoolserver (Martin Langhoff)
On Fri, Feb 20, 2009 at 1:21 PM, martin.langh...@gmail.com wrote: From: Martin Langhoff mar...@laptop.org Re-edit of the patch, based on Simon's merge to master. I cherry-picked Simon's patch, resovled minor conflicts, and edited as follows: - all gconf references are gone - grab jabber_server from the profile obj. - check only jabber server - ignore backup_url I cross-diffed the two patches, and nothing else is happening there. It tests well in sending the cookie to the XS too :-) m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Moon-9, almost (Re: addons.sugarlabs.org is starting to work)
On 18 Feb 2009, at 15:04, Tomeu Vizoso wrote: Hi, as the site is becoming more functional, we are in need of feedback before we direct there the masses. Could activity maintainers register and upload their last activity bundles? Please try to also upload at least one screenshot, the site will be much prettier that way ;) OK giving up for the night :-( I've merged and built a new moon-9 with aslroots very kind addition of resolution independent scaling code, but I can't get it uploaded to a.sl.org, I thought it was a Safari browser issue, so I tested with Firefox as well, but no luck. I get as far as: http://addons.sugarlabs.org/en-US/developers/addon/submit But the 'Get Started' button does nothing. Game over. Any hints welcome, but will need to wait until tomorrow for me wake up and try again. Regards --Gary P.S As a member of the ActivityTeam, I am rather embarrassed to have to ask what I should now do with the Moon-9.tar.bz2 file that fell out the back of ./setup dist_source (couldn't see any ActivityTeam wiki suggestions for how to officially publish Activities other than the links to addons). I'm not officially part of any (confusingly) named, temporally aligned, carbohydrate molecular substrate, but am very happy to provide the source code somewhere formal if it makes distro packager lives easier. Thanks, 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] Moon-9, almost (Re: addons.sugarlabs.org is starting to work)
On Fri, Feb 20, 2009 at 03:48:56AM +, Gary C Martin wrote: P.S As a member of the ActivityTeam, I am rather embarrassed to have to ask what I should now do with the Moon-9.tar.bz2 file that fell out the back of ./setup dist_source (couldn't see any ActivityTeam wiki suggestions for how to officially publish Activities other than the links to addons). I'm not officially part of any (confusingly) named, temporally aligned, carbohydrate molecular substrate, but am very happy to provide the source code somewhere formal if it makes distro packager lives easier. think, the right place for honey activities is: http://download.sugarlabs.org/sources/honey/ http://sugarlabs.org/go/DevelopmentTeam/Activities_packaging#Publish_source_tarballs_for_each_release -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Moon-9, almost (Re: addons.sugarlabs.org is starting to work)
Yeah, it seems like a lot of the buttons on the site do nothing when clicked right now. I just encountered the same problem. On Thu, Feb 19, 2009 at 10:48 PM, Gary C Martin g...@garycmartin.comwrote: On 18 Feb 2009, at 15:04, Tomeu Vizoso wrote: Hi, as the site is becoming more functional, we are in need of feedback before we direct there the masses. Could activity maintainers register and upload their last activity bundles? Please try to also upload at least one screenshot, the site will be much prettier that way ;) OK giving up for the night :-( I've merged and built a new moon-9 with aslroots very kind addition of resolution independent scaling code, but I can't get it uploaded to a.sl.org, I thought it was a Safari browser issue, so I tested with Firefox as well, but no luck. I get as far as: http://addons.sugarlabs.org/en-US/developers/addon/submit But the 'Get Started' button does nothing. Game over. Any hints welcome, but will need to wait until tomorrow for me wake up and try again. Regards --Gary P.S As a member of the ActivityTeam, I am rather embarrassed to have to ask what I should now do with the Moon-9.tar.bz2 file that fell out the back of ./setup dist_source (couldn't see any ActivityTeam wiki suggestions for how to officially publish Activities other than the links to addons). I'm not officially part of any (confusingly) named, temporally aligned, carbohydrate molecular substrate, but am very happy to provide the source code somewhere formal if it makes distro packager lives easier. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
