racket/gui/base frame lifetime

[greghendershott]

Moving from two comments in #472 by @acarrico to here as its own issue.

---

Here is an example, but may not be much use. Seems like documentation is the best solution? Starting with something like:

#lang racket/gui

(define frame (new frame% (label "example")))
(send frame show #t)

When you hit F5, you get a new repl with a new frame, shown in X11 (normally). After hacking around a while, I have seen racket-mode in a state where the new frame is not shown in X11. In this state, running the program at the command line does create the frame, and killing the process does allow racket-mode to create a new repl which acts normally.

I don't know how to reproduce this reliably though.

---

Actually I can reproduce this behavior by hitting ^d to terminate the repl. C-c C-\ seems to do it also. M-x racket-stop-back-end fixes the issue.

[greghendershott]

This probably relates to the change about a year ago, to support multiple REPLs.

Even with a single REPL, racket/gui/base has always been a bit tricky to handle: I really want to avoid loading racket/gui/base --- both the "heavyness" of that, as well as visual artifacts like a GUI frame appearing on some platforms -- until/unless someone is actually using it in their program.

IIRC, if you require racket/gui/base more than once in a Racket process it, it errors.

(Whereas normally if you require a module more than once in the same namespace, it's a harmless no-op. Or if you require it in a new namespace, it is instantiated for that namespace.)

So there is some dance trying to figure that out and load it only once, on-demand. Apparently I didn't consider that carefully enough for multiple REPLs. I'll investigate.

[greghendershott]

Maybe the answer is to create a distinct namespace in which racket/gui/base might eventually be required. Wait to do that until necessary. Then namespace-attach it into each the namespace created for each run of a user's program. Something like that... I'll see.

[acarrico]

It sounds like you've been struggling with racket/gui/base a while. I don't know how far you should bend over backwards to deal with it--perhaps it is more of an upstream problem. Is there some reason to expect the gui library to take any perceptible time to load? I didn't see an obvious reported issue. Also weird that there would be any visual artifacts before creating and showing a frame.

[greghendershott]

I think it's worth me taking another look. It's been close to 10 years. Things may have changed in recent versions of Racket, the operating systems, and/or my brain.

---

1. What I've seen before, IIRC, was on macOS and/or Windows: Merely (require racket/gui) (not even creating any GUI objects) would create an OS GUI representation of the Racket process -- it would appear in the alt/command + tab list, you'd see it in the dock, and sometimes even a "dummy" or "placeholder" top-level window.

   It was very distracting and annoying if you're not using racket/gui.

   Although I don't see that now with Ubuntu 18.04, I'll have to check again on other platforms.

2. Another problem with Racket Mode adding racket/gui as a hard/eager/unconditional require, is that it would be a hard/unconditional dependency. Although Racket Mode already requires some more libraries beyond Minimal Racket, including some pieces of DrRacket, it doesn't hard-require the GUI pieces.

   Doing so now would be opposite of where I'm trying to move, which is in making the dependencies fewer and more precise, e.g. Improve dependency on drracket package #471. This also was part of the decision to make racket-xp-mode a minor mode as opposed to baking check-syntax features into the racket-mode major mode for editing files.

---

Having said all that, it's worth me taking another look.

[greghendershott]

I did loop back to revisit this with commit 7f12cb1.

I didn't tag that commit to close this issue, yet. Although I think probably it does, I'm reluctant to declare "mission accomplished!".

[greghendershott]

Having lived with commit 7f12cb1 for awhile now, I think this approach does work well and I'm going to close the issue.

I very recently fixed two issues related to commit 7f12cb1, #555 and #556, as well as re-fixing issue #519. Although that sounds bad, the time I spent investigating and thinking about those, actually increased my confidence in the new approach. The issues were because I'd overlooked or mishandled a couple details.