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.
So it's a good job we're about to throw it all out and start again, eh folks?