When invoked from a modal dialog, the previous implementation
would never be invoked until the dialog is closed. If the image editor
is in the dialog, it would never show an image.
This service was initially supposed to work in any modal context.
It's because it used to be completely synchronous code before,
so it's really supposed to be invoked as soon as possible,
just without blocking the EDT anymore.
GitOrigin-RevId: 778f870a70a6078fdab893b91e1ea8ab42265ee2
The task is pretty isolated from everything, so no need
for a channel or a flow here, just launch these asynchronously
and let them complete whenever they will.
GitOrigin-RevId: 373390f44a386a1a36e746cac27141d11c432379
Exception handling code was accidentally lost when
converting to coroutines. Catch and log everything
to avoid uncaught exceptions. Ignore cancellation
exceptions because they're expected and not
errors. We don't have to reset the image on
cancellation either, as it could cause unnecessary
flickering when it's cancelled due to another
request arriving (another file is being loaded).
GitOrigin-RevId: 7ed4058783bd1d650a18b26eb179586021c9f604
This regression was caused by some ancient (2005) layout hack
that overrode the invalidate() method and used it to center the image.
However, Swing doesn't always call invalidate() when validating.
Sometimes it just calls validate(), for example, if the parent component
was invalidated. This made laying out the image editor UI very fragile
and dependent on the specific moment when validation / invalidation / revalidation
happens.
When the slow op fix was applied, the image started to load with some delay,
as it would be now loaded in background and only then displayed. This broke
the mentioned hack because when the image is updated, revalidate() is called
on the parent container, not on the image container itself, which would cause
Swing to skip the invalidate() method containing the hack.
Fix by removing the hack and replacing it with a very simple custom layout
manager instead. Now validation happens the way it's intended by Swing,
and the new layout manager is called whenever needed, and it does the same
thing as the hack did: center the image.
GitOrigin-RevId: cb6965a0535ee365326dce59bd015d689b541943
Create a service and use coroutines to freely jump between IO threads and EDT.
To avoid converting too much stuff to Kotlin at once, use dependency
inversion and provide an object for image file loading to ImageEditorImpl
through the new service.
Cancelling the image loader's job through dispose() looks a bit ugly,
but until we move the entire thing to coroutines, it seems to be the only reasonable
way.
GitOrigin-RevId: ce42805acfcb67bbdbb3de869fb7a3606adcf383
- Replaced direct access to ColorPicker's and ColorChooser's static methods with ColorChooserService to explicitly route all color picker popups and dialogs to a client
- Had to create ColorPopupCloseListener to support message about popup closing (so we could finish session in time and avoid memory leaks)
- Added notification for user if they have read only access instead of opening color picker and silently dropping all changes
Merge-request: IJ-MR-104316
Merged-by: Kate Botsman <kate.botsman@jetbrains.com>
GitOrigin-RevId: 5cf9468992e9f538be47f6b96d1759e31f6c241a
