Fucking Color Picker(tonymccoy.me)
tonymccoy.me
Fucking Color Picker
https://www.tonymccoy.me/projects/fcp/
139 comments
You can download GIMP which is about the same size, available for the same platforms, and includes a lot more stuff than just a color picker.
in Blender, you can choose your color picker type... https://docs.blender.org/manual/en/latest/interface/controls...
7 searches for cancer in this thread as of 7:51 AM UTC. (Not including my comment)
Got me thinking about the meaning of c-word and I realized electron is a contagious form of cancer. It spreads from devs to user sure, but it is also spreading from devs to devs and more and more devs are using it. Fucking Microsoft has an enterprise product built in electron now. Who would have thought?
Got me thinking about the meaning of c-word and I realized electron is a contagious form of cancer. It spreads from devs to user sure, but it is also spreading from devs to devs and more and more devs are using it. Fucking Microsoft has an enterprise product built in electron now. Who would have thought?
I know some people think Electron is cancer[1], but it is the fastest way to write cross-platform applications. I've been trying to learn to make apps for macOS, and it feels like even Apple doesn't want me write apps for the Mac.
[1]:https://medium.com/commitlog/electron-is-cancer-b066108e6c32
[1]:https://medium.com/commitlog/electron-is-cancer-b066108e6c32
128 MB for something that should be a couple hundred KB at best? Yes, it is cancer.
Well now it's 128MB for something that did not exist.
Which platform supported by Electron does not have existing color picker applications?
Been using GColor2 forever on Linux. And I believe there are others.
Don't really see how this improves it. I use Mac OS as well but I don't miss the color picker from Mac OS when I'm using Linux, not sure what his problem is. Or the attitude in general, I wouldn't want to be running something showing at all times such a cute name on screen. No thanks.
Don't really see how this improves it. I use Mac OS as well but I don't miss the color picker from Mac OS when I'm using Linux, not sure what his problem is. Or the attitude in general, I wouldn't want to be running something showing at all times such a cute name on screen. No thanks.
Provide an alternative to the cancer that has every single advantage of Electron.
Qt
One of the advantages of Electron is that apps can be written in JavaScript and other web technologies, making it accessible to many more developers.
You can use QML and QtQuick and use Javascript plus a markup langauge.
I'd like for people to drop the whole 'x is cancer' thing since aside from the actual fuckery of cancer most things aren't that bad. A little too flippant imo :)
Is it actually faster to develop in Electron than with QT and C++?
It has been over a decade, but I remember it being both straight-forward and pleasant to support Linux, Windows, and MacOS. I vaguely recall supporting Solaris too.
It has been over a decade, but I remember it being both straight-forward and pleasant to support Linux, Windows, and MacOS. I vaguely recall supporting Solaris too.
To be fair to Electron, Qt is an enormous dependency as well. Not as memory hungry at runtime, but Qt 5.12.1 frameworks for macOS are over 260MB. Granted, Qt is at least modular so you don't necessarily need them all.
However, given macOS apps don't really support shared libraries (at least in the typical sense), it adds up pretty quickly if you've got a few Qt apps.
However, given macOS apps don't really support shared libraries (at least in the typical sense), it adds up pretty quickly if you've got a few Qt apps.
> 260MB
That includes all the tooling/headers/.a/etc.
See this for the accurate size for the Qt runtime: https://github.com/qmlnet/qt-runtimes/releases
Windows - 43MB
OSX - 32.2MB
Linux - 57.6MB
That includes all the tooling/headers/.a/etc.
See this for the accurate size for the Qt runtime: https://github.com/qmlnet/qt-runtimes/releases
Windows - 43MB
OSX - 32.2MB
Linux - 57.6MB
Those are compressed figures (.tar.gz). Decompressing the OSX 64-bit runtime frameworks from there yields 85 MB. Which is less than the figure I had, but I believe is roughly in the same ballpark as the Electron runtime[1].
My original figure was probably debug frameworks (it's whatever Homebrew installs by default). However, I'd already excluded the tooling.
[1] https://github.com/electron/electron/issues/2003
My original figure was probably debug frameworks (it's whatever Homebrew installs by default). However, I'd already excluded the tooling.
[1] https://github.com/electron/electron/issues/2003
Oops, good catch, brain fart.
But yeah, 85MB for a complete UI runtime seems entirely acceptable to me.
But yeah, 85MB for a complete UI runtime seems entirely acceptable to me.
That's a good comparison, and I think I should qualify my statement. It's the fastest way to develop cross-platform apps when you already know web development. I've only done some trivial apps with QT and Python, and it was pretty straight forward. The UI didn't look as nice as it does with Electron. I'd be interested to hear someone's opinion who has real experience with both.
edit: u/781 has some experience with both and says Electron was faster to develop, his comment is below: https://news.ycombinator.com/item?id=19652691
edit: u/781 has some experience with both and says Electron was faster to develop, his comment is below: https://news.ycombinator.com/item?id=19652691
You can style the Qt GUI same as you would style the electron GUI so that’s a false equivalence kinda
I don't know about QT and C++, but a while ago I wanted to try out Electron and I just could not figure out how to build anything with it.
As someone who wrote GUI apps in most of the frameworks, starting with raw Win32 and MFC, yes, doing a GUI in Electron is massively faster, especially if you use modern frameworks like Vue or React.
You don't even need to know C++ to write a Qt app.
See Qml.Net (https://github.com/qmlnet/qmlnet), or PyQt.
See Qml.Net (https://github.com/qmlnet/qmlnet), or PyQt.
Web developers using Electron probably count in the time to learn C++ vs the fact that they already know web stack. ;)
I just realized this morning that JavaScript is the new Java.
js targets the browser (angular, React...), the back-end (node), the desktop (Electron) and mobile (React native). Just like the Java of old with applets, javax, JME, and of course weblogic and friends, js today allows you to code anything, as long as you don’t mind doing it badly, insecurely and/or wastefully.
Due to this ubiquity, a large majority of job openings list js in one form or another as a prerequisite (remember when entreprise code was synonymous with Java?)
Once you know enough js to be dangerous, there’s little incentive to pick up another programming language.
js targets the browser (angular, React...), the back-end (node), the desktop (Electron) and mobile (React native). Just like the Java of old with applets, javax, JME, and of course weblogic and friends, js today allows you to code anything, as long as you don’t mind doing it badly, insecurely and/or wastefully.
Due to this ubiquity, a large majority of job openings list js in one form or another as a prerequisite (remember when entreprise code was synonymous with Java?)
Once you know enough js to be dangerous, there’s little incentive to pick up another programming language.
Of they can just use QML and use JavaScript and a declarative language for their UI.
I think the bottom line is that most of the time you see an electron app, just say to yourself, "this wouldn't exist if electron didn't exist."
It isn't replacing app dev. It's adding more app developers.
It isn't replacing app dev. It's adding more app developers.
cancer is also one of the "fastest way" to grow some kind of tissue. That might kill you in the end.
> it is the fastest way to write cross-platform applications.
I disagree. Maybe that's true if you're a webdev unwilling to learn anything else, but Lazarus is the fastest way I've found to write cross-platform GUI software, and as a bonus it compiles to native code in a single executable.
I disagree. Maybe that's true if you're a webdev unwilling to learn anything else, but Lazarus is the fastest way I've found to write cross-platform GUI software, and as a bonus it compiles to native code in a single executable.
If you wonder about linux: gcolor2 (http://gcolor2.sourceforge.net/) does the job.
And for size fetishists: it weights 42KB.
And for size fetishists: it weights 42KB.
Also, xmag, you already have it installed if you use the X Window System. It's 41kb, extremely lightweight (always starts instantly) and also magnifies a screen portion which is helpful for picking colours.
> you already have it installed if you use the X Window System
Maybe.
It looks like it's been spun out into `x11-apps` on debian based distros in the last year or two, and for some reason I don't have that package installed despite using X
Maybe.
It looks like it's been spun out into `x11-apps` on debian based distros in the last year or two, and for some reason I don't have that package installed despite using X
Something I never realized about xmag is that if you click on a pixel, it tells you that pixel's color as a hex triple.
One good option for Windows is COPI, 88 KB .exe: https://www.heise.de/download/product/copi-colorpicker-65782
> for Windows is COPI, 88 KB .exe
And the EXE is only 32 KB when UPX is applied on it. And uses only 1 MB of RAM when running.
And the EXE is only 32 KB when UPX is applied on it. And uses only 1 MB of RAM when running.
Seriously there was no existing color picker app for Windows alraady?
Of course there are many, but bashing Windows is free. After 10 seconds on google:
http://colorcop.net/
http://www.iconico.com/download.aspx?app=ColorPic&type=free
http://www.youngsmarts.com/download.htm
... and so on.
http://colorcop.net/
http://www.iconico.com/download.aspx?app=ColorPic&type=free
http://www.youngsmarts.com/download.htm
... and so on.
Didn't know about Color Cop, it's great!
Of course there was, even open source Electron ones[1], but that wouldn't be a blog post and a chance to "promote" yourself.
Also, opening up Photoshop for the color picker? Paint opens faster than I can blink and has a color picker.
[1] https://electronjs.org/apps/colorpicker
Also, opening up Photoshop for the color picker? Paint opens faster than I can blink and has a color picker.
[1] https://electronjs.org/apps/colorpicker
I use Pixie[1], which works really well even on Windows 7 and 10. It's an 11kB portable app.
[1] http://www.nattyware.com/pixie.php
[1] http://www.nattyware.com/pixie.php
Thank you, this is beautiful.
There are a couple of other cool tools on the page too that I weren't aware of, like this:
http://www.nattyware.com/fontster.php
It's a HTML + Javascript desktop application that weighs 2 K. And it even uses native widgets and looks and feels like a real application. Isn't that something... ;)
There are a couple of other cool tools on the page too that I weren't aware of, like this:
http://www.nattyware.com/fontster.php
It's a HTML + Javascript desktop application that weighs 2 K. And it even uses native widgets and looks and feels like a real application. Isn't that something... ;)
Have been using Pixie since forever on Windows. Neat little tool.
Wow, this is waaaay too big for my taste.
I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.
I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.
Well, for one, you could skip writing it for Mac OS because it already has a fucking color picker.
This is an answer without a real problem, for Mac users anyway.
This is an answer without a real problem, for Mac users anyway.
Windows and Linux already have color pickers too.
Yes, this 450 line program could have been written in whatever native language you want with probably 3x the code and time spent, but why would you? Developer time has been more expensive than hardware for a decade now.
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
Ah yes, the good ol' "Efficiency doesn't matter on my hardware in my situation" argument. Brought to you by the same culture that ends up with devs being surprised most of their users in fact don't have 8-core 32G machines with 4k screens, unlike all of their colleagues and immediate peers.
For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.
For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.
I would in fact argue that until we are at a point of diminishing return of improving hardware that it is good that software is becoming more and more "bloated", because that's the only incentive to keep researching more efficient hardware.
Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections.
As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections.
As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
> we are at a point of diminishing return of improving hardware
We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development.
That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt.
> that it is good that software is becoming more and more "bloated"
No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf.
> that's the only incentive to keep researching more efficient hardware.
No it isn't, this is just more baseless speculation to support your point.
We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development.
That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt.
> that it is good that software is becoming more and more "bloated"
No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf.
> that's the only incentive to keep researching more efficient hardware.
No it isn't, this is just more baseless speculation to support your point.
> Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features.
I don't see it. The latest version of iOS is (apparently) such a big performance improvement that its performance got top billing as a "Feature" from Apple [1]. They brag about how it's ~50% faster at several common tasks.
[1]: https://www.apple.com/ios/ios-12/features/
I don't see it. The latest version of iOS is (apparently) such a big performance improvement that its performance got top billing as a "Feature" from Apple [1]. They brag about how it's ~50% faster at several common tasks.
[1]: https://www.apple.com/ios/ios-12/features/
Why is everybody always so concerned with developer time, but never with user time? The author of this tool even complains about the startup time of photoshop, but somehow has no problem with building a tiny tool on Electron. The irony is quite strong here.
> Developer time has been more expensive than hardware for a decade now.
How about developer time of 1 person vs. hardware (and electricity, CO2 emissions...) of 1 million users?
How about developer time of 1 person vs. hardware (and electricity, CO2 emissions...) of 1 million users?
> vs. hardware (and electricity, CO2 emissions...) of 1 million users?
Do you actually have a million users? Can that developer time be spent saving even more hardware or human costs elsewhere?
Do you actually have a million users? Can that developer time be spent saving even more hardware or human costs elsewhere?
Slack probably does.
> Do you actually have a million users?
Everybody who works on a cross-platform version of a generic utility has potentially many millions of users.
> Can that developer time be spent saving even more hardware or human costs elsewhere?
Nobody knows. But it's obvious that wasting resources like this is going to scale with every user - even non-users who just download out of curiosity.
Everybody who works on a cross-platform version of a generic utility has potentially many millions of users.
> Can that developer time be spent saving even more hardware or human costs elsewhere?
Nobody knows. But it's obvious that wasting resources like this is going to scale with every user - even non-users who just download out of curiosity.
> Everybody who works on a cross-platform version of a generic utility has potentially many millions of users.
Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well.
I'm going to assume the answer is "no, this does not currently have a million users".
> Nobody knows.
We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal.
I'm going to assume the answer is "yes, that developer time can be more efficiently used."
> But it's obvious that wasting resources like this is going to scale with every user.
This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs?
[1] https://en.wikipedia.org/wiki/Opportunity_cost
Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well.
I'm going to assume the answer is "no, this does not currently have a million users".
> Nobody knows.
We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal.
I'm going to assume the answer is "yes, that developer time can be more efficiently used."
> But it's obvious that wasting resources like this is going to scale with every user.
This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs?
[1] https://en.wikipedia.org/wiki/Opportunity_cost
> I'm going to assume the answer is "no, this does not currently have a million users".
You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere.
The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere.
The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
> You can spend all day asking irrelevant questions
We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant.
> The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case.
You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine.
Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far.
But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is.
> You don't need justification for developing something that isn't good because of wrong or selfish priorities,
Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant.
> The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result.
Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case.
You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine.
Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far.
But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is.
> You don't need justification for developing something that isn't good because of wrong or selfish priorities,
Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
> What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
It's simply completely irrelevant what the developer might or might not be working on also in your imagination, when we are judging the product based on its technical merits.
Inventing some extremely important better use of the developer's time to justify inflicting a wasteful 55MB download on the world, is a strawman argument of the same quality you complained about.
It's simply completely irrelevant what the developer might or might not be working on also in your imagination, when we are judging the product based on its technical merits.
Inventing some extremely important better use of the developer's time to justify inflicting a wasteful 55MB download on the world, is a strawman argument of the same quality you complained about.
I deal with programs that crash OOM on 32GB+ machines. I deal with products that actually have a million users, with gigabytes of download. I don't need to invent anything that the developer could be working on, existing problems to work on are abundant. And I don't even work on anything important! But more important than this color picker? I'm pretty sure you could think of concrete examples of that too, without resorting to imagining anything.
And if we're limiting the discussion to just the technical merits of a product, I'm not sure why you started discussing developer time and expense at all. You're the one who brought up "dev time vs millions of users hardware", and I'm just pointing out that it's perhaps more realistic to view this as "dev time" vs "thousands of users hardware" in this particular case, and that there's a lot of mildly important things the developer could work on instead.
And if we're limiting the discussion to just the technical merits of a product, I'm not sure why you started discussing developer time and expense at all. You're the one who brought up "dev time vs millions of users hardware", and I'm just pointing out that it's perhaps more realistic to view this as "dev time" vs "thousands of users hardware" in this particular case, and that there's a lot of mildly important things the developer could work on instead.
We choose to code so people with lower spec machines should also be able to run the program without having to worry about it running like trash.
Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104
Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104
For me it takes 1 second to hit alt+print screen and then open ms paint with my shortcut ctrl + alt + P.
A color picker using Electron. The epitome of resource waste.
xmag comes by default on most Linux distros
KDE/Plasma actually comes with a built-in color picker which I use on a daily basis:
https://kde.org/announcements/plasma-5.5/plasma-5.5-colorpic...
https://userbase.kde.org/Plasma/ColorPicker
https://kde.org/announcements/plasma-5.5/plasma-5.5-colorpic...
https://userbase.kde.org/Plasma/ColorPicker
I had become so used to just grabbing color values from any old pixel on the screen..., but on Windows the best way I came up with was to take a screenshot, wait for Photoshop to open, then get the color value through the PS eyedropper tool. That took probably 30 seconds to get a single color, since Adobe software is somehow still dog slow on brand new hardware.
You can do the same thing in MS Paint and save yourself 15 seconds.
You can do the same thing in MS Paint and save yourself 15 seconds.
and you can leave it running in the background all day long
Nope, you cannot colorpick with MS Paint from the whole visible screen (i.e. all windows and the desktop)
The workflow is:
1) Take a screenshot.
2) Paste it into Paint.
3) Use the eye dropper to select the pixel that has the color you want.
This is the equivalent of editing a file with Notepad++ instead of opening it in Visual Studio.
1) Take a screenshot.
2) Paste it into Paint.
3) Use the eye dropper to select the pixel that has the color you want.
This is the equivalent of editing a file with Notepad++ instead of opening it in Visual Studio.
If you can screenshot it, you can paste it into MS Paint. No difference from Photoshop or any other image editing program.
The only problem I have with MS Paint is that it doesn't give me the hex value of the color I picked, only the individual RGB values.
The only problem I have with MS Paint is that it doesn't give me the hex value of the color I picked, only the individual RGB values.
I think this is more down to Apple style workflow than actual requirements.
With Apple you have to do things the special Apple way because Steve Jobs said so.
On Linux I am not thinking 'oh, where is my system wide colour picker and getting irate because there isn't one'. The colour picker works fine in the image editor program, with the browser add on I am covered for practically every use case.
Sure I had to add the browser extension and would be stuck without it, but my thinking was to get the browser extension rather than even think to install an OS widget.
I can't say that I have had a genuine need for a OS level colour picker ever. It is just not something needed. And no, just because I am not on an Apple machine does not mean I don't do anything 'creative'.
With Linux there are plenty of colour pickers already out there, 'pick' is very neat as it gives you a little screenshot of the context of where you got your colour from with a sensible colour name given too (albeit not a standard X-Windows style one, so you get 'Hot Cinnamon' instead of 'chocolate').
With Apple you have to do things the special Apple way because Steve Jobs said so.
On Linux I am not thinking 'oh, where is my system wide colour picker and getting irate because there isn't one'. The colour picker works fine in the image editor program, with the browser add on I am covered for practically every use case.
Sure I had to add the browser extension and would be stuck without it, but my thinking was to get the browser extension rather than even think to install an OS widget.
I can't say that I have had a genuine need for a OS level colour picker ever. It is just not something needed. And no, just because I am not on an Apple machine does not mean I don't do anything 'creative'.
With Linux there are plenty of colour pickers already out there, 'pick' is very neat as it gives you a little screenshot of the context of where you got your colour from with a sensible colour name given too (albeit not a standard X-Windows style one, so you get 'Hot Cinnamon' instead of 'chocolate').
I actually tried installing this on my Mac and it doesn't open. I'm on 10.14.4.
choco install instanteyedropper
Fucking Electron
> So I wondered... why didn't Windows just have a fucking color picker?
Color Picker for Windows (500KB) (1.6MB unzipped): http://instant-eyedropper.com
Significantly smaller than the Electron app and works across Windows XP to 10.
Color Picker for Windows (500KB) (1.6MB unzipped): http://instant-eyedropper.com
Significantly smaller than the Electron app and works across Windows XP to 10.
Windows has a million color pickers, just go to chocolatey
I use this and couldn't recommend it more
MWSnap has a color picker in addition to a screen capture and has been around since 2002. I still use it on Win10.
http://www.mirekw.com/winfreeware/mwsnap.html
http://www.mirekw.com/winfreeware/mwsnap.html
I just use ShareX on windows which has color picker tool. Also you can simply create a system-wide keybind for it.
I bound mine to the middle click action of the taskbar.
but I also overrode the tooltip text on the screenshot cursor to display the RGB hex, as a ctrl+c will copy whatever is in this box
but I also overrode the tooltip text on the screenshot cursor to display the RGB hex, as a ctrl+c will copy whatever is in this box
Complains about Photoshop being slow to start. Writes color picker in Electron.
One of the slowest things in photoshop is the initial document selection/welcome screen.. which is probably... javascript+browser engine.
And I also think the slow "new document" screen is also javascript
Also let's not forget all those stupid creative cloud background updater jobs / services... that use node.js
And I also think the slow "new document" screen is also javascript
Also let's not forget all those stupid creative cloud background updater jobs / services... that use node.js
Confused... why do you need Photoshop? Can't you just PrtScn, paste in MS Paint, and use the eyedropper?
Absolutely. But he doesn’t know how to use windows. That’s why he went to linux.
A dev missed some feature of their usual OS and so wrote a cross platform version open source in their spare time.
Who cares that they used the “wrong” language or framework, or could have solved it another way or “who need this functionality anyway”.
Isn’t this supposed to be what the dev spirit is about?
Who cares that they used the “wrong” language or framework, or could have solved it another way or “who need this functionality anyway”.
Isn’t this supposed to be what the dev spirit is about?
That isn't the problem. The problem is the community, and the effect Electron is having on it.
Cross platform application development is considered a "solved problem" with Electron, and it's developed a cult that leads people to disparage native applications and native development as inferior in all cases, as if Electron were already the best possible solution rather than a hack around webdev that blew up because of the SV hype machine.
Because of this commoditization around a single language and a single framework (mostly by corporate interests, mind you,) curiosity and innovation are halted in favor of developer time efficiency and resume visibility. No one is even going to bother trying to create the next cross-platform application solution after Electron, because they would only be able to do so in Electron.
It's getting kind of ridiculous.
Cross platform application development is considered a "solved problem" with Electron, and it's developed a cult that leads people to disparage native applications and native development as inferior in all cases, as if Electron were already the best possible solution rather than a hack around webdev that blew up because of the SV hype machine.
Because of this commoditization around a single language and a single framework (mostly by corporate interests, mind you,) curiosity and innovation are halted in favor of developer time efficiency and resume visibility. No one is even going to bother trying to create the next cross-platform application solution after Electron, because they would only be able to do so in Electron.
It's getting kind of ridiculous.
> A dev missed some feature of their usual OS and so wrote a cross platform version open source in their spare time.
So what matters is the "why" and the "what", and we can just forget about the "how"? Engineering is all about the how we do things, and HN tends to have more engineers than your typical online community. What's wrong with that?
So what matters is the "why" and the "what", and we can just forget about the "how"? Engineering is all about the how we do things, and HN tends to have more engineers than your typical online community. What's wrong with that?
100%. HN comments can be so perfectionist which is ironic given the name.
Someone spent their free time to give the world something free, shame on them it's not perfect.
Someone spent their free time to give the world something free, shame on them it's not perfect.
If anyone is put off by it being an Electron app and are running Windows, here's an AHK[0] script to get the hex code of the pixel color under your cursor and copy it to your clipboard:
---
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
---
It's bound to Win+h (hex color) by default.
It's not fancy, but it works. You just run it in the background and hit the hot key to copy the color whenever you want to. There is no UI.
What's neat about it is the entire source code fits in a tweet: https://twitter.com/nickjanetakis/status/1108825825116332032
And it uses 0.6MB of RAM when running.
[0]: https://www.autohotkey.com/
---
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
---
It's bound to Win+h (hex color) by default.
It's not fancy, but it works. You just run it in the background and hit the hot key to copy the color whenever you want to. There is no UI.
What's neat about it is the entire source code fits in a tweet: https://twitter.com/nickjanetakis/status/1108825825116332032
And it uses 0.6MB of RAM when running.
[0]: https://www.autohotkey.com/
> It's not fancy
Excuse me, this is one of the tiniest and most useful things i've seen in my life as a budding designer.
Excuse me, this is one of the tiniest and most useful things i've seen in my life as a budding designer.
Thanks, I'm glad you like it.
It was something I whipped up in 5 minutes about a month ago when I really wanted a quick and dirty color picker. I do use it in practice.
One shortcoming is it doesn't visually show the color after you copy it, but that could also be done with AHK. You could totally have it show a small 16x16 window with the color which would disappear after 2 seconds and would get refreshed after you pick a new color if it were still visible.
You could even go 1 step further and change it to zoom around your cursor on key press, and then copy the color on mouse click while showing a 16x16 window color preview on hover. That would be the ideal solution, but something like that might be 3-4 hours of hacking around with no real AHK knowledge instead of 5 minutes and that wasn't worth it to me at the time.
It was something I whipped up in 5 minutes about a month ago when I really wanted a quick and dirty color picker. I do use it in practice.
One shortcoming is it doesn't visually show the color after you copy it, but that could also be done with AHK. You could totally have it show a small 16x16 window with the color which would disappear after 2 seconds and would get refreshed after you pick a new color if it were still visible.
You could even go 1 step further and change it to zoom around your cursor on key press, and then copy the color on mouse click while showing a 16x16 window color preview on hover. That would be the ideal solution, but something like that might be 3-4 hours of hacking around with no real AHK knowledge instead of 5 minutes and that wasn't worth it to me at the time.
AutoHotkey is amazing. It's a little gem of a Windows app. I only wish I discovered it earlier, when I was still using Windows as my main OS.
AHK can be used to trivially fix many usability warts you have with random software, and is powerful enough that someone implemented a clone of dwm tiling window manager in it (bug.n, [0], I used it for more than a year and can attest it works very well).
--
[0] - https://github.com/fuhsjr00/bug.n
AHK can be used to trivially fix many usability warts you have with random software, and is powerful enough that someone implemented a clone of dwm tiling window manager in it (bug.n, [0], I used it for more than a year and can attest it works very well).
--
[0] - https://github.com/fuhsjr00/bug.n
Totally agreed.
I'd go as far as saying AHK is one of the few tools on Windows that I really miss when on a Linux system. It's that good and I don't even know it too well, I just hack things together as needed. Bash is great and all but AHK does so many useful GUI things.
Thanks for the link on bug.n. I use i3 on my Linux laptop and for day to day usage I do prefer a tiled window manager of some sort. My Windows box is my main workstation so having some type of proper tiled wm would be really nice. Currently I use dexpot (virtual workspaces), AHK (global hotkeys), keypirinha (fuzzy find app launcher) and the built in Win 10 window split shortcuts to get as close as I can to an i3 set up.
I'd go as far as saying AHK is one of the few tools on Windows that I really miss when on a Linux system. It's that good and I don't even know it too well, I just hack things together as needed. Bash is great and all but AHK does so many useful GUI things.
Thanks for the link on bug.n. I use i3 on my Linux laptop and for day to day usage I do prefer a tiled window manager of some sort. My Windows box is my main workstation so having some type of proper tiled wm would be really nice. Currently I use dexpot (virtual workspaces), AHK (global hotkeys), keypirinha (fuzzy find app launcher) and the built in Win 10 window split shortcuts to get as close as I can to an i3 set up.
AutoHotKey is great and the kind of thing that should just be built in to desktop OSs. Why shouldn't I just be able to assign any key combo to anything, contextually? Why do we have to rely on applications supporting hotkeys at all?
This seems like a very Windows-specific complaint, not a general desktop OS one.
Oh? What is the Linux equivalent? I'm aware of KDE having a hotkey system but from what I recall it didn't allow you to bind keys to scripts or contextually. Maybe there's some X component I'm not aware of? That's nice, probably doesn't work in Wayland. Of course in Wayland such things would be left up to the compositor.
"Linux" isn't the only other OS either (and here doesn't quite make sense, seeing as it's a userland detail that doesn't really have anything to do with the kernel the distros share). Apart from the ability to change the keybinding dictionary for basic stuff like copying and pasting and such, Automator on macOS lets you pretty much bind anything to anything.
How does a color picker weigh ~50MB? Is there something wrong with the framework it's using?
In total, the app is 122 MiB large.
Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker.
The actual app itself is in the resources directory which is 1.8 MiB large.
This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (1.4 MiB).
The actual content created by the author is in app.js, package.json and static, which together take 160 KiB, of which 52 KiB is the logo (would have been much smaller as SVG) and 68.8 KiB a bundled font.
In the node_modules directory major contributors for size that I see are:
* node_modules/tinycolor2/demo (288 KiB; largest contributor here is a jquery copy)
* node_modules/tinycolor2/docs (228 KiB)
* node_modules/tinycolor2/test (116 KiB)
* node_modules/electron-settings/node_modules/fs-extra/docs (96 KiB)
* node_modules/electron-settings/node_modules/fs-extra/CHANGELOG.md (56 KiB)
* node_modules/user-media-screenshot/.idea/ (44 KiB)
All of the stuff I listed above is quite redundant for the users who just want to run the app. If you remove them, the 1.8 MiB become 764 KiB for the entire app and I'm pretty sure that minifiers, bundlers etc. could make it even smaller.
The runtime could be provided by the OS. I think it's definitely possible to create apps < 500 KiB with web technology, it's just the deployment patterns that turn this into a major download of 122 MiB. As for the RAM usage, idk about that. I guess if the runtime is provided by the OS, it would be the same electron binary so the OS could share that one at least.
Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker.
The actual app itself is in the resources directory which is 1.8 MiB large.
This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (1.4 MiB).
The actual content created by the author is in app.js, package.json and static, which together take 160 KiB, of which 52 KiB is the logo (would have been much smaller as SVG) and 68.8 KiB a bundled font.
In the node_modules directory major contributors for size that I see are:
* node_modules/tinycolor2/demo (288 KiB; largest contributor here is a jquery copy)
* node_modules/tinycolor2/docs (228 KiB)
* node_modules/tinycolor2/test (116 KiB)
* node_modules/electron-settings/node_modules/fs-extra/docs (96 KiB)
* node_modules/electron-settings/node_modules/fs-extra/CHANGELOG.md (56 KiB)
* node_modules/user-media-screenshot/.idea/ (44 KiB)
All of the stuff I listed above is quite redundant for the users who just want to run the app. If you remove them, the 1.8 MiB become 764 KiB for the entire app and I'm pretty sure that minifiers, bundlers etc. could make it even smaller.
The runtime could be provided by the OS. I think it's definitely possible to create apps < 500 KiB with web technology, it's just the deployment patterns that turn this into a major download of 122 MiB. As for the RAM usage, idk about that. I guess if the runtime is provided by the OS, it would be the same electron binary so the OS could share that one at least.
Nice breakdown of wasted resources.. It's frustrated me for a long time how people are carelessly bundling unused code, which is unfortunately common in JavaScript-land.
Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed.
As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673
However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..
Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed.
As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673
However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..
I'm not sure what it is about the node development environment but you are right. I haven't seen such wildly complicated dependency trees in any other language. Literally hundreds of modules can come together to make even simple applications.
Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious.
I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.
Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious.
I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.
Here's the thing though: You could build this in pure Node and call Windows APIs, Qt, etc and it'd be much, much smaller.
But everyone just goes ahead and pulls in Chrome.
It's shameful, and the worst part is that I get it - at this point I'm suggesting we go to Electron for a new application at work because it seems like the best maintained UI frameworks with readily available 3rd party components are all web based.
But everyone just goes ahead and pulls in Chrome.
It's shameful, and the worst part is that I get it - at this point I'm suggesting we go to Electron for a new application at work because it seems like the best maintained UI frameworks with readily available 3rd party components are all web based.
It might be the Unix philosophy taken to its logical extreme. Everything should do one thing and do it well. So now we have libraries that are literally a single function.
I find it darkly funny that Electron is the new size/waste-of-resources whipping boy. Java applications generally suffer the same issues with the exception that the runtime isn't usually distributed with every application. But the goal of write once, run anywhere is basically the same.
Now that Java is being developed at such a speedy clip at the cost of breaking changes, we may see Java runtimes being shipped with apps. (I'm personally still on Java 8 because that was the last release before drastic breaking changes started happening.)
Just kidding. Java has been abandoned in favor of web apps anyway.
Now that Java is being developed at such a speedy clip at the cost of breaking changes, we may see Java runtimes being shipped with apps. (I'm personally still on Java 8 because that was the last release before drastic breaking changes started happening.)
Just kidding. Java has been abandoned in favor of web apps anyway.
Thanks for the wonderfully detailed breakdown. I wish every electron app could get this.
I don't hate web technology, I just hate electron's distribution model. There are so many frameworks to get around this.
I don't hate web technology, I just hate electron's distribution model. There are so many frameworks to get around this.
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
> What´s the problem with this?
The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
Just download more RAM!
On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
Because there are few people on earth more entitled than the modern web developer?
Nah dude this line of thinking got us here. We need to reach back to what the OG's in computing thought about. Small size, fast performance. Limit ourselves.
I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones."
Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that.
We need a return to small-footprint as a feature.
I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones."
Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that.
We need a return to small-footprint as a feature.
Hehe, kinda funny when an application comes with more security vulnerabilities than it has lines of code for its own logic ;-)
EDIT: edited to make it less ambiguous
EDIT: edited to make it less ambiguous
My app does very little and is meant to be self-hosted for your own use. Or are you talking about Elixir or Nim as a language?
Edit: Oh I get it you actually meant:
"Hehe, kinda funny when your application written for Electron comes with more security vulnerabilities than it has lines of code for its own logic ;-)"
Edit: Oh I get it you actually meant:
"Hehe, kinda funny when your application written for Electron comes with more security vulnerabilities than it has lines of code for its own logic ;-)"
Sorry, is this a comment on elixer or Nim?
Neither.
It is about having a color picker (probably just a few lines of code) bundled with quite a set of dependencies and complex chromium runtime environment which does not get updated regularly. Therefore they keep their vulnerabilities even after they are known and fixed in later versions of the dependencies.
With small footprint applications, you are less likely to have such problems.
It is about having a color picker (probably just a few lines of code) bundled with quite a set of dependencies and complex chromium runtime environment which does not get updated regularly. Therefore they keep their vulnerabilities even after they are known and fixed in later versions of the dependencies.
With small footprint applications, you are less likely to have such problems.
Can't argue with you there, I tend to use tcl/tk for something this small.
There is no problem. It is just like flying with a helicopter to the supermarket. You just need a supermarket with a large enough parking lot.
but better than using 5 different cars for 5 different supermarkets.
First, this is a false dichotomy. There are alternatives to Electron that don't require a 120 MiB runtime and don't involve using the OS APIs directly.
Second, this is not a criticism on application writers, but on Electron itself. It could use a runtime available on computers (virtually every computer has a browser) or, at least, a shared runtime that would download itself.
Bundling a browser with EVERY different app is not only a waste of space and of RAM, but also a security issue: now you have to wait for each app developer to update the app in case there's a security problem with Electron, Chromium or any of its 2000 dependencies, and that's "if" they upgrade. And that update takes at least another 120 MiB to download, for each Electron app you have.
Instead of downloading 120 MiB for each app, each app could come in a small package and only download the runtime if it's not available in the computer yet. Java got it right in the 90s, .NET got it right in the 2000s, although downloading the runtime had terrible UX for stupid marketing reasons (you had to provide e-mail to download from the Sun or the MS website).
Second, this is not a criticism on application writers, but on Electron itself. It could use a runtime available on computers (virtually every computer has a browser) or, at least, a shared runtime that would download itself.
Bundling a browser with EVERY different app is not only a waste of space and of RAM, but also a security issue: now you have to wait for each app developer to update the app in case there's a security problem with Electron, Chromium or any of its 2000 dependencies, and that's "if" they upgrade. And that update takes at least another 120 MiB to download, for each Electron app you have.
Instead of downloading 120 MiB for each app, each app could come in a small package and only download the runtime if it's not available in the computer yet. Java got it right in the 90s, .NET got it right in the 2000s, although downloading the runtime had terrible UX for stupid marketing reasons (you had to provide e-mail to download from the Sun or the MS website).
> What´s the problem with this?
It's 120 MB for literally a fucking color picker.
It's 120 MB for literally a fucking color picker.
yes and it works everywhere, everytime.
Every native app I've used works everywhere I've used it, every time as well.
That native apps were wildly unstable, or that it was impossible to find native apps that ran on different platforms before Electron is a myth. Electron didn't solve those problems, because they weren't problems.
Electron solved the problem of "how can I, a web developer, run a website on the desktop but make it seem like a native app and call myself an application developer?"
That native apps were wildly unstable, or that it was impossible to find native apps that ran on different platforms before Electron is a myth. Electron didn't solve those problems, because they weren't problems.
Electron solved the problem of "how can I, a web developer, run a website on the desktop but make it seem like a native app and call myself an application developer?"
ColorMania works great and is 774 KB. http://www.blacksunsoftware.com/colormania.html.
Doesn't seem to fucking work.
On Linux it seems confused with a muti-monitor setup, the orbit button does nothing.
On Windows, in a VM, the orbit button opens a web browser to https://www.tonymccoy.me/orbit/#ffffff and gets a 404 Not Found
On Linux it seems confused with a muti-monitor setup, the orbit button does nothing.
On Windows, in a VM, the orbit button opens a web browser to https://www.tonymccoy.me/orbit/#ffffff and gets a 404 Not Found
Also QT provides a cross-platform color chooser widget.
https://doc.qt.io/qt-5/qcolordialog.html
KDE's KColorChooser is simply a wrapper around this and is less than 100 lines of code, mostly setting up the about box.
https://kde.org/applications/graphics/kcolorchooser/
This could have trivially been made into a cross-platform color chooser that uses significantly less resources.
On my Linux box Fucking Color Chooser spawns 4 fucking processes uses 128 MB of RAM and 4% CPU.
KColorChooser uses 15 MB in one process and near zero CPU.
Please stop making everything a web application.
https://doc.qt.io/qt-5/qcolordialog.html
KDE's KColorChooser is simply a wrapper around this and is less than 100 lines of code, mostly setting up the about box.
https://kde.org/applications/graphics/kcolorchooser/
This could have trivially been made into a cross-platform color chooser that uses significantly less resources.
On my Linux box Fucking Color Chooser spawns 4 fucking processes uses 128 MB of RAM and 4% CPU.
KColorChooser uses 15 MB in one process and near zero CPU.
Please stop making everything a web application.
I was really excited until I saw Electron at the bottom.
A color picker is a tantamount example of an application that does not belong on the Electron platform.
A color picker is a tantamount example of an application that does not belong on the Electron platform.
I use pyautogui for this, pyautogui.displayMousePosition().
It obviously doesn't have a fancy preview, different representations or the other stuff you would get in a proper color picker, but it's fast and easy if you already have pyautogui installed and works on both linux and windows.
It obviously doesn't have a fancy preview, different representations or the other stuff you would get in a proper color picker, but it's fast and easy if you already have pyautogui installed and works on both linux and windows.
Sorry but both Mac and Windows are proprietary, no color picker can save you.