yes, it is intended
(cherry picked from commit 0b4c9a2197c343382142ed88aec54eb87192d0ad)
IJ-CR-138667
GitOrigin-RevId: 4768bcef63b12840736c483b58b728db12b543d9
not necessary anymore (see the commit, when it was removed)
this should fix the failed test `FileComparisonFailedError: 'intellij.platform.execution.impl' API dump does not match the actual API`
(cherry picked from commit 1e38ad80468fcab9541c5989f83f7e2e4c4b0c72)
IJ-CR-138667
GitOrigin-RevId: 7978505a09d1af492360dc92f8b8a1d23f255a37
2 problems are fixed by this commit:
1) bad naming of `EditRunConfigurationsInNewUiAction` and its needlessness (IJ-CR-138667)
2) missing of actions in OldUi, which were reorganized by previous commits
To avoid duplication of "Edit..." items in Old UI that was solved before this commit by `EditRunConfigurationsInNewUiAction` implementation, the action with id `IdeActions.ACTION_EDIT_RUN_CONFIGURATIONS` is added under the corresponding condition in code after the commit. (After the completely removing of Old UI this part of changes can be reverted)
About the missing actions in Old UI:
They were missed because the DataContext did not contain a value for `RUN_CONFIGURATION_KEY` during actions updates. This is fixed by the introduced overridden `createActionPopup` method.
(cherry picked from commit 867e94bdedfdd753e783812d1939e22a3e37baa4)
IJ-CR-138667
GitOrigin-RevId: 86da724a6dac4218f392e91f4577e1458827635b
the new key-values in `ActionsBundle.properties` file are the copies of the corresponding `choose.run.popup.*` keys from `ExecutionBundle.properties`. The keys are renamed to the "action.[action_id].text/description" and moved to `ActionsBundle.properties` file so that they were automatically assigned to the corresponding actions declared in `LangActions.xml` file without writing any special code for doing this. The corresponding key-values were not removed from `ExecutionBundle.properties` because they have other usages. These usages were not rewritten so that they use the new key-values from `ActionsBundle.properties` because it can lead to changes in 100500 files, that can complicate possible backporting.
(cherry picked from commit 7ea94ef5f48a4dd323eb4cb33e149f772c0377f6)
IJ-CR-138667
GitOrigin-RevId: b9f345d1c3045151f5dcc335b0a0f654da408c42
... in Run Configiration executors menu and convert it into AnAction
(cherry picked from commit 608be4e8de2e2efe0490553dc3ead5987dc74060)
IJ-CR-138667
GitOrigin-RevId: 7f100be25f9970485a2dff9e81514bfa79043d02
to share functions that don't require analysis between K1 and K2 implementations of ReplaceExplicitFunctionLiteralParamWithItIntention.
^KTIJ-30542
GitOrigin-RevId: 3a4abe5ef00cc53c14136cd8a4853a7812f583f7
Since the even handler runs in a different thread from the progress modal, `ModalityKt.defaultModalityImpl()`
won't be able to get it from `ProgressManager.getInstanceOrNull()?.currentProgressModality`, causing the
modality state to fall back to non-modal, delaying the label update until after the settings dialog is closed.
It's fixed by just storing the settings dialog modality state before showing the progress modal and passing
it to `runInEdt` explicitly.
Signed-off-by: Sergey Pak <sergey.pak@jetbrains.com>
GitOrigin-RevId: ae45788cc3f16bb92e2bad666ba16b733762a216
There are two methods that open a file in RD: `blockingHandleModel` and `blockingHandleModel2`
They do the same thing, but only `blockingHandleModel2` triggers events such as `beforeFileOpened`, `fileOpenedSync` and `fileOpened`.
However, under `model.fireFileOpened` `blockingHandleModel` method is called (which doesn't trigger any events)
It seems that during refactoring the condition was misused. I switch methods so the correct one is called under the `model.fireFileOpened`
GitOrigin-RevId: 432487ac80e492527b0bee79b534bb2f1d334e49
There are two parts to the fix:
* explicitly flushing settings to disk before the initial sync — while the sync subsystem
correctly filters out files not matching the selected sync categories, it only seems to
take into account files that are actually persisted on disk when uploading them. When
setting up sync, the settings object initially remains in-memory (at least until the
time IDE decides to flush it on it's own), so initial upload might be missing the
settings state, giving appearance of all the categories being synced, instead of just
the selected ones,
* correctly categorise plugin settings — `SettingsSyncFiltering.getSubCategory` was written
to only classify font settings properly, so you could not disable a specific plugin from
syncing. This is now fixed by using plugin ID for category while filtering. It might make
sense to unify this code with `SyncPluginGroup` one way or another, but it was simpler to
just duplicate the behaviour for this fix.
Signed-off-by: Sergey Pak <sergey.pak@jetbrains.com>
GitOrigin-RevId: 88ab02f1198479eaad8966b7890748b87e53f5e0
It is natural for DSL that functions that define something (like subcommands in our case) can be called multiple times.
As suggested in review IJ-CR-135172.
GitOrigin-RevId: 8b7d3a650fde4cb0562dd95620df595bb24adda4
It is natural for DSL that functions that define something (like shell options in our case) can be called multiple times.
As suggested in review IJ-CR-135172.
GitOrigin-RevId: 2abe69dbbacf69dc2bed4e254ed3f78069852748
NettyChannelProvider from intellij.libraries.grpc.netty.shaded is a subclass of ManagedChannelProvider from intellij.libraries.grpc
Without this fix, PluginException: Cannot load class io.grpc.netty.shaded.io.grpc.netty.NettyChannelProvider is thrown caused by NoClassDefFoundError: io/grpc/ManagedChannelProvider.
GitOrigin-RevId: 11881a7c425ba959119ab4280ba067b305f4f803
