Now it works perfectly, thanks! :)

Thanks for working on this! :-)

I've managed to get more info about the crash also by following this guide:
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves#Attaching_gdb_to_an_io-slave

Thanks for guidance regarding getting additional debug info. I'll try to get it soon :).

Hi! Probably after this commit sftp slave crashes when showing a directory with links. Please see my code comment. Can you also reproduce or is it on my side only?

Alex, I remember You wanted to do that. So if You still want, feel free to work on it :). If not, I'm going to dive in.

Works as expected. Thanks! :)

I like this change, thanks Davide! I think ::sorry dialog is even better for this scenario but that's a matter of taste :).

From my testing, it is now working nicely. Thanks, Alex!

Thanks!

Hello after some time. I finally manage to more or less finish the layout rework I was planning. I tried to work in most of what we discussed here.

I also think it would be better if search-as-you-type mode was configurable. On top of the proposed change of course :).

I agree, too. Thanks, Yuri!

Except the doc changelog mentioned by Toni I haven't found any obvious missing pieces. Thanks Nikita!

Thanks Toni for updating the website! I agree with the current state of this diff.

Thanks Alex! It is working as expected. And like Toni said, the behaviour is much simpler now :).

Thanks, Toni! :)

Nice :).

Nikita, thanks for merging this big thing.

In D12369#253383, @nmel wrote:

It means that you can assign shortcuts to specific bookmarks and those were stopped working after managing. For example, I assigned Ctrl+~ to the root data dir on my machine because it's like a home for the most data. This Ctrl+~ is lost together with toolbar buttons. Now it works without a problem.

Good work stacking the changes, Nikita, thanks!

Accepting the update, thanks!

In-source builds are highly discouraged by CMake. This case is not in-source (binaries are not placed beside source files) or out-of-source (binaries are still inside the source tree). Not a big deal, IMO.

Thanks Toni!

I was so used to building in nested build folder. KDevelop itself propose it as a default build path. But maybe it is a bad practice, I don't know. Is it? :) I'm accepting since the other change is needed for sure.

Thanks!

Nicely fixed, thanks Nikita!

Same here, replicated with attached krusaderrc. And it no longer happens with this patch. Thanks, Nikita! :)

Sorry for my late response. Thanks Nikita for fixing all the issues and Toni for useful testing screenshots.

Thanks Nikita for your big work! :) It works nicely. I have 2 observations:

1. choosing dark theme not working in dark environment - I'm proposing a simple solution - please see my code comment
2. icon "application-x-cmakecache" (e.g. for file CMakeCache.txt inside krusader/build folder) is now rendered as a fallback icon (even with breeze) although previously it was rendered as "unknown"
   • I'm not sure if this is even solvable, or if it is important; I was currently unable to come up with a solution

Thanks, Nikita!

Maybe we need to use something neutral like circle or diamond... With these missing/unreadable/broken icons the app looks like a broken one while it's not...
Also, I guess we better save a particular image we pick into the resource file, so we can load it for sure. Are you fine with it?

Same goes for me, sorry for not replying. The patch works as expected :).

I'm fine with "emblem-unreadable" although my preference would rather be "image-missing" :).

Fine work, Nikita, now it works! Thanks for the investigation:). I've tested it in Plasma (on Arch linux) as well as in Ubuntu 17.10 VM.

Nikita, I like this approach, thanks for working on this! Sorry it took me so long.

Thanks, Toni! :)

Last info: on my side everything seems to compile and work just fine now. Thanks for your work! :)

Rade, interesting thought about the OFM standard! I've created a topic in krusader-devel so we can discuss:
https://groups.google.com/forum/#!topic/krusader-devel/zu1dE3GUK0w

Works on top of latest branch commit. Thanks! :)

I propose we add CHANGED: ... to commit message, so it goes to the ChangeLog.

Thanks for fixing the shift scenarios. And good idea with the smart case-matching, I like that :).

Thanks, Rade, for the fix :).

Now everything seems to work just fine, thanks!

Sorry for being dark for so long, Radek. I was busy and I hope it will get better. Thanks a lot for your ideas.

Sorry it took me so long.

Thank you both for the effort to fix this issue! I'm accepting since this patch fixes the issue flawlessly and is readable for me. Rade's readability code suggestion is also OK but I really cannot decide which one is better, sorry :).

