Call window close at com-exit

[nomennescio]

When CTRL-Q or similar is pressed in the UI, com-exit is called, which currently has:

: com-exit ( -- ) 0 exit ;

However, this fails to close Window, which would prevent some code to dispose of resources to be triggered.

@mrjbq7 suggested:

: com-exit ( -- ) worlds get values [ [ close-window ] ignore-errors ] each 0 exit ; 

[nomennescio]

It seems ungraft* is still not being called on ui.tools.listener even with 378fb18 and 7aa0e50

[mrjbq7]

Interesting, it appears M\ object close-window calls ungraft but the UI backends don't...

[mrjbq7]

So perhaps we should change it to have an inner backend close-window* and an outer close-window that calls ungraft before close-window*...

[nomennescio]

It's nearly impossible for me to track this down, because using the Walker will cause a segmentation fault at certain points.
How do you debug this?

[mrjbq7]

Paper debugging by logic or [ . ] with-global style stdout print debugging You can’t currently debug the UI with the UI

…

On Mon, May 27, 2024 at 10:35 AM nomennescio ***@***.***> wrote: It's nearly impossible for me to track this down, because using the Walker will cause a segmentation fault at certain points. How do you debug this? — Reply to this email directly, view it on GitHub <#3004 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF5A4CDEMKDUBEB433QJDZENVFFAVCNFSM6AAAAABILNRTPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTHA3DQNRTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nomennescio]

Ye olde printf debugging

[nomennescio]

Paper debugging is how I usually do it, however in this case the whole UI stack is relatively new to me, so will take significant time to work through. Have to pass on that for now.

[mrjbq7]

It would be cool to have it drop into the command line debugger but I *think* there are some issues due to using the main thread to pump the UI, but would make a nice contribution. On May 27, 2024, at 10:37 AM, nomennescio ***@***.***> wrote: Ye olde printf debugging —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[mrjbq7]

You know, I think it's sort of "working".

ungraft is being called, but it defers the ungraft* until later (ungraft-later), and we don't wait for that later before calling exit.

[nomennescio]

I couldn't check what the ungraft-later did, but then we would need to wait for it run.

[mrjbq7]

I mean we could also enqueue a close-later, but alternatively, we could add an ungraft-now...

[nomennescio]

I think it all has to do with the whole native handling of windows, where you need to post messages and do stuff async, that we need to do things -later, isn't it? But then again, the whole Factor windowing stuff is new to me.

[mrjbq7]

the -later is largely to allow for "change a bunch of UI stuff" in one iteration of the UI thread message loop, then apply all the changes, then loop again. There are cases where do-it-now is useful.

[nomennescio]

so why not just:

: ungraft-now ( gadget -- )
    dup [ ungraft-now ] each-child ungraft* ;

plus flushing the graft/ungraft queues?

[mrjbq7]

Perhaps want to do the current way but also flush queues so you don’t ungraft twice.

…

On Mon, May 27, 2024 at 12:31 PM nomennescio ***@***.***> wrote: so why not just: : ungraft-now ( gadget -- ) dup [ ungraft-now ] each-child ungraft* ; plus flushing the graft/ungraft queues? — Reply to this email directly, view it on GitHub <#3004 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF5A4TCDDNZLGM34ZDL6LZEOC2RAVCNFSM6AAAAABILNRTPGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTHE3TANRRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mrjbq7]

This calls ungraft* properly when com-end is called, but it doesn't seem to work with Cmd-Q on mac maybe?

4311024

[nomennescio]

It does now work on Windows with CTRL-Q, thanks!

[nomennescio]

Windows close button works now too!

[nomennescio]

And ALT-F4 too!

It seems the whole feature is now working as expected!

[mrjbq7]

Ctrl-D works on windows

[nomennescio]

Not really, it keeps the windows open.

I noticed your revert. Pity you don't want an alias for the user to type. Seemed like a good solution to me.

[nomennescio]

a50f45c

and

831568a

[mrjbq7]

Ctrl-D works consistently on all platforms.

OS-specific commands (Cmd-Q / Alt-F4) work also.

Users can make their own words if they want that.

[nomennescio]

This was about having a command to type.

(for those people that expect such a command to exists. e.g. when starting factor from a shell)