[Idea]: Direct .zip import for custom runners

[iharuya]

Overview of the requested feature

Installing runners from the Runner Gallery is currently a bit tedious as users have to manually unzip and select image files.

An option to import a runner by simply selecting (or dragging & dropping) the downloaded .zip file directly within the app.

Thank you for your great work on RunCat!

Reason for the request

I want to make custom runners and encourage people to actually use it.

Related Issues

No response

Check List

• I have read the CONTRIBUTING.md and agree to follow it.
• The proposed feature is beneficial to a wide range of users and not just a personal preference.
• Checked that no similar requests already exist.

[ToooAir]

I also wish that user can import runners from RunCat Classic, as I lost those image of my custom runner.

[Kyome22]

@iharuya Thank you for submitting your idea.
I think being able to import custom runners directly via ZIP is a great idea. However, since we need to review the data structure of the download files on the Runner Gallery side, we plan to handle this with caution.

[iharuya]

@Kyome22 thanks for considering. I agree this could lead a security hole so we have to be careful.

[heung115]

Hi @Kyome22, I'd like to work on this issue. I already have a local draft of the implementation, but I wanted to confirm the expected scope before refining it and opening a PR.

My current plan is to:

• allow both .png and .zip through the existing file importer and drop target
• keep file access in DataClient, with ZIP import handling in Model/RunnerService
• read PNG frames directly from the archive in filename order, without extracting them to disk
• preserve the existing frame dimension checks and 30-frame limit, while also enforcing archive size and entry-count limits

Could you please confirm a few details before I finalize the implementation?

1. Would you be open to a PR for this issue at the moment?
2. Should ZIP imports strictly match the current Runner Gallery structure (<name>-frames/<name>-frame-N.png) and reject unrelated entries, or should any ZIP containing valid PNG frames be accepted?
3. Would you prefer using an existing ZIP library such as ZIPFoundation, or keeping the implementation self-contained with a small reader limited to the ZIP formats needed here?

I’ll keep the PR narrowly scoped to ZIP import and adapt the implementation to whichever direction you prefer.

[Kyome22]

@heung115
First, regardless of this PBI, I am working on a major refactoring of the source code, so there is a possibility that pull requests will conflict.

Also, regarding this issue, I am considering whether it would be better to make it so that setting values such as the runner name and monochrome/color settings can also be imported together, since we are going to the trouble of importing via ZIP. In that case, we would have to change the data structure, including the ZIP, on the Runner Gallery side. However, since the runner name is not localized, automatically populating it might not be that useful, so there are points to consider regarding how far it is worth going. (Could using Foundation Models for automatic translation also be an option?)
If we pack information other than frame images into the ZIP file, I would also want to prevent the overall data structure of the Runner Gallery from managing the same information redundantly, so it is not simple.

Therefore, I was thinking of taking my time to consider this after the refactoring is done.

[heung115]

@Kyome22 Thanks for the detailed explanation. I really enjoy using RunCat Neo, so I wanted to contribute if I could.

I understand. I’ll hold off until the refactoring and ZIP format are settled. Hopefully I can help out later.