Nikita, thanks for review and testing! However I'm abandoning this diff because Alex wrote a more comprehensive patch for the problem. So we can discuss there: D11840

Hi Alex! Thanks for looking into this. You seem to have a complex patch that fixes more issues regarding the refreshing. I'll abandon D11699 in favour of this one.

Thanks Nikita for unifying the comments and docs!

Looks good, although I think it should be "won't" not "wouldn't" as it is an action that will not happen in the future not an action that has not happened in the past. I think there should be a 'the' between 'in' and 'currently' as well, but it's perfectly understandable without it.

Sorry about that, I should have waited a bit longer. So how about this?

// removing action from previous menu is necessary 
// otherwise it wouldn't be displayed in currently populating menu
if (_mainBookmarkPopup) {
    _mainBookmarkPopup->removeAction(_quickSearchAction);
}

I found the change that's introduced the lines you want to remove. As the lines were added as a response to a bug, I was interested what was the problem.

I think the root cause is slightly different because if your statement were true, the bar wouldn't be shown again with the same menu where it was shown for the first time. Likely, if you add an action to many menus (in this case, each tab has its own menu), QWidgetAction is displayed only on the first one. Given many menus could be visible at the same time, it might be a feature, not a bug...

Sorry for the first iteration in this CR. It seems I still have much to learn with arc :).

Thanks for taking the time to trace the code changes!

Works nice, thanks!

Thanks for extensive info! I was still unable to see all the warnings with the flags -Wmaybe-uninitialized -Wstrict-aliasing -Wunused-result enabled. So I guess it is indeed specific to GCC version 7. It doesn't really matter, thanks Nikita for taking care of the warnings!

Can you test the latest revision one more time?

ideas are appreciated

Just testing info: it works nicely, thanks! :) I'll test further diff updates if there are any.

Is there a better way too accomplish what I have done? E.g without having to add a new function to listpanel?

Thanks Nikita for fixing the warnings :). I can only replicate the one in krjob.cpp. How do do I display the rest of the warnings? I've only used -DCMAKE_BUILD_TYPE=Release when calling cmake, is there something else to set up for release building? Maybe the version of my gcc (7.3.1) can play a part in this...

Is there something I may be doing wrong?

Sorry to be late on this. I cannot compile plasma-pa anymore after this change with error:

Scanning dependencies of target org.kde.plasma.volume-plasmoids-contents-rcc
make[2]: *** No rule to make target 'applet/org.kde.plasma.volume-contents.rcc', needed by 'applet/CMakeFiles/org.kde.plasma.volume-plasmoids-contents-rcc'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:191: applet/CMakeFiles/org.kde.plasma.volume-plasmoids-contents-rcc.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

Hi! After this commit various akonadi dependent projects won't compile - e.g. akonadi-contacts, akonadi-mime and others claiming this error:

In file included from /home/kotelnik/kde/usr/include/KF5/AkonadiCore/item.h:27:0,
                 from /home/kotelnik/kde/usr/include/KF5/AkonadiCore/itemfetchjob.h:24,
                 from /home/kotelnik/kde/src/kde/pim/akonadi-mime/src/removeduplicatesjob.cpp:23:
/home/kotelnik/kde/usr/include/KF5/AkonadiCore/tag.h:25:10: fatal error: akonadicore_debug.h: No such file or directory
 #include "akonadicore_debug.h"
          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.

I'm using kdesrc-build environment.

Thanks for the fix!

In D11624#233131, @rade wrote:

Given Rade's points, I see that it may be useful for some people, so I suggest we add another config option "Search in special items" for this feature and stop arguing. My only ask is to leave it off by default.

Sounds good to me. Would you mind doing the patch for it though? I'm not really sure how the config code works, and you seem to have a good grasp of it.

It works:), thanks!

Thanks Nikita for looking into this! I was unable to test it until now since I don't usually have access to a PC with standard keyboard with numeric keypad. It works nicely.

adding all the keys we _know_ we don't want to search for like tab etc to the filtering if statement is a good idea

Works nicely, thanks!

Agreed with Rade about the missing displayed shortcuts. Otherwise it works nicely, thanks!

Nice! I have to note that this only works without issue if it is applied along with D11523.

It seems to work nicely. Thanks!

Thank you both for the review :)