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] 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
[sugar] Gadget's feature integration in Sugar
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. Here is a list of few points that should be discussed about their sugar integration. - We need GUI to perform buddy searches. Buddies can be searched using their properties (color, key, jid). - We also need GUI to perform Activity searches. Activities can be searched using their properties (color, name, type, tags) or their participants (based on their jid). I guess these searches should be done directly from the mesh view. How should we expose the different type of search in the GUI? - 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? Once a search is performed, user will automatically received change notifications from the result of the search until the search result (called view in Gadget) is closed. Do we want to allow users to keep more than one search result a time? If yes, we need GUI to close views. If not, I'll guess that each new search will close the previous one. For privacy reasons, user can choose to not be indexed by gadget (so he can't be found by other users). Do we want to expose this in the GUI? As that's not a really common use case, I guess an option modifiable using sugar-control-panel should be enough. Suggestions are more than welcome. Thanks, G. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
