[sugar] Preparing for the feature freeze
Tue Jun 3 10:25:49 EDT 2008
On Tue, Jun 3, 2008 at 6:29 AM, Guillaume Desmottes
<guillaume.desmottes at collabora.co.uk> 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
>> 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
> 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
More information about the Sugar-devel