When a frontend process starts for the first time on a machine where the corresponding major version of the regular IDE has been already used, we need to migrate some plugins (e.g., keymaps) from the IDE to the frontend. Before it was done using the existing MigrateFromCustomPlace option. However, with such an approach, the whole config directory for the frontend process (which already has some files) is deleted and replaced by the IDE's config directory. And this causes problems, e.g., because it tries to back up and remove the 'process.lock' file. Since we need to migrate only plugins in this case, it's better to have a special config migration option for that. So MigratePluginsFromCustomPlace is introduced, and ConfigImportHelper is changed to run 'migratePlugins' only if this option is used.
This logic will be removed later when the frontend process starts to use the same directory for downloaded plugins as a regular IDE (see RDCT-1738).
(cherry picked from commit e1325d9c9b3866b692a0e20bcdb8cd8e15344ca0)
IJ-CR-147196
GitOrigin-RevId: 632de6d78c8e694dfde0bae87c4bab59d9eeddcd
Before the presence of the plugins directory was used as a marker, but after IDES-6286 is implemented, it may happen that some plugins are installed for the frontend before it starts. In that case the plugins directory will be created, but we still need to migrate the plugins from the local IDE on start. So now a special file frontend-plugins-migrated.txt in the plugins directory is used as a marker.
GitOrigin-RevId: 84e1f9682361256c7a30f6d78f3fa12f6dae465a
Because it's used in initLux, it's accessed at an early delicate stage.
But UiUtil is a huge class that invokes a lot of stuff in its static init,
and some of that stuff (JBInsets.create) involves scaling, which isn't
initialized here yet.
Invoking preload() from there was a mistake. It's not guaranteed
that all data needed to compute the scaling factors is ready.
And we don't really need it at that stage.
To fix this properly, we extract just the part of UiUtil that's
used in initLux. It isn't even a public API. And as a bonus,
it'll be faster here too, as we don't need to load that huge class
anymore.
GitOrigin-RevId: 6ad6bbb24c7753cfb27f148e405a31117ad74964
After IJPL-148565 is fixed, we now have ModuleLoadingRule enum for modules included in plugins. Since the meaning of its entries is the same as the meaning of ModuleImportance's entries, the enum and its entries are renamed for consistency. Currently, we cannot reuse RuntimeModuleLoadingRule for plugins to avoid adding dependency from intellij.platform.core.impl to intellij.platform.runtime.product module.
GitOrigin-RevId: c508919804af4a1910c4ee1ce2253228c4164b82
'initMainDescriptorByRaw' function which is used for non-bundled plugins, now searches for content modules under lib/modules first.
PluginBuilder used in tests now allows putting module descriptors to separate JARs. The 'loadDescriptor' function used in tests now takes ZipFilePoolImpl instance instead of NonShareableJavaZipFilePool, because the latter doesn't work with the memory file system used in some tests (Path::toFile call fails).
GitOrigin-RevId: 0276dfd4717f50d97cfa25088b30f2fddf3d1c49
Similarly to how JBUIScale.systemScaleFactor can be computed
incorrectly and then cached, the same thing can happen to
JreHiDpiUtil.isJreHiDPIEnabled, which in turn will cause
the computation of systemScaleFactor to go wrong
(for example, isJreHiDPIEnabled relies on
SunGraphicsEnvironment.uiScaleEnabled_overridden
which is initialized along with LaF).
Add a similar assert to JBUIScale.preload to check that the value of
JreHiDpiUtil.isJreHiDPIEnabled was not initialized before. Which it
normally shouldn't. Except when it's called from initLux(),
which invokes static initialization of UiUtil, which calls JBUI.scale,
and that causes early init of isJreHiDPIEnabled. For Lux it seems
to be OK, though, just that we have to take that into account,
which is why the new JreHiDpiUtil.preload is allowed to
be called several times, ignoring the subsequent calls,
as to not throw an error if it was preloaded intentionally,
as opposed to an accidental JreHiDpiUtil.isJreHiDPIEnabled
call somewhere.
JreHiDpiUtil.isJreHiDPIEnabled had to be refactored a bit to ensure
that all computations happen inside initialization. No more bypass
for macOS and Wayland. Technically, on macOS we could simply
skip the check in JBUIScale.preloadOnMac, but it's still better
to have it, as detecting early access on macOS, where it's harmless,
could help us to fix it on other platforms, where it isn't.
GitOrigin-RevId: 31989284e85cfd09903f79debdf5858e0c0d0177
The embedded frontend launcher in PyCharm Community already has the proper pathsSelector, so an attempt to fix it will replace 'PyCharmCE' by 'PyCharmCECE'.
GitOrigin-RevId: dfba27a2316c9934a8b6bfa3025909a88731ffa7
We use the same distribution of the frontend part for community and ultimate/professional editions of IntelliJ IDEA and PyCharm, and 'idea.path.selector' property is set to the value from the ultimate/professional edition. To use proper value when connecting to a backend from the community edition, we need to adjust it based on the product code specified in the join link in the command line arguments.
GitOrigin-RevId: 663f40075eef089d7a8e36ec0ee2a8ba5f39af10
Since it's used for the frontend process only, the check for the mode isn't needed anymore. However, we still need to support a 'generic' variant of the frontend which isn't built for a specific IDE and therefore needs to use a 'JetBrainsClient' prefix for directory names.
GitOrigin-RevId: be52b1a8d32c2e63fe6d90a279e93209a07b2f43
This is needed for clarity, since we have a separate P3PathCustomizer now. The common code which was reused by P3PathCustomizer is moved to a separate PerProcessPathCustomization class.
GitOrigin-RevId: bee9775ff2f5790239a6c1b55283ffbadb11f39f
If the frontend process uses the same 'idea.paths.selector' as the monolithic IDE, it's better to put its temporary config and system directories under a special 'frontend' folder. This way they won't be mixed with other per-process folders, and we can be sure that they won't be cleared by the monolithic IDE while the frontend process is running.
GitOrigin-RevId: 5662f7fce327bd5c4d38a829d21d420caee63777
'intellij.platform.bootstrap.coroutine' module provides a custom variant of DebugProbesKt class from kotlin-stdlib, so it should come first in the classpath to ensure that coroutines dumps work if the IDE or tests are started without packing modules to JARs and without explicitly specified coroutines agent.
GitOrigin-RevId: 2751c8052f3c0285ad109d67daa1d3eb0e7ddb10
If the frontend process uses the same config directory as the corresponding local IDE, there is no need to customize where it imports settings from, the default behavior should work well. However, we still need to store plugins for the local IDE and the frontend variant separately, because not all plugins are compatible with both variants, and we currently cannot determine compatibility while loading plugins. So plugins for the frontend variant are stored in ${idea.plugins.path}/frontend directory.
It isn't enough to migrate plugins from the local IDE to the frontend during migration of the settings. It may happen that the local IDE of this major version was already run on this machine, so when the frontend is started, the config directory will exist and no importing will be performed. To initiate migration of plugins in that case, PerProcessPathCustomizer manually initiates config importing if the plugins directory doesn't exist.
Also, it may happen that the frontend process performs the initial config importing. In that case, it also migrates the plugins for the local IDE from the previous version, because when the local IDE will be started for the first time, the config directory will exist and no importing will be performed.
GitOrigin-RevId: 9dae5c03001b45240e6ae3bbaa56224b522de2f4
We use the same root JetBrainsClientPlugin.xml for all IDE-specific frontends, and not all product content modules specified in it are available in all IDEs. E.g., 'intellij.notebooks.ui' isn't present in CLion. Since content modules are optional, absence of some of the in the distribution shouldn't cause an error.
GitOrigin-RevId: 074f93d1a5c31de6d6bf5152d96ba150c72bf7b2
The frontend part of the IDE has its own list of content modules, and at least one of them ('intellij.cwm.guest.notebooks') is not included in lib/modules directory, and it's not simple to put it there, because it's currently part of CWM plugin distribution. So 'findProductContentModuleClassesRoot' is introduced in 'ProductLoadingStrategy', which computes path to the classes root of the module using data from the module repository if the module-based loader is used.
GitOrigin-RevId: dddcb8b16dce64fd73a0cbdde507daaa5b069a10
To find and report native crashes `PerformanceWatcherImpl` requires two files: `.pid` and `.appinfo`
These files are stored in the system directory (`PathManager.getSystemPath()`).
For JetBrainsClient we replace default system path (`JetBrains/IntelliJIdea[VERSION]`) with custom per process path (`JetBrains/JetBrainsClient[VERSION]/tmp/per_process_system_0`)
This custom directory is cleaned up on every start therefore `.pid` and `.appinfo` files are also deleted and `PerformanceWatcherImpl` cannot send crash reports.
To fix that, we now keep these files between client restarts.
GitOrigin-RevId: 7c50445d07767cc3a12e36c5511778235e8142b6
