[sugar] Gadget's feature integration in Sugar

[Marco Pesenti Gritti]

On Mon, Jun 2, 2008 at 1:41 PM, Guillaume Desmottes
<guillaume.desmottes at collabora.co.uk> 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.
>
> 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?

I'm not sure it's necessary to differentiate the two in the UI. We
chould just search for both and perhaps support some keyword in the
query.

> - 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.

> 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.

Maybe in a future UI revision... I wouldn't worry about it for now.

> 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.

Make sense.

Marco