Add some kind of top-level application type about druid

[ratmice]

IIUC this is partially there with AppDelegate<T + Data> and Commands,
With the missing bits being in platform/, having a mechanism for the backend to send Commands or Events like OpenFile. AppDelegate doesn't by itself get passed down to platform and runloop, and in fact Data doesn't exist at the druid-shell level.

As far as I can tell, all events currently in the macOS platform currently come from an ivar held within an NSView. One thing worth noting is that on macOS there is always a window. If there is no window on screen, there is still the application icon. Well i guess it isn't actually a window, but it does have a view, and afaict that is the main thing that is needed.

The NSApplication class has a method -dockTile, which has a method contentView which you can use to set/get the AppIcon's view.

File > Open outside of dialog boxes on macOS happens through the NSApplicationDelegate class, which will receive a message application:openFile:, the first argument being the application from where you can get the dockTile from. Plus we get to draw on it!

Is there anything that I am missing already which allows us to send events to AppDelegate events without a window?
Would making an icon window (window-like-thing?) a parameter to AppLauncher be a viable solution?

[cmyr]

Interesting, I didn't know about NSDockTile!

The initial design of druid came out of work on xi-win, which was windows only. On windows, it's fine to treat the window object as the top-level object in an application. Druid's current architecture is a consequence of this; we treat a window (or the window's root view, on macos) as the top level object, and all events are delivered through a window.

This just doesn't make a ton of sense on mac. I'm also not sure about the idea that there's "always a window"; I don' think that the app icon really counts; for instance it's possible to have a running application with no dock icon.

So what I really want here is for us to have an actual NSApplicationDelegate in the mac backend, and some kind of optional AppHandler or something in druid. This is tricky though, as a design problem; I'm not sure exactly what events should go through here, I'm not sure how it should work on other platforms, and I'm not sure how it should interact with window objects.

[ratmice]

Indeed, the wrinkle that NSDockTile is window-similar, but not actually an NSWindow, and only deals with a subset of events, (i.e. not focus and other things) is more tricky to deal with in druid/ than druid-shell which is what I was initially looking at.

I don't know about App's without an icon. Back in the day, I believe in order to bypass icon creation you need to implement a standalone NSService the details of which escape me, but I don't believe it was NSApplication based unless the service was part of an application in which case the application still had an icon.

Anyhow, neither here nor there I agree entirely that on macOS a plain NSApplicationDelegate seems better, it seemed like using NSDockTile it might fit the existing model, but it seems to just cause a bunch of tricky typing issues.

[cmyr]

yea, I think the problem is really that our model has some simplifying assumptions that we're going to need to revisit.

[Zarenor]

I know maybe the complication isn't quite what you wanted to hear, but it's also possible to have: tray-icon-only applications on windows, usually interacted with from a context menu, though sometimes creating a window, which may or may not have a taskbar icon separate from the tray one; as well as icons on the taskbar that appear as normal applications, but don't have a window (and handle the click on their icon some 'interesting' way).

I'm not sure we're planning to handle those in druid, but it sounds like (based on all this MacOS windowless talk) we might. And that we certainly are considering it for druid-shell.

[cmyr]

yea, I think these are interesting cases but I'm not thinking about them too much, right now; I'm also not thinking about the 'toolbar only' mac app case. The distinction with the mac, afaiut, is that any windowed application is expected to persist after all of its windows have closed.

[xStrom]

Windows notification area icons need to be associated with a window. Note the HWND field of the NOTIFYICONDATA struct.

There's some discussion of it on Stack Overflow. You could create a message-only window, but it wouldn't work for keeping notification icons alive due to not receiving taskbar creation messages. Best to just associate the notification area icon with a proper window and just hide the window if necessary.

[ratmice]

For the record, I wasn't really speaking about Menu Bar applications at all,

In particular when we're implementing NSApplicationDelegate the first parameter to the methods is an NSApplication instance, from there we can call [[app dockTile] contentView], and get something which which is something Widget-like, in that it is expecting events.

Alas there is the caveat already mentioned that its a view not in a window.
But I think we can rely on it existing throughout the lifetime of the application from startup until termination, for the cases under consideration.

(To try and summarize my thinking above)