Tested Synchronizer, Konfigurator and DiskUsage, no problems found.

Thanks, Toni and Nikita.

...where !(_job == 0) is not equal to !_job == 0.

Isn't the result always the same?

3rd opinion. I agree it should be shown only if the file is actually going to be hidden (Show Hidden is off in settings), otherwise Krusader looks dumb. I agree that users should be able to disable the warning, because for us it may look like an uncommon operation, however some users may work with dot files extensively. This kind of attention to small details make a huge difference in user experience.

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

Thanks, Alex!

And thanks Nikita, Alex, and Moritz! (and Yuri :-)

Code looks good and still works!

Sorry, but not being able to have a way to disable the warning message is not acceptable for me. There may be users who do this renaming very often to filter folders in their list view.
Dolphin has the option to disable it, Krusader should have it too.

In D15693#531988, @nmel wrote:

@yurchor, could you please update the docs once it's merged?

Works great and the code looks clean and neat! Thanks for working on this.

Thanks for fixing the bug i introduces, Davide! Works fine.
These shortcut redirections a damn complicated.

Alex's recommendations were applied in order to ease the reading of the source code (and the changes could be applied quickly :-) ).

In D22957#514005, @asensi wrote:

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).

Didn't test myself. But if you tested it, Toni, adding the two lines should be safe.

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.

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.

Code looks good and still works!

All right, Davide and Nikita, thanks!

Note: For the tests that I performed under Kubuntu 18.04, executing dpkg -l showed:
kio 5.44.0-0ubuntu1 amd64 Resource and network access abstraction

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.

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.

The new code works using Kubuntu 18.04. Other people can do their checks. Thanks, Davide!

The new code works using Kubuntu 18.04. Other people can do their checks. Thanks, Davide!

The new code works using Kubuntu 18.04. Other people can do their checks. Thanks, Davide!

In D23001#531057, @gengisdave wrote:

I personally think that the original repo could be used, my perfect solution would be a scratch repo. But (this is a big but) the target of this set of patches shouldn't be a normal user but a distro packager, and we must show big warning saying that this does not mean that the developing is active and only trivial patches for critical bugs could be backported; sometime a single-line patch cannot be backported because all the logic around was changed, or the backport does not fix at all or even worse. Also, because the development is closed, no bugs should be reported because the first answer would be "can you try on a newer version?".

I personally think that the original repo could be used, my perfect solution would be a scratch repo. But (this is a big but) the target of this set of patches shouldn't be a normal user but a distro packager, and we must show big warning saying that this does not mean that the developing is active and only trivial patches for critical bugs could be backported; sometime a single-line patch cannot be backported because all the logic around was changed, or the backport does not fix at all or even worse. Also, because the development is closed, no bugs should be reported because the first answer would be "can you try on a newer version?".

I don't have write access to the repo, can someone please push? Thanks

The patch works fine, although it requires KIO 5.62 or a reverse patch

This diff contains combined changes on two separate repositories. Phabricator will have a problem with this kind of change. Please split into two reviews. I'm ok with the content.

Tested, it works perfectly with every archive as if it had been opened with Ark

Reviewed and tested (I'm using Plasma) - works good. Thanks for the fix, Alex!

Reviewed and tested - works good. Thanks for the fix, Toni!

The baloon-like message presents strange behaviors when doing some resizing, if someone wants propose HTML+CSS code, or an image, or other way, in order to draw attention of more developers...

The disabled source code was removed, as nobody objected to it, and it's undoable.

Sometimes people are aware that there's a git history, but leave code disabled on purpose. Anyway, this change can be undone, too :-)

The first screenshot looks better than others, IMO.

It can be restored from git history in case it's needed. It's your call.

I also have seen it when I tested published changelog files and wanted to remove it. Thanks for bringing my thoughts to live. :)
It's not rendered but mentioned in old comment in the report-bugs/index.html - can you remove the comment as well?

Reviewed and tested - all good! Thanks for the fix, Toni!

I also have seen it when I tested published changelog files and wanted to remove it. Thanks for bringing my thoughts to live. :)

Reviewed and tested - all good! Thanks for the fix, Toni!

Kindly ping

Kindly ping

Thanks, Nikita! After asking in the krusader-users mailing list, no objections were made since Aug . 19. The commit will be made.

"application/vnd.rar" was incorporated to krArc/krarc.protocol, as suggested by N. Higa. Two reminders were also added.

In D23476#520060, @nhiga wrote:

Should we also add application/vnd.rar to krArc/krarc.protocol?

Note: The krarc.protocol file is also being talked about by N. Higa in https://phabricator.kde.org/D23476

Should we also add application/vnd.rar to krArc/krarc.protocol?

+1 according to shared-mime-info the mime type is indeed application/vnd.rar

• updated SHA256 checksum

Haven't tested the patch, but the change looks good to me.

P.S.: Some steps still have to be done, like the ones that Nikita commented "It will be great to have starting steps for each type of work (for example, want to do Bug Triaging - go to the specific bugzilla link showing the list of not triaged bugs and try to repro bugs one by one, and then post your comments in the bugs)" or mentioning that a linked page is in English.

I suppose that today you have received a "Invitation to participate in a survey" mail from Lydia Pintscher. It reminds of when she wrote in https://phabricator.kde.org/T9581 about Krusader on Windows and "have you thought about using this as an opportunity to recruit someone new? Maybe a blog post or mailing list post asking if there is someone with the will and knowledge to drive this forward?", which has something to do with the subject of the present code review.

In D23309#516348, @nmel wrote:

@yurchor, in any case, the changes to the docs shall be made only in master, since stable is in the doc-freeze mode, correct?

In D23309#516339, @pino wrote:

In D23309#516337, @yurchor wrote:

The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs

https://cgit.kde.org/websites/krusader-org.git/
Just open a review request for that repository (or commit directly), it is not complicated...

Please always open a review! Committed and pushed changes are deployed directly to live site. People make mistakes, it's normal, and reviews reduce the likelihood of a mistake.

Thanks everyone!

It seems that we need some thoughts from developers on how to proceed.

In D23309#516337, @yurchor wrote:

The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs

Yes, Pino is right on the general level. The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs (slowly updates, no translations, etc.). So I'd better leave the things as is. Just my 2 cents.

Changes that were suggested.

In D23309#515733, @asensi wrote:

Note: There are some reasons why Krusader users have documentation available in their computers, maybe Yuri Chornoivan can give more information about it.

Personally, I think that there will be no harm if we have as many ways to engage new developers as we can.

In D23309#515717, @pino wrote:

TBH I'd just add the instructions to https://krusader.org/get-involved/, and not to the user documentation.