Packer plugins UI/UX improvements

[D1P]

Working with WCX packer plugins is, in its current shape, inconvenient. Below are concrete issues and a proposal.

1. Plugin settings are reachable only through the Pack dialog.

The WCX API has a ConfigurePacker entry point, and per the documentation it is invoked only when Configure... is clicked in the Files → Pack dialog. To reach a plugin's settings, a user has to:

• open the Pack dialog;
• pick a file extension associated with the plugin from the dropdown (not the plugin name, and not its path);
• click Configure....

If a plugin returns neither PK_CAPS_NEW nor PK_CAPS_MODIFY from GetPackerCaps — i.e. it does not support creating or modifying archives — its extensions do not appear in that dropdown at all, and there is no legitimate way to invoke ConfigurePacker through the UI. Workarounds discussed on this forum for years include associating a dummy extension purely to reach the settings, or calling the exported ConfigurePacker function directly via rundll32.

The obvious, minimally invasive fix is a Configure... button in the plugins dialog itself, next to the selected plugin — not next to an extension.

2. The "Configure packer extension WCXs" dialog itself is confusing.

• Editing a value in the extensions dropdown can trigger the prompt "The association for the extension . was changed. Save?" — even for extensions that no plugin is actually associated with.
• The dialog does not allow removing a plugin as an entity: you can only unlink extensions one at a time. The matching dialogs for WFX and WDX plugins are organised around the plugin itself and provide explicit Add / Remove operations. The current WCX dialog has New type... (add) but no symmetric remove.
• The numeric value preceding the plugin path (e.g. chm=257,… in wincmd.ini, also surfaced through the dialog) is a PK_CAPS_* bitmask. To understand what the plugin supports, a user must open the help and mentally decompose the number into a sum of powers of two. The UI does not decode it.
• The plugin → extensions relationship is not shown directly anywhere: the dialog is organised "by ini file order", so finding out how many extensions a particular .wcx is bound to requires walking through the entries one by one.
• The bitness of the module that is actually loaded is not reflected in the dialog. wincmd.ini stores the path with whichever extension was picked at install time (.wcx or .wcx64); if a .wcx64 sibling exists next to a stored .wcx path, the 64-bit Total Commander silently loads that one instead, and the dialog gives no hint of it.
• There is no toggle for the archive-opening mode — Enter (enter the archive like a directory) vs. Ctrl+PgDn only (treat the file as a regular file by default, enter the archive only on explicit request). This is governed by the PK_CAPS_HIDE flag (256) returned by the plugin from GetPackerCaps, and the user cannot override it from the UI. In practice the need to flip this comes up regularly — a typical case is wanting to keep the system-associated application (an emulator, a viewer, ...) on Enter while still being able to enter the archive deliberately via Ctrl+PgDn. The known workaround, used by some plugin authors, is to ship two builds of the same .wcx that differ only in the PK_CAPS_HIDE bit.

Proposal

Replace the current dialog with a tabular list with the columns:

Code: Select all

Plugin path  |  Associated extensions  |  Supported flags (decoded PK_CAPS_*)

…with Add / Edit / Remove / Configure operations on each entry. Out of the flag set, at least PK_CAPS_HIDE is worth exposing as a TC-side toggle (with a "default — whatever GetPackerCaps returned" hint): that resolves the Enter / Ctrl+PgDn case without requiring separate plugin builds. The remaining bits, which describe real code capabilities, should obviously stay read-only.

I understand WCX is not a subsystem most users touch daily, and that experienced users have built muscle memory around the current dialog. I have been using Total Commander for over a quarter of a century, and that is precisely why I would like such small details to keep getting better.

[ghisler(Author)]

The idea of the plugin settings dialog is not for general settings, but for setting pack options like the compression method, whether the user wants a solid archive etc. That's why it's in the pack dialog.

[D1P]

The idea of the plugin settings dialog is not for general settings, but for setting pack options like the compression method, whether the user wants a solid archive etc. That's why it's in the pack dialog.

Thank you for the clarification — that helps me sharpen the question rather than the argument.

If ConfigurePacker is, by design, only for pack-time options, then the question I am really raising is: where do general plugin settings go?

The WCX API exposes exactly one UI configuration entry point — ConfigurePacker. There is no separate "general settings" callback. As a consequence:

• A plugin without PK_CAPS_NEW / PK_CAPS_MODIFY (i.e. a pure unpacker — and there are quite a few of these: image-format unpackers, disk-image readers, CHM/HLP/MSI viewers, etc.) does not even appear in the Files → Pack dropdown. Under the strict reading of your design intent, such a plugin therefore has no UI-accessible settings at all — yet many of them do have settings that are clearly not pack-time options (codepage / charset, parsing strictness, log verbosity, default view mode, whether to expose hidden streams, …).
• Plugin authors who do have such general settings nevertheless wire them into ConfigurePacker — because it is the only callback the API gives them. CHMDir, the FAT image plugin, the ISO plugin and others all do this in practice. The settings exposed through that dialog are not "compression method / solid archive" — they are general behavioural switches.
• The PK_CAPS_HIDE bit (Enter vs. Ctrl+PgDn) discussed earlier is the cleanest example: it is plainly a general behavioural setting, not a pack option, and its current absence from the UI is exactly what forces some authors to ship two builds of the same .wcx differing only in that one bit.

So the practical picture, regardless of the original intent, is that ConfigurePacker is the general settings dialog for many plugins, simply because the API offers nothing else. Given that, requiring the user to enter the Files → Pack dialog (which a read-only plugin cannot even reach) to get to those settings is a UI accident, not a design choice.

Two ways forward, both modest:

• Add a Configure... button next to the selected plugin in the plugins dialog, which simply calls the existing ConfigurePacker export. No API change, no plugin change — just a second path to the same callback, available regardless of PK_CAPS_NEW/MODIFY.
• If you would prefer to keep ConfigurePacker strictly for pack-time options, then introducing a separate general-settings export (e.g. ConfigurePlugin) in a future SDK revision would be the cleaner long-term answer — but the first option already covers the existing ecosystem without any SDK change.

Either way, I think the underlying issue is real and worth addressing: today, a non-trivial fraction of WCX plugins have settings that the user can effectively reach only through workarounds.

[ghisler(Author)]

Add a Configure... button next to the selected plugin in the plugins dialog, which simply calls the existing ConfigurePacker export. No API change, no plugin change — just a second path to the same callback, available regardless of PK_CAPS_NEW/MODIFY.

I think that this would be the better option because existing plugins would benefit too.

[D1P]

I think that this would be the better option because existing plugins would benefit too.

Thank you. That would be great.

Just to make sure the rest of the original post does not get lost in the ConfigurePacker thread: the same dialog redesign would also be the natural place to address the other points I raised — the missing Remove plugin operation, the PK_CAPS_* bitmask shown as a raw number rather than as decoded capabilities, the lack of a plugin → extensions view, the bitness of the actually loaded module not being reflected, and the PK_CAPS_HIDE / Enter vs. Ctrl+PgDn toggle.

None of these requires SDK changes either; they are all UI-side. Happy to discuss them individually if any of them is contentious.