Refactor: Separate Core Logic from UI for CLI/GUI Independence

[totalbrain]

Description
Separate the core optimization logic from the UI to make the app modular. The core should handle input/output independently (e.g., console, file, event viewer) without relying on Tkinter. This is like logging systems that output to multiple sinks.

Why this is useful?

• Enables CLI mode (--terminal) without GUI dependencies
• Makes output flexible (console, file, notification, etc.)
• Improves maintainability and testability
• Allows future extensions (web API, integration with other tools)
• Reduces main.py length by modularizing

Implementation Ideas

• Create src/core.py for all optimizations (apply_optimizations)
• Use abstract I/O handlers (e.g., ConsoleOutput, FileOutput)
• Main entry: Check args --gui / --terminal and load appropriate mode
• Example structure:
  • src/core.py: Pure functions for token crushing
  • src/ui.py: GUI logic (Tkinter)
  • src/cli.py: Console logic (argparse)
  • main.py: Parse args and route to UI or CLI

Additional context

• Inspired by logging modules (console, file handlers)
• Relates to issue #X (CLI version)
• Test with pytest: Core independent of UI

Priority

• Must-have

[totalbrain]

Hey @Syogo-Suganoya!

Just a heads up – I'm starting this refactor to make the core logic 100% independent from UI/CLI, turning it into a pure engine that can be used anywhere (GUI, CLI, extensions, etc.). This way, we can collaborate better: you focus on GUI enhancements (like the awesome theme toggle and drag & drop you already nailed), and I'll handle the core optimizations.

Quick summary of what's on my mind:

• Core in src/core/ (pure Python, no dependencies – just input/options → output/stats)
• Techniques in separate files (src/core/techniques/remove_comments.py, etc.)
• Interfaces separate (src/interfaces/gui/ for UI, src/interfaces/cli/ for terminal)
• Benefits: Faster tests, easy extensions (e.g., VS Code plugin), and modular for future like web API
• Implementation: Start with engine.py for crush(), models.py for results, and main.py for mode detection

If any strategies, suggestions, or coordination ideas come to mind (e.g., how to handle theme in the new structure), I'd love to chat – let's sync up and make this epic!

What do you think? 🚀

[Syogo-Suganoya]

@totalbrain
Thanks for sharing the plan — the direction sounds excellent.

Decoupling the core logic from the UI/CLI will make the project much more maintainable and flexible, and the structure you proposed looks solid. Having a pure engine layer also makes future extensions (plugins, web API, editor integrations, etc.) far easier to build, so I’m fully on board.

I especially like the idea of placing the optimization techniques in separate modules; that will keep things clean as the feature set grows.
For the interfaces, a dedicated interfaces/ namespace makes sense to me.

A couple of minor thoughts:

• If the core will eventually expose multiple “entry points” (e.g., crush, analyze, stats), designing a small public API early could help.
• For theme handling or UI-related settings, keeping them strictly on the interface side sounds right — the core should stay completely unaware.
• Let’s make sure we don’t break existing behavior; once the engine draft is up, I can help test the integration side.

Overall, I think this refactor is absolutely the right move.
Happy to sync up anytime if you want to discuss architecture or module boundaries in more detail.

Great work — excited to see this come together!