3 ms·

> desktop applications where the "beachball" or whited-out windows is normal and unavoidable If desktop development is "malpractice", this is actually a clear-

by toyg 5y ago

> desktop applications where the "beachball" or whited-out windows is normal and unavoidable If desktop development is "malpractice", this is actually a clear-cut case of slander and libel. Beachballs are absolutely avoidable, with some basic thread management - which is fairly trivial in any half-decent modern toolkit.

PaulHoule 5y ago
How come I see them all time, especially with applications from Microsoft, Adobe and other big software firms?
- mike_hearn 5y ago
  This is like asking why clicking buttons or links in web apps often just does nothing. You don't notice because you "know" the browser is loading the next page, you're waiting for the server and because you know that browsers don't bother displaying beachballs anymore even though the app is busy. But it's not actually any different. If you like, structure your desktop app as two threads. One does the UI. The other does processing stuff. Exchange only messages back and forth. I've actually written a desktop app this way in the past. However it's not the silver bullet you might expect, largely because expectations users have for desktop apps are significantly higher than on a web app. In particular they expect something obvious to happen when they click buttons or menu items, and they definitely don't expect long delays simply because the backend is busy. So I ended up having to introduce some shared memory and read/write locks back again, as the pure message passing model was occasionally introducing UI stalls. In a web app you'd just ignore them because standards are low. On the desktop it's like on mobile, you have to care about the responsiveness a lot more.
- toyg 5y ago
  Apart from the argument of different expectations discussed in the sibling comment, there is the fact that those behemoth apps you use are largely not developed with modern toolkits. Most of them are 30-year-old piles of C++ hacks, built to work on operating systems that don't even exist anymore and badly patched, year after year, to keep up with OS vendors' agendas. Unsurprisingly, they screw up from time to time. The funny thing is that, despite thall this, often those piles of hacks are still compared favourably with Electron apps and browser-based apps.

by toyg 5y ago

PaulHoule 5y ago

How come I see them all time, especially with applications from Microsoft, Adobe and other big software firms?

mike_hearn 5y ago
This is like asking why clicking buttons or links in web apps often just does nothing. You don't notice because you "know" the browser is loading the next page, you're waiting for the server and because you know that browsers don't bother displaying beachballs anymore even though the app is busy. But it's not actually any different. If you like, structure your desktop app as two threads. One does the UI. The other does processing stuff. Exchange only messages back and forth. I've actually written a desktop app this way in the past. However it's not the silver bullet you might expect, largely because expectations users have for desktop apps are significantly higher than on a web app. In particular they expect something obvious to happen when they click buttons or menu items, and they definitely don't expect long delays simply because the backend is busy. So I ended up having to introduce some shared memory and read/write locks back again, as the pure message passing model was occasionally introducing UI stalls. In a web app you'd just ignore them because standards are low. On the desktop it's like on mobile, you have to care about the responsiveness a lot more.
toyg 5y ago
Apart from the argument of different expectations discussed in the sibling comment, there is the fact that those behemoth apps you use are largely not developed with modern toolkits. Most of them are 30-year-old piles of C++ hacks, built to work on operating systems that don't even exist anymore and badly patched, year after year, to keep up with OS vendors' agendas. Unsurprisingly, they screw up from time to time. The funny thing is that, despite thall this, often those piles of hacks are still compared favourably with Electron apps and browser-based apps.