3 ms·
You are replying out of context: if your file is on a network drive it doesn't matter if you have shiny UI, or text based terminal, you gonna wait for the round
by dgan 3y ago
You are replying out of context: if your file is on a network drive it doesn't matter if you have shiny UI, or text based terminal, you gonna wait for the round trip with your UI being unresponsive
- pests 3y agoThat doesn't follow. Your UI can be responsive while the round trip happens. The application won't literally stop working 100%.
- _y5hn 3y agoYep. Non-blocking threads was a thing in the 90's also. BeOS probably the poster-child of that.
- amelius 3y agoOnly if the programmer wasn't on fast local storage when they tested their code.
- theamk 3y agoDepending on the application. Take single-window editor (think notepad) for example. If the "load" command is blocking, what can you do? You cannot allow editing - the existing buffer will be replaced once load completes. You can show the menu, but most options should be disabled. And it will be pretty confusing for user to see existing file remain in read-only mode after "open" command. The most common solution if you expect loads to be slow is a modal status box which blocks entire UI, but maybe shows progress + cancel button. This definitely helps, but also a lot of extra code, which may not be warranted if usual loads are very fast.
- pests 3y agoWell, notepad is a bad example because it has tabs now. If the load command is blocking, show an indicator of that inside the tab. The user can switch to the other tab and have a full editing experience - this buffer obviously will not be replaced. If you pick another single-window app, my response is: that is a decision they chose to make. They can also choose to go multi-window or tabbed just like notepad did.
- kaba0 3y agoYou still don’t block the render thread.
- nicoburns 3y agoAt the very least: allow the user to close the window or cancel the in-progress load.