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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
