Closed facelessuser closed 9 years ago
No problem. :)
I wasn't aware about the .no-sublime-package
file so the binary permissions became an annoyance with the zip package.
@weslly, I have also thought about providing a binary for Windows color picker. I only suggest this because sometimes, something goes wrong with the ctypes method, and the colorpicker stops launching.
I was thinking about doing it in AutoHotKey (a windows scripting language) and posting the providing the source and the binary. I may even be able to preserve the functionality of ST2 windows where it takes the hwnd id. But I am hoping it will be more reliable as it would be a self contained app.
Let me know if you are on board with something like this.
The ctypes color picker is really limited indeed. I tried to replace it with a binary before but it didn't work well on x64.
I found this one a while ago but I have no experience with C#, so I wasn't sure on how I would return the value to stdout: http://www.codeproject.com/Articles/9959/Adobe-Color-Picker-Clone-part
I don't use windows but I heard about AutoHotKey before, sounds good to me.
The ctypes color picker is really limited indeed. I tried to replace it with a binary before but it didn't work well on x64.
The main thing that gets me is sometimes it just stops working. I guess other third party colorpickers support could be added. Support could be added for general well known colorpickers (mainly retrieving the format from stdout); the user would just point ColorPicker at the binary via the settings file. Maybe it could even be generalized, you specify the path, the color format that is returned, and the regex to parse the color, and internally it uses the regex to get the color channels and send them through the relevant convert to get the rgb hex value. That is probably the better way than physically trying to provide other 3rd party color pickers, but the current simple solutions are great to have it working out of the box.
I found this one a while ago but I have no experience with C#, so I wasn't sure on how I would return the value to stdout: http://www.codeproject.com/Articles/9959/Adobe-Color-Picker-Clone-part
If I get the time I'd love to code one up from scratch, it probably won't happen any time soon, but I've thought about it.
I don't use windows but I heard about AutoHotKey before, sounds good to me.
I only use Windows at work, at home its OSX. Windows is the computer of choice for most be corporations still. The binary will be be a 32bit exe that links to windows 32 bit libraries, so it will work on x64. The great thing about AutoHotKey is it is great for finding windows, getting window handles, PIDs, augmenting current running windows etc. Heck, you can generate your won windows. I can probably use it to position the color picker over the window properly in ST3, and maybe put Sublime in a state where doesn't turn white when you click it in the background.
What I will probably do at first though is provide the binary without killing the legacy method, just disabling legacy by default. That way if someone complains, they can enable legacy support via the settings file. But hopefully all will work well, and the legacy support could be deprecated. And in the future maybe add in support for 3rd party pickers so people can stop asking you to implement one for them :wink:.
I probably to optimistic with the 3rd party stuff as most don't auto-dismiss when you use them...sigh.
Cleanup is now in. I will worry about the windows binary next week.
@weslly I know absolutely no C#, but I got http://www.codeproject.com/Articles/9959/Adobe-Color-Picker-Clone-part working with your plugin. I wasn't planning on it, but this morning I was just curious how hard it would be, so I took about an hour to play. I still need to figure out passing in inputs, but I think we can replace windows crappy color picker with this one.
Ha!, Arguments handled. Now I just need to make the dialog pop up in the task bar...
New colorpicker is over on this branch for testing: https://github.com/weslly/ColorPicker/tree/win_colorpicker.
Nice! I'll setup a Windows VM to test it today. :)
This one looks way better than the old one, I noticed it doesn't have the "pipette" tool though, but the native never had one either (unlike OSX and Linux). I like the idea of being able to point the plugin to an external binary so people can use a different one, I guess the difficult part would be setting and getting the colors since very feel 3rd party tools bother handling stdin and stdout.
It's possible I could add a pipette in the future, but I will need time before that happens. This one is coded to take stdin and stdout, but yeah 3rd party don't always do that. A lot of them just copy it to the clip board or are integrated at a lower level to interact with apps.
Oh I forgot to commit the changes to the plugin. I will commit then soon.
Okay all changes are now committed.
I think this is all wrapped up. I will keep an eye out if there are problems with the new picker tool and resolve them if any crop up. Some day in the future, I will probably look into adding a pipette. I will also post the modified code somewhere soon so that if someone with actual C# experience wants to improve it or maybe even take it over :wink:.
Okay, thanks for the help with the plugin :)
@weslly, wanted to an idea for simplification of the existing plugin by you before I think about implementing it.
Instead of unpacking all of your binaries, I want to just add
.no-sublime-package
to the root of your project and add an__init__.py
file to yourlib
folder which will keep your package from being installed as a zip and allow you to access scripts and binaries directly from lib. Then, at most, do a couple of chmods. No need to asynchronously do anything.I think then I would probably just push the windows ctype abstraction down into the lib layer. It would really clean up the main code.
I just wanted to check with you because maybe you prefer it the current way.