All Gradle importing tests are executed as part of the Gradle Integration Tests bucket on the Team City
GitOrigin-RevId: 20b9a5dc45baa2584a864aaee64d5c9a5d4b9fb3
1. Keep fast PSI icon providers but run VFS patchers over their results
2. (Avoid recursion in `ElementBase` and `PsiBasedFileIconProvider`)
3. Add test to assert same psi/vfs file/dir icons
Fixes
IJPL-714 PsiDirectory ignores FileIconProvider EP
IJPL-939 PsiIconUtil.getProvidersIcon ignores FileIconPatcher EP
GitOrigin-RevId: 948129ab4b9a9195a32d4b2a4ec191bcbd647d80
Added the detailed comment for the GradleProjectTestApplication annotation. This annotation should be used only with the GradleProjectBaseTestCase
GitOrigin-RevId: 37f090b9a9d875964114739f2c5905610d215d02
The top/left insets weren't taken into account: the toolbar height
isn't always the same as its bottom-edge coordinate.
Get its bounds and convert them to the panel's coordinate system
to make code more generic and layout-agnostic. This also factors in
the insets automatically.
Use case: the Remote Host tool window, it has a top border
on the panel.
GitOrigin-RevId: 04574d8a0f2b64a08e012fa600023e9b6891b971
The "excellent" Swing API strikes again: x is integer, but getX
is floating-point. Of course we don't want to use equality
on floating-point numbers.
GitOrigin-RevId: 3bdac7537a157911cf7e7e89360e9dbcd28d1104
Similarly to a component touching the tool window header, we need to
avoid double borders at the left/right/bottom edges, in cases when
the tool bar that should be there (and is the reason for adding a border
to begin with) isn't visible.
GitOrigin-RevId: f9ad39005964852696a92ebb0635290762857127
Track scroll panes automatically as they're added and add borders if a scroll pane
touching the edge is scrolled. Needed for complicated tool windows like Build,
where it's hard to figure out the exact scroll panes to track, because they are added
to a splitter, which may or may not have other components and it may change
at any moment.
So instead track scroll panes and check their location to see if scrolling should add
a border.
GitOrigin-RevId: 1dae2bf8b5ce43beb54de84a59a58e78721fb3eb
They were ignored by the layout code, making it impossible to use
borders on splitters. And we need one for the Build tool window.
GitOrigin-RevId: d730e55ec16de38a4d5280266238932923e1c58d
Layout indexes for branch heads are saved in the GraphLayoutImpl#startLayoutIndexForHead field, and binary search is used to find a head commit by layout index.
Since all branch heads are used for building graph layout, some branch heads are contained in other branches. If a less important branch is contained in a more important branch, the less important branch does not receive its own layout index and is assigned a layout index from the more important branch. This means that GraphLayoutImpl#startLayoutIndexForHead is no longer sorted, and binary search may return incorrect results on it.
This commit includes only important branch heads with own layout index into the GraphLayout.
follow-up: 1cd228ff6107d0ca03d5f3172f9940e0d55d9e4f
GitOrigin-RevId: f3d5bf4cc85b6b8dbea81895a650e4eca8985cad
Since branch heads are now being used as the start nodes for building graph layout, a head commit might be visited earlier from another head, giving it a layout index different from the currentLayoutIndex value.
This commit avoids the problem altogether by computing layout indexes array for heads after all layout indexes have been calculated.
follow-up: 1cd228ff6107d0ca03d5f3172f9940e0d55d9e4f
GitOrigin-RevId: c01942bad60c09979711769905ac35a43b9c98f0