[#IDEADEV-15498] Recent Files dialog may open so slowly after pressing Ctrl+E, that it's possible to by mistake type a couple of characters to the current file

IDEA: Development

Recent Files dialog may open so slowly after pressing Ctrl+E, that it's possible to by mistake type a couple of characters to the current file

Created: 16 Nov 06 17:24 Updated: 06 Nov 08 23:16

Component/s:

Code Navigation, User Interface

Fix Version/s:

Undefined

Original Estimate:

Unknown

Remaining Estimate:

Unknown

Time Spent:

Unknown

File Attachments:

6140_luontes_22.12.2006_16.35.33.zip (2.50 Mb)
2.

6140_luontes_22.12.2006_16.39.22.zip (2.51 Mb)

Image Attachments:

1. typedTooFast.png
(19 kb)

Environment:

WinXP SP2, P4 3GHz, 2GB RAM, JDK 1.5.0_08

Build:	6,103
Severity:	Medium

Description

« Hide

When the recent files limit has been set high, for example to 50, sometimes the delay between pressing Ctrl+E and the Recent Files dialog opening is so long, that the user may accidentally type a couple of characters before the dialog opens. As a result, some random characters are accidentally typed to the currently open file.

This is a problem especially when switching between two most recent files, because the user can very quickly type "Ctrl+E, Enter" (see the attached picture). If the user uses the search feature of the Recent Files dialog and starts typing the first letters of a file name, it's likewise possible to type one or two characters before the dialog opens.

EXPECTED

The Recent Files dialog should be better optimized, so that the delay in opening the dialog would be as small as possible. The delay should not increase when the recent files limit is high; it should be possible to use a limit of 50 or higher without performance penalty.
Even if there is some delay after pressing Ctrl+E, the user interface should block all input until the dialog has focus, so that no characters could be mistyped to the currently open file, no matter how fast the user can type.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Jon Steelman - 21 Dec 06 21:23

Esko, is this still a problem for you as of build 6140? I filed a similar issue--
http://www.jetbrains.net/jira/browse/IDEADEV-11898
– that JetBrains marked as resolved. It is now faster with 6140 but can still take up to 3 seconds for me first time, so I was wondering how your performance is.
Thanks,
Jon

[ Permlink | « Hide ]

Esko Luontola - 22 Dec 06 17:33

It opens faster, but it's still sometimes possible to type some keys after pressing Ctrl+E and before the dialog pops up. Especially so, if the computer is at the same time doing some other work which causes IDEA to slow down. I'll attach a CPU snapshot where I just open and close the Ctrl+E menu.

In my opinion, the handling of the Ctrl+E hotkey and opening the dialog should be done in the AWT event thread, so that it would block all user input until the dialog shows up. This way it would not matter, even if the computer is slower than the user's fingers.

[ Permlink | « Hide ]

Esko Luontola - 22 Dec 06 17:39

This snapshot was taken after IDEA was just started, and was in an idle state. Here is recorded the pressing of Ctrl+E, after which the menu opens for the first time (with a short delay).

[ Permlink | « Hide ]

Esko Luontola - 22 Dec 06 17:42

Here is recorded the switching between two classes. The keys pressed are: Ctrl+E, Enter, Ctrl+E, Enter.

The menu opened quite quickly, but it would still have been possible to press Enter so quickly after Ctrl+E, that some keys would have been accidentally typed to the currently open file.