Bug 465254 - When opening destination folder after, open the extracted top-level folder instead of the parent folder if it's the only top-level entry
Summary: When opening destination folder after, open the extracted top-level folder in...
Status: REPORTED
Alias: None
Product: ark
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Elvis Angelaccio
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-04 07:11 UTC by Jakub Kuczys
Modified: 2023-02-04 07:24 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Kuczys 2023-02-04 07:11:41 UTC
Currently, when extracting an archive with a single top-level entry that is a folder, the "Open destination folder after extraction" option will open the parent even when the "Extraction into subfolder" option is unchecked. This makes it hard to find that extracted folder since it needs to be found among the other files and folders in the destination directory.

I want to suggest that in such a case, Ark should instead open that top-level folder rather than the destination folder. If you think that this is not a good default behavior, it could be a global setting, perhaps overridable before the extraction with an option. It would make it a lot more ergonomic in my opinion. It still leaves a case of a single top-level entry that is a file where this new behavior couldn't apply but it's definitely progress. The logic for detecting a single top-level entry should already be present since it is needed for the "Extract to a subfolder if the archive has more than one top-level entry" global setting.
Comment 1 Jakub Kuczys 2023-02-04 07:24:18 UTC
https://bugs.kde.org/show_bug.cgi?id=465255 could be a good enough workaround for this that *also* works for archives with a single top-level entry that is a file. I'm mentioning this in case you're not interested in adding both of these functionalities so that you know that 465255 is somewhat more universal than this is.