See more at the announce forum.
I saw this on the forum this week:
1 mixin template foo() 2 { 3 int _ignoreme() 4 { 5 if (readln.strip == "abort") throw new AbortException; 6 return 1; 7 } 8 int _alsoIgnoreMe = _ignoreme(); 9 } 10 void main() 11 { 12 mixin foo; 13 }
The idea? To mix in statements to be executed in scope. But mixin templates can only contain declarations, so how can we do it? The hack there realizes that statements can be inside function declarations, and a variable initialization can call a function...
...so it just puts the code in a function and calls it! So simple, but it works, can call runtime functions, and can even access local variables in the scope where it is mixed in. Pretty cool and creative combined use of D features.
You know what drives me nuts? How many UIs I see that change shape on various mouse events. Look at this, for example:
Isn't that frustrating? Or try to use this box and another window at the same time:
Does that drive you NUTS?! Well, I encountered all three of these behaviors in recent memory. Many web sites have hover events that change the size of the box. Something as simple as item:hover { font-weight: bold; } can cause this: bold text tends to be wider than normal text, which will change the size of the element. In some cases, this will cause an endless loop (until the user moves the mouse again) with the element shrinking away from the cursor, turning the hover back off, then growing back under it, turning hover back on. It can also cause a whole reflow and move subsequent elements onto a new line.
The end result is the user must approach the element from the right angle to actually click on it without triggering a change of shape that moves it out of reach! This is insane. Website with menus triggered on hover also do the same kind of pain, though thankfully, that mistake has gone out of fashion with the growth of mobile.
Speaking of hover, don't use menus on hover. Ever. Especially if there isn't a timer on it disappearing. My power company website does this, but since I have a different minimum font size in my browser, it is spaced incorrectly... and there is a gap between the hover activation zone and the actual menu. Makes it impossible to use.
The other behavior in the mouse selection demo is one Microsoft Edge used to do (Microsoft - to my rejoicing - finally fixed this in a recent version. Just in time to announce they are moving to Chromium. Ugh. But that's another rant.). In older versions of Edge, the URL bar would hide the http:// part. Until you click it... then, the whole URL is available again.
That would drive me nuts when I would try to edit a URL. I'd line up my mouse over the character I wanted to edit and click... then the text would move out from under me, and I'd select the wrong text. Ugh!
Similarly, the second example is something I see in a web app I have to use for work. Its description field transforms into a taller textarea when it gets focus. But it gets and loses focus along with the whole browser (and generally, the larger display area is far more useful anyway, since it is easier to see the contents). The boss sends me a todo list, and I open it in the browser and go to my text editor to implement the requests. And the list disappears.
Especially since I use sloppy focus and pile windows on top of each other, this really annoyed me. Moving the mouse around would resize UI.
So, to sum up, I don't mind a visual cue when the mouse moves. In fact, I kinda like that - it is nice to see where the arrow is and get some indication of what widget that will affect. But you must be very careful that these cues don't cause the UI to change shape and most certainly doesn't perform an actual action!
My other three related rants on this: 1) tooltips. They pop up when the user does nothing and disappear when they do something. I don't hate them... but I don't love them either. They can show additional information that otherwise won't fit - good - but they are still limited, can hide other stuff the user might have been looking at, and you can't use the mouse on them to select, copy, etc. Use with caution.
2) I hate the trend to have stuff appear when you scroll up or down. Don't use sticky headers (they break page down too!), and don't have the header magically follow you when you start scrolling back up either. It breaks spatial orientation.
But I am going to close with the worst thing I have ever seen in new trends... 3) infinite scroll. A scroll event should jus show you more of what's already in the window. But with infinite scroll, it changes the UI's shape when you scroll. Disgusting. And so many more problems you can find other rants about online. This pattern should NEVER be used. It is one thing for a scroll event to load content that is coming into view, but it should never change the content length and thus never change the size+shape of the scrollbar UI. And scrolling back to the same place should display the same content! Scrolling is meant to be an idempotent action - you are just looking around, not changing stuff.
Please stop changing things when the user is just looking - whether scrolling or simply moving the mouse!
Big announcement this week: DConf 2019 announced for May 8 - 11, 2019 in London. And I want to call out the thread on CTFE floating point printing - that is some hard code, so having a self-contained port that happens to be CTFEable is cool to keep in mind! Lastly, read on for statements-in-mixin-template tip!
Note: reenabling RSS is on my list for next week.