Earlier quoted context omitted.
PhPStorm and NetBeans are not 'native'.
Care to elaborate?
There's nothing to elaborate. They're both Java/Swing apps.
VS Code uses 13% CPU when idle due to blinking cursor rendering
751–760 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#752Earlier quoted context omitted.
"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants." Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.
> Trying to shoehorn everything into "the web" 'Trying to shoehorn' is just your opinion. > Use the right tools for the job. What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies. Or should I use Qt, with it's tiny support community? Also why is React/React-Native not 'the right too…
It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable.
"Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to invalidate the project.
By the way, if you'd like to really throw a stick into Qt proponents spokes, ask them what sort of accessibility story QT has for custom rendering components. Ask, "How can I support a colorblind or legally blind person with this component?"
Qt's developer story here is not nonexistent, but it throws into sharp contrast how _complete_ the web is from the perspective of accessibility for people who need auditory assistance or do not use conventional input devices.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#753Earlier quoted context omitted.
> If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing h…
Maybe it's just me, but I always avoid apps that don't integrate well with my platform. They're just not pleasant to use. I want the same look and feel, I want the same file browser, I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day. I'm not so sure it's mitigated by the web - people may browse Facebo…
> I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day.
You must not use OSX native apps then with multiple monitors then. They don't work right (at least not for me!) One of the reasons I use Chrome for so much is that when I change my workspace (as someone who does both coding and project management this is increasingly a requirement) I don't want my UI to clip off the frame unrecoverably or render as a blurry mess.
> I'm not so sure it's mitigated by the web - people may browse Facebook and a few news sites, but those aren't complex applications at all and they have very simplistic UIs
You should look at the Chrome Web Store. But... also... "Facebook?" "Simplistic?" Simplistic is hacker news, where I can't use an Emoji.
> that don't attempt to imitate familiar desktop controls
One last thing: this is much more a sign of the current UI style of the time, and is very much a product of a post iPhone world where unique visual styles are expected. Even then, a text editor is such a specialist piece of work even native apps struggle and cheat, doing things like avoiding sheet animations and providing unique UI and UX components. Native apps have been introducing their own file hierarchy and multi-modal buttons since the time of emacs.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#754Earlier quoted context omitted.
Indeed. Especially since TCP-based X would require that you stall operations if you drop a packet so that draw-ordering is preserved.
Could have sworn that there exist multiple takes on extensions for that, but none that has been rolled into Xorg proper. This either because lisencing, or because the current devs have GPU stars in their eyes. BTW, it is downright funny how just about every Gnome guy i have encountered online seems to come across a pedantic grump. that would not know a joke if it fell on his head...
Interesting how one person is a common denominator in all those interactions ;)
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#755Earlier quoted context omitted.
That varies on the OS/driver/hardware, but IMO, the new AMD graphics drivers being in the kernel tree are the way to go, or something similar like a partnership between MS/AMD/Nvidia. As a consumer it's incredibly frustrating to have a buggy driver and not know who is responsible. Is it MS? Windows comes with a lot of drivers so blaming MS seems fair. Is it the hardware manufacturer? Sometimes you can get the latest…
You're making this harder than it needs to be. All Windows drivers are signed. Blame the party that signed the buggy driver.
You sign an executable to attest that it is authentic, not that it is bug-free.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#756Earlier quoted context omitted.
I mean, I couldn't agree with you more about the asininity of embedding a browser in a 'native' app (for anything other than web browsing). But I use VSCode all day, every day, and subjectively it feels zero-latency on my aging laptop.
It's kind of a crazy concept, especially if you are old enough to remember the days where RAM was counted in kilobytes and you would optimize assembler code to save clockcycles. On the other hand, this is 2017, and people apparently don't care much about the footprint of their software, as long as it's convenient and it solves their problem. And ultimately that's what counts I guess.
So today I noticed that when you try to select text in a tool window, it really does act like a browser. The window won't scroll. The selection spills into other windows. There's no way to select anything you'd have to scroll to.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#757The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_... . Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings . "But camgunz, I need an embedded browser" I agree, separate windows are for savages.…
but but camgunz isn't the commercial license like a new house, three kidneys, and your cat? 3,540.00 USD to be exact :P ... each year to be exact :P
Just don't link your app statically.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#758The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_... . Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings . "But camgunz, I need an embedded browser" I agree, separate windows are for savages.…
In what do you prefer to write cross platform apps? Is there a more productive platform? The thing with the web, is that it's very easy for those familiar with it to try and shove into everywhere, I do it too. The amount of code that does things that are useful that one can just steal for his project is very high, with all the fiddles and bins and even more importantly, very accessible and, sometimes, when the gui co…
If I need to throw together a GUI app I usually use Python and PySide. I've had co-workers use Qt Creator and they built way better and better looking apps than I did. There are tons of Qt examples and the docs are pretty good.
Electron is almost never a reasonable choice. As a platform it's one of the slowest and most limited. You have a choice of a single, pretty bad language. It only works on a few platforms, and in practice it's limited to even fewer because of its poor efficiency.
I'm sympathetic to devs that don't want to venture outside of JavaScript, but in the same way we shouldn't pretend that C is a great language to write web backends in, we shouldn't pretend JavaScript is a good choice for anything but the most basic of web scripting. Writing apps in JS, you're going to experience poor performance, high memory usage, a lack of portability, difficulty scaling to a large codebase, and problems with concurrency.
You can usually tell when devs choose the wrong tool. If you write a DB in Java, you'll have problems with the GC impacting your latency (Cassandra). If you build a desktop app in JS you'll have weird problems with resource usage (Atom). If you build a web app in C it'll take 4 times as long, be unstable, and have weird restrictions. We should recognize that every tool has its use, and stop wildly spending resources making one tool passable at everything.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#759The answer to all this is: "use Qt". "But camgunz, I only know JavaScript" That's cool! Look into QML. "But camgunz, I only know X" That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_... . Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings . "But camgunz, I need an embedded browser" I agree, separate windows are for savages.…
> use Qt It has only been few years since a bug in file copy animation in systray that caused 100% cpu utilization in KDE Plasma 4 has been fixed. It wasnt the first bug in this regard nor it was the last one (IIRC. I saw a similar one in Plasma 5 too, though I didn't check it). Qt is old but cant say it is efficient or optimized. Qt5 programs that use classical QtWidgets have significantly more memory consumption th…
I'm not arguing Qt is perfect; no software is. But you can't argue that a platform built on JS and the DOM will ever perform as well as a native toolkit unless the native implementor makes unbelievable mistakes, or we put a vastly disproportionate amount of work into the JS platform. If you really have a thing against Qt, GTK has a bunch of bindings too (including JS!); go wild.
Or to put it another way, if you can switch your stack and get a "few years" of progress, that actually sounds amazing.
(Plus, and this applies to Electron too, you're free to fix bugs in open source dependencies that impact your project).
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#760Just another day in the Electron universe. My personal favorite is resource waste of another variety: Slack and WhatsApp using multiple gigs of RAM for unbelievable basic (which is their selling point) chat apps.
Admittedly, Slack uses tons of memory because animated GIFs do, plus all the other embeds that is supports.
/giphy time to burn up ram from everyone in the channel