I used to subclass in Simple Menu, but then eliminated the C++ plugin so I could put it on the Store, so this is important for now.

I like this, and I'll likely need it in my kscreen OSD code aswell (positioning there is unreliable, and my best guess is that this is the exact same problem @mart is trying to solve here).

+1

Relavent follow up to the unanswer question from yesterday:

why does the implicit height change when we show it

It's from some code in NotificationItem.qml

ColumnLayout {
    id: mainLayout
    anchors {
         left: appIconItem.visible || imageItem.visible ? appIconItem.right : parent.left

This changes when we show the popup, the width available show the text, that changes the implicitHeight of the dialog, which changes the actual height.

I /think/ changing them to check whether the image is loaded rather than visible will fix that issue.
I commented it out and gammaray no longer shows the implicitHeight changing

with patch applied on plasma-framework and notifications applet from master all seems to still work ok.

so, if i understand correctly, to try with notifiaction applet with your D6237 on top, and this patch that keeps updating the visibility of the main item.

In D6215#116837, @mart wrote:

with patch applied on plasma-framework and notifications applet from master all seems to still work ok.

so, if i understand correctly, to try with notifiaction applet with your D6237 on top, and this patch that keeps updating the visibility of the main item.

doesn't seem to work on wayland :/

this is how it looks under wayland, keeping the visibility change of the mainitem in plasma-framework and your patch in the notifications applet

it's maybe due to the layout of actions buttons that changes (in the notification applet, populatepopup) but this (columnLayout computed height) doesn't really have effect until it's visible.

In D6215#117370, @mart wrote:

it's maybe due to the layout of actions buttons that changes (in the notification applet, populatepopup) but this (columnLayout computed height) doesn't really have effect until it's visible.

in fact, if in the notification applet i do, right before setVisible():
popup->property("mainItem").value<QQuickItem*>()->setVisible(true);

making mainitem visible just before the showevent,
then the look is correct.

if i do that right in the showevent handler, it's too late and i get wrongly calculate sizes and spurious extra resize events

with this, that removes most of the properties depending from visible, i usually get properly sized notifications, tough every now and then the size still fails and a reposition is always visible right after the notification appears
https://pastebin.com/ia8nLGiw

this will work only when the Dialog' version of setvisible is called,

So this will break released Plasma?

In D6215#117498, @davidedmundson wrote:

this will work only when the Dialog' version of setvisible is called,

So this will break released Plasma?

no, it just means that who calls show() or the wrong setVisible() would just get the previous behavior of mainItem being shown only at showevent, so with the potential resize/position glitch that is already in now, but setvisible gets called both there and in the showevent, so it wouldn't significantly break (just in most common case, the second setvisible would be a noop)

ping?

no, it just means that who calls show() or the wrong setVisible() would just get the previous behavior of mainItem being shown only at showevent,

Ok, great

It's somewhat confusing as you have multiple completely independent attempts to solve the same problem.

We have a patch now consists of:

1. an early mainItem->setVisible()
2. always updating the platform window size regardless of whether it's visible
3. some other wayland changes (which aren't in your commit message)

And we have another patch that:

4. removes use of item::visible in working out window size
5. inhibits resizing whilst we re-populate actions whilst invisible

I'm after some explanation of what the problem(s) each one of those is solving.

If 1 works, I don't see what 2 accomplishes, you're setting the platform window size earlier, but to something that we know is wrong.

Also if 1 works, we don't need 4 or 5? Unless it's because notification does is doing the positioning before the show event? At which point we could just fix that more normally.

so, on the 5 points:

1. yes, is necessary, resizing windows in their show event is definitely not enough, causes events to arrive to reset to the old geometry in race with the setgeometry done there, if it's the qpa, if it's qwindow, if it's the windowmanager doing that i have no idea, i have spent a week looking into that and really don't want to dive more in that spaghetti, more than accepting "qt wants sizes set before the showevent, move is fine" as a fact and adapting to it
2. no it's not doing that anymore, all it changes is having syncToMainItemSize/updateLayoutParameters actually work when they are called with the window not visible, exactly because of 1)
3. yeah, perhaps it should do it in a separate commit, and should be done everywhere a plasmashellsurface is used, or you will have wrong positions after hide/show that don't cause a moveevent
4. as i explained in D6216, not strictly necessary, but avoids many bindings and resizes that happen when the window gets shown and hidden, that shouldn't be seen by the user anyways but useless never the less
5. is done for a specific scenario (that is seen in the dbusnotificationtest manual test in knotifications) A notification is visible, and its content is replaced while still visible, so the actions gets removed, the window gets resized, all notifications gets rearranged, then actions populated again, window resized again, all notifications resized again. it is not strictly a bug, the whole procedure looks ugly and glitchy, especially if the number of actions after repopulating is the same, no resize or reposition of notifications should happen at all.