Re: [Sugar-devel] Sugar and activities flag day
On 09/20/2010 09:46 PM, Walter Bender wrote: On Mon, Sep 20, 2010 at 3:27 PM, Marco Pesenti Grittima...@marcopg.org wrote: On Mon, Sep 20, 2010 at 4:40 PM, Tomeu Vizosoto...@sugarlabs.org wrote: The hackers at #python in GIMPNet have proposed holding a hackfest for porting Sugar to introspection and thus getting PyGObject ready. Who else would be interested from the Sugar side? We'll also need sponsors for travel and venue. Right now Boston, Bolzano and Prague have been mentioned as possibilities. The GNOME Foundation will be able to fund some travel but it will be easier to get that funding if other organizations partner on this one. I might be able to make it if it's in Europe. In the US would probably be more complicated for me. Then can I through Paris into the mix? -walter Berlin might be an option, too. We have conference rooms at buero20 [1] where i have my office atm. I will ask them what the situation is like. Regards, Simon [1] http://www.buero20.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/20/2010 11:10 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Mon Sep 20 12:45:28 +0200 2010: Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. Then we need to extend a.sl.o to host source tarballs as well. Right now activity developers need to either have a sunjammer account or abuse the wiki if they want to publish tarballs. Yes, I think that the tarballs would fit there perfectly well. I think we can live with the increased load of the storage demand for each activity (please correct me if that is wrong). If I remember Aleksey correctly, from a technical point of view this would not be a hard thing to do. If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. Let's hope the subject drew enough attention to make someone actually adjust the wiki. Yes, and thanks for helping discussing this. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Pass the contact-id to the buddy-removed signal instead of the handle #2349
On Mon, Sep 20, 2010 at 22:39, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Mon Sep 20 14:56:04 +0200 2010: --- Would have been nice to note that this is a regression and callers expect the contact_id instead of the handle. At first I was worried that this might break other code, but the patch actually makes the listeners work again. Seems like this bug has been there since the signal was added, but indeed I can make explicit that I'm not changing the signal signature but passing the expected argument. Thanks, Tomeu Reviewed-By: Sascha Silbe sascha-...@silbe.org 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] [PATCH] Added busy cursor when we open any section in control panel. (Ticket #245)
On Mon, Sep 20, 2010 at 22:33, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Ishan Bansal's message of Mon Sep 20 17:36:03 +0200 2010: The sections in control panel should activate busy cursor so that user could be given a impression that their request is in progress. Like for the other patch, please wrap lines so they fit into 80 columns (70-75 for the subject). [src/jarabe/controlpanel/gui.py] @@ -214,11 +214,14 @@ class ControlPanel(gtk.Window): globals(), locals(), ['model']) model = ModelWrapper(mod) + self.get_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH)) + self._section_view = view_class(model, self._options[option]['alerts']) self._set_canvas(self._section_view) self._section_view.show() + self.get_window().set_cursor(None) The cursor shape is global state, so it should be reset in a finally: clause with everything between the two set_cursor() calls in the try: block. There's also the question of which window we want the cursor to be changed. As the CP is modal, would we want it to be on the whole screen? If so, we could add a public method on HomeWindow which would be used here and in the other places where we are changing the cursor. It could also prove handy in debugging wtf the cursor is not coming back to the default shape in the future. Regards, Tomeu 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] [SoaS] Policy for activities for downstream inclusion
On 09/21/2010 03:49 AM, Gary Martin wrote: On 20 Sep 2010, at 22:10, Sascha Silbesascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Mon Sep 20 12:45:28 +0200 2010: Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. Then we need to extend a.sl.o to host source tarballs as well. Right now activity developers need to either have a sunjammer account or abuse the wiki if they want to publish +1 though FWIW the timeline for this is likely to wait until a python port/upgrade of ASLO has happened, perhaps well into next year. Oh? Isn't it just another upload option as we have already for the .xo? If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. Let's hope the subject drew enough attention to make someone actually adjust the wiki. A major point for activity separation from core in my view (and the reason I try to avoid contributing code to Sugar core) is to keep out of, and as far away as possible, from the release cycles. I have no idea what I'll get the chance to work on tomorrow, or next week, even though I keep a detailed todo list. The best I can do is try to shuffle relevant tasks about to try and fit in, but that leaves me working on things inefficiently, and often that I'm least motivated by at the time. But uploading a tarball or not has nothing to do with the release cycle, right? If the packagers know that activities are announced a certain way (ASLO email) they can package the new activities as they see fit. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug No. #1442
On 09/21/2010 03:17 AM, Gary Martin wrote: Hi Shan, On 20 Sep 2010, at 21:54, Shanjit Singh Jajmannshan...@dev.seeta.in wrote: Sir/Ma'am, I am actually facing problem with this particular bug( http://bugs.sugarlabs.org/ticket/1442 ), it would be helpful if a few pointers be provided. Also if someone could elaborate on how to check between sugar / activity Compatibility it would be helpful. This seems a rather hopeful bug to really fix, I'm not clear there is an actual solution. Version support/awareness is currently covered/attempted by a mix of distro/deployment testing and the flags set when an activity maintainer uploads a new activity release to http://activities.sugarlabs.org. I understand the ASLO flagging may not be happening very well after an irc chat with David (dfarning) and have offered to at least try to sweep through 0.82 and flag wrongly categorised activities on ASLO. I try to make the activities I look out for work on _all_ official Sugar releases, though this might have to break at some point given the likely code churn for future 0.92. I do test all my releases on 0.82, 0.84, and a recent Sugar build when available (0.88 usually, 0.90 pre releases are still pretty unstable to do much sane activity release work on other than obvious reported API breaks). I understand it could be possible to introduce a minimal version support value by the developer in the activity.info file, but many activity breaks to my eye are new Sugar/distro releases that break some previously supported feature or dependancy. As an activity developer there is no obvious way to pre guess what features some distro or core Sugar developers may decide to drop in the future. Sorry if that is not much help, there may well be some generic solution, but I don't see it just now — you have a tough bug! Regards, --Gary To make it short, for starting fixing bugs you should probably pick another one if that is not the one you absolutely need to fix. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
On 21.09.2010, at 03:39, Alberto Arruda de Oliveira wrote: Hello, I've been adapting an application to use as an activity, and I have some questions about the way to save on sugar. At first, I tried to just create a directory inside my Activity folder especially made for saving files, but it did not work, because of the access permissions to it, and, although we could simply manually change the folder permission for writing on that folder, we would have to do it for every single OLPC we installed our activity into and we didn't want that. Then, we started trying with the journal. Everything was going fine, until we discovered that another sugar activity, Scratch, implemented saving and loading on a similar fashion we previously wanted. It has a folder inside it's Activity directory with subdirectories related to each kind of Scratch project. Also, Scratch's Activity directory has the same access permission as any other sugar Activity installed. So, my question is, does anyone knows how Scratch implements it's save / loading method? is there any guide explaining how to do it without using the journal? Keep in mind that we do know that there are other directories we could use to save our files, but we would like to use our Activity directory if possible. You cannot. Scratch used to copy all the files from the bundle directory to the writable directory (the data directory in SUGAR_ACTIVITY_ROOT). This happened in its startup wrapper script. It tested for the existence of the copied folder, and if it was not there (that is, the activity was run the first time), did the copying. http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#File_Access As others have pointed out, the newest Scratch version stores into and loads from the Journal. It does not copy from the bundle anymore. For loading examples it still shows the files in the bundle, but they are read-only now. You can only save to the Journal. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
On 21.09.2010, at 04:02, Gary Martin wrote: Sorru, not much help, but my understanding is that Scratch has recently been updated to fix this long standing non-standard Sugar behaviour, and now uses the Journal to store it's state. Removal of explicit Save/Save as dialogues is a specific UI design goal in Sugar. In Scratch, the dialogs have not been removed. The Journal is made to look like any regular folder in Scratch. There is no automatic saving. The Scratch developers did not want that. They think Scratch should look the same on all supported platforms, and behave as uniformly as possible. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
Excerpts from Alberto Arruda de Oliveira's message of Tue Sep 21 03:39:13 +0200 2010: I've been adapting an application to use as an activity, and I have some questions about the way to save on sugar. First of all, welcome! At first, I tried to just create a directory inside my Activity folder especially made for saving files, [...] Please don't do this. There's exactly one place for storing user data and it's called the Journal (or rather the data store which is the actual component storing the data, the Journal is just UI where the user can browse the data). Putting user data anywhere else is a recipe for disaster. You're taking the files out of version control (which I'm actively working on getting into the next version of Sugar), so accidental changes are irreversible. Recent versions of Sugar will even delete all activity-related directories on deinstallation of the activity. If there's anything the Journal (resp. the data store) is lacking for you, please speak up. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
On 21.09.2010, at 12:32, Sascha Silbe wrote: Excerpts from Alberto Arruda de Oliveira's message of Tue Sep 21 03:39:13 +0200 2010: I've been adapting an application to use as an activity, and I have some questions about the way to save on sugar. First of all, welcome! At first, I tried to just create a directory inside my Activity folder especially made for saving files, [...] Please don't do this. There's exactly one place for storing user data and it's called the Journal (or rather the data store which is the actual component storing the data, the Journal is just UI where the user can browse the data). Putting user data anywhere else is a recipe for disaster. You're taking the files out of version control (which I'm actively working on getting into the next version of Sugar), so accidental changes are irreversible. Recent versions of Sugar will even delete all activity-related directories on deinstallation of the activity. If there's anything the Journal (resp. the data store) is lacking for you, please speak up. What's lacking is a filesystem-based interface to the DS that lets legacy apps use it without much change. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Added busy cursor when we open any section in control panel. (Ticket #245)
Excerpts from Tomeu Vizoso's message of Tue Sep 21 09:58:38 +0200 2010: There's also the question of which window we want the cursor to be changed. As the CP is modal, would we want it to be on the whole screen? We should bind the cursor to the CP window. In the long run I would like to see the CP move to a non-modal, fullscreen window design. There's no good reason for it to be modal and it currently prevents the user from browsing documentation or asking a friend for help (using Chat) while keeping the CP open. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Pass the contact-id to the buddy-removed signal instead of the handle #2349
Excerpts from Tomeu Vizoso's message of Tue Sep 21 09:54:49 +0200 2010: Seems like this bug has been there since the signal was added, but indeed I can make explicit that I'm not changing the signal signature but passing the expected argument. That would be nice. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
Excerpts from Bert Freudenberg's message of Tue Sep 21 12:45:42 +0200 2010: What's lacking is a filesystem-based interface to the DS that lets legacy apps use it without much change. You mean like datastore-fuse [1]? Sascha [1] http://git.sugarlabs.org/projects/datastore-fuse -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] wordgroupz ( A vocabulary building app) ported to sugar
Hi, wordgroupz is a vocabulary building application. It's written using PyGTK. wordgroupz details available at http://ratnadeepdebnath.wordpress.com/2010/09/09/wordgroupz-version-0-3-released/ I ported wordgroupz to sugar desktop environment. I tested it on sugar-jhbuild. The following libraries are needed for running wordgroupz: python DB-API 2.0 interface for SQLite 3.x python-sqlite2 pygtk2 python-nltk pywebkitgtk urllib2 python-BeautifulSoup gstreamer-python espeak Sugar bundle for wordgroupz available at http://rtnpro.fedorapeople.org/wordgroupz/Wordgroupz-1.xo Thanks, Regards, rtnpro ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
On 21.09.2010, at 13:40, Sascha Silbe wrote: Excerpts from Bert Freudenberg's message of Tue Sep 21 12:45:42 +0200 2010: What's lacking is a filesystem-based interface to the DS that lets legacy apps use it without much change. You mean like datastore-fuse [1]? Sascha [1] http://git.sugarlabs.org/projects/datastore-fuse Yes. That would help non-Sugar apps. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Fedora-14-Beta-RC3-i386-netinst with Sugar-desktop (all items checked) in Customize now 3 major bugs in sugar 0.89.6 Fedora release 14 (Lauglin) Same bugs seen in Soas Night
Correction: After reboot bug 3 seems to have been fixed. It took several minutes to recover jabber connection first time logged out/in Note: Sugar-emulator works best if copy education/sugar start item to desktop. right click properties, and edit command: sugar-emulator -f (add the -f) for full screen. logout gets you back to Gnome from sugar. Tom Gilliard satellit Thomas C Gilliard wrote: Install report: Netinstall CD with 14.17.4 Anaconda to extenal 250Gb USB HD Repos: f14 Beta f14-Beta Updates testing Fedora-14-Beta-RC3-i386-netinst with Sugar-desktop (all items checked) in Customize now boots HD,firstboot, boots to login Gnome Sugar on gdm switcher on login Sugar: Bugs Seen: 1-) get Enter password for Keyring 'Default'to unlock popup (requires 4+ cancels) http://bugs.sugarlabs.org/ticket/2339 (Already logged into wireless AP in Gnome) 2-)CP Software update not working http://bugs.sugarlabs.org/ticket/2351 3-)after restart: no avitars in f1 neighborhood http://bugs.sugarlabs.org/ticket/2335#comment:6 Full Report: http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick_release_process#Installation Tom Gilliard satellit ___ 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] Some questions concerning saving methods on sugar
Excerpts from Bert Freudenberg's message of Tue Sep 21 14:16:24 +0200 2010: What's lacking is a filesystem-based interface to the DS that lets legacy apps use it without much change. You mean like datastore-fuse [1]? [1] http://git.sugarlabs.org/projects/datastore-fuse Yes. That would help non-Sugar apps. Give it a try then, please. AFAICT nobody else has used it so far which doesn't exactly motivate me to work on it more than I need myself. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
On 21.09.2010, at 15:08, Sascha Silbe wrote: Excerpts from Bert Freudenberg's message of Tue Sep 21 14:16:24 +0200 2010: What's lacking is a filesystem-based interface to the DS that lets legacy apps use it without much change. You mean like datastore-fuse [1]? [1] http://git.sugarlabs.org/projects/datastore-fuse Yes. That would help non-Sugar apps. Give it a try then, please. AFAICT nobody else has used it so far which doesn't exactly motivate me to work on it more than I need myself. Sascha I don't need it myself either. I implemented proper Journal support for my activity long ago. There is a chicken-and-egg problem here. Unless this is already shipping, people won't use it in their activities. But I'm not even suggesting we need to do this - I was just answering on Alberto's behalf to your question what the data store is lacking. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make sure we don't change the owner's colors because of a network event #2348
On Mon, Sep 20, 2010 at 22:45, Sascha Silbe
sascha-ml-reply-to-201...@silbe.org wrote:
Excerpts from Tomeu Vizoso's message of Mon Sep 20 14:55:28 +0200 2010:
---
src/jarabe/model/neighborhood.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py
b/src/jarabe/model/neighborhood.py
index b808e12..76a0a7d 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -829,7 +829,7 @@ class Neighborhood(gobject.GObject):
def __buddy_updated_cb(self, account, contact_id, properties):
logging.debug('__buddy_updated_cb %r', contact_id)
- if contact_id not in self._buddies:
+ if contact_id is None or contact_id not in self._buddies:
logging.debug('__buddy_updated_cb Unknown buddy with contact_id
%r',
contact_id)
return
I guess this is the correct change, but we should note exactly when
contact_id is None and why we simply ignore that case. At least to me
it isn't obvious from the code. It feels strange to receive an update
for Buddy None.
Agreed, the history behind is that we may get presence updates for
contacts from which we haven't gotten their contact-ids nor other info
yet. I have plans to fix it in tp-gabble because it also gives us an
opportunity for reducing the bandwidth used, but it will take a bit
more time.
I'm going to make it clearer in the code and repost the patch.
Regards,
Tomeu
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] [PATCH] Make sure we don't change the owner's colors because of a network event #2348
Because the owner is stored in Neighborhood._buddies in the key None.
---
src/jarabe/model/neighborhood.py |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/jarabe/model/neighborhood.py b/src/jarabe/model/neighborhood.py
index b808e12..ff973fd 100644
--- a/src/jarabe/model/neighborhood.py
+++ b/src/jarabe/model/neighborhood.py
@@ -829,6 +829,10 @@ class Neighborhood(gobject.GObject):
def __buddy_updated_cb(self, account, contact_id, properties):
logging.debug('__buddy_updated_cb %r', contact_id)
+if contact_id is None:
+# Don't know the contact-id yet, will get the full state later
+return
+
if contact_id not in self._buddies:
logging.debug('__buddy_updated_cb Unknown buddy with contact_id
%r',
contact_id)
--
1.7.2.3
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Sugar Journal - Erase confirmation
On Mon, Sep 20, 2010 at 23:50, Samuel Greenfeld greenf...@laptop.org wrote: In Sugar's Journal, the per-entry Erase menu choice does not ask for any confirmation prior to deleting an object. This presents the risk of accidentally deleting something, especially since the View Details menu choice is immediately above it I searched bugs.sugarlabs.org looking to see if anyone had ever suggested verifying the erasure/deleting of a Journal entry prior to doing so, but could not find any obvious tickets on the subject. Does anyone know if this is by design? I don't really remember, adding Eben and Christian to CC in case they do. Cheers, Tomeu --- SJG ___ 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] Make sure we don't change the owner's colors because of a network event #2348
Excerpts from Tomeu Vizoso's message of Tue Sep 21 15:58:25 +0200 2010: Because the owner is stored in Neighborhood._buddies in the key None. Took me a while to understand what this means, but it's descriptive enough. Reviewed-By: Sascha Silbe sascha-...@silbe.org Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Pass the contact-id to the buddy-removed signal instead of the handle #2349
Excerpts from Tomeu Vizoso's message of Tue Sep 21 15:44:05 +0200 2010: I'm proposing this patch for inclusion in master during the hard code freeze period as per http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule The benefit is a more consistent neighborhood view and the risk is very low. +1 from me, FWIW (I guess only Simons vote matters). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Pass the contact-id to the buddy-removed signal instead of the handle #2349
On Tue, Sep 21, 2010 at 17:23, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Tue Sep 21 15:44:05 +0200 2010: I'm proposing this patch for inclusion in master during the hard code freeze period as per http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule The benefit is a more consistent neighborhood view and the risk is very low. +1 from me, FWIW (I guess only Simons vote matters). Yup, maybe you should be part of the release team? Regards, Tomeu 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] [PATCH] Pass the contact-id to the buddy-removed signal instead of the handle #2349
On 09/21/2010 05:32 PM, Tomeu Vizoso wrote: On Tue, Sep 21, 2010 at 17:23, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Tue Sep 21 15:44:05 +0200 2010: I'm proposing this patch for inclusion in master during the hard code freeze period as per http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule The benefit is a more consistent neighborhood view and the risk is very low. +1 from me, FWIW (I guess only Simons vote matters). Yup, maybe you should be part of the release team? Regards, Tomeu +1 from me as well. So far the release team is me and Tomeu - due to historical reasons (maybe Marco wants to get back in at one point :). If you read that at least 2 members need to approve a break [1] the policy might sound a bit funny. I am happy if new people want to jump in the team. You have shown great commitment in reviewing patches and at many other places. I am sure you would be a good fit :) Regards, Simon [1] http://wiki.sugarlabs.org/go/Development_Team/Release#Hard_code_freeze ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Make sure we don't change the owner's colors because of a network event #2348
On 09/21/2010 05:20 PM, Sascha Silbe wrote: Excerpts from Tomeu Vizoso's message of Tue Sep 21 15:58:25 +0200 2010: Because the owner is stored in Neighborhood._buddies in the key None. Took me a while to understand what this means, but it's descriptive enough. Reviewed-By: Sascha Silbesascha-...@silbe.org Sascha Please go ahead here, too. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some questions concerning saving methods on sugar
Excerpts from Bert Freudenberg's message of Tue Sep 21 15:30:38 +0200 2010: [datastore-fuse] There is a chicken-and-egg problem here. Unless this is already shipping, people won't use it in their activities. But I'm not even suggesting we need to do this - I was just answering on Alberto's behalf to your question what the data store is lacking. I wouldn't consider it a lack on the data store side. To activity developers, it doesn't matter too much what the low-level interface looks like (POSIX EAs vs. DBus). If you want it to integrate well with Sugar, you need to add metadata in both cases (datastore-fuse does the same amount of guessing that traditional file managers do to fill in some of the metadata). These days DBus APIs are even more standard than extended file attributes (and much better supported in various languages AFAICT), so I don't see how a POSIX based interfaces makes it easier for activity developers. What might be more useful (to developers of non-Python activities) is a high-level, cross/multi-language API for accessing the data store. IIRC alsroot was working on one. For activities written in Python sugar.datastore.datastore should work fine (even if you don't use the rest of the activity framework). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Child in charge of FOSS or Sugar
On Tue, Sep 21, 2010 at 9:21 AM, Teemu Leinonen teemu.leino...@aalto.fi wrote: The issue is even more important when the project is claiming to promote FLOSS culture, like in the case of Sugar. In my definition of That is _not_ the primary goal of Sugar. Sugar aims for lots of goals, first and foremost, is about children as users, and their learning. One of the key aspects of the FOSS culture that is very visible in Sugar is that it is something explorable, learnable, hackable (as opposed to a black-box). Other aspects of FOSS are less applicable to primary-school age children and their learning, so... 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
Re: [Sugar-devel] SL bug #1520
Tomeu, I had a word with Bernie regarding the issue and he says that probably newer versions of the X server actually implement XUngrabKey() with keycode= Any Key as specified in the man-page. He said he had seen the source code and someone (whot) reworked that function sometime back, probably fixing up the bug. I tested sugar-emulator on Ubuntu Maverick and it seemed the keybindings were working. I tried Alt+ Tab and it worked. It seems the component has already been fixed. Regards, Mukul Gupta Research Engineer, SEETA On Tue, Sep 14, 2010 at 1:11 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Sep 10, 2010 at 18:07, Mukul Gupta mu...@seeta.in wrote: Hi, The patch is a temporary fix. According to Bernie,some other component is broken(X server?) and this is just a work around. Ok, it would be very helpful to know which other component is broken and in which way. However, I have filed a bug at gnome-bugzilla ( https://bugzilla.gnome.org/show_bug.cgi?id=629210#c0 ) regarding the same. Note that in GNOME they use a different patch submission process: http://live.gnome.org/Git/Developers#Contributing_patches Basically, you don't put r* flags and use instead the Status combo in the Details page for the patch. Regards, Tomeu Regards, Tomeu Regards, Mukul On Fri, Sep 10, 2010 at 2:27 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Sep 8, 2010 at 11:15, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Sep 7, 2010 at 20:01, Mukul Gupta mu...@seeta.in wrote: Team, I am working on Bug # 1520 on sugarlabs. http://bugs.sugarlabs.org/ticket/1520 I tried to reproduce the issue on sugar-emulator. I realised that Alt + Tab did nothing. Instead, Alt+Tab functioned for GNOME. I tried to run sugar from sugar-session. Still, Alt+ Tab did nothing. Firstly, I would require some pointers on how to reproduce the bug. Secondly, when I read the comments on the bugs page, I realised that fran pointed out that this functioning of the Alt+Tab as mentioned in the bug can also be considered as a utility rather than a bug. A very similar bug to bug #1520 is #1518. http://bugs.sugarlabs.org/ticket/1518 As far as solving the current bug is concerned I realised that Bernie had created a patch for the same in fedora and that could be implemented on ubuntu. I have studied the patch - http://sascha.silbe.org/patches/metacity-ungrab-keybindings.patch Should this patch go upstream? Ping, the metacity maintainer has shown interest but wants to give it a good deal of testing before pushing and has requested a bug to be filed. I just want to know if this patch is considered a proper fix that can go upstream. Regards, Tomeu Regards, Tomeu Regards, Mukul Gupta Research Engineer, SEETA ___ 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] Bug no. #2093
Team, I'm currently working on http://bugs.sugarlabs.org/ticket/2093 (related to Turtle Art). I'm having a problem comprehending this bug. It'll be helpful if a few pointers are provided to me describing this bug. Regards, Shachi. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Bug #1742
Hi, I am working on the bug : http://bugs.sugarlabs.org/ticket/1742 I investigated a bit and found that the BuddyMenu in Neighbourhood view is not getting updated without restart. It would be helpful to get some pointers on how to update the buddy status without restarting in BuddyMenu. Regards, Dipankar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SL bug #1520
Excerpts from Mukul Gupta's message of Tue Sep 21 20:06:11 +0200 2010: I had a word with Bernie regarding the issue and he says that probably newer versions of the X server actually implement XUngrabKey() with keycode= Any Key as specified in the man-page. He said he had seen the source code and someone (whot) reworked that function sometime back, probably fixing up the bug. What component (package) is that in and which version fixed it? Or which source file and function contains the change so I can try scanning the repo? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug no. #2093
On Tue, Sep 21, 2010 at 2:19 PM, Shachi Paul sha...@seeta.in wrote: Team, I'm currently working on http://bugs.sugarlabs.org/ticket/2093 (related to Turtle Art). I'm having a problem comprehending this bug. It'll be helpful if a few pointers are provided to me describing this bug. Please see http://bugs.sugarlabs.org/ticket/2093#comment:2 -walter Regards, Shachi. ___ 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] [DESIGN] Sugar Journal - Erase confirmation
On Tue, Sep 21, 2010 at 10:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 20, 2010 at 23:50, Samuel Greenfeld greenf...@laptop.org wrote: In Sugar's Journal, the per-entry Erase menu choice does not ask for any confirmation prior to deleting an object. This presents the risk of accidentally deleting something, especially since the View Details menu choice is immediately above it I searched bugs.sugarlabs.org looking to see if anyone had ever suggested verifying the erasure/deleting of a Journal entry prior to doing so, but could not find any obvious tickets on the subject. Does anyone know if this is by design? I don't really remember, adding Eben and Christian to CC in case they do. I don't remember either. We really should be asking to confirm, especially for user-generated data. But if and when someone digs into that code, it would be great to finally address the issue of selecting multiple objects. Deleting one item at a time, even without the additional step of a confirmation, is tedious. -walter -walter Cheers, Tomeu --- SJG ___ 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] [DESIGN] Sugar Journal - Erase confirmation
On Tue, Sep 21, 2010 at 4:18 PM, Walter Bender walter.ben...@gmail.comwrote: On Tue, Sep 21, 2010 at 10:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 20, 2010 at 23:50, Samuel Greenfeld greenf...@laptop.org wrote: In Sugar's Journal, the per-entry Erase menu choice does not ask for any confirmation prior to deleting an object. This presents the risk of accidentally deleting something, especially since the View Details menu choice is immediately above it I searched bugs.sugarlabs.org looking to see if anyone had ever suggested verifying the erasure/deleting of a Journal entry prior to doing so, but could not find any obvious tickets on the subject. Does anyone know if this is by design? I don't really remember, adding Eben and Christian to CC in case they do. I don't remember either. We really should be asking to confirm, especially for user-generated data. But if and when someone digs into that code, it would be great to finally address the issue of selecting multiple objects. Deleting one item at a time, even without the additional step of a confirmation, is tedious. Agreed. I think the expectation there was that a confirmation dialog would appear in a strip beneath the toolbar, with Cancel and Erase buttons. I also agree with Walter regarding the need for multiple selection support; we had some nice mockups with checkboxes that enabled single-click (without modifier) selection of sets of objects to take action on. Eben -walter -walter Cheers, Tomeu --- SJG ___ 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] [DESIGN] Sugar Journal - Erase confirmation
On 21 Sep 2010, at 23:56, fors...@ozonline.com.au wrote: Agreed. I think the expectation there was that a confirmation dialog would appear in a strip beneath the toolbar, with Cancel and Erase buttons. I also agree with Walter regarding the need for multiple selection support; we had some nice mockups with checkboxes that enabled single-click (without modifier) selection of sets of objects to take action on. Increasing the workload in deleting can make it more risky. Back in the bad days before resume by default I have lost work while deleting journal spam. The greater the level of tedium, the less the level of care. Its easy to delete the wrong item, the journal reorders itself while you are hovering on an item and waiting for a menu. A confirm button won't help there, you don't notice the changed selection. Multiple selection reduces the tedium, confirmation then makes more sense. +1 for a confirmation once we have a multiple selection mechanism! An alternative to confirmation would be to implement some sort of trash bin, has that been considered? It could even be semi-hidden in control panel and auto emptying. I presume checkboxes means one at a time selection. Has selection of consecutive items, either by mouse swipe or by start and end selection, been considered? My past votes have been towards a start/end selection, and/or a toggle selection mechanism (equivalent of Mac shift key start/end, and individual selection while holding the command key). My worry with check boxes is that it is always visible, cluttering the Journal display for what I'd consider an advanced user function, and very introduces a UI modality that needs some explicit way for being un-set once started. The 'give everything a checkbox approach' also strikes me as the bad old way of HTML email clients before reasonable JavaScript support that had no better design option at the time. OT: For touch only UIs there seems no standard support for multi selection of items in a list. Check boxes may be more explicit in these cases, though some kind of tap and hold, and or tap hold and drag could also cover similar needs. For the iPad the design is to add a top level 'Edit' button as part of the list view, and when touched a new edit modality is entered where all list entries then gain a new button for one tap easy deletion (and often also a drag reorder widget) — tapping edit again reverts to the usual (safe) list view behaviour. The primary use cases for multiple selection are delete and copy to/from usb. Yep, and perhaps also the share with friend case. --Gary Tony ___ 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] Scale TA font proportional to Sugar font-settings. (SL#1858)
This patch scales the font in TA by using ZOOM_FACTOR
set in sugar.graphics.style (SL#1858)
---
TurtleArt/tawindow.py | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/TurtleArt/tawindow.py b/TurtleArt/tawindow.py
index 3100d7c..39c1612 100644
--- a/TurtleArt/tawindow.py
+++ b/TurtleArt/tawindow.py
@@ -33,10 +33,11 @@ from gettext import gettext as _
try:
from sugar.graphics.objectchooser import ObjectChooser
+from sugar.graphics.style import ZOOM_FACTOR
from sugar.datastore import datastore
from sugar import profile
except ImportError:
-pass
+ZOOM_FACTOR = 1
from taconstants import HORIZONTAL_PALETTE, VERTICAL_PALETTE, BLOCK_SCALE, \
PALETTE_NAMES, TITLEXY, MEDIA_SHAPES, STATUS_SHAPES, \
@@ -125,16 +126,16 @@ class TurtleArtWindow():
self.orientation = HORIZONTAL_PALETTE
if olpc_xo_1():
self.lead = 1.0
-self.scale = 0.67
+self.scale = 0.67 * ZOOM_FACTOR
self.color_mode = '565'
if self.running_sugar and not self.activity.new_sugar_system:
self.orientation = VERTICAL_PALETTE
else:
self.lead = 1.0
-self.scale = 1.0
+self.scale = 1.0 * ZOOM_FACTOR
self.color_mode = '888' # TODO: Read visual mode from gtk image
-self.block_scale = BLOCK_SCALE
+self.block_scale = BLOCK_SCALE * ZOOM_FACTOR
self.trash_scale = 0.5
self.myblock = None
self.nop = 'nop'
@@ -2035,7 +2036,7 @@ class TurtleArtWindow():
blk.spr.set_label(blk.values[0].replace('\n', RETURN))
elif btype == 'start': # block size is saved in start block
if value is not None:
-self.block_scale = value
+self.block_scale = value * ZOOM_FACTOR
elif btype in EXPANDABLE or btype in EXPANDABLE_BLOCKS or \
btype in EXPANDABLE_ARGS or btype == 'nop':
if btype == 'vspace' or btype in EXPANDABLE_BLOCKS:
--
1.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Scale TA font proportional to Sugar font-settings. (SL#1858)
On Wed, Sep 22, 2010 at 09:10:21AM +0530, Kandarp Kaushik wrote:
This patch scales the font in TA by using ZOOM_FACTOR
set in sugar.graphics.style (SL#1858)
But the font size is set by the gconf float
/desktop/sugar/font/default_size ... available as
sugar.graphics.style.FONT_SIZE
Using ZOOM_FACTOR is too general, based on SUGAR_SCALING, and so Turtle
Art won't scale fonts in proportion to the font-size setting.
@@ -125,16 +126,16 @@ class TurtleArtWindow():
self.orientation = HORIZONTAL_PALETTE
if olpc_xo_1():
self.lead = 1.0
-self.scale = 0.67
+self.scale = 0.67 * ZOOM_FACTOR
self.color_mode = '565'
if self.running_sugar and not self.activity.new_sugar_system:
self.orientation = VERTICAL_PALETTE
else:
self.lead = 1.0
-self.scale = 1.0
+self.scale = 1.0 * ZOOM_FACTOR
self.color_mode = '888' # TODO: Read visual mode from gtk image
-self.block_scale = BLOCK_SCALE
+self.block_scale = BLOCK_SCALE * ZOOM_FACTOR
self.trash_scale = 0.5
self.myblock = None
self.nop = 'nop'
@@ -2035,7 +2036,7 @@ class TurtleArtWindow():
blk.spr.set_label(blk.values[0].replace('\n', RETURN))
elif btype == 'start': # block size is saved in start block
if value is not None:
-self.block_scale = value
+self.block_scale = value * ZOOM_FACTOR
elif btype in EXPANDABLE or btype in EXPANDABLE_BLOCKS or \
btype in EXPANDABLE_ARGS or btype == 'nop':
if btype == 'vspace' or btype in EXPANDABLE_BLOCKS:
But it seems here you are not scaling the fonts, but rather block sizes.
I'm confused.
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] wordgroupz ( A vocabulary building app) ported to sugar
Hi, wordgroupz is a vocabulary building application. It's written using PyGTK. wordgroupz details available at http://ratnadeepdebnath.wordpress.com/2010/09/09/wordgroupz-version-0-3-released/ I think wordgroupz will make a good addition to the education tools in sugar. I ported wordgroupz to sugar desktop environment. I tested it on sugar-jhbuild. The following libraries are needed for running wordgroupz: python DB-API 2.0 interface for SQLite 3.x python-sqlite2 pygtk2 python-nltk pywebkitgtk urllib2 python-BeautifulSoup gstreamer-python espeak Sugar bundle for wordgroupz available at http://rtnpro.fedorapeople.org/wordgroupz/Wordgroupz-1.xo Please check if this is satisfactory and feel free to suggest any improvements. I also need an icon for wordgroupz for sugar. Any help will be highly appreciable. Thanks, Regards, rtnpro ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] wordgroupz ( A vocabulary building app) ported to sugar
On 22 September 2010 16:50, Ratnadeep Debnath rtn...@gmail.com wrote: snip / Sugar bundle for wordgroupz available at http://rtnpro.fedorapeople.org/wordgroupz/Wordgroupz-1.xo Please check if this is satisfactory and feel free to suggest any improvements. I also need an icon for wordgroupz for sugar. Any help will be highly appreciable. Well done on your release! My *personal* feeling is that you should change the name of the Activity. Ideally, all Sugar Activities should be verbs.[1] I know that many Activities haven't followed the HIG guidelines, but following them demonstrates a level of care. At the very least, I'm not happy with the trailing Z. I don't think encouraging misspelling is entirely suitable for an educational environment. Well done on the software, it looks very promising. Tim [1] http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/Activities/Activity_Bundles#Activities_as_Verbs ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
