refactor(gui): declare each column width once; persist the file-details list - #844

Two changes: a mechanical de-duplication across the wxDataViewCtrl lists, and one behaviour change that comes with it — the file-details dialog's list now remembers its column widths and sort order, which it never did. Details in its own section below; everything else is behaviour-preserving.

Every column in the wxDataViewCtrl lists declares its width twice, in two calls that nothing keeps in sync:

AppendTextColumn(_("File Name"), COLUMN_SHARED_NAME, wxDATAVIEW_CELL_INERT, 400, wxALIGN_LEFT, colFlags);
m_columnStore.RegisterColumn(COLUMN_SHARED_NAME, 400, "N");

The two are consumed by different paths, which is why the duplication went unnoticed: wx uses its copy as the initial on-screen width, while CListColumnStore keeps its own as the width to restore a column to when it is un-hidden with nothing cached for it. Let them drift and a column returns from the header menu at a different width than it launched with.

The legacy CMuleListCtrl::InsertColumn() took the width and the persistence key in one call and could not drift. The dataview port split that apart, because wxDataViewCtrl::AppendTextColumn() has nowhere to put a key.

What changes

Three wrappers on CMuleDataViewCtrl — AddTextColumn, AddIconTextColumn, AddBarColumn — take the label, model column, key and width together and forward the one width to both destinations. The 43 columns across the server, search, friend and shared-files lists go through them, and every standalone RegisterColumn() is gone from the list subclasses.

CListColumnStore::RegisterColumn() itself is untouched: the legacy wxListCtrl lists still reach it through CMuleListCtrl::InsertColumn().

Why Add* and not an Append* overload

An overload with a different signature still binds to the wx method wherever a call is missed — compiling cleanly and persisting nothing.

That is not hypothetical. The sweep did miss one: COL_DIRECTORY in the search list, whose trailing comment sits after a comma and confused the rewrite, while the cleanup still removed its registration. With a distinct name it stayed visible as AppendTextColumn, and both grep and the width/key check caught it. As an overload it would have compiled and silently stopped persisting that column.

New behaviour: CFileDetailListCtrl gains persistence

It was the one dataview list without any: a user who widened "File Name" lost it the moment the dialog closed, and the sort reset to Sources-descending on every open.

It needs no teardown handling, because saving is event-driven in the base — header click, show/hide, and drag-resize through OnIdle → OnColumnWidthsChanged(). The dialog the user acted on is the one that writes, so the per-open lifetime is not a problem. New keys N and S under TableWidthsFileDetail / TableOrderingFileDetail; no GetOldColumnOrder() override, since nothing was ever written under that name to migrate.

Behaviour elsewhere

No column's width, order, visibility or key changes. All 43 were checked identical to master — and re-checked after clang-format rewrapped the calls, since that rewrote the very lines carrying them.

Worth setting expectations for review: no column had drifted on master, so hide/show already returns the launch width today. This removes the possibility of drift rather than fixing a live symptom — there is nothing to reproduce before/after.

Testing

amule and amulegui build clean; 33/33 unit tests; clang-format 18 and both clang-tidy tiers clean on the diff with 0 compiler errors. Validation greps: RegisterColumn( matches only ListColumnStore.cpp, MuleListCtrl.cpp and MuleDataViewCtrl.cpp; no list subclass still calls wx's Append*.

Manual GUI passes still to do: hide/show every column in each of the five lists, and a fresh-profile layout comparison.