Review Request: Allow Containments to define the Layout strategy

[Aaron Seigo]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://mattr.info/r/295/
-----------------------------------------------------------

Review request for Plasma.


Summary
-------

Currently new containments are placed on the desktop based on the screen affinity (e.g. "belongs to screen 1"). This obviously doesn't work well when we have overlapping screens according to x.org (lies! damn lies! ;) and it makes dealing with on-the-fly changes to screens a bit annoying. It also raises problems for adding new desktop-y containments which aren't associated with any screen.

This patch implements a (trivial, even mildly naive) system of laying out the containments in something of a grid-like pattern, slotting containments when they change in the first available space.

I considered going for a strictly grid layout based system (and even just using a grid layout itself) *but* the following considerations prevented me from going this route:

* I do want users to eventually be able to click and drag containments into (to Corona) random groupings (spacial properties)
* We are likely to have non-Containment items on the Corona at some point, Panels already have their own layouting system now, and so using a stock layout or any other such layout mechanism would be full of special cases anyways


Diffs
-----

  /trunk/KDE/kdebase/workspace/libs/plasma/containment.h
  /trunk/KDE/kdebase/workspace/libs/plasma/containment.cpp

Diff: http://mattr.info/r/295/diff


Testing
-------

Using it with two desktop containments, which are set to overlap on startup in plasma-appletsrc. The repositioning successfully moves them apart.


Thanks,

Aaron