Once he reopened the already closed case and forwarded it to the product team. But a few days ago, Microsoft employee Rich Turner ( bitcrazed, a senior program manager at Microsoft) sent a comment. The comments go back and forth a bit – and an MS employee tries to lure Bruce Dawson onto the 'read, laughed, punched' feedback hub loop. Currently, the delay from releasing the mouse to displaying the jump list is 200 to 250 milliseconds – too long for an optimal GUI design. Last year he had complained about a delay of 500 milliseconds to open a jump list. Closing multiple programs in this way becomes frustrating, even after the ReadFile fixes.ĭawson has a fairly well-equipped Windows 10 machine, but it is too slow to react to jump lists, he writes. I don't want to wait for my computer, especially when doing simple and repetitive actions that I know it should be able to do roughly ten times faster. This is well beyond the ideal human interaction times and is a constant frustration. However, closer analysis shows that there still remains a 200-250 ms delay from the moment that the mouse button is released until the menu appears. Last year I reported a ~500 ms delay due to massively redundant ReadFile calls. I frequently right-click on items in the task bar in order to view their properties or close them. Dawson has published a post on GitHub that deals with slow jump lists.
Instead of going to the hamster wheel feedback hub, Dawson chose his own way (I do the same). The Google Chrome for Windows developers Bruce Dawson was annoyed about the fact that jump lists only open after 200 milliseconds. A corpse in the cellar are probably also the slow opening jump lists, as MSPU reports here. Different context menu styles, broken start menu or not working search etc. Regarding the user interface, Windows 10 is in many places only to be understood as a broken and tinkering grave for failed developers.
0 kommentar(er)
