Notes from "Async and representation"

[Eike Hein]

General comment: Please note that these size hints aren't only
there so the shell can decide which representation to pick, but
at times also do things like:

* Set useful default sizes (e.g. for popups from panels) *before*
  appearance.
* Affect interaction behavior (e.g. lock down resizing in one
  axis but allow it in the other, by setting min/max accordingly).
* Programmatically resize things while shown.

Consider the Homerun Kicker launcher menu:

http://i.imgur.com/eiq6D5w.png 
http://i.imgur.com/h9Y5jH2.png
http://i.imgur.com/o3s3Bzk.png
http://i.imgur.com/KG2R98u.png

Here's a collection of things it does with sizing:

* Not shown on the screenshot, but the compact representation
  shown on the panel supports custom non-square images that it
  scales while preserving aspect ratio, so it needs to hint
  that to the panel layout.

* When the popup opens with the full representation inside,
  it's default size is optimized for its content.

* It lets you adjust the height of the popup, but not the
  width ... which actually feels really nice when resizing,
  but is actually just a side-effect (more on this later).

* It programmatically resizes its popup depending on the
  appearance of thos extra search result columns.

Let's please avoid getting side-tracked with discussion over
whether those specific use cases are things that should be
done; the more interesting point is that someone ended up
doing them in the real world, and that the set of legitimate
use cases is at least conceivably really that wide.

The other thing is that this was actually pretty hard to pull
off in Plasma 1. There are some redundant APIs in the
plasmoid API in Plasma 1 - some prop-based, some procedural -
and not all of them actually work. There are syncing and
ordering problems with applying the root props to the popup
applet, which e.g. necessitated locking down the horizontal
axis to also be able to do the programmatic resize. I also got
the feeling that props on the root vs. props on the compact
repr were getting confused depending on the order in which
things were set ... but I don't remember the details, sorry,
I should have kept more extensive notes.

I think the guiding principle for redesigning this stuff in
Plasma 2 should be "explicit is better than implicit". Let's
try to avoid doing magic props that mean this thing in this
circumstance and this other thing in this other circumstance,
it's better to be expressive and be able to specify the props
for each circumstance and give applet authors control. There
is always another pressure acting on them not to abuse the
control: Users don't like crap UI that does dumb things, so
policing these things hard often isn't necessary and ends up
limiting use cases instead.


Cheers,
Eike