Feature: Add ZIP encoding selection support for browsing archives with non-UTF-8 filenames#18529
Feature: Add ZIP encoding selection support for browsing archives with non-UTF-8 filenames#18529oxygen-dioxide wants to merge 18 commits into
Conversation
|
Problem: users still can't double-click a file in the archive to open it because process.Start() doesn't support custom zip encoding. (However, this bug also occurs for 7z files, so I may create another PR to fix it.) |
oxygen-dioxide
force-pushed
the
zip-encoding-oc
branch
from
c9d280e to
722fb3c
Compare
|
moved the combobox to bottom right corner |
|
Thanks! I'd like to take a closer look and get some feedback from @mdtauk but I can already tell that the overall location looks a lot better in that screenshot. |
|
What do you think about replacing the ComboBox with a Button and Flyout like we do for git branches? Please let me know if you want me to push a commit. |
Looks good to me |
|
What's the expected behavior when opening a regular zip file? |
|
For ascii or utf-8 zip file, the encoding selector shouldn't show up. I've fixed my code. |
There was a problem hiding this comment.
Do these newly added methods support password requesting? Apparently, it silently fails?
|
CI is now failing and most of my reviews are still present. |
|
@oxygen-dioxide fyi |
| IsItemClickEnabled="True" | ||
| ItemClick="ZipEncodingList_ItemClick" | ||
| ItemsSource="{x:Bind StatusBarViewModel.ZipEncodingOptions, Mode=OneWay}" | ||
| SelectedItem="{x:Bind StatusBarViewModel.SelectedZipEncoding, Mode=OneWay}" |
There was a problem hiding this comment.
When a ListView's ItemsSource is replaced (which happens every time StatusBarViewModel is reassigned during a tab switch), the ListView internally resets SelectedItem = null. With a TwoWay binding, this null propagates back to the ViewModel property, overwriting the previously selected encoding:
UpdateStatusBarProperties()
→ StatusBarViewModel DP set → DataContext changes
→ ItemsSource binding evaluates → ListView resets SelectedItem = null
→ SelectedItem TwoWay binding writes null → SelectedZipEncoding = null ← bug
This happens despite UpdateZipEncodingStateAsync() already having restored the correct encoding synchronously earlier in the same UI cycle.
Changing to Mode=OneWay breaks the ListView → ViewModel propagation path, preventing the spurious null write. The user's selection is still synced to the ViewModel via the existing ItemClick handler (called when the user picks an encoding from the flyout):
ItemClick → SelectedZipEncoding.set → triggers OnZipEncodingChangedAsync() → stores the encoding and refreshes the view, just as before.
The ViewModel → ListView direction (OneWay) still works, so on tab switch or encoding restore, the ListView correctly highlights the matching item from the ViewModel's SelectedZipEncoding value.
There is still a problem: when a zip file is opened, the detected zip encoding is shown on the button, but isn't shown as selected in the flyout menu. Let me fix it.
There was a problem hiding this comment.
We should find the root cause and fix this to use the TwoWay binding.
3 participants
Problem
When opening a ZIP archive whose filenames use an encoding other than the user's OS encoding, the filenames appear garbled
Solution
Added a ComboBox in the navigation toolbar that appears when browsing a ZIP archive with undetermined encoding, allowing the user to select the appropriate character encoding. When a custom encoding is selected, the app switches from SevenZipSharp to SharpZipLib to read filenames and file contents.
Resolved / Related Issues
To prevent extra work, all changes to the Files codebase must link to an approved issue marked as
Ready to build. Please insert the issue number following the hashtag with the issue number that this Pull Request resolves.Steps used to test these changes
Stability is a top priority for Files and all changes are required to go through testing before being merged into the repo. Please include a list of steps that you used to test this PR.
previous behaviour:
current behaviour:
