[sugar] Preparing for the feature freeze
The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? Let me start it. Priorities goes from 0 to 5. * Control panel (almost ready) - priority 5 * New startup notification (has patch, has consensus?, needs to clean it up) - priority 4 * Session. Can either create a sugar-session based on gnome-session or come up with something minimal. I tend to prefer the first option at the moment even if it will provide us some unneeded features. - priority 4 * Browser bookmarks and autocompletion. - priority 3 Please add stuff you know about. I can clean up and move to the wiki when we are done. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Three more items I can think of: My take on the priorities. * Switch from Matchbox to Metacity and Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? * In-page search in Browse. Priority 3. * Presence scalability when using Jabber (gadget). Priority 2. * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser Priority 3. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:03 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? Let me start it. Priorities goes from 0 to 5. * Control panel (almost ready) - priority 5 * New startup notification (has patch, has consensus?, needs to clean it up) - priority 4 * Session. Can either create a sugar-session based on gnome-session or come up with something minimal. I tend to prefer the first option at the moment even if it will provide us some unneeded features. - priority 4 * Browser bookmarks and autocompletion. - priority 3 I agree with all that. Do we have clear what needs to be done in the last item? Eben, do you know? Three more items I can think of: * Switch from Matchbox to Metacity and activate composition (eToys and Record have trouble with this). * In-page search in Browse. * Presence scalability when using Jabber (gadget). * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser My current top priority is the last one. I proposed journal object transfers to OLPC, but as I had no replies I guess that their deployments are not asking for it very strongly. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Hello, On Tue, Jun 3, 2008 at 2:56 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Three more items I can think of: My take on the priorities. * Switch from Matchbox to Metacity and Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. I agree with Marco on this. At the moment, I don't think Metacity gives us anything other than whatever is given (in terms of functionality) by Matchbox. The main reason for considering a switch to Metacity is, IIRC, seamless running of stock desktop apps within Sugar, and I think we would need some more work before this can be achieved (eg: support for standard window icons in the activity list, etc). I would probably stick to Matchbox during this release cycle, and devote a complete release cycle to testing out Metacity + Sugar for finding out possible regressions and weird behaviours. The only significant advantage is composite support, my comments on that below: activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? Some comments: a) Memory is a pretty significant issue. I was running a yum install gucharmap in a B4 while sugar + browse + terminal activity was running, and during the installation of the dependencies, I saw a number of Out of memory messages (I think they were being printed by some XML related utilities.. scrollkeeper ??) b) The compositor in metacity seems to be quite new (http://svn.gnome.org/viewvc/metacity/trunk/src/compositor/compositor.c?view=log). I'm not sure what's up here, I remember seeing drooling at screencasts of a branch of metacity called luminocity around 2 years back. Maybe they have only recently started to merge stuff ? For stock builds, the compositor is disabled (via a Gconf option, though it is compiled in), so I am not very sure how stable thing thing is. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. A nice thing about this is that little changes to sugar are expected to be needed, so it's easy to swap-in swap-out, perhaps in a quick 8.2.1 release? Well, if we go for the fullscreen hint approach, it will need changes to all the non-python activities, so it would be pretty invasive. activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. Bernando was saying that this is not possible because of *video* memory constraints. If we only keep the active activity composited, we could limit this to a total of 4MB with peaks of 6MB (desktop window + active activity + inactive activity while we take the screenshot). I would like to see a proof of concept of this approach. Doesn't sound too bad if the avoided rewrites give us a smoother experience. Notifications on the lower corners look quite weird because of lack of transparency, btw. * Presence scalability when using Jabber (gadget). Priority 2. Sure about this? Usefulness of presence is very limited without this. Did we actually reach the point where reliability of the network with a high number of buddies/activities make this useful? What work is involved to get this working? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: * Presence scalability when using Jabber (gadget). Priority 2. Sure about this? Usefulness of presence is very limited without this. Did we actually reach the point where reliability of the network with a high number of buddies/activities make this useful? What work is involved to get this working? Gadget is a server side component for the jabber server that will address the scalability issues by showing presence for only a subset of those on the server. It will therefore allow many more on the server at once. There will be PS and mesh view changes required - see Guillaume's recent mail(s) to [EMAIL PROTECTED] While this is not related to reliability of simple mesh, it will definitely improve reliability of collaboration via jabber server on AP. Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:03 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? Let me start it. Priorities goes from 0 to 5. * Control panel (almost ready) - priority 5 * New startup notification (has patch, has consensus?, needs to clean it up) - priority 4 * Session. Can either create a sugar-session based on gnome-session or come up with something minimal. I tend to prefer the first option at the moment even if it will provide us some unneeded features. - priority 4 * Browser bookmarks and autocompletion. - priority 3 Please add stuff you know about. I can clean up and move to the wiki when we are done. I'd like to land the private invite stuff for Chat invites from a non-Sugar jabber client. It's almost ready. Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 12:29 PM, Guillaume Desmottes [EMAIL PROTECTED] wrote: What happens if we land only the backend without the search features? Do we only see a random number of buddies? Yes, if sugar request these buddies (shouldn't be more complicated than a D-Bus method call on PS). I think that's a good idea to focus on random queries for now as it doesn't require new UI and sugar changes should be pretty simple. That's not a new feature from user pov but could allow us to deploy a public jabber server without the shared roster hack and see how it scales. True. We could probably land the sugar changes even after the freeze. It would be good the bulk of the work before though (gadget, gabble, ps, sugar-toolkit). Is Collabora planning to do the UI side of it? For now I'm focusing on PS API. If someone wants to work on the GUI side when they are done that would be great. What kind of API are you planning for the PS? Trying to understand how much work it will be to hook it up into the UI. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. A nice thing about this is that little changes to sugar are expected to be needed, so it's easy to swap-in swap-out, perhaps in a quick 8.2.1 release? Well, if we go for the fullscreen hint approach, it will need changes to all the non-python activities, so it would be pretty invasive. Ouch, is that acceptable? What will happen when kids try to run an old activity? activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. Bernando was saying that this is not possible because of *video* memory constraints. Hmm, but not all those pixmaps will be kept in video mem, right? If so, then I don't get why the faster builds work so fine. Anyway, Martin Dengler did an awesome job measuring the mem hit in matchbox, so I guess we should reread it and maybe redo the tests with metacity: http://lists.laptop.org/pipermail/sugar/2008-March/004718.html Sayamindu, you say you got OOM problems after activating composition, can you check where that memory is going? Or might be the X server crashing instead? If we only keep the active activity composited, we could limit this to a total of 4MB with peaks of 6MB (desktop window + active activity + inactive activity while we take the screenshot). I would like to see a proof of concept of this approach. Me too ;) Just for the record, I'm not strongly advocating for composition in 8.2. I just happen to think that it could bring a lot of value and we should consider carefully if it's doable or not. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett [EMAIL PROTECTED] wrote: Gadget is a server side component for the jabber server that will address the scalability issues by showing presence for only a subset of those on the server. It will therefore allow many more on the server at once. There will be PS and mesh view changes required - see Guillaume's recent mail(s) to [EMAIL PROTECTED] When is the backend planned to land? What happens if we land only the backend without the search features? Do we only see a random number of buddies? How does it work from the UI code perspective? We set a filter and buddies which doesn't match the search disappear (as if they have had left)? Is Collabora planning to do the UI side of it? Sorry, lots of questions :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 12:11 +0200, Marco Pesenti Gritti a écrit : On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett [EMAIL PROTECTED] wrote: Gadget is a server side component for the jabber server that will address the scalability issues by showing presence for only a subset of those on the server. It will therefore allow many more on the server at once. There will be PS and mesh view changes required - see Guillaume's recent mail(s) to [EMAIL PROTECTED] When is the backend planned to land? Well, this involves work in a lot of modules: - the gadget component itself - telepathy-gabble: new API's for search/random and protocol to talk to Gadget - sugar-presence-service: new API's using Gabble's search features - sugar-toolkit: convenient wrapper for PS new API's - sugar: GUI to perform searches, etc Currently, most of the work has been done in Gadget and Gabble and I recently started PS changes. What happens if we land only the backend without the search features? Do we only see a random number of buddies? Yes, if sugar request these buddies (shouldn't be more complicated than a D-Bus method call on PS). I think that's a good idea to focus on random queries for now as it doesn't require new UI and sugar changes should be pretty simple. That's not a new feature from user pov but could allow us to deploy a public jabber server without the shared roster hack and see how it scales. How does it work from the UI code perspective? We set a filter and buddies which doesn't match the search disappear (as if they have had left)? Don't know. I'm not a GUI expert, we are open to any suggestion. Is Collabora planning to do the UI side of it? For now I'm focusing on PS API. If someone wants to work on the GUI side when they are done that would be great. Sorry, lots of questions :) np :) G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 12:16 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. A nice thing about this is that little changes to sugar are expected to be needed, so it's easy to swap-in swap-out, perhaps in a quick 8.2.1 release? Well, if we go for the fullscreen hint approach, it will need changes to all the non-python activities, so it would be pretty invasive. Ouch, is that acceptable? What will happen when kids try to run an old activity? Well, there is no official API freeze in effect yet. Old activities will get a window frame. Personally I think that's acceptable if using the fullscreen hint is considered the best semantic. We could also consider to use normal window + maximized. If someone could spend some time thinking about the possible approaches and to write them down (with advantages and disadvantages) that would be a good step forward. activate composition (eToys and Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. Bernando was saying that this is not possible because of *video* memory constraints. Hmm, but not all those pixmaps will be kept in video mem, right? If so, then I don't get why the faster builds work so fine. What I understood from Bernardo is that they needs to be in video mem. If you open several windows in faster and try to rotate the screen, does it work? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) (2) Browse has some issues that are important to Uruguay (#6825, 6826, #7078) -walter ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Gadget's feature integration in Sugar
On Tue, Jun 03, 2008 at 12:06:44PM +0200, Marco Pesenti Gritti wrote: On Mon, Jun 2, 2008 at 1:41 PM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Hi, Daf and I are making good progress on Gadget, so that's a good time to start to think about its integration in Sugar. Basically, Gadget is a XMPP server component that should solve our current scalability issues and drop the ugly shared roster hack. I invite you to take a look on the Use Cases and Design Goals sections of http://wiki.laptop.org/go/XMPP_Component_Protocol to have a better idea of what Gadget is and which problem it tries to solve. [...] - As we intent to drop the shared buddy server hack, people won't see all the buddies connected on the server anymore. They'll see their friends, the result of the active searches and a maximum of $N random buddies and $N' random activities. Should we hardcode the value of this $N? Make it configurable from the GUI? From sugar-control-panel (and so stored in a config file)? Adapt it according the number of buddies already displayed on the mesh view? I think it can be calculated depending on the screen and icon sizes. It might be useful to expose this calculated value somewhere (control panel?), because it sounds kind of flaky (nonobvious, nondiscoverable, limiting, non-deterministic) to me to have this limit. If we intend this limit to actually be hit often, perhaps it would make sense to expose it to the user in the mesh view (an icon + textbox right-justified in the toolbox? I'm thinking firefox's search bar, though this should not be used that much...perhaps it should only appear if the activity/buddy search results are limited?)? Marco Martin pgpqhmZI05bmN.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
It is definitely tied to something that is different between the Joyride and the update.1 streams. It still works in 703... -walter On Tue, Jun 3, 2008 at 7:53 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender [EMAIL PROTECTED] wrote: Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) Joyride has no composite enabled, so this seems to be something different. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 12:34 +0200, Marco Pesenti Gritti a écrit :
For now I'm focusing on PS API. If someone wants to work on the GUI side
when they are done that would be great.
What kind of API are you planning for the PS? Trying to understand how
much work it will be to hook it up into the UI.
Probably something similar than the Gabble one. See
http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget
Search queries will return a {Buddy,Activity}View object. This object
will have a Get{Buddies,Activities} method to retrieve the result of the
search, a Changed (or Added/Removed) signal to track changes and a
Closed method when user is not interested anymore by the result of the
search.
Does it make sense to you? Suggestions are welcome.
I'll update http://wiki.laptop.org/go/Presence_Service_D-Bus_API with my
changes.
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender [EMAIL PROTECTED] wrote: Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) Joyride has no composite enabled, so this seems to be something different. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Gadget's feature integration in Sugar
On Tue, Jun 3, 2008 at 1:52 PM, Martin Dengler [EMAIL PROTECTED] wrote: It might be useful to expose this calculated value somewhere (control panel?), because it sounds kind of flaky (nonobvious, nondiscoverable, limiting, non-deterministic) to me to have this limit. If we intend this limit to actually be hit often, perhaps it would make sense to expose it to the user in the mesh view (an icon + textbox right-justified in the toolbox? I'm thinking firefox's search bar, though this should not be used that much...perhaps it should only appear if the activity/buddy search results are limited?)? This is up to Eben, but a preference doesn't make a lot of sense to me here, as long as we have a fixed size view. You can only fit a certain number of items in it, assuming it's correctly calculated I see no reason for the user to want to tweak it. Unfortunately I'm now thinking that we might not be able to calculate a limit, because it depends on the number of activities, buddies and buddies per activity and hence it keeps changing. Another possible approach is to set an arbitrary (configurable?) limit of buddies/activities related to network scalability and make the mesh view scrollable (a la google maps). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 5:26 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser Priority 3. I think this is much higher on the list. My understanding is that the current version is non-functional, due to the recent Journal enhancements. This makes this a regression, and something that needs to be fixed regardless of the design enhancements. Priority 5. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Browse: Make the object chooser transient on the activity window
r+ Tomeu Vizoso wrote: ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 6:29 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mardi 03 juin 2008 à 12:11 +0200, Marco Pesenti Gritti a écrit : On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett What happens if we land only the backend without the search features? Do we only see a random number of buddies? Yes, if sugar request these buddies (shouldn't be more complicated than a D-Bus method call on PS). I think that's a good idea to focus on random queries for now as it doesn't require new UI and sugar changes should be pretty simple. That's not a new feature from user pov but could allow us to deploy a public jabber server without the shared roster hack and see how it scales. How does it work from the UI code perspective? We set a filter and buddies which doesn't match the search disappear (as if they have had left)? Don't know. I'm not a GUI expert, we are open to any suggestion. The vision for the neighborhood has always been to have a more dynamic, animated environment. Up front we were told /not/ to expect to have scaling, but that translation of sprites from point A to point B should be doable. The neighborhood view will, quite literally, come to life when we add that, and it's also a crucial element of the scalability/filter UI. The answer to the above question, of course, is that they disappear because otherwise we're not doing ourselves any benefit regarding the display of information. The full answer is that non-matching objects should slide off-screen, while new matches slide on, maintaining a spacial relationship as though the were all in a plane which extends well beyond the screen boundaries. Without this, the spacial metaphors will be lost, and it won't be clear what's happening when searches are entered and cleared. If we can add some more smarts to the layout, we might not even need some limit on the number of items we show; if instead we can manage to create a layout in polar coordinates where r corresponds to the relevance of the object with respect to the search (degree of match) and theta is used to give us some wiggle room for preventing collisions, then we might treat it as a single large space, with or without scrolling capabilities. I'd leave this exercise to future experimentation, of course. The previous concept is what I've had in mind. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 4:14 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 5:26 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser Priority 3. I think this is much higher on the list. My understanding is that the current version is non-functional, due to the recent Journal enhancements. This makes this a regression, and something that needs to be fixed regardless of the design enhancements. Priority 5. Unless the functional enhancements are somewhat coped with the fixes, I'd say this should stay priority 3 as a feature. But should obviously be a blocker bug for post feature freeze. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 7:20 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? This is a feature freeze, not a bugfix/patch freeze, correct? Correct. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? This is a feature freeze, not a bugfix/patch freeze, correct? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 01:53:37PM +0200, Tomeu Vizoso wrote: On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender [EMAIL PROTECTED] wrote: Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) I am looking into this. Joyride has no composite enabled, so this seems to be something different. According to xdpyinfo the Composite extension is enabled on joyride 1998. So if this is different it is different in a way that xdpyinfo does not know. On 1998 I get the following messages to the virtual terminal (I assume they are delivered via printk): cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost ... 59 printk messages suppressed ... Any ideas? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Software Status Meeting Tomorrow @ 1600 EDT, 2000 UTC in #olpc-meeting on freenode
On Tue, Jun 3, 2008 at 6:09 PM, Michael Stone [EMAIL PROTECTED] wrote: Martin Langhoff, our esteemed school-server architect asked us if we could wake him up at 6:00 AM (in NZ) instead of 4:00 (AM). Can we oblige? Please note the new times: 4:00 PM EST, 2000 UTC. I expect that we'll spend the bulk of our time discussing work toward 8.2.0, a.k.a. the August Release. I'll try to make it but I'm not sure I'll manage to :( 10 pm is not best for me... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
It is proving hard for me to get consensus on the new bundle format, but I hope that I can do so soon enough to get some forward-compatibility patches in. Right now, I think that that would be: allow tar as well as zip bundles (though zip bundles would remain the norm for now) allow multiple installed versions of a bundle (activity registry by hash, version, and key/thread/bundle id) metadata to associate journal entries with correct version of bundle. (The signature stuff may or may not be ready to include in this list, but is not as urgent for forward-compatibility purposes.) On Tue, Jun 3, 2008 at 11:29 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 7:20 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] adding a bad device to the frame shouldn't crash sugar
---
src/view/frame/devicestray.py | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/view/frame/devicestray.py b/src/view/frame/devicestray.py
index 1accdad..1b7f3d1 100644
--- a/src/view/frame/devicestray.py
+++ b/src/view/frame/devicestray.py
@@ -35,11 +35,17 @@ class DevicesTray(HTray):
self.__device_disappeared_cb)
def _add_device(self, device):
-view = deviceview.create(device)
-# TODO: *Tray classes don't allow yet to set the alignment.
-self.add_item(view)
-view.show()
-self._device_icons[device.get_id()] = view
+try:
+view = deviceview.create(device)
+# TODO: *Tray classes don't allow yet to set the alignment.
+self.add_item(view)
+view.show()
+self._device_icons[device.get_id()] = view
+except Exception, message:
+import logging
+logger = logging.getLogger('DevicesTray')
+logger.warn(Not able to add icon for device [%s], because of
+an error (%s). Continuing. % (device, message))
def _remove_device(self, device):
self.remove_item(self._device_icons[device.get_id()])
--
1.5.5.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH 0/2] speaker icon tidyup
Just some tiny speaker icon tidyups Martin Dengler (2): set_mute -- set_muted, consistent with get_muted() return 0, not None, if we can't get the mixer volume src/hardware/hardwaremanager.py |7 --- src/model/devices/speaker.py|2 +- 2 files changed, 5 insertions(+), 4 deletions(-) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH 2/2] return 0, not None, if we can't get the mixer volume
---
src/hardware/hardwaremanager.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 29f5fba..2f92537 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -60,7 +60,7 @@ class HardwareManager(object):
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
-return None
+return 0
max_volume = self._master.max_volume
min_volume = self._master.min_volume
--
1.5.5.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
