Thanks! Landed (Hope this revision will close itself).

Tested with various umasks and local / remote fs - works nicely. Please don't forget to fix the build (and possibly, the commit messages) before merging. Thanks!

Alex, it looks good now - thanks! Let me test it and I'll get back to you in a few days.

You're right Nikita. I changed it now so that local files are created with QFile. Umask is applied here.

• SQUASH_ME Panel: Create new local text files directly with QFile

Refactoring code is fine, however setting 644 unconditionally introduces a security issue. The permissions for new files should follow umask setting. Otherwise users may unintentionally share their new files with other users.

Thanks for the reviews!

Thanks. Working fine.

Nice fix and improvement. Thanks!

• fixed build and formatting

Due to no response from Davide, I'm taking over. I also see lots of deprecation warnings and would like to fix it. The most recent revision doesn't compile, however. I have a fix and will update shortly.

+1
Compiles, installs and works as expected.

Kindly ping.

Hello All,

Kindly ping.

Hello Guys,

OK, so will you provide me the necessary permissions for that? I suppose, it is this repository: git@git.kde.org:krusader.git

In D16223#345641, @nmel wrote:

In D16223#344556, @mchabrecek wrote:

I can push it, I might need some help:
Is it enough to merge my branch to master, add code review link (= Differential revision https://phabricator.kde.org/D16223 ??) and push the master?
Or is there something more?

Since this is a single change and not multiple related changes, I would squash your branch into a single commit, rebase on top of the master, add the CR link and push it. Thanks!

In D16223#344556, @mchabrecek wrote:

I can push it, I might need some help:
Is it enough to merge my branch to master, add code review link (= Differential revision https://phabricator.kde.org/D16223 ??) and push the master?
Or is there something more?

In D16223#344206, @nmel wrote:

In D16223#344018, @mchabrecek wrote:

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

For minor tweaks like this we usually approve and let author incorporate the fixes before pushing. Just to reduce turnaround time. Of course, if someone else pushes (or lands) the change, the author should send updated diff first.

Miroslav, are you going to push this change to the repo or you want us to do it? I think it's worth getting the permission as you're going to do several consecutive changes on this refactoring and, hopefully, other improvements. Please read our commit guidelines before pushing.

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:/