Live data from Hacker News

Fucking Color Picker

Post reply on HN

Print view View original

71–80 of 140 posts

Re: Fucking Color Picker

#71

Post by heywire » Sat, Apr 13, 2019, 1:10 PM UTC

781 wrote: post #46

nieksand wrote: post #13

Earlier quoted context omitted.

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.

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.

*if you are a web developer familiar with these frameworks.

Re: Fucking Color Picker

#72

Post by pooya72 » Sat, Apr 13, 2019, 1:11 PM UTC

781 wrote: post #51

babuskov wrote: post #26

Earlier quoted context omitted.

Web developers using Electron probably count in the time to learn C++ vs the fact that they already know web stack. ;)

As a C++ developer who had to learn Javascript and Vue to write an Electron app, it was still faster than writing the same app in QT (which I used before).

How and why was it faster? Did it have to do with the tooling?

Re: Fucking Color Picker

#73

Post by altcognito » Sat, Apr 13, 2019, 1:11 PM UTC

kgraves wrote: post #37

> 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.

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

Re: Fucking Color Picker

#74

Post by MaulingMonkey » Sat, Apr 13, 2019, 1:13 PM UTC

lazyjones wrote: post #61

MaulingMonkey wrote: post #56

Earlier quoted context omitted.

> 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? 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

Re: Fucking Color Picker

#75

Post by _noise_ » Sat, Apr 13, 2019, 1:18 PM UTC

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

Re: Fucking Color Picker

#76

Post by Polarity » Sat, Apr 13, 2019, 1:20 PM UTC

est31 wrote: post #64

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 (…

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.

Re: Fucking Color Picker

#77

Post by TeMPOraL » Sat, Apr 13, 2019, 1:20 PM UTC

nickjj wrote: post #55

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…

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

Re: Fucking Color Picker

#78

Post by pooya72 » Sat, Apr 13, 2019, 1:22 PM UTC

781 wrote: post #46

nieksand wrote: post #13

Earlier quoted context omitted.

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.

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.

Sorry, I know I asked you this below. I'm just a new programmer trying to learn, how is that GUI development in Electron is faster?

Re: Fucking Color Picker

#79

Post by [deleted] » Sat, Apr 13, 2019, 1:23 PM UTC

pooya72 wrote: post #72

781 wrote: post #51

Earlier quoted context omitted.

As a C++ developer who had to learn Javascript and Vue to write an Electron app, it was still faster than writing the same app in QT (which I used before).

How and why was it faster? Did it have to do with the tooling?

[deleted]

Re: Fucking Color Picker

#80

Post by lazyjones » Sat, Apr 13, 2019, 1:24 PM UTC

MaulingMonkey wrote: post #74

lazyjones wrote: post #61

Earlier quoted context omitted.

> 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. 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"…

> 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.

Post reply on HN