FrameManager.cs is a 10k-line monster — let's break it up (happy to do the first PR)

[lilei105]

Hey @limbo666 —

Been hacking on a fork of Desktop Frames + and want to start sending stuff upstream, but I keep slamming into one thing: FrameManager.cs. Figured I'd flag it and offer to help.

The deal

FrameManager.cs is ~9,940 lines / 477 KB. For scale, that's ~5.7× the next-biggest file in the repo, and bigger than the next half-dozen .cs files combined. It's basically one giant god class — ~100 methods across 15+ unrelated concerns:

• frame lifecycle
• the whole Tabs engine
• icon rendering / extraction
• drag & drop, resize, snap
• context menus, draw mode
• JSON save/load
• auto-hide, launch effects / animations
• click / launch handling

...all crammed into one file with a single #region. No internal structure to speak of.

Why it's a pain

Every frame-related change funnels through this one file, so any two patches — mine and yours, or two contributors' — collide constantly. It's basically the worst-case shape for git merges; keeping a fork in sync with upstream is where I hit it every single time. PRs that touch it turn into huge, scary diffs that are slow to review and easy to break. And a new contributor basically has to swallow a 10k-line file before they can safely change anything.

You've already started fixing this

Half the repo is already marked "Extracted from Framemanager for better code organization" — FrameDataManager, FilePathUtilities, IconManager, SnapManager, LaunchEffectsManager, PortalFrameManager, and friends. So the direction's set, it just hasn't reached the core orchestrator stuff still stuck in FrameManager.

What I'd do (small, safe, mechanical slices)

One extraction per PR, pure move + rename, no logic changes:

1. Tabs engine (~17 *Tab* methods) → new TabManager. Clean boundary, great first slice.
2. Icon stuff → into IconManager.
3. Drag/drop + resize/snap → IconDragDropManager / SnapManager.
4. JSON save/load → finish moving into FrameDataManager.
5. Launch effects / animations → LaunchEffectsManager.

End state: FrameManager shrinks to just the lifecycle/orchestration core, and changes stop all landing in the same giant file — which directly shrinks the conflict surface for everyone.

Quick win while that happens: even just dropping a few #regions in to group things by concern would make the file way easier to navigate and merge.

I'm in

I can knock out #1 (the Tabs extraction) as a standalone PR — move only, no behavior changes, easy to review and bisect. Point me at whichever slice you want first and I'll get going. Or if you've got a different split in mind, I'll follow your lead.

[lilei105]

Hey - just opened the first PR for this: #130. Tabs engine moved into TabManager, pure move, no behavior changes, builds clean. Take a look whenever you get a chance.

[limbo666]

Hey! Thank you so much for tackling this. You are absolutely right about FrameManager.cs—it is a bottleneck, and your roadmap for extracting these managers is spot on.

Here is the current situation: I have been working offline on a massive update that heavily alters the core files, and I am about to push it to the repo. If we merge this PR right now, it will create a massive conflict with my incoming update.

To avoid breaking the source code, I will push my major update first. Once the new baseline is live, would you be willing to sync your fork and apply this extraction to the new FrameManager? I completely support this refactoring direction and would really appreciate your help getting it done.

[lilei105]

Ah, had no idea you were already on it — makes total sense. We can sort out the rest once your update is live.

[limbo666]

@lilei105
OK, repo is up to date!
It still needs more fixes to be ready for release but since you are on it for refactoring you have green the green light to work.

[lilei105]

@limbo666 First cut is up - PR #131 (extract Tabs engine into TabManager, pure refactor, no behavior change): #131 - builds clean, tabs verified working. Details in the PR. If it lands, next cuts (IconManager / Snap / FrameData / LaunchEffects) follow.

[limbo666]

PR #131 merged ☺️

[lilei105]

@limbo666 Cut #2 is up - PR #132 (remove ~341 lines of dead icon code from FrameManager, zero behavior change): #132 - pure deletion, builds clean. The full IconManager move was trickier than expected (half-finished extraction + unequal duplicates), so I pulled the safe dead-code cleanup out first; details in the PR. Real move to follow as its own PR if this lands.

[lilei105]

@limbo666 Cut #3 is up - PR #133 (move snap A-cluster into SnapManager, pure refactor): #133 - bonus: it eliminates the existing SnapManager-Framemanager circular dependency (those snap-preview methods were always just callbacks for SnapManager anyway). Builds clean. #132 (dead code cleanup) is still waiting on you when you get a chance.

[lilei105]

@limbo666 Separate question on the next cut (IconManager). It looks like a half-finished extraction: its AddIcon/UpdateIcon/UpdateFrameDataForIcon are dead copies (zero callers), lagging behind the live versions still in FrameManager (which have more - grayscale, custom text color, Portal branches, network fail-safe, StoreApp handling, _iconStates cache). My plan B would be: overwrite the dead copies with the live versions, merge duplicated helpers (GetUrlCustomIcon vs ExtractCustomIconFromUrl), relocate private deps (_iconStates, IsNetworkPath, BackupOrRestoreShortcut), rewire 6 external call sites, and plug LazyIconLoader into the live path. Before I move all that code around - does IconManager, in your mind, own the full icon UI lifecycle (add/update/render)? Or should it stay a lower-level icon-source/cache utility and leave UI orchestration in FrameManager? Want to align with your vision first.

[limbo666]

Yes. This was abandoned and needs to be refactored but It is quite tricky...
If you feel confident enough you can work towards refactoring the icon management to icon manager but this need to be done with extreme caution.
The reason I left it that way was because I hit bugs here and there, missing the correct icon representation for missing folders and files (we have a special treatment for targets that are not available) and to be frank I was excausted chasing the issues.
If you feel that you can handle the migration to IconManager without breaking the code this should be a great approach.