#7685 NORM 9.1.0: Alternate home layouts; fixed ring scaling; better modularization of layouts

[Eben Eliason]

I want to initiate some discussion on a similar topic to the one you
bring up here, regarding the extensibility of the layouts.  What I'd
like to see is layout modules which provide translation from a set of
input coordinates to a set of output coordinates (eg,
_calculate_position), which are then fed to a smooth positioning
algorithm, making it possible to transition cleanly between layouts,
and to rearrange layouts via drag'n'drop.

Let me illustrate what I mean by way of an example.  Consider the Ring
view you bring up.  If we define our translation function to calculate
a radius based on the number of elements in the list, and then
calculate the radial ordering of the elements by calculating the angle
between the center of the ring and their input coordinates
(atan2(y,x)), we can then equally space them around a ring spatially
relative to their initial locations. The beauty of this idea is that
we get drag'n'drop reordering "for free".  If, every time new
coordinates are calculated, we animate the icons to their new target
positions, we can simply drop an icon anywhere we choose on the screen
and it will neatly slide into the nearest spot in the ring.

Of course, the translation function could do anything.  It could force
things onto a grid, into a sunflower, into non-overlapping positions,
etc.  All of these types of layouts require merely the list of
coordinates (since we assume equal size elements) as input.

We can make things more interesting, however, by offering further
information, both as input and output.  If we define an object which
represents an element in the layout, giving it size, position,
orientation, name, tags, and other metadata, (all of these mutable by
the translation function) it's possible to create layouts that perform
logical grouping, create sortings (even in multiple dimensions),
filter the input, etc. The visualization space is much greater (and
think of how much fun it could be to create new layouts like this for
visualizing the neighborhood view.)

- Eben

PS.  You could raise UnimplementedException, or you could simply
define the identity function in the base class.


On Thu, Sep 11, 2008 at 3:07 AM, Zarro Boogs per Child
<bugtracker at laptop.org> wrote:
> #7685: Alternate home layouts; fixed ring scaling; better modularization of
> layouts
> -------------------------+--------------------------------------------------
>   Reporter:  cscott     |       Owner:  marco
>       Type:  defect     |      Status:  new
>   Priority:  normal     |   Milestone:  9.1.0
>  Component:  sugar      |     Version:  not specified
>  Resolution:             |    Keywords:  r?
> Next_action:  never set  |    Verified:  0
>  Blockedby:             |    Blocking:
> -------------------------+--------------------------------------------------
>
> Comment(by mtd):
>
>  I like the (sugar) patch (it's moved to
>  http://dev.laptop.org/git?p=users/cscott/sugar;a=summary ), especially the
>  modularization parts.  Comments on the patch are 1) there are a few times
>  we do "y = m*x+b" instead of "y = m * x + b" that'd be nice to tidy up;
>  and 2) I wish the "RingLayout" class's name could better express that it
>  is suitable as a superclass to {Box,Triangle,Sunflower}Layout - perhaps
>  RingLayout should be renamed BaseLayout and its _calculate_position()
>  function should raise UnimplementedException, and then a new RingLayout
>  defined, which implements that function as the current RingLayout does.
>
>  If it were up to me it'd be r+ with those comments.  I don't know when it
>  should land, though.
>
> --
> Ticket URL: <http://dev.laptop.org/ticket/7685#comment:7>
> One Laptop Per Child <http://laptop.org/>
> OLPC bug tracking system
>