@robby Is there a way to create a new DrRacket window from within a quickscript and obtain the frame% object? I chased the File\|New to frame.rkt and it calls (handler:edit-file #f) but when I try this it opens a new GRacket window instead of a drracket frame. So I guess the handler must be set somewhere to something else. Any clue?

I can call (send the-current-drracket-frame file-menu:new-callback) but this won’t give me the new frame% object

The end goal is to move a tab to a new window

I think unit.rkt should have the callback.

Right, I got there, but I must say my understanding of units is fairly limited (after reading the docs), and drracket is not exactly the toy example of the guide :slightly_smiling_face:

Is it possible to obtain this callback without instantiating the unit again?

My failed attempt so far: This fails with unbond id frame:basics<%> which I tried to chase but couldn’t get rid of this message. #lang racket/base (require quickscript racket/class racket/unit drracket/private/unit drracket/private/drsig framework) (define-values/invoke-unit/infer unit@) (drracket:unit:open-drscheme-window #f) ; unbound id frame:basics<%> (define-script move-to-new-window #:label "Move tab to new window" (λ (selection #:frame fr) #;(handler:edit-file #f) ; GRacket by default, not what we want #;(send fr file-menu:new-callback #f #f) ; does not return the handle (drracket:unit:open-drscheme-window #f) #f)) But I suspect there’s a lot more stuff to do to be able to use the unit…

The exports of the unit are all already available to scripts, I believe.

Since the script is evaluated within the tool’s namespace, I believe they should be. But they are dynamic-required, so they should still compile on their own

Did you try calling drracket:unit:open-drscheme-window?

Yes, as you can see above

Without invoking the unit, I mean.

then I get unbound id

(assuming that commenting out the define-values/invoke-unit/infer line s what you meant)

Did you require drracket/tool?

no, that’s not the right one. One sec.

Looks like drracket/tool-lib is the one you want.

I can’t require this one, because it opens a DrRacket frame immediately, on which I have no control (also it’s messed up)

I think that migth be because of the namespace stuff that quickscript is doing.

That’s the library that exports all of the things described in the drracket tools manual.

Yeah, that was my first attempt. But even if you write a standalone module that requires drracket/tool-lib it will start a Drr instance

Not if DrRacket is already started and you’re in the correct namespace, it won’t.

You’ll just get the one that’s already started.

I think that quickscript is creating a new namespace

So when you require that in the new namespace it will start up a new DrRacket.

(Which won’t work unless you set up the rest of the environment properly.)

It might be the right approach for quickscript to share that module with the namespaces it is creating.

the script itself runs in the same namespace as the main drracket’s, but a new namespace is created to read the submodules of the quickscript that contain the menu info and stuff

Though when I reload the menu, it doesn’t start a new drr instance, so that seems to be fine

when a module is loaded, the value of current-namespace is consulted and, if the module has already been loaded, then you’ll get that module that was already loaded. The main drracket namespace is the one you want active when drracket/tool-lib is required.

So that way you’ll get the existing drracket instead of starting a new one.

Actually you’re right, a new namespace is created to obtain the procedures from the script, and then the procedure is called within the drracket’s namespace, so indeed the require drracket/tool-lib is different

It might make sense to share the drracket/tool-lib library with that new namespace that’s used to load the script. I’m not sure, tho. Depends what else is going on.

How do you share with dynamic-require?

The sharing works with the namespace.

Not the the particular require form you’re using.

So the value of current-namespace will be some namespace.

I see

with namespace-attach-module?

That’s the one that’s consulted, regardless if you’re doing dynamic-require or whateve else it might be.

Right, namespace-attach-module is how you share modules between two namespaces.

Note that it shares everything that is depended on.

In this case, that means anything that drracket/tool-lib depends on will also be shared.

(which is a lot of stuff)

That works!!

Thanks a bunch robby!

:slightly_smiling_face:

Wonderful, that should make quickscript much more capable now :slightly_smiling_face:

sweet!

all the tests pass, so that’s a good start

Can you think of something that may go horribly wrong due to sharing?

> override < method-not-found >

https://docs.racket-lang.org/tools/drracket_unit.html#%28meth._%28%28%28lib._drracket%2Ftool-lib..rkt%29._drracket~3aunit~3adefinitions-text~3c~25~3e%29._set-modified%29%29\|https://docs.racket-lang.org/tools/drracket_unit.html#%28meth._%28%28%28lib._drracket%2Ftool-lib..r[…]finitions-text~3c~25~3e%29._set-modified%29%29

weird

I thought I had all of them in https://github.com/racket/gui/issues/185

https://github.com/racket/drracket/commit/5d6b658d048afeace4defc090df53ae80da1f53a in particular should have fixed the problem with set-filename

One thing to make sure is that all of the evaluation is happening on the eventspace handler thread of drracket; lots can go wrong if that’s not the case.