sugar start-up profiling

[riccardo]

On Fri, 2008-08-01 at 10:41 -0400, Eben Eliason wrote:
> 
> On Fri, Aug 1, 2008 at 10:29 AM, Erik Garrison <erik at laptop.org>
> wrote:
>         On Fri, Aug 01, 2008 at 10:19:50AM -0400, Eben Eliason wrote:
>         > Another potentially interesting solution is a pseudo-spring
>         algorithm, by
>         > which we detect some numbers of neighbors (O(n)) and then we
>         "push" those
>         > neighbors away with some force vector, the magnitude of
>         which is weighted
>         > based on the size of the nodes, and the direction of which
>         is calculated as
>         > the angle between them.  This solution doesn't, in theory,
>         yield results
>         > that are as good as the other options (since it pushes away
>         at a fixed
>         > angle, instead of towards nearby positions with ow weights),
>         but it should
>         > be really quick.
>         >
>         > I'm sure there are other options, or combinations of these,
>         that we could
>         > explore as well.
>         >
>         
>         
>         Could we be positioning icons on the basis of prior usage
>         patterns?  By
>         this I mean that icons are spring'ed toward the XO icon with a
>         force
>         vector related to their recent usage patterns.  Additionally,
>         activities
>         which are started at similar times could be spring'ed
>         together.  I'm
>         envisioning a learning layout algorithm to distinguish the
>         most-used
>         activites.  This layout necessitates the collection of usage
>         data which
>         could also be shared with our developers.
> 
> 
> This is a good point, and I have to say "yes" and "no" at the same
> time.  I think your solution (I could be wrong!) is somewhat biased
> toward the particular case of the Home view, but this algo needs to
> work on the Groups and neighborhood views too.  Perhaps there are some
> (non-historical) ways to compare data in those views, but I'm not
> sure.
> 
> 
> In any case, there is another variable I would like to propose, which
> is a suggested distance from the center of the screen -- or, if you'd
> like, a spring of a particular k value between the center of the
> screen and the object.  My particular use case is that of search.  I'd
> like to see a bunch of search results slide onto the screen (and
> non-results slide off), and I'd like it even more if the most relevant
> matches moved closest to the center.  This is essential for
> scalability in the Groups and Neighborhood views.
> 
> 
> I could also see this working to bring frequently used activities to
> the center of the screen, and less frequently used ones to the edge
> (thought that interferes with free placement).  I also see it making
> for an intuitive activity search in the favorites view.  Even though
> only favorites are shown on screen by default, anytime a search is
> entered, the non-favorites (which, I propose, lay beyond the screen
> edges) which match can slide in, and non-matching favorites slide off,
> presenting this weighted view of matches. Clearing the entry, of
> course, returns the view to its natural state, with only favorites
> showing.
>  

What about doing collision detection with Box2D (fast, well maintained
etc..) ?

This would enable any of the layout discussed here (and funny animations
when new icons are dropped in the layout ;).


> - Eben
>         
>         Erik
> 
> 

riccardo