Skip to content

Instantly share code, notes, and snippets.

@02JanDal

02JanDal/candidates.md

Last active August 29, 2015 14:14
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save 02JanDal/8fb6f7fa489d1e963659 to your computer and use it in GitHub Desktop.
Save 02JanDal/8fb6f7fa489d1e963659 to your computer and use it in GitHub Desktop.
Download ZIP
Candidates for merging from MultiLaunch -> MultiMC
Raw
candidates.md

This is a list of code parts from MultiLaunch that could be merged into MultiMC, along with some thoughts on usefulness/feasibility etc.

Code parts

Accounts

A lot more flexible than the accounts system in MultiMC, allowing additional account types like Imgur etc. Merging shouldn't be to hard, and would bring some benefits. The current system in MMC is rather stable and without issues though, so that would need to be considered.

Utils

Several of the classes in core/utils would be very useful in MultiMC, like AbstractCommonModel (would need some work first), BaseConfigObject, FileSystem and Json. Easily mergable, can be introduced gradually. Maybe make use of biicode for this?

BaseVersion(List)

This part doesn't differ from MultiMC very much, but caching would be nice to have in MultiMC.

FileCache

Very similar to the Metacache, so likely easier to just do small changes (if any) to the existing Metacache.

Using LogicalGui to separate UI from logic

This is more of an ongoing change that may or may not happen.

IconRegistry, IconProxyModel

Easily mergable, mainly gruntwork. Would get rid of QIcon, which is makes logic depend on QtGui.

Task system

Mainly interesting would be StandardTask, after it's rewrite.

Network system

Relatively similar in API terms to the one in MultiMC, so should be easily mergable. The functionality is also very similar though, so the function-wise gain would be minimal.

Container/Component system

Would be a lot of work to merge, could be done using a BaseInstance subclass (ContainerInstance?), but would result in rather large amounts of code duplication. On the other hand it would make it easy to get among others the factorio stuff, shared folders, etc. into MultiMC. Still likely to much work.

Order of PRs

  1. Utils, including applying them to useful places
  2. Tasks
  3. Accounts
  4. IconRegistry, IconProxyModel
  5. Network stuff
  6. BaseVersion(List) and FileCache
  7. LogicalGui?
  8. Container/Component system?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment