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.

This looks good to me. Have only looked at the changes. Not tested it locally.

In D14266#297927, @szafar wrote:

When I created these commits on my local machine, they were committed with git as:
Author: Shadab Zafar <dufferzafar0@gmail.com>

But, now the commits are showing up in git as:
Author: Shadab Zafar <szafar@gmail.com>

I don't own that email address and have no clue where it came from.

Is there a way I can fix this for my future commits?

@yurchor

When I created these commits on my local machine, they were committed with git as:
Author: Shadab Zafar <dufferzafar0@gmail.com>

> ... if users pressed Tab when using the KTextEdit named textDescription, then the focus would go to the next control ...

In D13904#289074, @asensi wrote:

Thanks, Nikita. I'm not aware of a way to choose the kioslave modules that are going to be used, if it may help: to debug a kioslave what I did was using a virtual machine, where I was able to use the standard places for Krusader.

In D14230#294864, @asensi wrote:

... if users pressed Tab when using the KTextEdit named textDescription, then the focus would go to the next control ...

Thanks, Shadab, now the tutorial is better :-)

Thank you, Alex! For my part, using Kubuntu 18.04: my performed tests went alright, and the source code looks better :-) . Other people can do their checks.

First commit changes the layout of the result tab in the search dialog a
bit. E.g. the "Search text:" field is only shown the user specified text to
search for.

• Improve English in actions_tutorial doc

Thanks! Just a few minor corrections please.

While we are at it:

The tabstops list was changed because "KeyButtonShortcut" was a special case.

Thanks! Please use git cherry-pick -x when updating 2.7 branch in the future.

For this kind of change please go through reviews in the future because any change becomes live automatically.

In T8662#151300, @asensi wrote:

I prefer reviewing changes before applying them, but I understand that we often lack time :-)

Tested, works as expected. Thanks a lot Toni!

The changes were applied after talking in https://phabricator.kde.org/T8661 and https://phabricator.kde.org/T8662. The commit can be seen in https://commits.kde.org/websites/krusader-org/77cbd247bac59546826b2d1bbbce9810322868c8

Thanks, Nikita, it's done :-) .

Thanks, Alex, it's done :-) .

The diff was updated because of some posterior changes.

I have trouble applying the patch to current master:

$ arc patch D13499
 INFO  Base commit is not in local repository; trying to fetch.
Created and checked out branch arcpatch-D13499.
Checking patch krusader/Panel/panelfunc.cpp...
error: while searching for:

Hi Toni,

Oh, sorry. Yes, this was lost.
But simply add to the documentation what you think is importance. The wiki is a collaboration tool with edit history for us developers and users No need to ask for permission imo.

Mmm... more than two months have passed :-) ... This is just a message so that this differential revision is not forgotten.

Nikita, if you haven't got the time for this change, I can do the changes myself.

Sry, I know not more than https://www.startpage.com/do/search?q=python+kio. You should ask on kde-devel@kde.org.

Not the best place to ask, but is there a way to integrate KIO in my application that is written in Python + PyQt and not in C++ ?

Tell me this - can other command line applications interact with stash:// ?

Yeah, I keep forgetting the fact that virt:// is totally inside Krusader and dolphin or other apps can't see the results.

An include was moved to the cpp file, as Nikita wrote.

Thanks, Nikita. I'm not aware of a way to choose the kioslave modules that are going to be used, if it may help: to debug a kioslave what I did was using a virtual machine, where I was able to use the standard places for Krusader.

Took some time but now its in master.

Reviewed and tested - works nicely!
Please push this.

In D13499#287720, @asensi wrote:

Unfortunately, I need to take this back. I recently tested TC and it doesn't cancel the filter in this case, only hides the bar

You don't have to worry, I suppose that nobody was thinking about e.g. ending a quickfilter after F4 is used.

Toni, this sounds like a great change! Thanks for working on this!

Unfortunately, I need to take this back. I recently tested TC and it doesn't cancel the filter in this case, only hides the bar

Thanks Toni and Yuri.

In D13499#284250, @nmel wrote:

In D13499#281839, @yurchor wrote:

Just used to press Esc. But it's a habit. For sure, it is more convenient to have fewer keystrokes... Just my 2 cents.

Thanks for the feedback! Do you think it should be applied to all bar modes?

In D13499#281839, @yurchor wrote:

Just used to press Esc. But it's a habit. For sure, it is more convenient to have fewer keystrokes... Just my 2 cents.

Toni, thanks for checking and testing.

In D13499#280459, @nmel wrote:

Added more people explicitly - guys, what's your opinion on this subject and do you know if the behavior is changed intentionally or not?

Toni, you mentioned an old VM with an old Krusader on it — can you check, please?

Thanks for the review and useful tips, Toni!

This thing bugs me for a while, and now I finally have a chance to fix it. I think it's a regression from previous versions because I remember my frustration when it was introduced. According to the related bug, it should be before v2.4.0-beta1, but I don't have any really old versions installed. Toni, you mentioned an old VM with an old Krusader on it — can you check, please?

Thank you all! For my part, using Kubuntu 18.04: my performed tests went alright; some files (inside an iso file) that could not be seen, now can be seen correctly. Other people can do their checks.

Added more people explicitly - guys, what's your opinion on this subject and do you know if the behavior is changed intentionally or not?

Note: The tag "Krusader" was added to the present differential revision so that it's seen now at least in https://phabricator.kde.org/project/view/79/ and https://phabricator.kde.org/tag/krusader/ , and consequently more people may review this proposal.

Nice! There's more information in https://phabricator.kde.org/D13572

Was it changed for a reason?

I confirm that what Nikita tried doesn't work. Thanks, Nikita!

In D13499#277695, @asensi wrote:

I think the current behavior is useful as is, i.e. keep the search active unless the dir is changed. Let's discuss more and
consider implementing an option to keep current behavior.

Mmm... Krusader's behavior was that, after quicksearching a file, when pressing Return (or Enter), the search bar was hidden (like Total Commander or Double Commander) but after Krusader 2.4.0-beta3 the behavior was changed.

In D13497#277928, @abika wrote:

Deletion (== physical deletion OR moveToTrash) should be possible inside the virtual directories the normal way with the Delete key, F11, etc.. This has always been like that (or as far as i know Krusader), I only refactored the code.

Explanation, as this is my code:
The files()->isRoot() condition is intended. Virtual deletion is only possible when the current directory is the root of vfs:// containing virtual directories. Deletion (== physical deletion OR moveToTrash) should be possible inside the virtual directories the normal way with the Delete key, F11, etc.. This has always been like that (or as far as i know Krusader), I only refactored the code.

Also, using Krusader 2.4.0-beta3, when "files fed to list box" are deleted... they are physically deleted.

> Removal of items from virtual lists is not a very handful feature after all...

I think the current behavior is useful as is, i.e. keep the search active unless the dir is changed. Let's discuss more and
consider implementing an option to keep current behavior.

Thanks for testing, Toni!

I think the current behavior is useful as is, i.e. keep the search active unless the dir is changed. Let's discuss more and consider implementing an option to keep current behavior.
Also, why have you decided to apply only to Search mode? Following the logic regarding Total Commander, it uses Filter mode for its quicksearch. In addition, for Select + F8/Del it might be useful to hide the bar, as there is nothing remain to select, but I'm not sure if it's good in terms of consistency.