Less blocking popups

[Piotr Kożuchowski]

That must be my most hated aspect of Illuminated Cloud - blocking popups everywhere, even if I don’t need them
I will try to list items that have been horrible UX for me and how would I see them improved.

1. Deploy/Retrieve selected item
   When I want to quickly retrieve selected classes from higher sandbox, it will get me through Listing connections, “Loading Details from Dev”, “Listing metadata from Dev”, then “Loading Details from UAT”, “Listing metadata from UAT” and if misclick… well there’s more of listing for me. This takes inadequate measure of time compared to what I want to do.

Proposition:
Skip listing for Context retrieval/deployments and let me do this action right away. The items to retrieve are right there.
List when changing to Custom scope.

2. Execute Apex / Logs - Retrieving flags
To be honest, I don’t really need to know the flags 99.9% of the time . I’d rather have the apex executed right away and flags may be retrieved in the background if at all. Can be retrieved lazily too.

3. Changing connections
Now sure how doable is that given plugin limitations, but all I want when changing connection is that next deployment/retrieval/refresh will use that connection. Currently, in medium sized project it takes 1.5 minute to switch to different connection while opting for reusing existing offline symbols and not reloading project (measured with stopper in my hand).

My main use-cause for changing connection is switching between Dev/Qa/UAT for debugging, sometimes switching between Dev sandboxes. Either way, I will hardly ever need to reload the symbol table.

‌

4. Option to hide Deployment popup in background by default

When I work, I want to push the state I’m on and keep working - hence it would be more efficient if deployment was in the background right away. Currently, I have to grab my mouse, click Background button and go back to keyboard to go back to work.

Proposition is to have option to hide this popup in background by default.

‌

I’m saying these from my personal experience, but I suspect this is representative for a great deal of developers

‌

[Scott Wells]

I've probably done about as much as I can with this at this point unless there are specific examples in recent builds that you'd like to discuss.

One of the issues is that synchronous operations run under a progress indicator cannot be sent immediately into the background. I wish they could, but if you push them into the background from the get-go, they become asynchronous. Many operations must execute in a certain order. While it might be possible to restructure things to follow a promise-style pattern, it would require a HUGE refactoring of much of the core IDE to do so.

In the 2020.* family of JetBrains IDEs, backgroundable operations, i.e., those that have traditionally started in a modal but can be moved to the status bar, now start in the background by default. It's actually a backward-incompatible change, but I may retain this new behavior if/when they fix it. As a result, things like bulk deployment/retrieval, OST generation, etc., all move immediately to background processes immediately after you choose the options for the respective operations.

I've also done quite a bit of work to keep interactions with the Salesforce CLI--in particular to get org lists and details--in the background. When CLI connection information is found to be stale, I try to retrieve that information in the background as often as possible, and I've started using the new --skipconnectionstatus flag of force:org:list to ensure the runtime of that command is as short as possible. If it's still an obstacle, you can configure IC not to run those commands automatically but to show a notification instead, or even to do nothing.

I'm resolving this overall issue at this point, but again, if there are specific items that warrant further discussion, feel free to log corresponding issues here, one for each, so that I can prioritize and tackle them in turn.

[Piotr Kożuchowski]

Ah, that’s too bad.

At some point in my current project, I’ve had a glitch where changing connection didn’t trigger any indexing/module/offline symbols and it was working like a charm. Later on, I had to redo project setup and the glitch was gone.
Is there any chance to make it work like this? Like I’ve said, on one project I will mostly switch between sandboxes - Dev/Qa/UAT etc. so I don’t really need to reindex anything, it’s the same stuff.

‌

[Scott Wells]

Not really. Unfortunately changing a connection inherently corresponds to changing to an OST for that connection since different orgs (often) result in different OSTs due to differences in org shape. IC will prompt you to copy/reuse an existing OST if available, but in the end it still has to rebase on an OST that's considered to be for the newly-selected org.

How often are you switching connections, and how long is the resulting reindex taking?

[Piotr Kożuchowski]

Usually it’s a few times a day. Switch takes about 20-30 seconds if I use existing symbol table, 2 minutes with generating new (which I don’t usually do).
Cumulatively may seem not much, but it’s enough to switch attention elsewhere