any reason for the odd specificity of 0.737? and, seems an unrelated change with adding a widget gallery?

this is not directly related to this review in particular but i see it in several places in this file and should be paid attention to: if the opacity is being animated, this line is going to be quite heavy, as well asproperty bindings on conditions on opacity, like for enabled and z just there, that would cause a lot of slot invocations during the animation, and is easily avoided.

i think it could well use the immutability properties of plasmoid.. as it tries hard to have a single immutability for the whole shell (and i would like to keep it that way) tough if you feel safer to check the property on the final containment, fine

seems an unrelated change?

No, it's the equivalent of the hardcoded RGB triplet that was in the C++ code before. I decided to move it into QML as part of the widget gallery change because the tab button background colors relate to the background color, so I wanted all three colors in the presentation/QML code.

Good point, what style do you suggest?

Mostly because the Widget Explorer model takes a containment assignment to work, and I don't know what that code does (or will do in the future) if passed an immutable containment, so it seemed safer.

See earlier explanation :)

I don't get why we are we creating this dynamically? and why on hover?

I assume it's because WE is costly? and doing it on hover makes it seem faster?

but this code has a quirk that if you hover and then click (a fairly common pattern) you'll actually be creating this component twice.

A Loader with: active: activeTab == 1 || hoveredTab ==1 would be ideal and more declarative.

It's better to just adjust Widget Explorer if we need to add functionality into WidgetExplorer

Doing something like this is the sort of thing that's going to unnoticeably break in the future when someone re-arranges those categories.

for every mouse move you have two of these being emitted in sequence

one from the old tab, one from the new tab.

Can you be guarantee what order that happens in?

Good catch thanks, fixed in follow-up commit.

About not using a Loader: I need guaranteed ordering between the component instanciation and reset() being called in onActiveTabChanged, but I'm also instanciating on hover, when calling reset() is inappropriate. Using a Loader and Component.onCompleted isn't good enough, because the handler wouldn't have the "why" information needed to decide whether to call reset() or not. Ultimately going procedural was a tad easier here, even if it suffers the decentralization cost.

Agreed, will look into it (I didn't like it much while writing ...).

Yeah, the leave/enter ordering is reliable and unit-tested in Qt (I remember from working on the hover code in Qt Quick).

Would it help if you pass the containment to the createObject call to avoid some re-evaluation?

root.widgetExplorer = widgetExplorerComponent.createObject(root, {
    containment: containmentInterface.screenContainment(plasmoid)
})

Note that you cannot unlock widgets if kiosk restrictions (SystemImmutable) apply in which case this entire feature should be disabled or else you open a neat way for users to screw with a locked-down desktop.

Doesn't hurt, will do.

Yep, note the review update that added a SystemImmutable check hiding the tab bar (and thus the entire feature).