The dots are so delicate, with tiny magnet wires and soft plastic that can melt, that it has to be done very carefully. Even with the very best desoldering equipment it would take forever.
Put a hot air gun on the back of the board, and they'll either just drop out or do so with a small poke of the pins.
Well, the reason we introduced it is because we realised it’s a lot of work to make these - be that paint, write, collect, curate - someone needs to do it and we need to incentivise people in our society to do it.
Maybe these incentives weren’t perfect. If we throw all of this away, we’re back at the original problem.
You imply that there was no original problem to be solved; I think that’s naive.
It's really funny to see the delusion being defended so vigorously by people - presumably well-meaning people - purporting to defend the livelihoods of musicians and artists, while the musicians and artists are desperately trying to free themselves from the jaws of their IP agreements precisely so that their music can spread more easily.
I imagine this is already well-known on HN, but there is a significant movement underfoot in the worlds of bluegrass/old time/trad/jam toward DRM-free and CC licensing.
True revolution in UX will come from making customisation accessible
...like it was back in the days when Windows actually had a very customisable UI[1], and then the "skinnable" UIs of the early 2000s (most of which were extremely gaudy, but then again, maybe that was what the majority of the population wanted.) Now it has devolved into little more than this: https://support.microsoft.com/en-us/windows/experience/perso...
Hot Dog Stand is really illustrative of the change in attitude. Previously: "It's your computer, of course you're allowed to make it look ugly." Now: "It's our computer, that's not on brand."
...and even if the app is a game, it can still make great use of Win32 controls creatively. Minesweeper is one example that comes with Windows, and I remember plenty of other casual (non-3d) games in the 90s/early 2000s making use of buttons, both ownerdrawn and stock, likely to avoid having to write their own hit-testing code.
I don't think the original Minesweeper used actual buttons for its playing field. That'd be a lot of controls that can be better handled by one custom drawn control. They also did look different from actual Win32 buttons which likely is another clue.
Sadly, almost nobody uses Win32 scroll bars any more. Everybody uses frameworks that provide their own custom scroll bars.
The frameworks that actually wrap a Win32 scrollbar are the ones doing it right; the ones that (badly) reinvent a scrollbar are the ones to avoid. The real problem in this case isn't frameworks, but how they make use of the platform capabilities.
Oh hell no. If you think "scroll here" is a sane default, you haven't experienced the pain of jumping possibly thousands of lines in a long document with an accidental click, and no easy way to go back to where you were.
I don't think that's a serious problem. There are three possibilities I can think of:
1. You're editing text outside of Emacs. Your cursor remains where it was, so you insert a single character and the document scrolls back to the cursor. You can then delete that character.
2. You're editing text in Emacs. You like to pretend it's still the 1970s and off-screen cursors are some pie-in-the-sky fantasy. You solve the problem with some unspecified ELISP wizardry, which as a self-respecting Emacs user you are surely capable of.
3. You're reading a read-only document. You activate your full-text search, which every good document viewer has, and start typing the last sentence you read while it's still fresh in your memory.
and start typing the last sentence you read while it's still fresh in your memory
Double hell no. The majority of the time it's a log file with lots of repetitive lines, and I'm definitely NOT going to remember exactly the line, especially after the disruption of accidentally jumping somewhere unexpected.
GPUs have been using a 256MB window since they started coming with 256MB of VRAM, as it would otherwise be a pointless waste of address space to have a window larger than the actual amount of VRAM. Previously, they would have a window exactly equal to the size of VRAM (likely rounded up to the next power of 2.)
There would also be a block of memory mapped hardware registers also needing address space that you have to poke to make the GPU actually do GPU things, instead of just being an expensive way to add extra memory to a system, no?
And if my experience from embedded development is in any way transferable, they're probably fairly spread out and probably takes a fairly big chunk of address space too.
Yes, typically the memory mapped memory is in one (64-bit) bar, memory mapped registers in another (64-bit) bar, plus for compatability with vga, probably a 32-bit memory bar and an i/o bar. 64-bit bars take up two bar slots, so that fills all six slots in the PCI config.
Put a hot air gun on the back of the board, and they'll either just drop out or do so with a small poke of the pins.
reply