|
|
Annoying lack of app responsiveness - second try...
|
|
|
|
Addicted to MacNN
Join Date: Mar 2006
Status:
Offline
|
|
OK. In iPhoto, when you attach a camera, and the app gives a menu that says "import photos" and you click "ok", if its a lot of photos, on a less than right now Mac, it takes a second or two. If you click again, because nothing happens, and you wonder whether your click did anything, when the computer responds, the first thing it does is re-draw the screen, and an icon that says "cancel download" takes the place of the "import photos" one. So when the computer recovers from the idea that you want to import photos, the first thing it does is offers you a dialogue about not importing photos.
I know why it does this, but honestly, how hard would it be to not respond to click that happened before a button was even drawn on the screen?
Come on. ****ing hell. Let's not cache mouse clicks and apply them to things that are not drawn yet.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
Not buffering mouse clicks is a really really bad idea. Whenever your computer is just somewhat busy it would randomly ignore mouse clicks. That would drive users insane.
Ignoring mouse clicks on controls that happened before they were even created sounds like a good idea. The problem is: it's not easy to implement. The Window Server who routes moue clicks to applications knows only about windows but nothing about their content. It has no idea where controls are let alone when they were created. The mouse events that the application receives has, like all events, a time stamp, but controls have none for their creation date (or anything else). So without the system support this would be a non-trivial task to pull this off for an application.
Another issue as one could see it: don't change the meaning of controls on the fly. Instead of changing the Import button to a cancel button dim the Import button and put the Cancel button next to it. That would solve your problem and can be implemented easily today. Safari's Stop/Reload button is another example for this. If you intend to click Stop just before it finished loading the page you might accidently cause it to reload the page again.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Mar 2006
Status:
Offline
|
|
Right - the simpler solution, as you say, would be to not replace the go button with a stop button in the same place, but I still think that buffered mouse clicks should not be applied to controls that were not there when the mouse click was made - I'm sure, as you point out, it is not trivial to do this, but hey, there's not much about modern OSs that are trivial.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Mar 2006
Status:
Offline
|
|
Hmmm - I'd like to - I'm not a developer though.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
The so called "online" ADC membership is free.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Mar 2006
Status:
Offline
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|