There's an old issue with the editor getting focused immediately
after the IDE window becomes active. But if the window became
active because of a click on some other focusable component,
that component almost immediately gets focus, and the editor
loses it. Unfortunately, this short focus gain is enough to overwrite
EditorsSplitters.getLastFocusGainedTime, which in turn makes
FileEditorManagerImpl.getLastFocusedSplitters and alike return
the wrong editor as the last focused one. From the user perspective
this short focus gain is the same as no focus gain at all.
The existing workaround with invokeLater didn't work
because by the time the window is activated, the rest of the focus
events often aren't even queued yet. Even the click itself
often doesn't arrive into the event queue by that time.
There's absolutely no way to tell whether the window activation
is caused by a click or, say, Alt+Tab.
The only more or less reliable way to fix it is to undo the focus time
update after it becomes clear that it wasn't a real focus gain.
However, it's tricky as well, as even when the mouse click arrives,
there's no indication whether the window activation was caused by it.
To guess it, we keep track of the last mouse coordinates when
the window was inactive and then compare with the click coordinates.
If they match, it's highly likely that the window was activated by
that click. The only other possibility is that the user alt+tabbed first
and then clicked without even moving the mouse by a single pixel.
It's quite unlikely, and we're willing to accept that in that case
the wrong editor will be considered active until the mouse is moved.
To undo the focus gain, we track focus requests in the editor,
and when focus changes, we check a lot of stuff. If the newly focused
component belongs to the same window, if that window was just
activated with a click, and if that component is not the editor
itself, then we undo the focus gained timestamp update.
And to ensure this undo has already happened by the time
we start selecting the opened file from the Project View,
we wrap that selectOpenedFileUsingLastFocusedEditor() call
into invokeLater. Since it's called on mouse release,
the relevant focus requests should be already in the queue,
and invokeLater guarantees that they'll be processed
by the time the selection starts executing.
GitOrigin-RevId: ab8769186f755089cf70cdcfccc7fa329862bd76
When we get a "Must be not computed before that call" error,
it's very hard to reason about the cause. It can be computed
almost anywhere, in any code that calls JBUIScale.systemScaleFactor,
often indirectly, by accident.
Save the stack trace the first time systemScaleFactor and later
attach it as the cause to the exception that's logged when
one of the preload() functions is called.
GitOrigin-RevId: 02eadede9353d2c6b862590881a9d8aafe11e541
+ `IdIndexEntryMapExternalizer` knows about Int2IntMap really used by IdIndex indexer under the hood, and persist primitive ints without excessive boxing
GitOrigin-RevId: 00211fac7cc1f21dd34843b066a0e27208cf938f
+ CustomInputMapIndexExtension is a replacement for CustomInputsIndexFileBasedIndexExtension, to create fully-customized externalizer for Map<Key,Value> -- planned to be used for IdIndex optimization
+ code cleanup and comments along the way
GitOrigin-RevId: f2e3cf5f35aebc61bddcfe2fb749fd72631d75a4
+ defaultMapExternalizerFor(): default factory for input map externalizers, reused by different index storage impls
GitOrigin-RevId: ec3a324630fdb8c200985ebc185d1e305d365fba
