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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel