Use new slot syntax in Compositor class
ClosedPublic

Authored by romangg on Jul 2 2019, 6:41 PM.

Details

Summary

As a preparation for further changes clean up the Compositor
class. First step is to use the new slot syntax and rename
some of the slots.

Includes some other minor code style improvements to the class
as well.

Test Plan

Manually in X and Wayland nested session.

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
romangg created this revision.Jul 2 2019, 6:41 PM
Restricted Application added a project: KWin. · View Herald TranscriptJul 2 2019, 6:41 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Jul 2 2019, 6:41 PM
zzag added a subscriber: zzag.Jul 2 2019, 7:00 PM
zzag added inline comments.
composite.h
41–48

Please reindent it to

enum SuspendReason {
    NoReasonSuspend,
    UserSuspend = 1 << 0,
    // ...
};
86–87

Why is it Q_INVOKABLE?

TimerEvent shouldn't really be made private.
We typically don't change accessibility of superclass methods.

zzag added a comment.Jul 2 2019, 7:04 PM

Now I get lots of

QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:740
QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:740
QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:740

TimerEvent shouldn't really be made private.
We typically don't change accessibility of superclass methods.

We don't? It's not really a make-or-break thing for me, but what's the rationale for that? It seems to me more sensible to have the most narrow accessibility used when possible and if there are no child classes to begin with don't declare something protected.

In D22218#489702, @zzag wrote:

Now I get lots of

QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:740
QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:740
QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:740

Thanks, forgot an old-style connect there.

romangg updated this revision to Diff 61025.Jul 2 2019, 7:17 PM

Fix issue pointed out by @zzag.

romangg added inline comments.Jul 2 2019, 7:18 PM
composite.h
86–87

There is a invokeMethod call to it.

romangg updated this revision to Diff 61028.Jul 2 2019, 7:30 PM
romangg marked an inline comment as done.

Reindent.

zzag added a comment.Jul 2 2019, 7:40 PM

I have another warning

QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:608
In D22218#489736, @zzag wrote:

I have another warning

QObject::connect: No such slot KWin::Compositor::scheduleRepaint() in /home/vlad/Workspace/KDE/src/kde/workspace/kwin/workspace.cpp:608

Thanks again. Did you trigger getting these warnings somehow? It didn't show for me. Will change.

zzag added a comment.Jul 2 2019, 7:44 PM

Did you trigger getting these warnings somehow?

I just opened Kickoff.

romangg updated this revision to Diff 61031.Jul 2 2019, 7:51 PM

Fix issue pointed out by @zzag.

zzag added inline comments.Jul 2 2019, 10:18 PM
composite.h
86–87

In general I don't see why making it Q_INVOKABLE is better than keeping as a slot. Either keep it as Q_SLOT or use QTimer::singleShot(0).

170–171

Please keep it protected.

romangg added inline comments.Jul 2 2019, 10:51 PM
composite.h
86–87

Why not Q_INVOKABLE?

170–171

Reply to what I asked first in this context.

zzag added a comment.Jul 2 2019, 10:58 PM

Can you re-iterate on why Q_SLOTS section has been removed?


Besides timerEvent and Q_INVOKABLE, I don't see any issues.

In D22218#489849, @zzag wrote:

Can you re-iterate on why Q_SLOTS section has been removed?

We don't usually use it nowadays anymore since any function can be the receiver of a signal with the new connect syntax. Is this incorrect?

zzag added a comment.Jul 2 2019, 11:19 PM

Okay, I see, let's keep suspend and setup as Q_INVOKABLE. Though I do agree with David that timerEvent should stay protected.

romangg updated this revision to Diff 61041.Jul 2 2019, 11:36 PM
  • resume() also with Q_INVOKABLE
  • use separate method in dbus adaptor for connecting
romangg updated this revision to Diff 61108.Jul 3 2019, 9:13 PM

Kepp the timerEvent protected. Discussed on irc and in query: argument for
keeping it is that it is done this way in Qt internals and that for deciding
about the accessibility of a method the semantic meaning is more important
than the actual usage by child classes.

zzag accepted this revision.Jul 4 2019, 7:56 AM
zzag added inline comments.
dbusinterface.h
172

Wrong terminator (not cyborg). Use **/ instead.

This revision is now accepted and ready to land.Jul 4 2019, 7:56 AM
romangg added inline comments.Jul 4 2019, 12:09 PM
dbusinterface.h
172

Wrong by what arbitrary rule? Two stars is wrong when looking at upstream recommendation and other projects. I told you this already half a year ago after you went through reformatting all the code base. Still you insist on that being the "right" way to do it. We should use one star at the end of Doxygen comments consistently for new comments.

romangg added inline comments.Jul 4 2019, 12:19 PM
dbusinterface.h
172

And this reformatting was done without checking back on my opinion on that first although quite a lot of that code was written by me and I'm an active core contributor to KWin longer than you.

Similarly just a few days ago you reformatted my complete XWayland drag-and-drop code to your personal code rules without review or even saying anything beforehand. I hope there won't be again an excuse for you to not come to a meetup so we can discuss your behavior in regards to code styling and review etiquette later this month at the KWin sprint.

This revision was automatically updated to reflect the committed changes.
zzag added inline comments.Jul 4 2019, 12:55 PM
dbusinterface.h
172

Listen, put yourself in my shoes. I see a code base with some certain coding style, and your patch follows slightly different style. Do you even realize that such small disagreements contribute to coding style masquerade?

If you don't like the current doxygen style, then submit a patch to change it to a more main stream style. Running git grep + sed with s/ \*\*\// \*\// should be enough. I'll accept that patch, and I think any fellas from Plasma do the same.

Also, I find it a bit frustrating that a lot of time goes into disputing coding style. If you don't like something, stick with it for a moment, but don't invent "new style." Address the issue in another patch.

and I'm an active core contributor to KWin longer than you.

OK.

romangg added inline comments.Jul 4 2019, 1:19 PM
dbusinterface.h
172

Yea, let's talk about this at the sprint. Just so we understand each other correctly: I don't have anything against you personally and I value your expertise and hard work on KWin.

Different people just have different styles of solving problems and if that's not organized correctly this might clash. We need to organize our project such that it suits the project, us and other part-time contributors and the KWin sprint will give us opportunity to do that.