[Sugar-devel] [PATCH] Properly store and load friends #2331
Because FriendBuddyModel has a different life cycle than BuddyModel
(are tracked also when online), we need to store the key and nick
so we can represent them in the UI when the contact are not online
and also so we can relate to the contact when it becomes online.
* src/jarabe/model/buddy.py: Move out FriendBuddyModel and add a
handle property to BuddyModel.
* src/jarabe/model/filetransfer.py: Ask neighborhood.py for the
buddy associated to a handle.
* src/jarabe/model/friends.py: Add FriendBuddyModel.
* src/jarabe/model/neighborhood.py: Set the contact handle on the
BuddyModel.
---
src/jarabe/frame/activitiestray.py |4 +-
src/jarabe/model/buddy.py | 23 +++-
src/jarabe/model/filetransfer.py | 28 ++-
src/jarabe/model/friends.py| 68 ++-
src/jarabe/model/neighborhood.py | 24 ++---
5 files changed, 97 insertions(+), 50 deletions(-)
diff --git a/src/jarabe/frame/activitiestray.py
b/src/jarabe/frame/activitiestray.py
index 9a1a9da..6bd2a1b 100644
--- a/src/jarabe/frame/activitiestray.py
+++ b/src/jarabe/frame/activitiestray.py
@@ -371,7 +371,7 @@ class IncomingTransferButton(BaseTransferButton):
self.notif_icon.props.icon_name = icon_name
break
-icon_color = XoColor(file_transfer.buddy.props.color)
+icon_color = file_transfer.buddy.props.color
self.props.icon_widget.props.xo_color = icon_color
self.notif_icon.props.xo_color = icon_color
@@ -396,7 +396,7 @@ class IncomingTransferButton(BaseTransferButton):
self._ds_object.metadata['buddies'] = ''
self._ds_object.metadata['preview'] = ''
self._ds_object.metadata['icon-color'] = \
-file_transfer.buddy.props.color
+file_transfer.buddy.props.color.to_string()
self._ds_object.metadata['mime_type'] = file_transfer.mime_type
elif file_transfer.props.state == filetransfer.FT_STATE_COMPLETED:
logging.debug('__notify_state_cb COMPLETED')
diff --git a/src/jarabe/model/buddy.py b/src/jarabe/model/buddy.py
index 531d7ea..5f3176e 100644
--- a/src/jarabe/model/buddy.py
+++ b/src/jarabe/model/buddy.py
@@ -28,8 +28,6 @@ from sugar.profile import get_profile
from jarabe.util.telepathy import connection_watcher
-_NOT_PRESENT_COLOR = #d5d5d5,#FF
-
CONNECTION_INTERFACE_BUDDY_INFO = 'org.laptop.Telepathy.BuddyInfo'
class BaseBuddyModel(gobject.GObject):
@@ -40,20 +38,10 @@ class BaseBuddyModel(gobject.GObject):
self._nick = None
self._color = None
self._tags = None
-self._present = False
self._current_activity = None
gobject.GObject.__init__(self, **kwargs)
-def is_present(self):
-return self._present
-
-def set_present(self, present):
-self._present = present
-
-present = gobject.property(type=bool, default=False, getter=is_present,
- setter=set_present)
-
def get_nick(self):
return self._nick
@@ -103,7 +91,6 @@ class OwnerBuddyModel(BaseBuddyModel):
__gtype_name__ = 'SugarOwnerBuddyModel'
def __init__(self):
BaseBuddyModel.__init__(self)
-self.props.present = True
client = gconf.client_get_default()
self.props.nick = client.get_string('/desktop/sugar/user/nick')
@@ -207,6 +194,7 @@ class BuddyModel(BaseBuddyModel):
self._account = None
self._contact_id = None
+self._handle = None
BaseBuddyModel.__init__(self, **kwargs)
@@ -231,9 +219,10 @@ class BuddyModel(BaseBuddyModel):
contact_id = gobject.property(type=object, getter=get_contact_id,
setter=set_contact_id)
+def get_handle(self):
+return self._handle
-class FriendBuddyModel(BuddyModel):
-__gtype_name__ = 'SugarFriendBuddyModel'
-def __init__(self, nick, key):
-BuddyModel.__init__(self, nick=nick, key=key)
+def set_handle(self, handle):
+self._handle = handle
+handle = gobject.property(type=object, getter=get_handle,
setter=set_handle)
diff --git a/src/jarabe/model/filetransfer.py b/src/jarabe/model/filetransfer.py
index e0809bb..0d21793 100644
--- a/src/jarabe/model/filetransfer.py
+++ b/src/jarabe/model/filetransfer.py
@@ -31,6 +31,7 @@ from sugar.presence import presenceservice
from sugar import dispatch
from jarabe.util.telepathy import connection_watcher
+from jarabe.model import neighborhood
FT_STATE_NONE = 0
FT_STATE_PENDING = 1
@@ -140,11 +141,7 @@ class BaseFileTransfer(gobject.GObject):
self.mime_type = props['ContentType']
handle = channel_properties.Get(CHANNEL, 'TargetHandle')
-presence_service = presenceservice.get_instance()
-self.buddy = presence_service.get_buddy_by_telepathy_handle(
-self._connection.service_name,
-
[Sugar-devel] Child in charge of FOSS or Sugar
For about a month ago, I asked as a curious outsider, if kids were actually hacking sugar. This question is in the same ball-part. I’m trying to understand Sugar-FOSS and the philosophy of debugging and the child’s role in this process. As I understand it, the term ‘Free’ in FOSS means both free of cost (mostly –always??), and free as in learners are “in charge of their educational environment” (Mako Hill, 29.04.08). Or as stated on Sugar Labs: “What are the benefits of using Sugar? - An emphasis on learning through doing and * debugging*: more engaged learners are able to tackle authentic problems” (sugarlabs.org). It doesn’t take long to see Seymour Papert in all this. *I’m wondering: * If a child as the learner is in charge of the learning environment, shouldn’t it be essential that the child is doing the debugging (…in collaboration with others – students, teachers etc.)? In my search for bugging/debugging in Sugar I found the ‘BugSquard/Bugreport’ on wiki.sugarlabs and it says: “If you're using Sugar on a Stickhttp://wiki.sugarlabs.org/go/Sugar_on_a_Stickor another distribution of Sugar http://wiki.sugarlabs.org/go/Supported_systems and find something specific you think could be improved—maybe something isn't working the way you think it should work, or you have an idea for how something could be better—you can file a *ticket. * A ticket is a way for anyone to suggest to the software or project developers that *they should work* on something […]. “[The tickets]” is the *most* important part—because reading the title of a ticket *is how a developer decides* if he or she is going to work on it”. I thought it was the child/sugar-user that should *decide on working on bugs/improvements*. As Papert says on debugging: “Errors benefit us because they lead us to study what happen, to understand what went wrong, and, through understanding, to fix it” (Mindstorms - 1980 (1993): 114), which is essential for learning learning. I have trouble seeing the correspondence between the child/sugar-user taking charge, debugging in Sugar-FOSS as a computational environment and a distant Sugar-developer deciding on debugging or making improvements. To me the ticket doesn’t look like the child is taking charge. I have 4 assumptions about this: 1. The BugSquard doesn’t mean that the sugar-user/child can’t be in charge and taking control and doing own improvements and bug-fixing in Sugar-FOSS- environment. If a child wants to release Sugar 6.1 then by all means. The BugSquard is just there to help and assist the child/sugar-user who doesn’t have the technical know-how to do improvements. 2. Not everyone can release Sugar 6.1, 6.2 etc. That’s the mission of the Development Team. They… “build and maintain the core Sugar environment. This includes specifying and implementing new features in conjunction with the Design Teamhttp://wiki.sugarlabs.org/go/Design_Team, fixing bugs as they are found by the Testing team and the Sugar community […]” (wiki.sugarlabs.org.). 3. Debugging and improving Sugar-OS is different from debugging and programming as a learning-process *in* a Sugar-activity like “Turtle Blocks”, which is the reason why.. 4. …it is possible to run Sugar-activities on Windows. It’s not possible to debug, improve, program and hack Windows (not legally anyway). But you can still debug and program Turtle as a Sugar-activity that runs on Windows. If I’m right about assumption 2,3,4 then children doesn’t benefit from Sugar as a FOSS. That’s mainly for Sugar-developers and the benefit of changing and reshaping Sugar for specific cultural needs i.e. languages, national curriculum-adaptation etc., a top-down-proces in a specific cultural context, that exclude children’s points of view. more like a 'cultural empowerment'. Last assumption: 5. Children benefits from Sugar because it’s a specific designed learning environment, but children (most of them) couldn’t care less about FOSS, and they are not in charge of the FOSS-environment. They are in charge of the progamming and debugging Turtle not the Sugar-activity itself, Just some thoughts and reflections Please leave a comment or fill in some missing links. Regards Soren Student in educational anthropology at Denmark ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RELEASE] sugar-datastore-0.89.4
On Tue, Sep 14, 2010 at 12:14:36PM +0200, Simon Schampijer wrote: On 09/11/2010 07:52 PM, Aleksey Lim wrote: == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.89.4.tar.bz2 == News == * metadata-only update sets filesize property to 0 #2229 * commit 3644fac reintroduced race condition, broke test suite #2104 * autogen.sh: pass --enable-maintainer-mode to configure Hi Aleksey, thanks for your release in time! Would be great if you could use the release script in sugar tools [1] so that we get formatted release messages. It is easier for me to construct the release pages then. Ok, got it. If it is about convenient way to create release pages, will use [1]. Regards, Simon [1] http://git.sugarlabs.org/projects/sugar-tools ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Specified bundle-id for read activity (Ticket #2170)
Changed the activity bundle identifier which conform the D-Bus spec. (Ticket #2170) --- activity/activity.info |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/activity/activity.info b/activity/activity.info index a11f14f..a6dcfac 100644 --- a/activity/activity.info +++ b/activity/activity.info @@ -1,6 +1,6 @@ [Activity] name = Read -service_name = org.laptop.sugar.ReadActivity +bundle_id = org.laptop.sugar.ReadActivity icon = activity-read exec = sugar-activity readactivity.ReadActivity show_launcher = no -- 1.7.0.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.89.9
Hi, this release of the sugar module corresponds to the coordinated Sucrose release 0.89.6. We are now in code freeze and will branch soon for unstable development in master. == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.89.9.tar.bz2 == News == * Properly store and load friends #2331 (Tomeu Vizoso) * Announce file transfer capabilities #1603 (Tomeu Vizoso) * Reset resolver cache when connection has been established #1940 (Simon Schampijer) * Display changed to 'Sugar in a window' instead of 'Xephyr on' Ticket #2285 (Ishan Bansal) * Protected Activities Support #2087 (Martin Abente) * Increase timeout for buddy properties queries #2298 (Tomeu Vizoso) * Set param-register to False after a RegistrationExists error #2296 (Tomeu Vizoso) * Change owner's jid to be hashed_pub...@server #2279 (Tomeu Vizoso) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Flip Sticks-7
Activity Homepage: http://activities.sugarlabs.org/addon/4044 Sugar Platform: 0.82 - 0.90 Download Now: http://activities.sugarlabs.org/downloads/file/27041/flipsticks-7.xo Release notes: * Conform layout to HIG's 16x12 * Add ta translation * Update vi, nl and fr translations Sugar Labs Activities http://activities.sugarlabs.org ___ 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
Soren Issues are What modifications are students likely to do What modifications are possible for a student to do What additional benefits are there to students from a FOSS project. It is possible for a student to submit a bug report to bugs.sugarlabs.org, they can even submit their own patch for review and incorporation into the next official release, or they can review others' patches. There are also unofficial forks to Sugar, a student could create their own unofficial fork. They are empowered. All this is unlikely. Particularly with the current target group for the XO being primary school students. It is possible though, with over a million XO laptops distributed, anything could happen. The sort of modifications that are more likely are the more trivial ones, see http://wiki.sugarlabs.org/go/Activity_Team/Modifing_an_Activity for modifications that are more achievable but unlikely to ever make it into a release. Having a FOSS culture means that lots of smaller design decisions are made which empower the learner. The OS is written in Python, an interpreted language which can be inspected and altered without compiling. Activities have a view source button. The entire system can be easily reflashed if corrupted. Nothing is locked down with passwords. Everything is editable. TurtleArt/TurtleBlocks has been designed for experimentation in a way that is unlikely to happen outside of FOSS. A pathway has been provided from the simple to full reprogramming. Firstly the earlier pallettes have simple move and turn blocks. The later pallettes have more complex things like variables. Then the function block allows the incorporation of a line of Python code, typically a function like sin(x). Stepping up a bit more is the Python code block which can hold multiple lines of Python code. Finally if you view source there is an invitation and instructions on modifying the code to create a new Python block. The newly released Sliderule activity works similarly. Sliderule is a virtual manipulative which allows students to investigate concepts of addition, multiplication and raising to a power, in a visual way. It also has dialog boxes which allow bits of Python code to be entered to create custom slide rules. View source has an invitation and instructions for reprogramming the Activity. Hope this helps. Tony For about a month ago, I asked as a curious outsider, if kids were actually hacking sugar. This question is in the same ball-part. I�m trying to understand Sugar-FOSS and the philosophy of debugging and the child�s role in this process. As I understand it, the term �Free� in FOSS means both free of cost (mostly �always??), and free as in learners are �in charge of their educational environment� (Mako Hill, 29.04.08). Or as stated on Sugar Labs: �What are the benefits of using Sugar? - An emphasis on learning through doing and * debugging*: more engaged learners are able to tackle authentic problems� (sugarlabs.org). It doesn�t take long to see Seymour Papert in all this. *I�m wondering: * If a child as the learner is in charge of the learning environment, shouldn�t it be essential that the child is doing the debugging (�in collaboration with others � students, teachers etc.)? In my search for bugging/debugging in Sugar I found the �BugSquard/Bugreport� on wiki.sugarlabs and it says: �If you're using Sugar on a Stickhttp://wiki.sugarlabs.org/go/Sugar_on_a_Stickor another distribution of Sugar http://wiki.sugarlabs.org/go/Supported_systems and find something specific you think could be improved�maybe something isn't working the way you think it should work, or you have an idea for how something could be better�you can file a *ticket. * A ticket is a way for anyone to suggest to the software or project developers that *they should work* on something [�]. �[The tickets]� is the *most* important part�because reading the title of a ticket *is how a developer decides* if he or she is going to work on it�. I thought it was the child/sugar-user that should *decide on working on bugs/improvements*. As Papert says on debugging: �Errors benefit us because they lead us to study what happen, to understand what went wrong, and, through understanding, to fix it� (Mindstorms - 1980 (1993): 114), which is essential for learning learning. I have trouble seeing the correspondence between the child/sugar-user taking charge, debugging in Sugar-FOSS as a computational environment and a distant Sugar-developer deciding on debugging or making improvements. To me the ticket doesn�t look like the child is taking charge. I have 4 assumptions about this: 1. The BugSquard doesn�t mean that the sugar-user/child can�t be in charge and taking control and doing own improvements and bug-fixing in Sugar-FOSS- environment. If a child wants to release Sugar 6.1 then by all means.
Re: [Sugar-devel] [IAEP] Child in charge of FOSS or Sugar
Søren, You raise some concerns that I have had. Over of time, I have come to slightly different conclusions. On 18 September 2010 01:27, Søren Hougesen soren.houge...@gmail.com wrote: For about a month ago, I asked as a curious outsider, if kids were actually hacking sugar. It is almost certainly the case that learners are hacking while using Sugar. I see less evidence that learners are hacking Sugar itself, but there is a lot of it: We often receive feedback through teachers. From my experience, Activity developers are more than willing to incorporate feedback from learners. My personal feeling is that Sugar Labs needs to have systems that are clear and consistent.. But responsibility for teaching those systems to learners should be pushed onto teachers. In my search for bugging/debugging in Sugar I found the ‘BugSquard/Bugreport’ on wiki.sugarlabs and it says: “If you're using Sugar on a Stickhttp://wiki.sugarlabs.org/go/Sugar_on_a_Stickor another distribution of Sugar http://wiki.sugarlabs.org/go/Supported_systems and find something specific you think could be improved—maybe something isn't working the way you think it should work, or you have an idea for how something could be better—you can file a *ticket. * A ticket is a way for anyone to suggest to the software or project developers that *they should work* on something […]. “[The tickets]” is the *most* important part—because reading the title of a ticket *is how a developer decides* if he or she is going to work on it”. I thought it was the child/sugar-user that should *decide on working on bugs/improvements*. I agree with the force of your argument. Interesting, I think that this process facilitates lots of involvement. I feel that our approach is reasonable, because it balances several forces. For example, some learners do not want to develop software. Making it easy to receive feedback is important. This explains the emphasis on tickets. Tickets also centralise the feedback, which helps to avoid duplication. Also, this quote does not imply that learners are not entitled to become developers, just that developers do development. Lastly, we operate under a volunteer model. This means that it's important to recognise that developers do decide which tickets to fix. There are other forces at play. I recall one thread on the development list that said there should not be in-code documentation in order to maintain the quality of the contributions of prospective developers. The reasoning was that if individuals are not able to understand the code by reading the source, then they are not qualified to contribute to Sugar's core. As Papert says on debugging: “Errors benefit us because they lead us to study what happen, to understand what went wrong, and, through understanding, to fix it” (Mindstorms - 1980 (1993): 114), which is essential for learning learning. I have trouble seeing the correspondence between the child/sugar-user taking charge, debugging in Sugar-FOSS as a computational environment and a distant Sugar-developer deciding on debugging or making improvements. To me the ticket doesn’t look like the child is taking charge. taking charge is part of the story. Tickets do allow people to participate at the level that they wish to. If learners would like to learn how to fix the problems that, I think their teachers should guide them. I'm not convinced that Sugar Labs should be in charge of educating learners. I think we need clear, consistent instructions that can be taught to learners who wish to contribute. I have 4 assumptions about this: 1. The BugSquard doesn’t mean that the sugar-user/child can’t be in charge and taking control and doing own improvements and bug-fixing in Sugar-FOSS- environment. If a child wants to release Sugar 6.1 then by all means. The BugSquard is just there to help and assist the child/sugar-user who doesn’t have the technical know-how to do improvements. 2. Not everyone can release Sugar 6.1, 6.2 etc. That’s the mission of the Development Team. They… “build and maintain the core Sugar environment. This includes specifying and implementing new features in conjunction with the Design Teamhttp://wiki.sugarlabs.org/go/Design_Team, fixing bugs as they are found by the Testing team and the Sugar community […]” (wiki.sugarlabs.org.). 3. Debugging and improving Sugar-OS is different from debugging and programming as a learning-process *in* a Sugar-activity like “Turtle Blocks”, which is the reason why.. 4. …it is possible to run Sugar-activities on Windows. It’s not possible to debug, improve, program and hack Windows (not legally anyway). But you can still debug and program Turtle as a Sugar-activity that runs on Windows. If I’m right about assumption 2,3,4 then children doesn’t benefit from Sugar as a FOSS. That’s mainly for Sugar-developers and the benefit of changing and reshaping Sugar for specific cultural needs
Re: [Sugar-devel] [IAEP] Child in charge of FOSS or Sugar
On Fri, Sep 17, 2010 at 9:27 AM, Søren Hougesen soren.houge...@gmail.com wrote: For about a month ago, I asked as a curious outsider, if kids were actually hacking sugar. Two factors are important here: - We all have very high and complex expectations for Sugar, so Sugar itself is internally complex; and that trend is increasing. So to actually hack in the core of Sugar you have to make a long trip of discovery and learning. (Activities are a lot easier to hack.) - Sugar (and XOs) have not been in use for long enough! Sugar users have only started their journey. Will they travel all the way to hacking Sugar? Hard to know! If they are working on TurtleArt / TurtleBlocks, EToys, Scratch or Pippy, they are on the right track. hth, 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] flashing time xo-1.5
On Wed, Sep 15, 2010 at 09:17:00AM -0300, Esteban Arias wrote: Hi, it is possible reduce the time of flashing xo-1.5? Dextrose version, delays 20 mins. thanks, since the xo-1.5 usually has a larger 'hard drive' (4gb), would you expect it to be the same as the xo-1 flash time? I expect the xo-1.5 flash time to be about 20 mins. -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] flashing time xo-1.5
Hi Esteban, we had exactly the same question asked by Guadalupe :-) -- Wad posted our answers / notes on de...@lists.laptop.org earlier today. [ It has nothing to do with Dextrose, and everything to do with the size of the image and the write speed of the SD card... ] In that thread you'll find some background on why it takes 20m, and some ideas on how to speed it up. cheers, m On Wed, Sep 15, 2010 at 8:17 AM, Esteban Arias ear...@plan.ceibal.edu.uy wrote: Hi, it is possible reduce the time of flashing xo-1.5? Dextrose version, delays 20 mins. thanks, -- Esteban Arias Investigación y Desarrollo - Plan Ceibal Avda. Italia 6201 Montevideo - Uruguay. Tel.: 2601.57.73 Interno 2228 E-mail : ear...@plan.ceibal.edu.uy ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- 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
