[Feature]: Formats keep piling up and nothing on a format says who it's for — how should Filee handle this before we add more? #832

What would you like Filee to do?

Formats have been added much faster than we have any way to sort them. Nothing on a format says who it's for or how common it is, so every new one lands in every user's lists, and the busy donuts are already full. I found this while counting for #806. That issue is about what the default donuts show; this one is about why that keeps breaking: how formats come into Filee and what they say about themselves. I don't have the answer, but I'm fairly sure that if we keep adding formats this way, Filee gets harder to use with each one, so I'd like to decide how it handles this before more formats arrive.

Where things stand (upstream/main; sources in brackets)

• Filee knows 270 formats. It knew 26 in v1.0.0 a month ago, 172 in v1.2.0 and 256 in v2.0.0 [FormatRegistry.Known at each tag]. 32 format requests are open, many of them specialist (STEP, DGN, 3DM, SKP, BLEND, MAX, OSM, GRIB, NetCDF, BLP, Minecraft packs, MIDI, ...).
• Everything Filee can write reaches everyone:
  • the preset editor's target list shows 176 output formats,
  • the preset library and the toolbar editor's palette show all of them too,
  • the toolbar page lists all 19 donuts.
• The busy donuts are full. The image donut uses all 12 slots on both faces, and the video donut uses 11 and 12 [BuiltInData, ToolbarProfile.MaxSlices].
• I sorted all 270 formats by hand into four classes (full table below; it's my judgement, so some calls are debatable, and I counted HWP and HWPX as everyday because of Korean users). 91 of the 176 output formats are specialist or legacy, and only 18 of those sit in categories of their own (CAD, 3D, maps, fonts). The rest are inside Image, Video, Audio, Text, Ebook and the other everyday categories. The table gives each format a single class, so it mixes two different things: who uses a format, and how often anyone wants it. It's here to show the size of the problem; if we go ahead, I'd redo it on two separate axes.

How formats are sorted today

There is more than the category. Five things in the code already sort formats, each for its own purpose:

Why this doesn't hold up as formats grow:

1. The category can't carry more. It drives behaviour (which options show, which tab a preset sits in), so DICOM can't be moved into a "medical" group without losing its image options. Who a format is for would need a place of its own.
2. "How common" exists, but not on the format. Registry order, the donut faces and DefaultTargets each decide it separately, with no shared rule, and nothing on the format itself records it.
3. A new format gets none of those signals. It isn't on any donut and isn't in DefaultTargets, yet it shows up in the target list and the palette's All tab right away. The front/back split only works inside a donut's 12 slots and does nothing for the lists.
4. The only per-format visibility switch is Writable, and it answers "can Filee write it", not "who wants it". So every writable specialist or legacy format reaches every user's lists.

What one more format costs today

• Everyone's target list, preset library and palette get longer, whether or not they will ever use it, and what they do use gets harder to find.
• The busy donuts have no free slots, so a useful new conversion either stays off the donut or pushes another one off. On the image donut this has already happened: "Extract Live Photo video" and "GIF" stay in the library because "Merge images" took the last slot [comment above the image donut in BuiltInData].
• Every place that shows formats is either a hand-picked list (each donut's slices) or everything (the lists above). So each new format either needs someone to place it by hand in every one of those places, or it shows up everywhere.

Why / when would you use it?

What #806 showed. We agreed to turn off whole fields (CAD, 3D models, maps, fonts, game textures), and I worked out a table for it. Counting the result:

• With all five off, the everyday donuts lose no slices. DWG, STL and the like only ever appear on their own donuts.
• The settings lists shrink a little: 176 → 158 target formats, 117 → 100 presets, 19 → 15 donuts in the toolbar page.
• The busy donuts are filled by general formats, less used but not specialist (TIFF, BMP, ICO and AVIF on the image donut, MKV and AVI on video, ODT and RTF on documents), which no field switch touches.
• Switches built on categories reach only 18 of the 91 specialist and legacy output formats; the other 73 live inside Image, Video, Audio and the rest.

So adjusting what's shown, one surface at a time, doesn't hold: every new format undoes it. At the pace of the last month (26 → 270), and with 32 requests open, the target list could pass 200 output formats and the donuts would keep pushing useful slices off, each time for every user.

Where the problem actually sits. I think it has three layers, and #806 only touched the last one:

Work on layers 2 and 3 can't keep up while layer 1 asks nothing of a new format, because each one has to be sorted afterwards. And which fix fits layers 2 and 3 depends on the answer to layer 1.

Ideas for how it could work

The question I can't answer for Filee: where should the breadth live? The README leads with "270 formats, no other software", so breadth is clearly a strength worth keeping. What I don't know is how it should reach users:

• Everything in the main app, for everyone. Then growth can't be slowed, and layers 2 and 3 have to carry it.
• Everyday formats up front, the rest still supported but kept out of the way (read-only, opt-in, or hidden until needed). Then layer 1 needs a bar, and layers 2 and 3 can stay light.

Below are the options I can see at each layer. I'm not picking among them; they mostly combine, and which ones make sense depends on the answer above.

Layer 1: what gets in

• (a) Keep adding formats as today.
• (b) A bar for new formats, for example: an output format only if ordinary users would want to make it; otherwise read-only, so it can be opened and converted from but never adds to the target lists.
• (c) Specialist families (CAD, 3D, GIS, medical, games, ...) as opt-in packs, the way optional engines are already installed on demand.

Layer 2: what a format says about itself

• (a) Category and Writable only, as today.
• (b) Who produces it: everyone, or one or more fields that aren't tied to categories (DICOM can be "medical" while staying an Image).
• (c) How likely someone wants to make it: for example main, more or rare. Only formats Filee can write need this, since the donut already shows only what fits the dragged files. Age is a reason a format is rare, not a value of its own: AVI and DOC are old but still common, PCX is old and rare. This would replace the three separate guesses (registry order, donut faces, DefaultTargets) with one value on the format.
• Whatever is added would be required for every format by tests, and asked for in docs/ADDING-A-CONVERTER.md like the category is today.

Layer 3: what users see

• (a) Hand-picked as today, plus the field switches from [Feature]: A rule for what Filee shows by default, before more formats are added #806.
• (b) Derived from layer 2 by rule: lists show what the user works in, legacy hidden unless searched for; donut fronts hold everyday conversions, backs hold edits and general ones. Hand picks stay as overrides.
• (c) Shaped by each user: they pick the fields they work in, and optionally their own frequent conversions (kept on the device) come forward.

I've put the field table from #806 on hold, since it would only cover a small part of layer 2. Please let me know which way you'd like Filee to go, and which of these you'd consider; I'll propose a first step based on your answer and follow your feedback.