Tested, works
My test list changes from

Installed mods:
  * Quetzal 1.8.9
  * DynamicData 2.77.0
  * Plot 2025.10.29

to

Installed mods:
  * DynamicData 2.77.0
  * Plot 2025.10.29
  * Quetzal 1.8.9

Thanks for the PR, @zeel2104 -- can you explain the design decision to make a struct with two strings in it, instead of just creating a vector of strings and sorting that?

I can't reproduce the issue this PR fixes. For me, they are already sorted alphabetically (even though I installed them in a different order on purpose). Perhaps it's OS-dependent? Or depends on when they were installed?

OS: Windows 11 build 26200
Architecture: x86_64
Version: 1.2.0dev.20260407 (Git shallow)
Build date: 2026/04/07 22:56:13
Build type: Release
Branch: (HEAD detached at 6db886fe0)
Hash: 6db886fe0e79bf060ffeaa50198da25702a17e31
Python 3.11.15, Qt 6.8.3, Coin 4.0.8, Vtk 9.3.1, boost 1_86, Eigen3 3.4.0, PySide 6.8.3
shiboken 6.8.3, xerces-c 3.3.0, IfcOpenShell 0.8.2, OCC 7.8.1
Locale: Polish/Poland (pl_PL)
Stylesheet/Theme/QtStyle: FreeCAD.qss/FreeCAD Light/
Navigation Style/Orbit Style/Rotation Mode: Blender/Rounded Arcball/Window center
Logical DPI/Physical DPI/Pixel Ratio: 96/81.5973/1
Installed mods:
  * A2plus 0.4.68
  * Assembly4 0.60.6
  * Cables Workbench 0.3.5
  * CfdOF 1.34.13
  * Curves workbench 0.6.71
  * Defeaturing Workbench 1.3.1
  * Road 2026.4.11
  * SheetMetal Workbench 0.8.10

@FEA-eng It is OS-dependent, specifically filesystem-dependent.
The mods list order is determined by filesystem enumeration order, where NT doesn't guarantee sorted enumeration (see FindFirstFile remarks) but NTFS is known to sort files internally, as is mentioned in this article by Raymond Chen.

@chennes
I used a small struct to keep the sort key separate from the rendered output.

The displayed line is not just the addon name: it may also include the version, disabled state, and preserves the existing formatted entry text. Sorting only a vector<string> would sort by the full rendered line, which ties ordering to presentation details instead of the addon display name itself.

With the struct, name is only the sort key and entry is the final output line. That kept the sorting logic explicit and avoided reparsing formatted text after sorting.

If you prefer, I can refactor it to a more compact representation like std::pair<QString, std::string>.

That feels over-engineered to me: this is effectively debugging output, with a well-structured, straightforward format. I suggest simply renaming addModuleInfo to getModuleInfoString, returning a std::string instead of appending to the stream, and storing those strings in a vector. Sort the vector, then spit it out. No custom struct, no new method, minimal code intervention. The overarching principle of separating data from presentation is a good one, but it's overcomplicating this simple task.

@chennes
I simplified it as suggested: the helper now returns a formatted std::string, the code stores those strings in a std::vector<std::string>, sorts the vector, and then writes the entries out. That removes the custom struct and keeps the change more local.

You can avoid the large diff by putting the function back where the original one was, so it's clear at a glance that this is a nice, small change: basically the function signature and a little bit of plumbing.

Done. I moved getModuleInfoString() back to the original helper location so the diff is easier to review at a glance. The behavior is unchanged.

Sorry I wasn't clearer in my last comment: the original function, addModuleInfo, was on line 111. If you move the "new" function, getModuleInfoString, to that exact same location, it will be obvious at a glance (and in a git blame) that there are actually very few changes here. The objective of the whole exercise is that this should be a very small, self-contained fix, and the overall size of the PR should reflect that.

@chennes
Done