Possibly (?) useful Linux testing feedback: On 64-bit Ubuntu 12.04, it works about as well as on 32-bit 12.04. The app loads and works, but there are issues with the font rendering (different ones) and with the widgets. I won't bother you with the details since you're building this for latter versions, but from the looks of it my guess would be that it works on 64-bit 12.10.

@quodlibet, thanks for the feedback, I am happy to hear it seems to work on 32 or 64 bit. I don't currently do an architecture check, so the plugin should run fine on either. I wonder if building for 12.04, would work on 12.10...From what I understand, there is usually the thinking that building with the oldest linux you can can sometimes be better if the shared libraries are backwards compatible. I am pretty sure there was a significant jump from 11.X to 12.10, was there big differences in core stuff when Ubuntu jumped from 12.04 to 12.10? I am not completely sure if/when they dropped gnome2. Is 12.10 using gnome3? I might have a 12.04 VM image...maybe I will build wxpython 2.9 on 12.04 and see how the editor built on 12.04 performs on 12.10.

If you are interested, I can give you the steps to get your system ready and build it on 12.04? Once the dependencies are in place, building the the Color Scheme Editor is pretty easy.

12.04 is the LTS (Long-term support). There don't seem to be vast differences between the two (they are both based on Gtk 3, which is what I thing you're referring to with Gnome 3), but I think there have been updates to Gtk that have not been backported.

facelessuser:

If you are interested, I can give you the steps to get your system ready and build it on 12.04? Once the dependencies are in place, building the the Color Scheme Editor is pretty easy.

Thanks for the offer, but as I'm not a programmer, I'd rather not install a whole bunch of dependencies just for this. I'm also quite handy with creating themes (thanks in large part to ScopeHunter & PlistJsonConverter My main use for this would be go get a quick overview of a new tmTheme, which I can actually do at the moment in its half-working state.

There's an issue with the placement of the button (not a big deal) on 32-bit:

How reproducible is this. There is supposed to be code that automatically resizes the window to fit the button in. This used to be a problem for me as well, but it is supposed to be fixed. I am wondering if it is a bug that sometimes pops up, or if it is always like that for you. Worse case scenario if I can't get it resized proper by default is allow the user to manually resize vertically.

quodlibet:

On 64-bit I get a number of error about PangoFc. I'm assuming I'm missing some dependenices, but I haven't looked at it too closely:

Not much I can say about that except try to apt-get install PangoFC I guess. I can make a note of it for others if that is the only missing dependency. I am testing on VMs that have all dependencies to build it, so it is hard for me to catch dependencies that others will be missing. Pyinstaller does its best to include everything it can when compiling the binary, but I guess it can't include everything needed.

It's very reproducible, but it only happens when using Openbox (which is what I usually use). On Unity I didn't have any problems. So it must be some kind of weirdness on the part of Openbox in how it renders dialogs.

facelessuser:

Not much I can say about that except try to apt-get install PangoFC I guess. I can make a note of it for others if that is the only missing dependency.

I have tried installing some Pango stuff but without resolving the issue. Googling the errors didn't help, either. Sorry

That is both the plus side and negative side of Linux. Highly configurable, and a billion different flavors of Linux, but it can be a pain to write applications to support all variations. I may play around in the future with openbox and see if I can find maybe the issue. Not sure about the Pango issue. I don't really have the motivation to download a bunch of virtual machines and build on different architectures. A lot of linux issues I am going to leave up to linux people to figure out when it deals with compatibility; it just isn't worth it to me to invest that kind of time.

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.

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.