On Friday 17 January 2014, Eike Hein wrote:
> 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.
so, at the moment, in my branch things are something like that:
root object is called Applet, so it has "real" properties
compactRepresentation/fullRepresentation
those two components support an attached property called SizeHint,
so you have something like:
Applet {
compactRepresentation: Component {
PlasmaComponents.Button {
text: i18n("Click me")
onClicked: plasmoid.expanded = !plasmoid.expanded
}
}
fullRepresentation: Component {
PlasmaComponents.Label {
SizeHint.minimumHeight: 300
SizeHint.minimumWidth: 200
//PlasmaCore.SizeHint.minimumHeight: 300
text: i18n("Hello world")
}
}
}
dimensions of the applet in the panel or the dimensions of the pospup should
follow size hints
to correctly switch it would also need something like a
switchHeight/switchWidth properties in Applet, since fullRepresentation may
not exist
this should cover most of the things you wrote about
(like a compactRepresentation that has minimumWidth: height*ratio should work
just fine)
another thing that will be necessary is a way to make applets providing a
single representation, like the taskbar doesn't have a compact one
only thing i'm afraid of, it becomes cooomplex, code-wise and for new
developers to understand
Cheers,
Marco Martin
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
