In D16223#344018, @mchabrecek wrote:

Is it approved and will be landed, or I have to send another arc diff with these 3 adjustments?

• Fixed spacing

Is it approved and will be landed, or I have to send another arc diff with these 3 adjustments?

You have to make the changes requested by Nikita.

In D16223#343997, @nmel wrote:

Thanks and welcome aboard Miroslav!

Thanks and welcome aboard Miroslav!

Looks much better, thanks!

I only skim-read the changes, looks fine.
And Krusader seems to work with the changes.

I have submitted the first patch here regarding signals and slots. It doesn't solve all the connect() statements. There many hundreds of them. I want to do it in more patches. One reason is that this is my first patch to this project. So I didn't work at something for 6 months and then struggle to submit it. It is here, can you check it? https://phabricator.kde.org/D16223.

I thought I had already committed that... changed to a more human macro name

Thank you for help,

Maybe a visual hint would be good so that the users know this feature exists.

Some changes were made after Alex Bikadorov made some propositions.

Some changes were made after Alex Bikadorov made some propositions.

Hi Miro,

Hello,
I started to work on replacing old connect() wih Qt5 syntax.
Alex wrote me that it would be the best to do automatically by some script, I don't see it realistic.
There are some tricky cases, which I don't know how to convert. May be you can help me.

Deletion was working as expected during tests. Maybe a visual hint would be good so that the users know this feature exists.

Since INSERT becomes kind of "global" macro, I suggest we rename it to UDS_ENTRY_INSERT, since the insert word is too generic while the implementation is not. Thanks!

Another address was updated

An address was updated

Thanks, Nikita, those lines will be added to the commit message:

FIXED: Memory leak in the Locate dialog
Differential Revision: https://phabricator.kde.org/D15678

Confirmed by the build (https://build.kde.org/job/Extragear/job/krusader/job/kf5-qt5%20FreeBSDQt5.11/4/warnings12Result/), 51 warnings fixed and 'missing-override' is not in the remaining 57.

Confirmed by the build (https://build.kde.org/job/Extragear/job/krusader/job/kf5-qt5%20FreeBSDQt5.11/4/warnings12Result/), 51 warnings fixed and 'missing-override' is not in the remaining 57.

Thanks Davide! This looks less cluttered.

Thanks Toni!

In D15400#328384, @gengisdave wrote:

every user is a tester too.

More importantly, whenever we make a change after this is merged, we will see the warning and fix the code. We put an effort before v2.7 release to make Krusader warning-free and we should keep it this way. So now the -Wsuggest-override is on the list of warning directives that we track. Thanks Davide (and Toni ;) )!

The new version works using Kubuntu 18.04. Other people can do their checks. Thanks, Davide! (and Nikita :-) )

Changed in favor of a macro solution (as suggested by Nikita).

In D15376#325404, @asensi wrote:

What do you think about creating a specialized version of UDSEntry, e.g. KrUDSEntry? This way the code:

Added flag for GCC as default

I've looked at the Clang behaviour: the -Winconsistent-missing-override flag is always set (Debug, Release and none), so GCC should be set the same. My initial thought was to not users to be worried; on a second thought, every user is a tester too.

Why not to update the flags for both debug and release (CMAKE_CXX_FLAGS var)? What's your reasoning? Does it hurt the release build?

I've tested with clang compiler and no additional flags are needed, on a clean Fedora 28 I used:

Thanks Davide! (and Nikita :-) )

It's nice to hear from you again, Davide!

Indeed, all warnings of this type are fixed. Thanks Davide!

In D15376#324514, @gengisdave wrote:

Where to put the macro? The three files don't have a common header file and I haven't found a suitable .h file; any advice?

The use of a Macro was my second way to solve this, but I thought it would add more complexity to the code; instead, this patch makes the code unclear to read.

I updated the diff to v2 to fix spaces as requested.

and reproducible adding -Wsuggest-override or -Winconsistent-missing-override (not sure, haven't tested with clang) to CMAKE_CXX_FLAGS

Should we add this into cmake config file to ensure that these flags are always on?

inline

In T9581#158530, @abika wrote:

My concern now is this: If you put effort in creating a Windows package for Krusader and there will be bugs (I bet there will), there should be someone working on it. Unfortunately we already don't have enough developer time to solve the >100 open bugs currently open for Krusader. And support for Windows will come on top of that. I would like to avoid a half working Windows version which will never be "stable" and that the effort will be for nothing.

Regarding background: You might want to read the blog posts here: http://kfunk.org/tag/kde-windows/ -- specifically: http://kfunk.org/2016/06/18/kde-on-windows-update/

Hi Lydia and everyone else,

Thank you very much for all, Lydia, although as far as Krusader developers know, there is no Windows version of Krusader (contributions are very welcome :-)).

For future reference, the commits may be seen in:

• https://commits.kde.org/krusader/a595bc13e3dbc7cf8f5b39988090e7422b689a4e
• https://commits.kde.org/krusader/9d0727b4b734691a58046748593254e6eed3262b

pushed. Forgot to include the link to this Diff in the commit message:/

• updated SHA256

It looks right to me :-)

For my part, I accept the proposal, thanks :-)

It looks all right to me :-)

Apply to stable branch. This will go after changelog / news update commits.

• updated documentation ChangeLog

In D14416#299836, @nmel wrote:

Hi Pino, Thanks for the suggestion. I didn't know about the tool. I briefly read the doc and found

Updating the configuration happens automatically, either when KDE gets started or when kded detects a new update file in the above mentioned location.

which means non-KDE users are out of luck. Am I right?

Thanks Toni! Works nicely.

In D14416#299821, @pino wrote:

Or, even better, use kconf_update to automatically migrate the setting to the new name, with no need to add fallback code to the application itself.
See https://techbase.kde.org/Development/Tools/Using_kconf_update
You can find examples of scripts for kconf_update in many applications, e.g. kmail, konversation, kontact, okular, tellico, kget, kcalc, akregator, gwenview, kile, etc.

Or, even better, use kconf_update to automatically migrate the setting to the new name, with no need to add fallback code to the application itself.
See https://techbase.kde.org/Development/Tools/Using_kconf_update
You can find examples of scripts for kconf_update in many applications, e.g. kmail, konversation, kontact, okular, tellico, kget, kcalc, akregator, gwenview, kile, etc.

Please also add FIXED: tag. See https://phabricator.kde.org/w/krusader/#commit-patch-guidelines

Please add fallback logic for the old setting. We can deprecate the fallback code with 2.9+ release.