Split CLI & GUI, alternative output formats

[encounter]

For integration into other tools, objdiff could have different output formats like asm-differ:

• JSON
• HTML?
• Terminal?

Having it be usable as a one-shot CLI app will permit integration with decomp.me.

[NickCondron]

The first step to accomplishing this is to segregate the core functionality from the GUI functionality. Then you can reuse the core functionality for the GUI & CLI. I think there is some work to be done in this area. For example, one thing I noticed are the idx fields for coloring in different structs like obj::ObjInsArgDiff that should probably be moved to GUI-specific code.

The convention I've seen in some projects is to have a top-level Cargo.toml that defines a virtual manifest and then you put any binary and library crates in some subfolder (eg. crates/*). See also discussion here https://matklad.github.io/2021/08/22/large-rust-workspaces.html#Large-Rust-Workspaces

I'm still familiarizing myself with the code base, so I'm curious how well-separated you think the code is?

[encounter]

Agreed on the objdiff-core approach. The existing code should be easy to separate, it’s already abstracted to support the threaded “job” system.

The idx fields aren’t necessarily GUI specific, they’re precalculated so that work doesn’t have to be done every frame.

[ribbanya]

Seems resolved by 4eba5f71b0501c86f0f4b55179602a899deb88b1 and 9a7d2bcebfa2b65f90c5fbe42095772859cfef42.