*** Bug 440924 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/258

*** Bug 441359 has been marked as a duplicate of this bug. ***

Git commit 542e2a214a48a0eba6938381f1e043a37909f200 by Alexander Lohnau.
Committed on 24/08/2021 at 14:21.
Pushed by alex into branch 'release/21.08'.

Fix selecting file always opening new instance

Instead try to attach to all existing instances and quit after succeeding.

M  +6    -8    src/global.cpp

https://invent.kde.org/system/dolphin/commit/542e2a214a48a0eba6938381f1e043a37909f200

*** Bug 441775 has been marked as a duplicate of this bug. ***

I don't see why this bug is marked as "resolved/fixed". I just got the update to kde gear 21.08.1 on my Neon user-edition box and nothing changed.
After compression it opens a new tab in Dolphin.

I'm also still seeing this bug in Dolphin 21.08.1 when actions are performed through the context menu. Here's the current behavior on my system:

X11 (Plasma): Compression opens a new tab in Dolphin. Extraction works as expected.

Wayland (Plasma and Swaywm): Both compression and extraction open a new instance of Dolphin.

Software versions (Arch Linux):
KDE Frameworks 5.85.0
Qt 5.15.2
Dolphin and Ark 21.08.1

It was later discovered that there are two issues. One was fixed here, and the other one was that Dolphin is failing to exit properly when its last window is closed, which masks the fix. With 21.08.1, can you confirm that when you experience this bug, there was secretly a dolphin process still running in the background?

If so, let's get a new bug report filed about that. It will need to be fixed separately. I believe some efforts are already underway to investigate, but it's good to get a bug report to track the issue too.

I still see the bug on a freshly booted system with no dolphin process running in the background. Dolphin remained running in the background only occasionally; I couldn't reproduce that specific problem consistently and most times the program exits properly.

