I suggest editing the readme on https://github.com/facelessuser/ColorSchemeEditor to either point to this thread or to expose downloadlinks and installation instructions directly (maybe also a link to the GUI source repo). Because as it is now it's nearly impossible to know how to get the thing working.

(Also posting here to kinda "subscribe" to this thread since I monitor all threads I posted in manually.)

As long as its in BETA, the readme may be pretty bare. I am lazy when it comes to readmes. Before I officially release it, I will document everything in the readme. Right now, the forum OP has everything you need. I will welcome a pull request with documentation .

I just found this plugin browsing through your repositories - you should really put this on Package Control! Up until now I've either been editing themes by hand using ColorPicker, or using the theme editor in TextMate 1 on my Mac. You should be able to set up the Package Control .json files to download the different binaries for different platforms by pulling from individual branches in your GitHub repo. If you still need help with documentation I'd be willing to help out.

It has been on my list. It is very usable as is, but sadly you have to manually set it up.

I just haven't taken the time to think through the distribution. The plugin side (the part that sublime uses to call the binary and send it what theme to edit) runs on all platforms universally. When the plugin initializes at Sublime startup, I call the binary and request the version to see if the plugin and the binary are compatible (in case I have added new features etc.). I want to eliminate calling the tool to request the version. I always get a lag during sublime startup while the plugin requests the version. Having an included versions file with the binary would let me eliminate requesting the version from the tool and speed up Sublime start time.

I also want the plugin code and the binaries to be two separate things. I don't want to have a branch for each platform where I am merging the plugin side of the code to all three branches, but that is a possibility. What I actually want, is a single repo branch for the plugin code, and then have the binaries in their own separate place. But I want Package Control to pull them both, or have plugin code that, once installed, checks out the binaries (with included versions file) itself. That way upgrading the binaries could easily be managed.

I guess I could just have it as a requirement that when you install the ST plugin, you have to also install the binary package part of the plugin via Package Control as well. I wonder if Package Control has a way to configure dependancies?

I really just need to sit down and plan it out, but I am also open to hearing some good ideas or getting help from others.

Package Control does not provide a way to specify dependencies, however it would certainly be awesome if it did. Relevant discussion here, and some here.

I think there is currently 2 solutions to the problem:

1. Provide 4 packages, one ST base and one core for each platform. The first package would tell you to download the corresponding package from package control if it does not exist (or even do it automatically, I think you can install arbitrary plugins using package control from within a plugin if you call the functions directly). The others would then do the same.Maybe you can even download arbitrary repositories that are not even listed in package control? That would surely be awesome.

2. Provide 1 package with 3 releases. You can either mirror the ST base code in each repo/branch or provide 3 manually created archives that you specify directly (using "url").

@FichteFoll, thanks for the info. I will explore what I can do with Package Control (PC) before I make any decisions. I am going to try to have a separate binary repo with separate OS branches. Then I will see if I can use PC from the ST plugin to pull the appropriate binary branches, if that doesn't work, I will explore other options.

Before I try and release this, I think I will set up using pipes with the ColorSchemeEditor. That way if a second instance of the editor gets launched, it can send its parameters to the first instance and close...I might even have the ST plugin send the info down the pipes without launching a second instance. Anyways, this all depends on what I get to first, but I will try and get this suitable for PC first, and see what I feel like doing then. Hopefully it won't take much.

I decided just to have the plugin manually download the zip file from github. I have an experimental branch that does this, but it is not currently threaded, so it freezes things up. I will thread it before I release it. It should be able to upgrade the binary when needed as well. But the point is, I can can have this work as a package once I clean it all up. Probably should be done by the end of the week if not sooner depending on how motivated I am.

Small fix posted. I wasn't testing from a completely clean environment, so the installation didn't fail for me. I have fixed the issue, and ensured the installation success message also displays. I have tested this on OSX and Windows, and it appears to be good. If anyone tries this please confirm it worked for you as well. I am going to polish up the binaries, and get this to Package Control soonish.

I will probably have to rename the package...I don't think I am the only one to have used ColorSchemeEditor as a name...I can probably just do it in Package Control settings.

I assume you haven't tested this on ST2 yet because there is no entry point for the plugin (only for ST3). Furthermore `set_timeout_async` is not available to ST and I'm actually not sure if just changing this to `set_timeout` won't freeze ST for the download duration. A real thread might be necessary in this case, which on the other hand can not call specific API functions, but I don't know which these are.

Anyway, I will look into this tomorrow and eventually do some updates for ST2 compatability or change the code to be ST2-only for another branch. I don't really like that though. Also, if you don't plan to support ST2 at all I would probably just leave it at that, assuming it works on my ST3 portable.