Stacks framework

Registered by Timon_and_Pumba

A framework should be made that allows applets to display elements in an Mac OS X stack-like way.

- Each element in the stack always consists of an image (Cairo surface?) and optionally a title. The image can have any size and the stack must always make sure that the horizontal centers of the images are aligned. All titles are either on the left side or the right side of the stack. If the titles are to the left side of the stack, then the right border/side of the titles have to be aligned with each other in some way (distance between border to center of image). If the titles are placed to the right of the stack, then the left border/side of the titles have to aligned with each other.
- The framework has to figure out on which side of the stack to place the titles. It can use factors as the amount of available space on each side of the stack, and perhaps the language used on the system (western/arab languages are read from left-to-right and right-to-left)
- The framework has to figure out the amount of space between the top and bottom of two adjacent images. This must not be controlled by the applet to avoid inconsistent behaviour.
- The framework has to figure out the angle of an image relative to the image of the previous element. It could make a decision based on where the stack begins (the position of the first element -- its image) and the screen space. Optionally applets should be able to control the angle indirectly by giving each element some weight (read: some number that indicates how important the element is). Using this weight the framework can calculate the angles. Applets displaying elements representing files in a directory can for example base the weight on the filesize of each file. Perhaps the framework should provide some strategies that an applet can choose from. In this case the framework could have optional support for the ODE physics engine. (ode.org)
- The applet should not be able to control the position of the first element. Only the angles should be able to be controlled _indirectly_.
- For reasons of simplicity and consistency, titles should just use the same theming (colors, font) as the tooltips of icons in the Awn panel. Applet must not be able to control the theming of the stack. Also, the framework must not provide any way to control theming (and thus affecting stacks of multiple applets). Instead, the framework should base the theming on the theming of the Awn panel.
- The stack should be able to figure out by itself how to position itself; it should curve to the right or left depending on where enough space is available.
- When hovering over the image of an element (and by that I mean only the image, not a virtual rectangle in which the image fits), it should reflect this hovering by applying a certain effect on the element.
- An applet should be able to allow elements to be inserted or removed by drag&drop. When inserting some thingy (entity?) it should decode this (framework must allow the applet to provide some function that receives the thingy and returns information that can be used by the stack) and temporarily insert and display in in the stack. An animation should be used when moving all the remaining elements and possibly some animation when the element appears in the stack. (Not sure what kind of animation). When an element is temporarily removed from the stack, animations should be applied also.
- The framework should possibly base the animations on the strategy used to calculate the angles (given the weights of the elements). For example if the ODE physics engine is used, then when a big HD movie is drag&dropped somewhere at the top of the stack, the stack could shake (because of the gravity that applies to the element representing the HD movie)
- The framework should be available to Vala, Python, and C applets. The code of the framework should be written in Vala if possible so that the framework can be constructed using modern language concepts/mechanisms provided by the language. To render the elements, Cairo or otherwise perhaps Clutter should be used.

Blueprint information

Status:
Started
Approver:
None
Priority:
Medium
Drafter:
onox
Direction:
Needs approval
Assignee:
onox
Definition:
Drafting
Series goal:
None
Implementation:
Started
Milestone target:
milestone icon 0.6.0
Started by
onox

Related branches

Sprints

Whiteboard

See https://code.launchpad.net/~onox/+junk/apple-stack-prototype

onox: In my Cairo python prototype it was more difficult to calculate and apply the hover effect on the images (although the prototype isn't very efficient) than with Clutter python. Also the hover animation appeared to be as fast in the Clutter python on my P2 (400MHz) as the Cairo python on my Pentium-M (1.6GHz). Recently tested some Clutter C examples on my P-M, which seemed to work, but Clutter python worked crappy many months ago. Also gnome-shell (which uses Clutter) works crappy/segfaults on my FireGL (RV350) card, so I don't know whether Clutter is advisable. It could be that Cairo Vala performance is OK.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.