Replace Q_WS_WIN with Q_OS_WIN in all the source code
ClosedPublic

Authored by asensi on Aug 5 2019, 9:06 PM.

Details

Summary

Replace the Q_WS_WIN macro with the Q_OS_WIN one in all the source code because, as they say in https://www.kdab.com/porting-from-qt-4-to-qt-5/:

In Qt 5, the Q_WS_* macros have been removed, so any code wrapped in them will never be compiled. Where appropriate (ie when code being wrapped is operating system specific and not window system specific), such code can and should be ported to the Q_OS_* macros.

Note: In https://doc.qt.io/qt-5/qtglobal.html it's stated what Q_OS_WIN is, but not what Q_WS_WIN is.

Diff Detail

Repository
R167 Krusader
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
asensi requested review of this revision.Aug 5 2019, 9:06 PM
asensi created this revision.
nmel added a subscriber: nmel.Aug 18 2019, 6:37 AM

This is a very serious change because now #ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN will include the code that previously was ignored. We must look at all those code paths and test features it affects. BTW, does it mean that some of those code paths do not work correctly in the current state?

asensi edited the summary of this revision. (Show Details)Aug 18 2019, 7:33 PM
asensi added a comment.EditedAug 18 2019, 7:41 PM
In D22957#513827, @nmel wrote:

This is a very serious change because now #ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN will include the code that previously was ignored. We must look at all those code paths and test features it affects. BTW, does it mean that some of those code paths do not work correctly in the current state?

Thanks for asking. Because the Q_OS_WIN code blocks are not new ones (previously they were Q_WS_WIN blocks) and having taken into account the aforementioned web pages:

a) Under non-Windows operating systems: The "#ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN" code paths have to work (as they did before this commit), because Q_OS_WIN is not defined there now, nor Q_WS_WIN was defined there previously.

Note: Krusader has the same behavior in the tests that I performed. Also, for example inside

void KRpermHandler::init()
{

there is a

#ifndef Q_WS_WIN

section where anyone can add a

qDebug() << "########################### EXECUTED, IN" << "krperm";

execute "krusader -d" and see the message. Also anyone can replace the

#ifndef Q_WS_WIN

with

#ifndef Q_OS_WIN

and see the message, too.

b) Under Windows operating systems is where the behavior has to change (the Q_OS_WIN code paths are aimed to work, because Q_OS_WIN is defined there).

Some tests were also performed by Moritz Bunkus (https://bugs.kde.org/show_bug.cgi?id=411446#c10) and he didn't see any problem.

abika accepted this revision as: abika.Sun, Sep 15, 5:23 PM
abika added a subscriber: abika.

I also don't see any problems. Q_WS_WIN was always false before, now Q_OS_WIN is still false under Linux.
And if it compiles now Windows and seems to work, even better.

This revision is now accepted and ready to land.Sun, Sep 15, 5:23 PM
nmel accepted this revision.Sun, Sep 15, 6:11 PM

a) Under non-Windows operating systems: The "#ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN" code paths have to work (as they did before this commit), because Q_OS_WIN is not defined there now, nor Q_WS_WIN was defined there previously.
b) Under Windows operating systems is where the behavior has to change (the Q_OS_WIN code paths are aimed to work, because Q_OS_WIN is defined there).

You're right, Toni. It's for Windows OS the code will change and it seems to be the right thing to do. This indicates, however, that Windows code branch is basically dead, nobody compiled and used it for years. Anyway, thanks for making this aligned with current state of things.

I agree with you. Thanks Alex and Nikita! (and Moritz :-)

This revision was automatically updated to reflect the committed changes.