Trying to roll back the diff made to this revision instead of having created a new revision.

• Add ability to drag entries from the sidebar tree

In D29871#676166, @dfaure wrote:

In D29871#676150, @rrosch wrote:

I didn't have an assert before though, should I replace the if statement with a Q_ASSERT then?

Yes I still believe you should.

I thought that was just to catch errors

Yes, it is. If everything works as intended, this method will never be called with canToggleShowHiddenFolders == false.
And if() makes people think that it can, which is just not true.

but since this is just an option

What is an option?

(and hence shouldn't cause problems when false)

Confusing code is a problem.

Q_ASSERT instead of redundant if(), as suggested

Argh, sorry about that.

Latest round of modifications according to review notes.

Removing unnecessary comment.

Added changes as requested.

Added the context menu code.

Hi all, if it's ok for me to weigh in on this a bit, I will say firstly that I love kate/kwrite, and was immediately blown away by both when I (finally) discovered them recently.

I agree about the cruft, and I highly recommend against shipping two home desktop files. As I have it now, it's just one extra line in two files, which an administrator could edit, or copy, if so motivated. At least on FC30, the kio plugin for fonts:/ is included in a package separate to konqueror (plasma_desktop, if I remember correctly), so someone could theoretically just create packages for sidebar buttons they want to have on their system, and use the current button .desktop files for reference. It's what falkon is doing for themes, for example.

Ahh, that would definitely be an interesting approach. Would you be opposed to having what is currently done incorporated now? I can't allocate time to implement your approach, or think of use cases where someone might want to choose one over the other (or potential problems with your approach), but at least with this we can have the option in there. For sure a context menu toggle would avoid any potential issues there could be (I have tons of old hidden folders in my home directory for example, I wouldn't always want it showing or toggling automatically on).

In D29871#675954, @dfaure wrote:

The commit log explains the what but not the why. Can you give more details about the use case for this? At first sight it smells like overconfigurability (given that the user can already request that hidden files are shown, more globally).

I just found this unsubmitted comment, not sure what happened, but I figured it would be useful information to pass along anyway. (I somehow managed to work around it a month ago, without compiling ECM):

Eighth revision of the konq sidebar code. After review.

Seventh revision of the konq sidebar code. After review.

By the way, this prevents compilation of the not-yet-committed sidebar panel code. Specifically, the sidebar/web_module/web_module.cpp

Seventh revision, after review (minor edit)

Seventh revision, after review

Sixth version, after review, fixing rebase(?)

• Sixth revision of the konq sidebar code. After review

Is there a temporary workaround for people who cannot yet upgrade to 5.68? Something we could wrap in something like

Getting a CMake error on plugins/fsview/CMakeLists.txt line 16 (ecm_qt_declare_logging_category). Fedora 30, i686, KF5 5.64.

Tested, no crashes, it works as intended, and it is beautiful! Thank you!

Hi, sorry for the lack of responses, for some reason I did not receive any of the notifications except this last one. I will test and comment as soon as I can. Wishing everyone safety and health too.

Keep only matters for further calls to openUrl, not the first one. It's about whether to *add* or *replace* the currently open URL.
KDirModel takes care of that.

Ok, I found one of the "implications". With model->dirLister()->openUrl(m_initURL, KDirLister::Keep); I can list KIO urls like remote:, font:, and applications:, but with model->openUrl(m_initURL, KDirModel::ShowRoot); I cannot, and only seems to display the the local filesystem (specifically it lists "/"). I can probably work around it, but just wanted to pass that info along. I think it would be great if the "root" could be shown for these as well.

Tested on patched KF5 5.64, on Fedora 30 (32bit)... root node shows up! I had to change the call in my code that was originally:

Patch at
https://invent.kde.org/kde/kate/commit/54b3fd74f74f604932b93f46aeaba4e8f5e9a2aa works as intended! Thanks!

I agree that sorting needs to be improved, however I don't have the skills right now (or time) to implement them.
Ideally the number of open files should sort numerically, and the last opened should sort via timestamp, to allow for locale-based display. But both of these require the same intrinsic change that I don't know how to do yet (the class is chosen by the .ui file, and a new overloaded class with the proper sorting functions would need to be implemented). But with this first set of changes in this patch we can get something out there for people to use now. Someone else might come later to do that, just as I did for this part.

As requested. You will notice that the button to sort has been removed and sorting is done only by clicking the header bars.

Implemented the changes suggested by dfaure.

Done! I submitted the merge via https://invent.kde.org/kde/konsole/merge_requests/19