If you are reworking the views you might want take a look at what I did: https://cgit.kde.org/clones/krusader/janlepper/krusader.git/tree/krusader/ListView?h=port-listview-rework
Among the changes:

• remove KrViewOperator
• KrView inherits QObject
• the actual widget is a separate object of the view (take a look at KrInterView for how I id it)
• more that I can't think of right now ;)

Agreed :)

In D5292#100763, @janlepper wrote:

Hmm, I can't update the diff (permissions?)

This is safer:

diff --git a/krusader/Panel/panelfunc.cpp b/krusader/Panel/panelfunc.cpp
index 3f2b184f7..c3dcaff41 100644
--- a/krusader/Panel/panelfunc.cpp
+++ b/krusader/Panel/panelfunc.cpp
@@ -310,11 +310,15 @@ void ListPanelFunc::doRefresh()
 
     // NOTE: this is blocking. Returns false on error or interruption (cancel requested or panel
     // was deleted)
+    QPointer<ListPanel> panelSave = panel;
     const bool refreshed = fileSystemP->refresh(url);
     if (refreshed) {
         // update the history and address bar, as the actual url might differ from the one requested
         history->setCurrentUrl(fileSystemP->currentDirectory());
         panel->setNavigatorUrl(fileSystemP->currentDirectory());
+    } else if (!panelSave) {
+        // panel was deleted while refreshing
+        return;
     }
 
     panel->view->setNameToMakeCurrent(QString());

Hmm, I can't update the diff (permissions?)

Sorry for the even later reaction ;)
Well, the QPointer doesn't hurt, but it doesn't fix the problem in this case.
Actually the ListPanelFunc object is destroyed before the ListPanel, so when you do the check for this->panel, this points to already freed memory.

In D5292#99747, @abika wrote:

There has been code in place to prevent this, but looking at PanelManager::deletePanel(), the panel is now unconditionally deleted.
So a proper fix would be to re-introduce the previous behaviour.

I removed the whole code together with the previous check

if (p && p->func && p->func->files() && !p->func->files()->vfs_canDelete()) {
    connect(p->func->files(), SIGNAL(deleteAllowed()), p, SLOT(deleteLater()));
    p->func->files()->vfs_requestDelete();
    return;

mainly because it doesn't follow the principle of encapsulation in OOP. The panel manager should not have to check the inner state of the filesystem refresh invoked by the panel function object.
This fix is totally fine imo.

I'm sorry for the regression.
I assumed this situation (a panel was destroyed while still refreshing) wouldn't occur.
There has been code in place to prevent this, but looking at PanelManager::deletePanel(), the panel is now unconditionally deleted.
So a proper fix would be to re-introduce the previous behaviour.
Asynchronous refresh of course would also fix that problem.

That was fast - thanks!

Right, I didn't really think this through.
So it's probably the lesser effort to embed Lister into the result view.

Well, you could add
static void KViewer::viewWithLister(QUrl url, QString searchText)

rebased

I assume gengisdave won't comment on this (hasn't been active for a while)

In D4146#84250, @abika wrote:

I personally prefer the old behavior. After restart going back to the "nearest" parent folder of a deleted path was pretty nice. And if it was a removable device I can mount it and go back to the folder with the history.

But whatever, another user setting for this would be too much. And yes, the while (true) loop wasn't nice.

In D2857#86585, @abika wrote:

In D2857#85422, @asensi wrote:

Is the working directory really important for (any) application?

I don't recall using any, although probably some exist, and if ListPanelFunc::runCommand() works and allows that those application work correctly, probably it would be better for Krusader to use that code.

Fair enough. I reverted it.

BTW: what is the reason for dialog.hideRunInTerminal();?

Very nice!
As a next step, if I didn't miss anything, calcSpaceFileSystem in AbstractJobThread::countLocalFiles() could be removed.
The packjob should be passed a list of URLs instead of file names which would eliminate the need to determine the URLs.

In D4146#84030, @asensi wrote:

Btw: Am I right assuming that having "Krusader" as a blocking reviewer requires all members to accept?

I'm going to accept it, so everybody will see how that works :-)

Another option: Use Lister and add the necessary methods.

True, that would be easier and also do the job.
KParts::TextExtension should come in handy here.

Before I go forward I would like some more opinions ;)

I intentionally went via ListPanelFunc::runCommand() so that the panel's path is set as working directory for the command.
With KRun::displayOpenWithDialog() there is no guarantee for that.

How about that?

I'm sorry - it's just a mockup ;)
I don't think I'll be working on this in the near future - just wanted to collect some ideas.
The mc-like result list will probably require a lot of work - in KrView there is a 1:1 relationship between view item and a file, but this would require multiple items per file.

In D3994#76189, @martinkostolny wrote:

Unfortunately I don't have this area studied enough yet to consult the direction. But I certainly can test your code and report issues:). So far I found some regarding refreshing:

• external changes aren't reflected (I have to manual refresh Ctrl+R to see them)
• undo action will not refresh view after it is done
  
  But I understand it is a work in progress, so please say if it is too soon to test these "corner" cases. Anyway, thanks for Your work!

The invocation In ListPanelFunc::doRefresh() seems to rely on the panel being the active one (which was true historically - when refreshing a panel would activate itself first).
Nowadays a panel might refresh while being inactive - breaking code which relies on the workdir matching the active panel.

Just so we don't duplicate our efforts: T5017

In T3419#71290, @janlepper wrote:

In T3419#70758, @abika wrote:

I'm still unsure if we should split the vfs class (in e.g. FileLister and FileOperations). Currently there is only one method that is used without vfs: copyFiles().

It's problybly not that important.

Thinking about it, a more beneficial thing would be moving to a non-blocking
refresh refresh like in KDirLister.

Then there is vfs::calcSpace() which also blocks.
From there I stumbled on vfs::calcSpaceKIO and "TODO called from another thread, creating KIO jobs does not work here".
I recall that KIO jobs move themselves to the main (or gui?) thread, or is my memory wrong here?

In T3419#70758, @abika wrote:

I'm still unsure if we should split the vfs class (in e.g. FileLister and FileOperations). Currently there is only one method that is used without vfs: copyFiles().

If I didn't overlook something this vfs instance is never deleted:
https://cgit.kde.org/krusader.git/tree/krusader/VFS/krvfshandler.cpp?id=2f50bd46ebcc643bd99f88afef45561f4fb5d08e#n54