I suggest editing the readme on 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.
Sorry for the rambling post .
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:
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.
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.
I wanted to get this done, so I went ahead and finished it up.
Can someone try out the experimental branch? github.com/facelessuser/ColorSc … compatible
Linux is probably hit or miss, and most likely only works on Ubuntu. I know they were compiled on a 12.X Ubuntu, not sure if they work on 13.X. But Windows and OSX should be fine.
Anyways, if someone does try it, please report if there were any problems, or if it worked great 
.
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.
I will be honest. All new plugins that I am doing, I code from an ST3 perspective. I code for what I use, and I am using ST3. Many of my plugins that originally were supported on ST2, I have continued to back-port features and fixes to the separate legacy branches, but that will only be until ST3 is released. I won’t kill them off, but new features I will leave to others to back-port if they are desired. I have a bunch of plugins right now, and supporting them all for multiple platforms is a bit of work. Most of my new plugins have been ST3 only: RawLineEdit, QuickCal, EasyDiff, etc. Maybe I will make some donate buttons very prominent on some of my projects and see which ones people actually support the most. Maybe those I will support in the long term for ST2.
As for the plugin at hand:
Using a real thread would fix that issue for sure; I almost did use a real thread, and I don’t mind switching to a real thread either (it really isn’t that much extra work to use real threads), but I took the path of least resistance last night to get the proof of concept out (and I wanted to try out set_timeout_async because I hadn’t as of yet).
Also, I would need to abstract the requests for package resources.
I think I would need to abstract some unicode stuff as well…pretty sure, there always seems to be some kind of unicode conflicts
I am not adverse to supporting this on ST2 and ST3 as a single branch. The tool itself already works regardless of platform (that is really 90% of the work). I imagine that once the plugin supports both, it really wouldn’t require much maintenance since its main purpose is to call the tool.
If you are feeling ambitious, I would gladly welcome help on getting it ST2 compatible. If not, I will take a look when I get some time. I will at least look at the threading issue tonight; I did take the easy way out on that one .
It is always hard for me to gauge how much real excitement there is for a plugin, so it also makes it hard for me to gauge how much effort to put in, so I always code for myself first and then others as my motivation allows.
Edit: If I am feeling ambitious tonight, I will see how far I can get with ST2 abstraction.
Now using the threading library.
Edit: I was wrong about the message dialogs. ST2 supports OK/Cancel dialogs.
pc-compatible branch now should handle ST2 or ST3. I have not tested it on windows yet, so there may be some file path issues. I will test it tomorrow when I get to a windows machine. It does appear to work on OSX though.
Small fix for windows now posted. Turns out opening a dialog in as a plugin is loading on ST2 on windows can cause sublime not to start. So a delay has been added before checking and prompting if a download is desired.
Good news is this works on ST2 and ST3 and has been verified on Windows and OSX now.
I’m sorry that I couldn’t take a look at it yesterday but I’m really busy atm and the spare time I get is spent in other ways than coding, even though I would love to. I’m hoping to look at it on the weekend but my workload is huge. (And it certainly doesn’t help that I’m continously adding more stuff to it, even though it increases less than before.)
No worries. Get to it when you can. I understand busy, it is the same reason why I have issues on my repos that have been open for months, it is also why this project hasn’t seen any recent development until now. I’ve been dragging my feet on completing this project for a while.
I tried in both st2 and st3 on Windows 7, have not tried OS X 10.9 or Windows 8 yet. I can apply changes to a theme but not save. When I do a save as it creates a monochrome theme.
When I use the 0.8 binary I have no issues and can save and save as though save as still creates a monochrome theme.
Bruce
[quote=“rgidney”]I tried in both st2 and st3 on Windows 7, have not tried OS X 10.9 or Windows 8 yet. I can apply changes to a theme but not save. When I do a save as it creates a monochrome theme.
When I use the 0.8 binary I have no issues and can save and save as though save as still creates a monochrome theme.[/quote]
Oh…wow. Hah, looks like a broke some stuff along the way. The monochrome theme is a default one that gets created when you don’t give it a theme. For some reason, I am dumping that during save as…I need to fix that. Thanks for the report! I don’t do a lot of save as, I mainly use the edit current theme, and watch my changes update there (by default it live edits a copy of the theme that it copies over to User/ColorSchemeEditorTemp). I don’t know if many people have been using this app, so development kind of slowed on this. I can get this fixed this week though.
OSX 10.9 appears to have an issue where it isn’t showing the menu bar items. Apparently there were some changes to Cocoa…I will play around and see if there is an obvious fix. I don’t know if recompiling on OSX 10.9 will make a difference.
I have plans to update some stuff for a 0.9 version. I will fix save as and post when it is finished.
Found the save as bug, it was sloppy on my part. But 0.0.9 will have it fixed. I will more thoroughly test the next one .
Still confused about OSX and wxpython on 10.9. No menu bar… 
Edit: Menu bar appears after selecting a different window and reselecting the app. Will probably be fixed in a new WxPython…but we will just have to wait for that …oh well. Everything else is moving forward.
After some more testing in Windows 7 and 10.9 I found if I open subclrschm inside of sublime I can not save changes (save grayed out), only save as but if I open it out side of sublime then save is available, after making a change.
I tried running subclrschm with sublime open and with it closed and the behavior was the same, it was only when it was called from sublime that save is inactive.