I dislike the implementation of Atom and have been highly critical of it on HN, even crashing a release thread once by pointing out how harebrained it is to implement complex text layout on top of browser APIs when the browser has access to a much richer text shaper itself - we'd know because we wrote it for Qt originally.
Because I've also worked on KDE for 12 years, wrote a big chunk of Plasma 5 and am one of the people porting it to Wayland. We want Wayland for many of the same reasons that make Atom bad, such as state synchronization problems and overhead with X11 (along with its very dire security story).
The intersection you suggest isn't real or doesn't matter. No one working on Wayland uses Atom.
However, just to be pedantic ( ;-) ), I'll have to point out that "a big part of the people defending VSCode in this post agree that X11 is slow" does not imply "a big part of the people agreeing that X11 is slow defend VSCode in this post". The two aren't commutative, since one set of people is quite likely much larger than the other.
Edit:
Oh, and since you mentioned working on Plasma for over a decade: Thank you for making awesome FOSS! :)
So it's a good job we're about to throw it all out and start again, eh folks?
As it were, GNOME's IDE (which I wrote) uses 0% CPU at idle.
This makes people, especially power users, disproportionately angry because when you rewrite something, it will be different (that's sort of the whole point);this is compounded by the fact that at the beginning it will be feature-poor compared to the older system.
"Why did you replace X with Y? With X, I could configure it to treat mouse-button-3 as mouse-button-2, but only when my USB mouse was not attached and I wasn't holding down any modifier keys."
See also: https://xkcd.com/1172/
Before I did any serious software development, I was on that side of the table being frustrated (I still cry a little inside any time I remember Galeon. Rest in Peace, my favorite browser).
I can also neither confirm nor deny that my windows are being decorated by sawfish and that I wrote a compositor in librep so that I could get modern features while using it.
The GNOME project will be 20 years old in a couple of months. So while it might feel like "every few years", we really don't change direction all that often.
As you can imagine, those that show up to do work have a great deal of say in where the project goes.
> you probably had a good reason for writing Builder instead of working on Anjuta, and that's just the way the GNOME community seems to do things.
> This makes people, especially power users, disproportionately angry because when you rewrite something
You've sort of made my argument for not changing Anjuta over the years. We knew the amount of stuff that had to be changed would leave both the code-base and UI looking very little like Anjuta. Best to let people continue using it in the mean time.
> (I still cry a little inside any time I remember Galeon.
It lives on as Epiphany and is the primary driver of the WebKitGtk backend.
Amazing how much work you can get done by just typing the damn code into the editor, sometimes.
However, writing typescript in vscode genuinely changed the way I think about editors. It's a smalltalkish sort of feeling where my code (at least the textual level) lives and breathes in the editor, automatic tooltips that are actually relevant, etc.
Idk. I like both.
You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU.
> So it's a good job we're about to throw it all out and start again, eh folks?
Yes, by those of us who have been working on the same platform you claim to love, for the better part of a couple decades.
You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic.
Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised.
So you stated clearly "all" applications (for "20 years") which is provably incorrect; and I home in on this because it's a recurrence of another 'well, you never had it before' argument (that really might be better directed at the decaying state of X11 client toolkits)
X11 isn't perfect, I have no doubt something better can be engineered (especially if it involves those who worked on X11). But people are missing the point that to replace X11 is a different matter from designing a better one. It involves acknowledging those who are quietly and successfully using X11 on a daily basis for the majority of their work and existing applications -- not telling us how wrong we are.
If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.
If something was written a long time ago and hasn't changed in this respect, BUT is still widely used... you can't say that "no X client draws like this nor has for 20 years."
RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;
Even the pixelcache uses server-side textures when available.
This is what Xshm does and why everything modern uses it. You get a server-side texture, but mapped into client address space so you can do direct draws and then XCopyArea() into your final location for double-buffering.
But gtk+ isn't really in the position to be able to control everything so precisely all the way down the driver stack to network transparency layers. So unless you connect to our process directly, like the HTML5 broadway backend, there is only so much we can do.
The broadway backend does employ various techniques to reduce the amount of content passed using a sort of rolling hash.
https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway...
I expect forthcoming app/display network transparency layers in GNOME's Wayland compositor to employ a similar strategy.
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...
(Accelerating OpenGL in hardware but displaying in an X11 window is a different question.)
Well, you haven't seen Windows then - the graphics stack is phenomenal and a marvel of engineering. nVidia drivers crash? I only get a second of black screen and then resume my work. Yep, that's right - no other GUI program crashed, I didn't had to do anything, literally just 1 second of black screen.
Oh and you can have one window on two monitors and both parts of window will have full vsync - insane, huh? :)
It's scary how good Windows is.
Oh I should also add that I haven't ever had any of the DPI issues the parent's parent is referencing. The only problem with multiple display DPI in Windows 10 is the shockingly bad fuzz you get on your secondary display from the thing being rendered either smaller or larger than normal (depending on whether the 4k is your primary or secondary) and then scaled up or down to fit the monitor.
After it goes to sleep, then I wake it up all open Windows have been resized into a tiny part of the screen and scaling goes weird.
https://duckduckgo.com/?q=windows+4k+monitor+resize+after+sl...
Terrible.
Having said that on macOS my external 5K LG monitor is causing complete system crashes now and again :(
I wish Windows based scaling on DPI instead of resolution, the system seems to be aware of both. On a more general level, I wish there was any hope of passing feedback to Microsoft/Apple/etc.
I'm a fan of no DPI scaling (100%) at 4K, at least on my 27" monitor. It takes 2-3 months of getting used to, but once your brain and eyes adapt, significantly lower dot pitches become completely unusable. The only thing I change is bumping up my terminal or editor's default font size a tad.
That said, I'm not sure how people with 24" 4K monitors do it without DPI scaling. I'd probably even prefer 30" myself.
Correction/clarification: significantly higher* dot pitches, as in lower pixel density. "Completely unusable" was meant in the sense of how it'd feel to return to 800x600 after being accustomed to 1080p. 4K is four times 1080p, so it's roughly comparable.
It wasn't my intention to offend anyone with poor eyesight, or suggest that people ruin theirs. Just that it's possible to get used to really low (dense) dot pitches, and once you do it's simultaneously really enjoyable and weird at the same time.
There's always room to improve but I'm really happy with the stability improvements they've put in.
Configuring X is not for the faint of heart, but in Unity it is basically magical and deals with HiDPI displays, etc. just fine. Feature for feature it is very similar to Win or Mac on the display and GPU driver front. The total package still feels rougher around the edges, but it is still good.
(I don't have enough experience with Mac's to speak to it).
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 drivers but the OEM hardware isn't quite standard so you're screwed. Is the OEM to blame? Usually, because they have their own driver update system, but then the question is why can't they use the native windows update system?
The current situation on windows seems to be that no one is responsible.
Cynical answer, and I will grant that gpu vendors are less bad than e.g. printer or smartphone drivers, but it just distributes drivers and so doesn't provide all the opportunities to upsell/advertise to/lock in the users that their bundled crap they can pair with the driver with their own installer allows
Also, Windows has this thing called minidrivers where Microsoft essentially writes a chunk of your driver for you (the generic chunk), and you only have to write the bits specific to your device. The idea is that Microsoft could QA their drivers better than J. Random OEM ever could, and so this'd reduce cost for OEMs and also make the Windows platform more stable.
https://msdn.microsoft.com/en-us/windows/hardware/drivers/ge...
X11 network transparency was nice feature when 10 mbit ethernet was hot as pizza, but these days remote desktop protocols offer more practical alternative.
Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?
I was responding to those who believe that this demonstrates a fundamental flaw in using Electron. My response emphasizes the tradeoffs involved. If they couldn't fix it, 13% background is undesirable, but it's not a dealbreaker for me if there are redeeming qualities. And it seems that VS Code certainly has some redeeming qualities.
[1] https://developers.slashdot.org/comments.pl?sid=10406465&cid...
As engineers it's our responsibility to not spend our users' resources unnecessarily. This thinking is how we got to the bloated web where pages need a megabyte (or several) of code just to render. Could you imagine an architect saying, "yeah, this design costs 2x that other one, but my clients are rich so it doesn't really matter"? The old saw that "anyone can build a bridge that stands up; it takes an engineer to build a bridge that barely stands up" applies.
I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.
That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.
Also the Qt community is minute compared to the JS community, that is significant.
Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.
i wonder if this expression constitutes a thought-terminating cliché.
This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incorrect tools
'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 tool'?
> [...] just as shitty as the web.
Again your opinion. In my opinion the web is a joy to work on compared to the cesspool that is native app development.
"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.
The drive-by downvotes really just prove my point.
Maybe React Native will work on desktop and fix all this eventually, but IMO React Native is just not there yet, it doesn't even feel native on mobile.
I say this as someone who writes both an app with both an Electron/React portion (in order mainly to interact with a specific JS library) and a Qt portion. I really do like the way React does a lot of things and npm seems like the exact right way to do package management in a programming language - but the JS ecosystem is a mess. While I'll agree the wealth of developers on it has had many good results, it's also created a horrible moving target. There are half at least 5 different and fairly popular module systems, module loaders, etc. There are constant attempts to use language features which aren't official yet or even at a final spec via babel. The build and packing systems are a mess, everyone has their own different series they prefer and getting working integration between a few can be problematic.
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 hours people spend are already mitigated by their web browser of choice, and that seems to not really cause any substantial problems.
Electron is a flawed framework for building an app, sure, but you could argue Cocoa or Windows Universal are equally flawed in many ways. They also require a lot more code to get equivalent layouts, are almost never very good at reactively resizing (you may say it doesn't matter, I say I unplug in an external monitor and expect to have something sane happen). The fact that a bug exist causing repeated simple draws to be more expensive than expected is normal for text editors. You can find issues caused by similar problems in Sublime, Emacs, and even Notepad++.
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 that don't attempt to imitate familiar desktop controls or to show desktop concepts like files and folders.
I have far more problems with Electron app sizing than I do with proper desktop apps - see my examples above.
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.
What build system did they use?
Where is that package? Does it even exist anymore.
Etc.
Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.
The platform that JS is based upon moves incredibly fast.
But, it is EXTREMELY EASY. There's a reason why Github, Microsoft, Facebook, Adobe etc converged on this decision, and it's not the bandwagon effect. Faced with the same task recently, I did my research, and it is indeed easy.
Since I work on the JVM, my alternative was JavaFX. That didn't seem so bad, but it was much more work. If you look at say IntelliJ IDEA on some platforms, you'll see the text rendering is much uglier than on Atom. Regrettably, if you want to acquire users, that matters more than conservation of resources.
I'm curious: have you ever tried interfacing with X11?
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.
Consider writing a douglas adams style book
People don't complain that web IDEs are bloated and slow because they need a web browser
Many of these same people will argue vehemently that X11, the shitty GUI layer for Linux that ran perfectly fine 20 years ago, is "slow" and "bloated" and needs to be replaced with Wayland, a new, completely different, shitty GUI layer.