That approach is a dead end, incapable of doing anything beyond the basics (notably it doesn't compose into structs) and is likely to be abandoned.
451 karma · joined October 22, 2015
what exactly does this mean?
Moreover, notice the example they gave there is atom interning, which is a roundtrip on the wire (though you can batch them even in xlib...), and they say "most real applications will see less benefit than this" since that's the worst case - most applications do atom work at startup, not in the main use cycle, which is famously both async and buffered (it used to be a FAQ on xlib tutorials reminding people to run the event loop, and error handling is complicated a bit by it).
This simply isn't true. Some operations require roundtrips, drag and drop comes to mind, but very simple things absolutely don't. Events come one way, draw commands go the other.
So does X.
> and (lossy) compression.
This is legitimate though, the X protocol has no support for any kind of bitmap compression and it can sometimes be pretty painful. Though internets getting faster and faster too so it isn't necessarily a big deal especially since it does have bitmap caching and some display-side rendering capabilities, but it sure would be nice if you could send other formats on the wire.
Part of what drives me nuts about Wayland is they could have learned these lessons from X's history and actually had it in mind. Instead, they threw it all out without learning a thing.
Running functions alone is not that interesting, and neither really is generating code. You can do those (arguably better for some cases) with helper programs as a separate build step. But reflection is non-trivial to do externally, so that's the biggest value add, and using it with all three pieces let you close the loop.
That said though, yeah, I don't think any of them use `@nogc`. I've actually tried to get the gc to interrupt audio code before and couldn't even hear it. I'm sure a bigger heap to scan might cause a problem in some situations, but these fears are really overblown in the popular commentariat.
"the best ever" implies it is the best.... ever. Inclusive of all competition. "the best firefox has ever had" limits the comparison to just firefox.
> What browser did you move to after you uninstalled Firefox because of the click in the URL thing?
I made my own ui skin for chromium. I'm not terribly happy about using chromium but I couldn't figure out how to use the firefox engine for it - another strategic mistake by the incompetent buffoons at Mozilla not making this easy, and of course doing the whole browser myself is a big job (heck, even the UI skin is a big job, there's a LOT of things still on my todo list, but it minimally works without driving me absolutely nuts which is more than I can say about Firefox's recent versions).
> To me it actually makes sense - I think most of the times when a user reaches the URL they want to put a new one, not to edit the existing one. This behavior makes that easier.
Most the time I want a new one, I'll open a new tab and thus have a blank url. If I'm clicking on an existing url, it is because I want to edit it.
But if I do want to replace it, the old double click behavior to select all made this utterly trivial too: single click to edit, double click to replace. Hell, they even used to have an about:config thing to make single click select all, but in their infinite wisdom, they removed even that hidden config option to turn it back off.
With the new behavior, editing a url becomes quite frustrating. The work around is to click, wait until the double click time period elapses, then click again. Don't do it too soon though, or it will do the completely useless "select word" thing instead. If you click a third time, it will now select all again! Fourth click? Back to select word. You must wait for a while before you can just click to edit.
Oh, and do you use middle click on X? That single click select all... does NOT assert the PRIMARY selection. But double and triple click do! So if you single click it, it looks selected... but it isn't. Double click out of old habit? Now it is wiped out. Ridiculous.
So this change marginally benefits some users (who probably don't really care) while being devastatingly crippling to the people who do. Maybe some utilitarian function can say +1 usability point times 10 million users outweighs -1000 usability points to 1000 users.
But I'm gonna go ahead and disagree. Mozilla is a niche product at this point, maybe they should start caring about the 1000 users they have left.
Ummm yes? Funny, I just wrote another comment complaining how hitting refresh on a major airline's flight status page is liable to give one of those terrible "something went wrong" messages (apparently the search results are liable to expire, but until they do, refreshing will actually update the info, so it is useful to periodically press to see if the flight got delayed).
Combining stop and refresh is also dangerous since that's a race condition. Suppose the page is taking forever, I decide I've had enough of that and want to press stop. But in the second it takes me to actually click on it, the page decided to finally load! Now my click, instead of stopping the annoying spinner animation, clears out the information that FINALLY arrived and brought the annoying spinner back.
(I actually think there is a pretty good case to just remove the stop button though, it isn't vital and just hitting back or close does the same thing anyway. But combining it with the refresh button is about the worst possible thing you could do to either button. It takes one useful button and one meh button and combines them into one awful button.)
Speaking of clicks, that's actually the last straw that made me abandon firefox entirely: in version 75, they broke clicking on the url bar. Instead of doing the sane thing - putting the cursor where I clicked - it instead selects all. Before, double click would select all, meaning if you wanted that, it was still easily available. Now double click instead selects... a word. So they completely removed the very useful single click functionality and turned double click into a completely useless behavior. Absolutely unbearable.
I could tolerate or undo most the other UI changes they did, but this click thing couldn't be user style'd away, couldn't be configured away. They just shoved this massive breakage down. So I uninstalled it .
> takes space even when you're not loading
I'd rather have a predictable UI of marginal utility that doesn't change out from under me than a UI that randomly changes from bad to worse in its own time. At least you can get used to consistency, even if it is consistently mediocre.
> What makes v1 "the best ever"?
Don't put things in quotes that weren't actually said. I actually said "v1 was not great but ok, and it got overall worse".
There's actually specific changes I think were good, coupled with other changes that were bad.
No wonder they peaked user share early on and have rapidly hemorrhaged since then.
Thankfully there's more to the game than the appearance. The music <3
The location of an import has nothing to do with compilation speed. The only time it would ever make a thing compile faster is if 1) it is local inside a template function, 2) that template is never actually used, AND 3) the module is never imported anywhere else in the program.
That does happen - I use this pattern for optional dependencies which aren't even looked at if not actually used - but it isn't generally the case. You have to actively think about it to fulfill all three requirements.
It wouldn't surprise me if he genuinely didn't know about how dstep and dpp are used.
Well, the developer wrote `import thing;` instead of either `static import thing;` or `import thing : specific, list;` so it was their decision.
I have code that has worked unmodified for many years. The language doesn't change that often.
This is easy to verify by looking at the archived releases.
betterC just plain disables a bunch of features. With real D, you can start with an empty runtime then enable stuff as you want it.
...or frankly just use the standard runtime and find joy.
Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says "the X server only talks to the compositor" I'm like "lol what compositor".
But even if you have one, it is still wrong. You have to understand that GUI applications are a LOT more than just low-level rendering. So even if you didn't need it for that, there's so much more going on that the server still plays its role in like coordinating copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc.
And it isn't true that everything goes through the middle man. A graphics-heavy X application actually tends to work very similarly to a Wayland application (not coincidentally - as people love to point out, a bunch of the Wayland devs worked on the gpu rendering parts of X before): you get a direct render context, write to a buffer, then inform it to draw it. See more https://keithp.com/blogs/dri3_extension/
Mixed DPI is fully supported by the system, but may be buggy in applications. See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality, or do auto-scaling for easy support bridges. KDE and Qt manage to do it. So much for "unfixable".
Again, factually false. X has various synchronization options from the older double buffer protocol to the XSync extension to the GLX/DRI vsync commands.
I've also never seen tearing in X since like 2006.
No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).