Quick guess: I'd be willing to bet when the a file chooser is first constructed, the default directory it opens on is the desktop folder.
And I'd be willing to bet we don't change the directory to that of the last opened project until after the file chooser is on screen. If the custom FileSystemView which shows folders with project icons is set at construction time (which it probably is), then it will briefly scan whatever folder the file chooser was on at construction time. IIRC, the badging is asynchronous, so even if the folder is immediately changed, that doesn't mean a background thread doesn't chug along for a while scanning away. That's a guess, but given the description, it seems pretty plausible. If so, the fix would be something like making the file system view not really do anything until the component is realized on screen, or setting it later (that could get messy), or having the file chooser keep a count of directories it's visited and have the view do nothing if the count is 0. Or maybe it's as simple as setting the directory before setting the view. Just a word to the wise: File chooser behavior is very different across look and feels / operating system, and this is likely some kind of initialization order or listener order issue - do not assume things are called in the same order on all look and feels - they won't be - test them all. Anyway, it might be something else but this is worth checking. I couldn't make heads or tails of the log file attached to the bug, but the fact that installing Quick File Chooser (which radically changes the way file choosers are initialized) fixes the problem strongly suggests it will be something like this. -Tim
