Fork me on GitHub

@djblue hello, I've been noticing that Portal IntelliJ plugin got worse at applying the theme, in the past when I ran it a second time it used to get the right theme, but now I have times where I can keep asking for new portal but it doesn't apply the intellij theme


restarting IntelliJ sometimes fixes it, is there a way to ask Portal to change the theme after it is initialized?


I see the set-theme command, but the intellij one doesn't show in the options


The problem is that the theme is and the issues is a race condition around when to apply the theme


if we are ok with some flickering in the initialization, maybe Portal could delay a bit the theme application to avoid this race condition?


That is one option. Another I'm thinking about is passing the options as a string via query params


as long as that message doesn't get big enough to blow out the URL size, that should be fine

R.A. Porter17:05:44

I feel pretty dim that I can't suss out what the race condition is, but my best guess is that the calls to .executeJavaScript on the CEFBrowser are async? If that's it, I'm wondering if this would resolve the problem:

Index: extension-intellij/src/main/clojure/portal/extensions/intellij/factory.clj
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
diff --git a/extension-intellij/src/main/clojure/portal/extensions/intellij/factory.clj b/extension-intellij/src/main/clojure/portal/extensions/intellij/factory.clj
--- a/extension-intellij/src/main/clojure/portal/extensions/intellij/factory.clj	(revision Staged)
+++ b/extension-intellij/src/main/clojure/portal/extensions/intellij/factory.clj	(date 1652117683035)
@@ -39,19 +39,22 @@
      {::theme (theme/get-theme)}})))
-(defn init-options [browser]
-  (run-js browser
-          (str
-           "sessionStorage.setItem(\"PORTAL_EXTENSION_OPTIONS\", " (get-options) ")")))
+(defn- get-ext-opts []
+  (str
+   "sessionStorage.setItem(\"PORTAL_EXTENSION_OPTIONS\", " (get-options) ");"))
+(defn init-options [browser]
+  (run-js browser (get-ext-opts)))
 (defn patch-options
    (doseq [browser (into [] (map :browser) (vals @instances))]
      (patch-options browser)))
-   (init-options browser)
    (run-js browser
-           (str "portal.ui.options.patch(" (get-options) ")"))))
+           (str
+            (get-ext-opts)
+            "portal.ui.options.patch(" (get-options) ");"))))
 (defn -uiSettingsChanged  [_this _] (patch-options))
 (defn -globalSchemeChange [_this _] (patch-options))


I'll have to take a look, but I pushed up which might help with the race condition :thinking_face:


@djblue I tried to build it here to test, but I'm getting some error, maybe it needs a more recent node version?

=> npx vsce package
----- Error --------------------------------------------------------------------
Type:     java.lang.IllegalArgumentException
Message:  Cannot open <#object[ 0x6ba20a7b ""]> as an InputStream.

    return (translations ?? [])


(from running bb ext)

R.A. Porter15:05:34

@djblue Did you have a chance to look at my proposal that avoids lock-checking?


@U01GXCWSRMW I can still reproduce the issue with the above diff. I think it's mainly around close/open, because close will kill the old http server, so open will start a new one with a new http port, aka a new domain. Thus run-js is probably running in the context of the old domain since loadURL is async.

👍 1

I think another option instead of using a future to poll is adding some event handlers, but I haven't looked into that yet and if the future option works well enough, I might leave it 😆

R.A. Porter02:05:16

If it works, it works. 😄


@U066U8JQJ not sure why it doesn't work for you but here is the latest build 👌

🙏 1

@djblue just did the first tests here, no wrong themes so far 😄

awesome 1

Ok... I lied. is the event listener version 😂 Seems to work just as well except the interaction with the Portal UI is a little simpler.


And here is the build if you'd like to try it 👌


seems good 👍

awesome 1