Double-click opening a file on macOS

[ArturKovacs]

When a file is associated with an app on macOS, the application:openFile: or the application:openFiles: function gets called instead of passing the target filepath as an argument. The application must handle theese calls otherwise the os will display an error message to the user that the appilcation doesn't support opening the file type.

Winit currently doesn't seem to handle either of these and there doesn't seem to be any other way of making a winit application able to handle opening a file for when the user double-clicks on an associated file.

[ArturKovacs]

I'm willing to implement this but first it would be nice to get some feedback from someone who's made macOS apps that can open associated files and has an idea of how this should be implemented in winit. My plan is to handle both of application:openFile: and application:openFiles:, immediately responding to the os that the opening was successful (event if it isn't going to be) and then sending or queing a winit WindowEvent with the list of file paths. The event would be a new variant and would look something like the following.

pub enum WindowEvent {
    // ...
    
    /// A file was requested to be opened. This must be handled to allow a macOS app to open associated files that are
    /// double-clicked. Other systems usually pass the file path as an argument to the program. (See `std::env::args()`)
    OpenFiles(Vec<PathBuf>),
}

[ArturKovacs]

@chrisduerr and @vbogaevsky as you are listed to be the contributors/maintainers for this platform, I'd like to ask you to give an opinion on the solution I suggested above. I'd be happy to tackle this 😊

[chrisduerr]

I've never built any macOS applications, so I cannot tell you if the API is correct or even sensible to use. Though as stated previously it would be a pretty strange API for something like this, rather than an application reentry.

But I see no reason what would stop anyone from just sending a PR to add these APIs, it all seems very straight-forward to me.

[alvinhochun]

Using event::WindowsEvent seems wrong as it doesn't seem like those events should be associated to a window. I wouldn't think adding a variant to event::Event is appropriate either, because it seems pretty much an event limited to macOS?

[kchibisov]

I still don't understand what the point here. You track clicks and you have some sort of file view in your application, then you make this click and it goes through your ui view hierarchy. Then you check if you point on file and open a file, why winit should be even involved here, opening files in UI toolkit has nothing to do with winit imho.

[ArturKovacs]

@alvinhochun Correct, these are limited to macOS as far as I can tell (Windows and GNOME will just forward the path as an argument and I assume so does every other Linux desktop envornment). If a variant shouldn't be added, what would be the solution you'd suggest?

@kchibisov No that's not what I'm trying to do. This refers to using the native file browser, "Finder" on macOS and double clicking there. The OS then figures out which application to open and the OS opens the application and calls this ominous application:openFile function.

[kchibisov]

Can't you just get NSApplication and do whatever you want without touching winit?

[alvinhochun]

@ArturKovacs I'm not sure if there are existing patterns in winit for handling platform-specific events.

@kchibisov My guess is that winit subclasses NSApplication in order to run its event loop, and the question would become something like "how to retrieve the NSApplication from winit" or "how to intercept platform-specific events/messages from winit".

[kchibisov]

@alvinhochun

winit/src/platform/macos.rs

Line 246 in 3a077ff

fn hide_application(&self) {

If something like that works, I'm curious whether using that method will work for file opening.

[alvinhochun]

Well, I was going to suggest adding EventLoopExtMacOS with a method to register a FnMut callback that is fired on application:openFile: and etc., but it seems a bit odd and I'm not entirely sure how it would work in practice (I guess the user might probably end up using EventLoopProxy to pass custom events).

[ArturKovacs]

Thanks for the pointer @kchibisov, I'll try to experiment a bit to see if it's possible without having to add anything to winit.

Yeah the platform specific extension trait would definitely be less intrusive, I like that idea, @alvinhochun. What I'm a bit concerned about is the timing of things, specifically if it's going to be possible for the user to call the appropriate function in time to actually receive the callback. Although this can be mitigated by keeping the last openFile request stored so that the user doesn't miss it even if registering the callback later.

[ArturKovacs]

I looked into this and as you probably know, winit defines the WinitWindowDelegate at runtime, during startup. What I would need is to add the twoapplication:openFile: methods to it. But I don't think it's possible after the class has been registered and instantiated so I just don't see a way for doing this without making modifications to winit.

Later I'll explore the possible implementation of an extension trait that allows registering a callback.

[kchibisov]

Hm, maybe we should have some event loop extension builder, I'd need something like that for Wayland actually.

[ArturKovacs]

You mean something like this?

enum Event {
   WindowEvent {...}
    // All the other events events 

    Extra(ExtraEvent)
}

// On Linux
enum WaylandEvent {
    ...
}
impl ExtraEventWaylandExt for ExtraEvent {
    fn into_wayland_event(self) -> WaylandEvent {...}
}