Re: [sugar] Preparing for the feature freeze
There is a good chance that this is not be possible without patching xulrunner, which would make me **really** nervous. What you are describing is the old firefox UI, and I *think* they took out the hooks to do that in xulrunner 1.9. Michael, is the target for this feature only G1G1? I think Peru run into this for web mail but I'm not convinced that providing UI to bypass certificates is the right solution there. Kids will be confused, especially if we provide a firefox 3.0 like UI (which seem intentionally designed to make it difficult to accept a custom/invalid certificate). Marco On Thu, Jun 5, 2008 at 7:12 AM, Eben Eliason [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: * Browser bookmarks and autocompletion. - priority 3 I'd really like to see some progress on #542/#5534 (deal with non-standard SSL certificate authorities). This is going to become a bigger and bigger stumbling block the longer we wait. Surely we could manage some sort of 'accept this cert' button? (Keep in mind the possibility of another G1G1 coming our way in the foreseeable future.) I think that a non-modal alert (akin to those used for downloads) would suffice. Toss up buttons for view cancel and accept, with the first of these presenting a modal alert with the detailed certificate information, and we'd be set. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
We probably found a way to just hook up the firefox dialogs, there are some missing bits but it will probably be easier than writing our own certificate manager. You can try it out manually btw by opening this url in a *separate* browser instance: chrome://pippki/content/exceptionDialog.xul Marco On Thu, Jun 5, 2008 at 10:20 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: There is a good chance that this is not be possible without patching xulrunner, which would make me **really** nervous. What you are describing is the old firefox UI, and I *think* they took out the hooks to do that in xulrunner 1.9. Michael, is the target for this feature only G1G1? I think Peru run into this for web mail but I'm not convinced that providing UI to bypass certificates is the right solution there. Kids will be confused, especially if we provide a firefox 3.0 like UI (which seem intentionally designed to make it difficult to accept a custom/invalid certificate). Marco On Thu, Jun 5, 2008 at 7:12 AM, Eben Eliason [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 12:36 AM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: * Browser bookmarks and autocompletion. - priority 3 I'd really like to see some progress on #542/#5534 (deal with non-standard SSL certificate authorities). This is going to become a bigger and bigger stumbling block the longer we wait. Surely we could manage some sort of 'accept this cert' button? (Keep in mind the possibility of another G1G1 coming our way in the foreseeable future.) I think that a non-modal alert (akin to those used for downloads) would suffice. Toss up buttons for view cancel and accept, with the first of these presenting a modal alert with the detailed certificate information, and we'd be set. - Eben ___ 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 à 14:33 -0400, Polychronis Ypodimatopoulos a
écrit :
Guillaume Desmottes wrote:
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.
I would suggest not returning objects on any of the dbus calls; this
makes it harder to go through and debug the code both in the presence
service and telepathy. We should try to keep it as simple as possible
wrt the messages that are exchanged between the presence service and
telepathy. The presence service currently offers a nice abstraction of
how telepathy works, but this abstraction is hindered by the fact the
the presence service returns telepathy objects.
PS won't return Telepathy objects but buddies and activities as it
always did. The {Buddy,Activity}Views returned in Telepathy won't be the
same as the one returned by PS. In the TP case, views contains handles,
in the PS case they contains buddy and activity objects (as when
GetBuddies or GetActivities methods are called on PS).
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 7:19 PM, Erik Garrison [EMAIL PROTECTED] wrote: 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. Awesome. 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. xdpyinfo reports that the composite extension is present, and I think that this has been like this since always. The difference between joyride and faster is that in the latter the window manager includes a composition manager that creates offscreen pixmaps for every window. Look for XCompositeRedirectSubwindows for more details in: http://ktown.kde.org/~fredrik/composite_howto.html http://svn.o-hand.com/view/matchbox/trunk/matchbox-window-manager/src/composite-engine.c?rev=1084view=markup 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 ... No idea about this :/ Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Wed, Jun 4, 2008 at 12:29 AM, Walter Bender [EMAIL PROTECTED] wrote: So I was probably wrong to bring up the Record bug in this thread. However, the Browse bugs seem to be related to unsupported features in the browser--e.g., the need for some daughter windows to appear. Feature or bug--not obvious. I would call it a bug since affects the basic behavior of what people expect from a browser. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Wed, Jun 4, 2008 at 10:31 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 12:29 AM, Walter Bender [EMAIL PROTECTED] wrote: So I was probably wrong to bring up the Record bug in this thread. However, the Browse bugs seem to be related to unsupported features in the browser--e.g., the need for some daughter windows to appear. Feature or bug--not obvious. I would call it a bug since affects the basic behavior of what people expect from a browser. By the same criteria you could probably call missing auto completion a bug too. We should probably try to come up with a better definition of the feature freeze at some point... The session work for example is totally a feature from the code point of view, but a bug from the user point of view. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Wed, Jun 04, 2008 at 10:28:25AM +0200, Tomeu Vizoso wrote: On Tue, Jun 3, 2008 at 7:19 PM, Erik Garrison [EMAIL PROTECTED] wrote: 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. Awesome. I currently believe that I've narrowed the bug down to something involving the colorspace conversion filter used in gstreamer (ffmpegcolorspace). See the ticket (http://dev.laptop.org/ticket/6850) for more details. 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. xdpyinfo reports that the composite extension is present, and I think that this has been like this since always. The difference between joyride and faster is that in the latter the window manager includes a composition manager that creates offscreen pixmaps for every window. Look for XCompositeRedirectSubwindows for more details in: http://ktown.kde.org/~fredrik/composite_howto.html http://svn.o-hand.com/view/matchbox/trunk/matchbox-window-manager/src/composite-engine.c?rev=1084view=markup Thanks. This makes sense to me. 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 ... No idea about this :/ What it means is that userspace software isn't processing buffers from the cafe chip fast enough. So they get thrown away. Does not appear to be a problem with the cafe1000-ccic driver. 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 11:03:44AM +0200, Marco Pesenti Gritti wrote: * Browser bookmarks and autocompletion. - priority 3 I'd really like to see some progress on #542/#5534 (deal with non-standard SSL certificate authorities). This is going to become a bigger and bigger stumbling block the longer we wait. Surely we could manage some sort of 'accept this cert' button? (Keep in mind the possibility of another G1G1 coming our way in the foreseeable future.) Michael ___ 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
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] 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] 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] 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] 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] 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