(In reply to NewmanIsaac from comment #7) 
> Wayland (Plasma and Swaywm): Both compression and extraction open a new
> instance of Dolphin.
> 
This was fixed in master: https://invent.kde.org/system/dolphin/-/merge_requests/261,
maybe need to backport to some "release" branch.

(In reply to NewmanIsaac from comment #9)
> Dolphin remained running in the background only
> occasionally; I couldn't reproduce that specific problem consistently and
> most times the program exits properly.

This is tracked in bug 441813, steps to reproduce also present.
If you can find other cases, please report.

(In reply to Andrey from comment #10)
> (In reply to NewmanIsaac from comment #7) 
> > Wayland (Plasma and Swaywm): Both compression and extraction open a new
> > instance of Dolphin.
> > 
> This was fixed in master:
> https://invent.kde.org/system/dolphin/-/merge_requests/261,
> maybe need to backport to some "release" branch.
> 
> (In reply to NewmanIsaac from comment #9)
> > Dolphin remained running in the background only
> > occasionally; I couldn't reproduce that specific problem consistently and
> > most times the program exits properly.
> 
> This is tracked in bug 441813, steps to reproduce also present.
> If you can find other cases, please report.

Was it fixed in dolphin or in ark? In Dolphin 21.08.1 I still experience this bug if I:
- Launch dolphin.
- Right click some compressed file and select "Extract" -> "Extract here, autodetect subfolder".

Is there a reason that this is not backported and fixed in  21.08.×?
It is a bug and not a change

*** Bug 442477 has been marked as a duplicate of this bug. ***

This bug is still reproducible at least on Wayland session of neon unstable.
I new tab opens in Dolphin after an extraction.

on neon unstable a new tab is open in Dolphin even when I cancel a compression via Plasma notification.

Created attachment 141826 [details]
video of the bug

This is probably related to this bug, if not please tell me so I can open a new bug report.

I am seeing this on dolphin 21.08.1

If a archive (rar/zip) is located in a folder where I just unfold the folder and extract the archive through the context menu, dolphin opens a new tab of the folder. When I access the folder and perform the same task, no new tab gets opened.

Please see the attached video.

*** Bug 442963 has been marked as a duplicate of this bug. ***

Still present in dolphin 21.08.2, on X11.

Do "extract archive here" on any archive file:
New window created, process '/usr/bin/dolphin <cwd>' created.

Do "compress here" on any file, (any archive type):
New window created, process '/usr/bin/dolphin --new-window --select <archive file>' created.

All extraneous dolphin processes terminate when their respective windows are closed, as expected.

This is extremely annoying, and clearly a regression. If it's fixed in 21.12 (is this time travel, or some secret release?), why not backport it to 21.08.x?

Confirmed on 21.08.2

Might be related to this issue:

https://forum.manjaro.org/t/ark-7zip-and-zip-compression-not-working-properly-and-crashing-dolphin/87123/39?u=winnie

And this bug:

https://bugs.kde.org/show_bug.cgi?id=442774


---


With Dolphin at 21.08.2 and Frameworks at 5.87.0, but with Ark at 21.08.1, it reveals this bug. If Ark is at 21.08.2 with the above combination, it reveals a different bug (ID: 442774), URL pasted above.

CORRECTION:

I meant to write "Confirmed on 21.08.1 for THIS bug, and on 21.08.2 on the OTHER possibly related bug."

*** Bug 444316 has been marked as a duplicate of this bug. ***

This bug is also happening on Kubuntu 21.10 using Plasma 5.23.2

Whenever I create a ZIP file using Right Click > Compress > Here (as ZIP), when the ZIP file is created a new tab is opened in Dolphin with the new ZIP file selected.

System info:
Operating System: Kubuntu 21.10
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.13.0-20-generic (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor
Memory: 15,6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1660/PCIe/SSE2

I also confirm this bug in my system.

Operating System: KDE neon 5.23
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.3
Kernel Version: 5.11.0-38-generic (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2

I confirm this bug too :

Operating System: Manjaro Linux
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.10-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor
Memory: 15.6 Gio of RAM
Graphics Processor: NVIDIA GeForce RTX 2070/PCIe/SSE2

Ark still opens a new Dolphin window although it's supposed to be fixed.

Operating System: Arch Linux
KDE Plasma Version: 5.23.3
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Graphics Platform: X11

(In reply to Andrey from comment #10)
> This was fixed in master:
> https://invent.kde.org/system/dolphin/-/merge_requests/261,
> maybe need to backport to some "release" branch.

While this does apply cleanly to the dolphin 21.08.3 release branch, it does _not_ fix the problem, at least not on X11. 

Whether or not it works on wayland I don't know, and frankly don't care, as plasma (along with pretty much everything else) on wayland is still largely unusable for people who actually want their system to do productive work. 



Since there appears to be little interest in fixing this regression, perhaps someone would be so kind as to point me at which particular short-sighted, untested "wayland fix" broke my desktop this time, so I can nuke it from orbit?

I have to admit that I am a bit baffled by this bug being 3 months old and a (potential) fix not to be expected before december, too. 

If we know what commit caused this, why was this not reverted before release, or at very least in a point release?

(In reply to Steve Vialle from comment #27)
> (In reply to Andrey from comment #10)
> > This was fixed in master:
> > https://invent.kde.org/system/dolphin/-/merge_requests/261,
> > maybe need to backport to some "release" branch.
> 
> While this does apply cleanly to the dolphin 21.08.3 release branch, it does
> _not_ fix the problem, at least not on X11. 
Sorry for the confusion, this probably were two different bugs with similar symptoms, which results they both have been tracked here in one issue.
So this was original fix:
https://invent.kde.org/system/dolphin/-/merge_requests/258
And these are mostly tested on Wayland:
https://invent.kde.org/system/dolphin/-/merge_requests/261
https://invent.kde.org/frameworks/kio/-/merge_requests/554

The latter two were not backported to stable but solved the issue on Wayland for me, it would be good if someone confirm on Neon unstable in VM e.g

I get the same results on both X11 and Wayland sessions of my neon unstable. The bug no longer occurs if 'Open new folders in tabs' option is checked in Dolphin settings. If said option is unchecked, both "Extract archive here' and 'Extract archive here, autodetect subfolder' options from
conttext menu open a new instance of Dolphin after extraction.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.23.80
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.3
Graphics Platform: Wayland

For context, I'm gathering that this regression came to be because of this behaviour change:

> What we want to happen is Dolphin to focus the window we have with the file selected.
> -- https://invent.kde.org/frameworks/kio/-/merge_requests/554

In my opinion, we should go back to the previous KDE 5.22.4 behaviour which is to compress/extract in the background. I'm not sure if this "we want to focus the window" idea is intended to interrupt the user, since even fixing the new tab/window regression sounds like a new problem would be introduced: I could be in another program doing other things and Dolphin jumps to the top (like it already gets in the way now). Even flashing in the 'taskbar' might not be suitable, because I may have changed folder/tabs after a long compression/extraction has completed. At the very least, an option to turn off any focus/attention grabbing feature would be appreciated.

If the idea is to help the user return to the folder, instead of trying to bring the window into focus, the notification that reads "Compressing a file (Finished)" & "Extracting Files (Finished)" might be a better outlet. There's already a button for "Open Containing Folder" for the extraction, but there isn't one for the compression notification.

Currently in 5.23.3 / Frameworks 5.88, there are similar instance-related bugs, and possibly causing confusion and/or may be related to this change:
- When compressing a file, and the window is closed, Dolphin crashes and the compression doesn't complete.
- When extracting a file, and is cancelled via notification, Dolphin continues to extract in the background.

(In reply to Luke Horwell from comment #31)

> Currently in 5.23.3 / Frameworks 5.88, there are similar instance-related
> bugs, and possibly causing confusion and/or may be related to this change:
> - When compressing a file, and the window is closed, Dolphin crashes and the
> compression doesn't complete.
> - When extracting a file, and is cancelled via notification, Dolphin
> continues to extract in the background.

Are there bug reports for these you could link? At least the first one sounds critical enough to warrant a revert for now, and personally I think the first one would also warrant raising the criticality.

Thanks in advance and kind regards

(In reply to Luke Horwell from comment #31)
> - When compressing a file, and the window is closed, Dolphin crashes and the
> compression doesn't complete.
> - When extracting a file, and is cancelled via notification, Dolphin
> continues to extract in the background.

crash reported as bug 445527. I'm unable to reproduce the another problem on neon unstable.

(In reply to Luke Horwell from comment #31)
> For context, I'm gathering that this regression came to be because of this
> behaviour change:
> 
> > What we want to happen is Dolphin to focus the window we have with the file selected.
> > -- https://invent.kde.org/frameworks/kio/-/merge_requests/554
> 
> In my opinion, we should go back to the previous KDE 5.22.4 behaviour which
> is to compress/extract in the background. I'm not sure if this "we want to
> focus the window" idea is intended to interrupt the user, since even fixing
> the new tab/window regression sounds like a new problem would be introduced:
> I could be in another program doing other things and Dolphin jumps to the
> top (like it already gets in the way now). Even flashing in the 'taskbar'
> might not be suitable, because I may have changed folder/tabs after a long
> compression/extraction has completed. At the very least, an option to turn
> off any focus/attention grabbing feature would be appreciated.
> 
> If the idea is to help the user return to the folder, instead of trying to
> bring the window into focus, the notification that reads "Compressing a file
> (Finished)" & "Extracting Files (Finished)" might be a better outlet.
> There's already a button for "Open Containing Folder" for the extraction,
> but there isn't one for the compression notification.
> 
> Currently in 5.23.3 / Frameworks 5.88, there are similar instance-related
> bugs, and possibly causing confusion and/or may be related to this change:
> - When compressing a file, and the window is closed, Dolphin crashes and the
> compression doesn't complete.
> - When extracting a file, and is cancelled via notification, Dolphin
> continues to extract in the background.

I would also find the new intended behavior very annoying. A better option IMO would be to add a button 'extract here (auto detect subfolder) AND open the created folder'.

Looks like the bug was only half-fixed, indeed. When the "Open new folders in tabs" and "Show on Startup: Folder, tabs, and window state from last time" options are in use, everything is fine. When one or both are unchecked, the issue re-appears.

Andrey and or Alexander, would yo mind taking a look? Thanks!

(In reply to Nate Graham from comment #35)
> Looks like the bug was only half-fixed, indeed. When the "Open new folders
> in tabs" and "Show on Startup: Folder, tabs, and window state from last
> time" options are in use, everything is fine. When one or both are
> unchecked, the issue re-appears.

Is "everything is fine" with regards to opening a new tab / window only, or does it also cover the cases Luke mentioned?  (Closing the dolphin window aborting the extraction, cancelling via the notification not actually cancelling the operation)

(In reply to Nate Graham from comment #35)
> Andrey and or Alexander, would yo mind taking a look? Thanks!

Sorry I doubt I can look ATM.
My stuff was about addressing Wayland case, I'm not familiar with original bug here.

It seems like Alexander was not here, added him.
Any thoughts Alexander?

(In reply to Christian (Fuchs) from comment #36)
> (In reply to Nate Graham from comment #35)
> > Looks like the bug was only half-fixed, indeed. When the "Open new folders
> > in tabs" and "Show on Startup: Folder, tabs, and window state from last
> > time" options are in use, everything is fine. When one or both are
> > unchecked, the issue re-appears.
> 
> Is "everything is fine" with regards to opening a new tab / window only, or
> does it also cover the cases Luke mentioned?  (Closing the dolphin window
> aborting the extraction, cancelling via the notification not actually
> cancelling the operation)
Hmm, these seem broken too. :/ What a mess. I'm wondering if it might make more sense to revert the original change that caused this. Does anyone happen to know what it was?

(In reply to Nate Graham from comment #35)
> Looks like the bug was only half-fixed, indeed. When the "Open new folders
> in tabs" and "Show on Startup: Folder, tabs, and window state from last
> time" options are in use, everything is fine. When one or both are
> unchecked, the issue re-appears.

On KDE neon with Plasma 5.23.3 and KDE Frameworks 5.87.0, with "Open new folders in tabs" and "Show on Startup: Folder, tabs, and window state from last time" options activated, the behavior is this:
- compressing a file opens the action result in a new tab;
- decompressing a file works as expected (no new tab is opened).

Also, if I make some compression/decompression actions (it doesn't matter) in the new window opened by Ark, all works fine (no new other window is opened).

> Hmm, these seem broken too. :/ What a mess. I'm wondering if it might make more sense to revert the original change that caused this. Does anyone happen to know what it was?

I don't know the exact commit, but a known good version was around 01 Jun 2021, (according to my snapshot Arch VM), running:
- Plasma 5.21.5
- Frameworks 5.82.0
- Gear 20.04.1

(It could be between 01 Jun 2021 - 12 Aug 2021, I haven't kept snapshots between those dates. This VM uses X11)

The "close window aborts extraction crash" bug started when KDE Gear 21.08.0 was released around 13 Aug 2021. I observe the compression happens inside the 'dolphin' process, which was a separate 'ark' process before this update.

The "cancel notification continues extracting" bug is actually even older. It happens in Plasma 5.21.5. I can see that the ark process keeps doing its thing despite the notification being cancelled, so I think that's an ark bug, not dolphin. The process happens inside 'dolphin' now, so that can be a bit confusing.

Finally, the "new window/tab after extraction/compression" (this original bug report) started around Plasma 5.22, Frameworks 5.84.0, Gear 21.08.0. I also confirm that in earlier versions, leaving "Open new folders in tabs" checked didn't open anything -- so an earlier variant of the regression -- but it currently open tabs too, I believe.

Just now, I checked "Open new folders in tabs", extracted a zip and it focused a completely irrelevant instance of dolphin without opening a new tab. I have this unchecked normally. This might be an incentive to ditch the "steal the focus" behaviour as mentioned in comment 31 if a clean revert is not possible.

I tried a git bisect on dolphin's repo too the other day, with no luck... only now I just realized the problem is not exclusive to dolphin's code. It may involve ark and kio too. Hope this helps.

>- compressing a file opens the action result in a new tab;

Okay, will write a fix for that

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/292

Since that merge request seems to mainly tackle the tabs: can we, for the current branch, get the original change reverted so at least until a proper fix is found people who don't have a very specific configuration won't get a new dolphin window/tab every time they compress / uncompress something?

If someone can identify the original change that caused this, and it's a clean revert, then that seems reasonable.

Same problem here. Every time I uncompress a file through the right click menu a new window of Dolphin is made. The Ark option "Open the destination folder after extraction" (or something like that) makes no difference.
Very annoying. Tell me if a screen capture or any more info is needed.

Dolphin: 21.08.3
Ark: 21.08.3
Operating System: Gentoo Linux
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2
Kernel Version: 5.10.76-gentoo-r1 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7 CPU 870 @ 2.93GHz
Memory: 7.8 GiB of RAM
Graphics Processor: AMD JUNIPER

Confirmed here, and looks like a Ark issue not a Dolphin one. Downgrading Ark to 21.07.90 fixed the issue to me. Bug confirmed on:

Dolphin: 21.08.3
Ark: 21.08.3
Operating System: Arch Linux
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.6-zen2-1-zen (64-bit)
Graphics Platform: X11
Processors: 32 x AMD Ryzen 5950X 16-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX2060/PCIe/SSE2

(In reply to Artur Paiva from comment #46)
> Confirmed here, and looks like a Ark issue not a Dolphin one. Downgrading
> Ark to 21.07.90 fixed the issue to me. Bug confirmed on:
> 
> Dolphin: 21.08.3
> Ark: 21.08.3
> Operating System: Arch Linux
> KDE Plasma Version: 5.23.4
> KDE Frameworks Version: 5.88.0
> Qt Version: 5.15.2
> Kernel Version: 5.15.6-zen2-1-zen (64-bit)
> Graphics Platform: X11
> Processors: 32 x AMD Ryzen 5950X 16-Core Processor
> Memory: 62.7 GiB of RAM
> Graphics Processor: NVIDIA GeForce RTX2060/PCIe/SSE2

A cache on dolphin made my previous result invalid, I've now checked every package of Ark available for me and made sure that both dolphin and ark was closed before each test. on <= 21.04.3 the issue doens't show up, on >= 21.07.80 the issue is present. Unfortunatelly I dont have packages for any version in between those two to pinpoint a more accurate version. Hope it helps.

The behavior seems to be hardcoded in Ark.

The bug is in Ark or Dolphin? Just wondering if I can upgrade dolphin to 21.12.

(In reply to Shay G from comment #49)
> The bug is in Ark or Dolphin? Just wondering if I can upgrade dolphin to
> 21.12.

Its on Ark, running dolphin 21.12.0 just fine, had to freeze ark on 21.04.3.

(In reply to Artur Paiva from comment #50)
> (In reply to Shay G from comment #49)
> > The bug is in Ark or Dolphin? Just wondering if I can upgrade dolphin to
> > 21.12.
> 
> Its on Ark, running dolphin 21.12.0 just fine, had to freeze ark on 21.04.3.

Thanks!

Can anyone verify it's fixed?
https://pointieststick.com/2021/12/10/this-week-in-kde-polishing-up-ark-and-dolphin/

(In reply to Shay G from comment #52)
> Can anyone verify it's fixed?
> https://pointieststick.com/2021/12/10/this-week-in-kde-polishing-up-ark-and-
> dolphin/

I'm having a little trouble following this bug but if we just take the OP where a new instance of Dolphin opens after extraction, then no, it's not fixed. 

Ark has 'Open Destination Folder after Extraction' unchecked but it still happens. 

openSUSE Tumbleweed
5.23.3
5.88.0
Ark - 21.08.3
Dolphin - 21.08.3

*** Bug 447075 has been marked as a duplicate of this bug. ***

(In reply to Pulse from comment #53)
> openSUSE Tumbleweed
> 5.23.3
> 5.88.0
> Ark - 21.08.3
> Dolphin - 21.08.3

Looks like it was fixed in 21.12, but you're still on 21.08.

(In reply to smow from comment #55)
> (In reply to Pulse from comment #53)
> > openSUSE Tumbleweed
> > 5.23.3
> > 5.88.0
> > Ark - 21.08.3
> > Dolphin - 21.08.3
> 
> Looks like it was fixed in 21.12, but you're still on 21.08.

It wasn't. Upgraded Ark to 21.12.0 and the bug is still present. Had to downgrade back to Ark 20.04.3. Dolphin can be updated suggesting that the bug is related to Ark not Dolphin.

As per the blog post, it will make its way into 22.04, so we have to wait roughly 5 months for it to appear. 
From what I can see in ttps://invent.kde.org/utilities/ark/-/merge_requests/80 it only went into master, why a one-liner with an additional included header (that seems to be available unrelated to the change) is not backported is a bit beyond me, but there is at least the hope that some packagers might patch it in the meantime.

(In reply to Christian (Fuchs) from comment #57)
> As per the blog post, it will make its way into 22.04, so we have to wait
> roughly 5 months for it to appear. 
> From what I can see in
> ttps://invent.kde.org/utilities/ark/-/merge_requests/80 it only went into
> master, why a one-liner with an additional included header (that seems to be
> available unrelated to the change) is not backported is a bit beyond me, but
> there is at least the hope that some packagers might patch it in the
> meantime.

Something changed in the update to my system today to make this problem even worse. Now, when the new Dolphin window opens, it ignores my Dolphin prefs and opens with Information, console and folder views all active. None of these are set by default on my main Dolphin instance.

5.23.4
5.89.0
Ark 21.12
Dolphin 21.12

(In reply to Christian (Fuchs) from comment #57)
> As per the blog post, it will make its way into 22.04, so we have to wait
> roughly 5 months for it to appear. 
> From what I can see in
> ttps://invent.kde.org/utilities/ark/-/merge_requests/80 it only went into
> master, why a one-liner with an additional included header (that seems to be
> available unrelated to the change) is not backported is a bit beyond me, but
> there is at least the hope that some packagers might patch it in the
> meantime.
Backported; it should show up in 21.12.1.

Still I'm not sure it's the permanent fix for this issue here. Wanting a file manager window to open after extraction in Ark is different from whether you want this in Dolphin, since when you invoke the functionality in Dolphin, you still have a file manager window open.

(In reply to Nate Graham from comment #59)
> (In reply to Christian (Fuchs) from comment #57)
> > As per the blog post, it will make its way into 22.04, so we have to wait
> > roughly 5 months for it to appear. 
> > From what I can see in
> > ttps://invent.kde.org/utilities/ark/-/merge_requests/80 it only went into
> > master, why a one-liner with an additional included header (that seems to be
> > available unrelated to the change) is not backported is a bit beyond me, but
> > there is at least the hope that some packagers might patch it in the
> > meantime.
> Backported; it should show up in 21.12.1.
> 
> Still I'm not sure it's the permanent fix for this issue here. Wanting a
> file manager window to open after extraction in Ark is different from
> whether you want this in Dolphin, since when you invoke the functionality in
> Dolphin, you still have a file manager window open.

Hi Nate, 

thank you very much for backporting. 

As for long term: I assume you mean that if the user doesn't come from dolphin, but rather from ark directly, it should open a window? I'd agree that the option in ark should modify that behaviour, and maybe not the one in dolphin.  However, I assume this is very much the minority of cases, I assume most users that do extract compressed files via GUI do come from a file manager, in our case dolphin, and not open ark directly. So as a default behaviour in the meantime, I think following that option is the least bad option.

As for dolphin: given we control the desktop file which creates that service menu, it would be simple to have the command modified to open the default file manager. However, getting the target folder might be more difficult, since that is something ark knows about, but dolphin doesn't. So maybe the option is two-fold:
1) Add a command line switch to ark which does, after extraction, open the default (or specified) file browser in the target directory once done
2) Use that switch in whatever command the context menu invokes 
3) Make that behaviour configurable, which is probably tricky, but technically could be done by having two different context menu entries, then users can choose with the options for context menus dolphin already provides.

Ultimately here is what I think makes sense:

Extracting within Ark:
- always respect the setting to open a filemanager or not after the job is done

Extracting or compressing from Dolphin's context menu item:
- open a new window after the job is done only when Ark's setting for that is set to true and also when any of the following conditions apply:
-- Dolphin isn't running anymore
-- A Dolphin window is open but its view is not showing the extraction/compression location

Would that make sense to you?

(In reply to Nate Graham from comment #61)
> Ultimately here is what I think makes sense:
> 
> Extracting within Ark:
> - always respect the setting to open a filemanager or not after the job is
> done
> 
> Extracting or compressing from Dolphin's context menu item:
> - open a new window after the job is done only when Ark's setting for that
> is set to true and also when any of the following conditions apply:
> -- Dolphin isn't running anymore
> -- A Dolphin window is open but its view is not showing the
> extraction/compression location
> 
> Would that make sense to you?

IMHO Ark options should change the behavior of Ark and Dolphin options should change the behavior of Dolphin. Regardless Dolphin is using Ark under the hood, the setting should be on Dolphin and affect only the right click "compress/decompress open location after extraction" behavior inside the file manager. If you open files directly through Ark, that's a completely different matter.

Regards.

Hi Nate, 

(In reply to Nate Graham from comment #61)
> Ultimately here is what I think makes sense:
> 
> Extracting within Ark:
> - always respect the setting to open a filemanager or not after the job is
> done

Yes. Agree.

> Extracting or compressing from Dolphin's context menu item:
> - open a new window after the job is done only when Ark's setting for that
> is set to true and also when any of the following conditions apply:
> -- Dolphin isn't running anymore
> -- A Dolphin window is open but its view is not showing the
> extraction/compression location

Disagree-ish. The problem with  "view is not showing the extraction" location. Since you have the options to extract it to a subfolder or auto detect (create a sub folder if there are files in the root of the archive, else don't) it is very hard for ark or dolphin to correctly decide if there already is an instance showing the location.  Personally I'd not want a window at all, in any case, it steals the focus and it annoys me. Other people might want it. So I think the only option is to either make it configurable or offer both kind of service menu entries  (extract versus extract and show)

Maybe something to discuss in the VDG channel, I poked you there. 

Kind regards, 

Fuchs

I would prefer to focus first on making the behavior good out of the box so we don't need a config option that affects just the context menu actions. Adding that would still annoy everyone who doesn't know about the option's existence, which would be most people. We can always add one later if our efforts to improve the default settings run into unavoidable issues.

(In reply to Nate Graham from comment #64)
> I would prefer to focus first on making the behavior good out of the box so
> we don't need a config option that affects just the context menu actions.
> Adding that would still annoy everyone who doesn't know about the option's
> existence, which would be most people. We can always add one later if our
> efforts to improve the default settings run into unavoidable issues.

Would be nice, but to be honest, I'm not sure there is any better default than "follow arks option" right now, the one you described imho isn't, simply because it will act inconsistently depending on whether it extracts to the current folder or create a or multiple sub folders. Then I'd rather default to "not open anything at all", since you never specified you want to open a file manager, only for files to be extracted.

(In reply to Nate Graham from comment #59)
> Backported; it should show up in 21.12.1.
>
Thanks. :)

(In reply to Nate Graham from comment #61)
> Ultimately here is what I think makes sense:
> 
> Extracting within Ark:
> - always respect the setting to open a filemanager or not after the job is
> done
> 
> Extracting or compressing from Dolphin's context menu item:
> - open a new window after the job is done only when Ark's setting for that
> is set to true and also when any of the following conditions apply:
> -- Dolphin isn't running anymore
> -- A Dolphin window is open but its view is not showing the
> extraction/compression location
>
If my 2c are worth anything at all:
The first bit, absolutely.
As for the second... Personally I'd quite like this whole idea to just go away, i.e. return to KDE 5.22.4 behaviour and leave service-menu (de)compression as an unobtrusive background task. 
As an added bonus, reverting this whole can-o-worms is likely the quickest and easiest solution as well.

Frankly I don't see how raising/focusing/opening file manager windows/tabs like this will be anything but an irritant to the (desktop) user, and if focus-stealing after a background job really is the goal here, I'd _very_ much like to see an option (ideally in dolphin) to turn it off. 
Focus stealing is, after all, evil incarnate.

We already have a notification system for notifying about background jobs, why not just use that instead of all this buggering about trying to pick a window/tab/yak to raise and somewhere sane to put yet more options? 
As Luke suggests above, all it really needs is an "Open Containing Folder" button for compression operations.

(In reply to Steve Vialle from comment #66)
> As for the second... Personally I'd quite like this whole idea to just go
> away, i.e. return to KDE 5.22.4 behaviour and leave service-menu
> (de)compression as an unobtrusive background task. 
> As an added bonus, reverting this whole can-o-worms is likely the quickest
> and easiest solution as well.
> 
> Frankly I don't see how raising/focusing/opening file manager windows/tabs
> like this will be anything but an irritant to the (desktop) user, and if
> focus-stealing after a background job really is the goal here, I'd _very_
> much like to see an option (ideally in dolphin) to turn it off. 
> Focus stealing is, after all, evil incarnate.
>
> We already have a notification system for notifying about background jobs,
> why not just use that instead of all this buggering about trying to pick a
> window/tab/yak to raise and somewhere sane to put yet more options? 

Fully agree with this opinion.

It worked smoothly prior to this, and was non-complex, and straight forwards.

It's like one step forwards and two steps back, for something that worked fine without "improvement".

I might have to file a *separate* bug report, for even in 21.12 there still exists a bug with the notification tray that freezes up the entire session when trying to compress file via Dolphin's context menu. :( It was interrelated with this bug, from what I recall. It's unclear if the process crashed or if the compression was successful.

Yeah, reverting the change and making people use the notification to access the file location might indeed be the best option given the complexity of the alternatives.

A possibly relevant merge request was started @ https://invent.kde.org/utilities/ark/-/merge_requests/87

Git commit 28f2ef4b22f53200cb8789dbc8fe8ecdba3a377f by Alexander Lohnau.
Committed on 25/12/2021 at 12:00.
Pushed by alex into branch 'master'.

Do not highlight file after compression

Dolphin opens a new tab whenever the file is compressed and
is not smart enough to highlight it in the currently open view.
Because people are annoyed by it and the alternatives are complex to implement,
removing it is the best solution.

M  +2    -5    app/compressfileitemaction.cpp

https://invent.kde.org/utilities/ark/commit/28f2ef4b22f53200cb8789dbc8fe8ecdba3a377f

Git commit 75c6927883342ec533aea4663b7b5dfcf8d699a6 by Alexander Lohnau.
Committed on 27/12/2021 at 15:55.
Pushed by alex into branch 'release/21.12'.

Do not highlight file after compression

Dolphin opens a new tab whenever the file is compressed and
is not smart enough to highlight it in the currently open view.
Because people are annoyed by it and the alternatives are complex to implement,
removing it is the best solution.


(cherry picked from commit 28f2ef4b22f53200cb8789dbc8fe8ecdba3a377f)

M  +2    -5    app/compressfileitemaction.cpp

https://invent.kde.org/utilities/ark/commit/75c6927883342ec533aea4663b7b5dfcf8d699a6

Patch here (unmerged) might be related as it fixed extra tab opening for me, even with the "Do not highlight file after compression" patch above reverted:
https://invent.kde.org/system/dolphin/-/merge_requests/270

The real fix is here:
https://invent.kde.org/system/dolphin/-/merge_requests/400

(In reply to Nate Graham from comment #35)
> When the "Open new folders
> in tabs" and "Show on Startup: Folder, tabs, and window state from last
> time" options are in use, everything is fine. When one or both are
> unchecked, the issue re-appears.
Actually it's the option name just misleading.
When "Open new folders in tabs" is unchecked, it doesn't even try to attach to existing Dolphin instances and opens a new window(s) unconditionally.
So the option should be inverted and named something like: "Open new folders in windows" instead.

Whether or not to open a new tabs is actually depends on if the containing dir is opened anywhere in one of existing Dolphin instances.

Git commit 73ff57bef44984643bf1ffdb9a478095cfb78dfb by Andrey Butirsky.
Committed on 22/06/2022 at 18:49.
Pushed by butirsky into branch 'master'.

do not open excessive tab

even if directory of the file to be created is not the top-most opened in
TreeView

M  +9    -0    src/dolphinmainwindow.cpp
M  +11   -0    src/dolphinmainwindow.h
M  +26   -9    src/dolphintabwidget.cpp
M  +25   -12   src/dolphintabwidget.h
M  +29   -7    src/global.cpp

https://invent.kde.org/system/dolphin/commit/73ff57bef44984643bf1ffdb9a478095cfb78dfb

(In reply to Alexander Lohnau from comment #71)
> Git commit 75c6927883342ec533aea4663b7b5dfcf8d699a6 by Alexander Lohnau.
> Committed on 27/12/2021 at 15:55.
> Pushed by alex into branch 'release/21.12'.
> 
> Do not highlight file after compression
> 
> Dolphin opens a new tab whenever the file is compressed and
> is not smart enough to highlight it in the currently open view.
> Because people are annoyed by it and the alternatives are complex to
> implement,
> removing it is the best solution.
> 
> 
> (cherry picked from commit 28f2ef4b22f53200cb8789dbc8fe8ecdba3a377f)
> 
> M  +2    -5    app/compressfileitemaction.cpp
> 
> https://invent.kde.org/utilities/ark/commit/75c6927883342ec533aea4663b7b5dfcf8d699a6

Please note this workaround has been reverted in favor of the real fix above.

Please test the fix on master, and if we still need to make the highlighting optional - please open a dedicated issue for that, I have some ideas in mind.
Thanks.

One or more instances of Dolphin open again after creating an archive or canceling compression via Plasma notification.

Operating System: Arch Linux
KDE Plasma Version: 5.25.90
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Graphics Platform: Wayland

Confirmed, again. Revert of the revert of the revert patch added back into my portage tree. Again.
Can we not just kill this misfeature with fire, please? And not keep trying to put it back in, pretty please? 

I mean, seriously, what is the use-case here? What problem are we trying to solve with this functionality?

I can confirm that this bug re-surfaced again, and I did see the revert on GitLab with "We no longer need this", yes, we do, and please keep the "workaround" or indeed do remove the misfeature that causes this bug.

(In reply to Patrick Silva from comment #77)
> One or more instances of Dolphin open again after creating an archive or
> canceling compression via Plasma notification.
Could you please provide more detail?
Are you creating archive in Ark or in Dolphin's context menu? Does it depend on any options, etc.?

(In reply to Andrey from comment #80)
> Are you creating archive in Ark or in Dolphin's context menu? 
Dolphin context menu, "Compress here". Any archive type.

> Does it depend on any options, etc.?
The only relevant options I can see are "open destination folder after extraction" in ark, and "open new folders in tabs" in dolphin. Both are unchecked.

This is exactly the same behaviour as described in the original report, and the "workaround" revert still solves the problem.

(In reply to Steve Vialle from comment #81)
> (In reply to Andrey from comment #80)
> > Are you creating archive in Ark or in Dolphin's context menu? 
> Dolphin context menu, "Compress here". Any archive type.
> 
> > Does it depend on any options, etc.?
> The only relevant options I can see are "open destination folder after
> extraction" in ark, and "open new folders in tabs" in dolphin. Both are
> unchecked.
> 
Same here.

(In reply to Steve Vialle from comment #81)
> (In reply to Andrey from comment #80)
> > Are you creating archive in Ark or in Dolphin's context menu? 
> Dolphin context menu, "Compress here". Any archive type.
> 
What about extraction? Does it respect "open destination folder after extraction" in ark?

> > Does it depend on any options, etc.?
> The only relevant options I can see are "open destination folder after
> extraction" in ark, and "open new folders in tabs" in dolphin. Both are
> unchecked.
As I wrote above, that  "open new folders in tabs" option naming in dolphin just unfortunate and misleading.
If it UNchecked, it _guarantees_ the new Dolphin window will be opened instead of selecting the archive in current tab/new tab.
Please try to check that option and retest.

For me it's been 100% reproducible when _creating_ an archive, not when extracting it. This is regardless of any settings in either dolphin or ark. It came with a recent update of either frameworks or plasma. 

What is worth mentioning is that this is on X11, while I don't see why it should make a difference, it actually did make one in the past where that bug was not (always) reproducible on wayland but on X11.

(In reply to Andrey from comment #83)
> What about extraction? Does it respect "open destination folder after
> extraction" in ark?
Checked or unchecked, nothing is opened after extraction from the dolphin context menu.
It _is_ respected when extracting an archive from within ark itself, as it should and always has.
IMO ark options should affect ark, and not bleed over into dolphin context menu actions anyway. They never have before AFAIK.

> As I wrote above, that  "open new folders in tabs" option naming in dolphin
> just unfortunate and misleading.
"Open new folders in tabs" does exactly what it says on the tin - it causes folders opened externally (e.g. from a desktop icon etc.) to open a new tab in an existing dolphin window, rather than opening a new window.
That's what it's always done, since the introduction of dolphin as the default file manager. It's not misleading, and it has only become "unfortunate" with the introduction of this "focus archive" shenanegans.

> If it UNchecked, it _guarantees_ the new Dolphin window will be opened
> instead of selecting the archive in current tab/new tab.
Well it does _now_. It sure didn't before all this started.

> Please try to check that option and retest.
Checking "open new folders in tabs" does indeed prevent the spawning of new dolphin windows on extraction. However, as above, it also causes externally opened folders to open tabs rather than new windows. 
For those of us used to a traditional desktop workflow, this is extremely irritating. It is also logically unrelated to background archive operations.

 
If and when you have something in need of testing I'm happy to do so... But I also need a desktop that works properly, so for now I'm going to keep patching out your changes locally until this doesn't steal focus, raise windows, hijack existing options, or generally get in my way.
I've been using KDE since 1.0 and I've never needed this, quite frankly I don't need it now either. Archiving is and always has been an unobtrusive background operation, and it has worked just fine that way for many years.

If you are determined to implement this feature, please provide a clearly labelled option (a *new* option, not one with it's own well-established uses) to disable it entirely.

> Checking "open new folders in tabs" does indeed prevent the spawning of new
dolphin windows on extraction.
s/extraction/compression/g

(In reply to Steve Vialle from comment #85)
> (In reply to Andrey from comment #83)
> > As I wrote above, that  "open new folders in tabs" option naming in dolphin
> > just unfortunate and misleading.
> "Open new folders in tabs" does exactly what it says on the tin - it causes
> folders opened externally (e.g. from a desktop icon etc.) to open a new tab
> in an existing dolphin window, rather than opening a new window.
> That's what it's always done, since the introduction of dolphin as the
> default file manager. It's not misleading, and it has only become
> "unfortunate" with the introduction of this "focus archive" shenanegans.
The name doesn't reflect the fact a new window will be opened shall the item is selected/opened externally in Dolphin with the option unchecked.
That is misleading.
 
> > If it UNchecked, it _guarantees_ the new Dolphin window will be opened
> > instead of selecting the archive in current tab/new tab.
> Well it does _now_. It sure didn't before all this started.
If you can read the code, you can make sure I didn't touch the option, so it works as before.

> > Please try to check that option and retest.
> Checking "open new folders in tabs" does indeed prevent the spawning of new
> dolphin windows on extraction. However, as above, it also causes externally
> opened folders to open tabs rather than new windows. 
> For those of us used to a traditional desktop workflow, this is extremely
> irritating. It is also logically unrelated to background archive operations.
The option influences behavior both when an item is selected externally or it's an archive crated from Dolphin context menu, it wasn't touched.

> I'm going to keep
> patching out your changes locally until this doesn't steal focus, raise
> windows, hijack existing options, or generally get in my way.
Nor any other options were touched.
 
> If you are determined to implement this feature, please provide a clearly
> labelled option (a *new* option, not one with it's own well-established
> uses) to disable it entirely.
I didn't implement the feature, the feature was there.
I just fixed it so it started to work for the context menu created archives at all (yes, it was there for them either).
This probably is the source of confusion.

PS:
The only behavioral change is for now no excessive tabs will be opened shall the "open new folders in tabs" Dolphin option is checked.
If the item is present in tab, it will be selected there instead of opening a new one.

So at least we now have an option to not open a new windows/tabs unnecessary, but that is the option which needs to be checked.

While I see your argument, I think there is no, absolutely zero, gain in opening a new window after _creating_ an archive. Extracting could be debated, but I don't see why anyone would expect creating a new archive to open a new window. Even more so with cancelling an ongoing operation. 

From a UX perspective, neither of these operations should imho open a window. If it can be disabled, but only by altering other behaviour of dolphin with the same setting, then I'd consider that a bug that needs fixing. And if there is a setting which does alter this and only this behaviour, I think the default setting should be "do not open a new window", since I don't see the use case of opening one after creating an archive or cancelling an archive process.

(In reply to Andrey from comment #87)
> I just fixed it so it started to work for the context menu created archives
> at all (yes, it was there for them either).

As far as I can see the problem began with https://invent.kde.org/utilities/ark/-/commit/ad8f47da4538d92d88900d5f86050b098f84239c, and as far as I am concerned https://invent.kde.org/utilities/ark/-/commit/28f2ef4b22f53200cb8789dbc8fe8ecdba3a377f is still the correct answer.
IMO "Focus newly created archives in file manager" is just a bad idea to begin with, and if it is to stay it needs an option in ark's settings to control it. Preferrably one that is off by default.

Apologies for blaming you for this, I guess you're just trying to make somebody else's "feature" work as intended.

For the rest, I wholeheartedly agree with everything Christian said above.

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/454

Could someone test
https://invent.kde.org/system/dolphin/-/merge_requests/454
before we cherry-pick that to the last point release 22.08.3?

Git commit c628c9d64d14e8bbcb380de08878d158857d0781 by Andrey Butirsky.
Committed on 12/10/2022 at 20:04.
Pushed by butirsky into branch 'master'.

fix opening new windows unnecessary

fixes a regression introduced by
https://invent.kde.org/utilities/ark/-/merge_requests/44

M  +19   -6    src/global.cpp

https://invent.kde.org/system/dolphin/commit/c628c9d64d14e8bbcb380de08878d158857d0781

i have just updated to Dolphin 22.08.2 on Arch Linux and I'm no longer able to reproduce. \o/

(In reply to Patrick Silva from comment #94)
> i have just updated to Dolphin 22.08.2 on Arch Linux and I'm no longer able
> to reproduce. \o/

Please try harder, the problem was fixed for master only for now.

Nevermind. The bug persists if 'Open new folders in tabs' is unchecked in Dolphin settings.

Git commit 348794eff8235f46b1f21d5e4b6fe0fe2b06ca57 by Andrey Butirsky.
Committed on 17/10/2022 at 22:44.
Pushed by butirsky into branch 'release/22.08'.

fix opening new windows unnecessary

fixes a regression introduced by
https://invent.kde.org/utilities/ark/-/merge_requests/44

(backported from commit c628c9d6)


(cherry picked from commit bc38cbd9f06d41b550d75b80b23025e60c9302f3)

M  +19   -6    src/global.cpp

https://invent.kde.org/system/dolphin/commit/348794eff8235f46b1f21d5e4b6fe0fe2b06ca57

The bug persists if 'Open new folders in tabs' is unchecked in Dolphin settings and I extract a .tar.gz archive located on desktop.

1. make sure 'Open new folders in tabs' is unchecked in Dolphin settings 
2. copy an archive to desktop
3. close all instances of Dolphin
4. extract the archive located on desktop

Result: Dolphin opens

(In reply to Patrick Silva from comment #98)
> The bug persists if 'Open new folders in tabs' is unchecked in Dolphin
> settings and I extract a .tar.gz archive located on desktop.
> 
> 1. make sure 'Open new folders in tabs' is unchecked in Dolphin settings 
> 2. copy an archive to desktop
> 3. close all instances of Dolphin
> 4. extract the archive located on desktop
> 
> Result: Dolphin opens

Could you open a separate issue regarding this corner case?
This report is too bloated already.

I'll change the status until then

(In reply to Patrick Silva from comment #98)
> The bug persists if 'Open new folders in tabs' is unchecked in Dolphin
> settings and I extract a .tar.gz archive located on desktop.
> 
> 1. make sure 'Open new folders in tabs' is unchecked in Dolphin settings 
> 2. copy an archive to desktop
> 3. close all instances of Dolphin
> 4. extract the archive located on desktop
> 
> Result: Dolphin opens

Also, I'm not sure why do you think it's a problem - if 'Open new folders in tabs' is unchecked in Dolphin settings that implies the new window should be opened by default, if we have no other settings preventing that?
Maybe it differs from original behavior but still I'm not sure if it can be considered as this bug.

(In reply to Patrick Silva from comment #98)
> The bug persists if 'Open new folders in tabs' is unchecked in Dolphin
> settings and I extract a .tar.gz archive located on desktop.
> 
> 1. make sure 'Open new folders in tabs' is unchecked in Dolphin settings 
> 2. copy an archive to desktop
> 3. close all instances of Dolphin
> 4. extract the archive located on desktop
> 
> Result: Dolphin opens

What do you have set in Ark's
ArkSettings::openDestinationFolderAfterExtraction()
setting?

Thank you very much for your interest on this issue Andrey. :)

Currently the destination does not open after extraction via context menu of Dolphin if "Open Destination Folder After Extraction" is unchecked in Ark settings. This is the expected behavior. I also can't reproduce the bug by extracting an archive located on desktop after unchecking the said Ark option and then restarting Plasma by running "plasmashell --replace". I needed to restart Plasma probably due to bug 443846. However, the destination opens after creating an archive via "Compress to..." via Dolphin or desktop even if the said option is unchecked in Ark settings.

The behavior after creating an archive should be configurable too.

Dolphin and Ark 23.04.1
Operating System: Arch Linux 
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Graphics Platform: Wayland

(In reply to Patrick Silva from comment #103)
> Thank you very much for your interest on this issue Andrey. :)
Welcome!
> The behavior after creating an archive should be configurable too.
IIRC we have no such option for the archive creation in Ark so we have the default behavior only.
I suggest maybe we could combine these two options in the current one and just rename it instead of adding a new one.

Anyway, should be tracked in a separate issue, could you file one?

Created bug 469762

Thanks, closing this one.

Git commit abf9cce66451bc7e37d0606cd3c804757207f9b7 by Méven Car, on behalf of 2155X 2155X.
Committed on 22/07/2023 at 15:06.
Pushed by meven into branch 'ark-01-master'.

Added a "Open destination folder after compression" setting and brought back
the feature of opening destination after compressing a file via the context
menu.

M  +2    -1    app/CMakeLists.txt
M  +2    -1    app/compressfileitemaction.cpp
M  +2    -0    kerfuffle/CMakeLists.txt
M  +6    -0    kerfuffle/ark.kcfg
A  +10   -0    kerfuffle/compressionsettingspage.cpp  *
A  +18   -0    kerfuffle/compressionsettingspage.h  *
A  +38   -0    kerfuffle/compressionsettingspage.ui
M  +2    -0    part/part.cpp

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/utilities/ark/-/commit/abf9cce66451bc7e37d0606cd3c804757207f9b7

This probably fixes bug 469762 instead?

Also please note the suggestion there:
https://bugs.kde.org/show_bug.cgi?id=469762#c1