Remove overloads on virtual methods

Authored by apol on Mar 25 2020, 3:15 PM.



Prefer virtual methods that take QRect and QSize rather than multi-int versions.
Makes for clearer API and reduces the amount of code that was taking all of the
components and turn it into a class.

Diff Detail

R108 KWin
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
apol created this revision.Mar 25 2020, 3:15 PM
Restricted Application added a project: KWin. · View Herald TranscriptMar 25 2020, 3:15 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
apol requested review of this revision.Mar 25 2020, 3:15 PM
zzag added a subscriber: zzag.EditedMar 25 2020, 4:22 PM

What I had back in my mind was to introduce eventually something like requestedClientGeometry(), requestedFrameGeometry(), and doSetGeometry() in AbstractClient. It would allow us to get rid of the force parameter, merge code that forces shaded geometry, and un-virtualize setFrameGeometry(), but code refactoring in this patch is also fine.

I have a few nitpicks, could you please address them before I click "Accept Revision"?


I don't like that the QRect type is erased. IMHO, it reduces readability. What about being explicit?

setFrameGeometry(QRect(pos(), size.boundedTo(area.size()), force);

It's a bit longer, but imho more readable.



apol updated this revision to Diff 78509.Mar 26 2020, 12:14 AM
apol marked an inline comment as done.

Address Vlad's comments

apol marked an inline comment as done.Mar 26 2020, 12:29 AM
zzag accepted this revision.Mar 26 2020, 8:06 AM
zzag added inline comments.

I'd swap size() and area.size() so when the code is read by someone it's easier to understand what we do.

This revision is now accepted and ready to land.Mar 26 2020, 8:06 AM
This revision was automatically updated to reflect the committed changes.