D6215: Make sure size is final after showEvent
Marco Martin
noreply at phabricator.kde.org
Wed Jun 21 11:12:05 UTC 2017
mart added a comment.
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 https://phabricator.kde.org/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.
REPOSITORY
R242 Plasma Framework (Library)
REVISION DETAIL
https://phabricator.kde.org/D6215
To: mart, #plasma, davidedmundson
Cc: sebas, hein, davidedmundson, plasma-devel, #frameworks, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, apol, mart, lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170621/04161860/attachment.html>
More information about the Kde-frameworks-devel
mailing list