search

fyne-io / fyne

Cross platform GUI toolkit in Go inspired by Material Design
https://fyne.io/
Other
25.05k stars 1.39k forks source link

Capability to intercept Quit from Menu/Dock for Mac #5062

Open kvishal7 opened 2 months ago

kvishal7 commented 2 months ago

Checklist

Is your feature request related to a problem?

I am working on a cross-platform backup application where it is required to save some context when the application is quit. In case of Windows/Linux it works well since there app can be quit only from the system tray / linux top bar respectively using the fyne menus. But for Mac, there is a 'Quit' option in the main menu of the app as well as on right clicking the app icon in the dock which can't be intercepted using the existing APIs.

Is it possible to construct a solution with the existing API?

I have tried but couldn't find anything relevant.

Describe the solution you'd like to see.

Being a cross-platform framework, it would be favorable to have a generic quit intercept API for the application using which we can define the quit action for all possible ways: fyne menu (All platforms), OS menu and dock (Mac).

andydotxyz commented 2 months ago

Can you describe more about what you are trying to do? Typically interception like this is done on the window level as that is where content that is un-saved would be.

kvishal7 commented 2 months ago

I need to protect the application from abruptly quitting (by providing a confirmation popup) in case some operations are going on.

Typically interception like this is done on the window level as that is where content that is un-saved would be.

It's a single window system tray application. If I get you correctly, you are referring to intercepting close event of a window. But for system tray apps, close window events should hide the window but app should still run in BG.

dweymouth commented 2 months ago

But for system tray apps, close window events should hide the window but app should still run in BG.

This is possible if the user closes the window, but even on Mac it's standard that a quit command from the dock or the menu is for exiting the app. What isn't possible right now, and is a separate issue, is for a Mac app to by default just hide the window instead of exiting when the window is closed, even if it has no system tray.

andydotxyz commented 2 months ago

But for system tray apps, close window events should hide the window but app should still run in BG.

Sure thing, and that's what window CloseIntercept supports so that's OK. However a system level Quit isn't something that all platforms allow us to override. I wonder if perhaps this relates to the concept of needing to support background services - then the OS or driver can do the "right thing" if a background item is running and the user requests the app to quit. I think that we could support that, at least in theory.

kvishal7 commented 2 months ago

I wonder if perhaps this relates to the concept of needing to support background services

Yeah, that's pretty much our use-case.

and without this, the application loses it's fluency and reliability. For now I'm only able to intercept Cmd + Q using "golang.design/x/hotkey"

Looking fwd to this feature.

dweymouth commented 2 months ago

If you need to support a background service on desktop, that is not a system tray app, perhaps using multiple processes and an IPC mechanism like gRPC is the way to go? Only use the Fyne process for the GUI and do your service logic separately?

kvishal7 commented 2 months ago

perhaps using multiple processes and an IPC mechanism like gRPC is the way to go

Oh, I think I misunderstood about the background service. Our application orchestrates most of the tasks. It surely can be done this way but I think these intercepts will be very useful for many different kinds of App as well. Mac Apps like Numbers or Excel have these. Our need use-case is quite similar.

andydotxyz commented 2 months ago

Mac Apps like Numbers or Excel have these.

can you expand on this? As far as I can see they manage close intercept on windows like I mentioned before...

andydotxyz commented 2 months ago

without this, the application loses it's fluency and reliability.

Why is it less reliable? You can tidy up resources and shut down background processes in your main() after the app Run() returns.

kvishal7 commented 2 months ago

can you expand on this? As far as I can see they manage close intercept on windows like I mentioned before...

Not just on windows, but also all the close operations supported by MacOS - (Cmd + Q), Quit from menu bar, Quit from the dock and I'm interested in all the close operations as we already have window intercept in fyne.

kvishal7 commented 2 months ago

Why is it less reliable? You can tidy up resources and shut down background processes in your main() after the app Run() returns.

You're right. But don't you agree that intercepting the Quit gives an overall better UX. There can be cases of accidental quits when the user doesn't want to stop their backups but ends up not having any.

kvishal7 commented 1 month ago

@andydotxyz any chance this would be addressed in the future ?

andydotxyz commented 1 month ago

Well, it cannot simply be implemented in the current state as the discussion has not resolved. Some OS simply will not allow you to intercept or veto the user requested quit of an app.

We have already covered how unsaved content can be saved through window close intercept (where the OS supports it the window will be asked to close before the app exits).

If the new requirement is about background services then perhaps that is where the implementation belongs? It was discussed at FyneConf contributor chat and the background running of code seems to raise enough questions that we probably need to actually get a full API for managing it.