Allow window to be a child of an existing NSView on Mac OS

[glowcoil]

I'm interested in adding this functionality to winit. My use case is writing cross-platform VST audio plugins; I would like to use winit and glutin to keep the platform-specific code to a minimum, but currently I'm unable to use them on Mac OS as the VST host creates a window for me and the API just hands me an NSView.

I've looked into adding this via the platform-specific builder. It would require a different way of event handling than using a window delegate, some functionality (such as setting the window title) would be unavailable or a no-op, and there would be a lot of branching based on whether we have an NSWindow or just an NSView. It seems doable, but I wanted to hear opinions on whether this is the right approach for winit.

[monomadic]

I've modified winit already to do this, but it is an older version (0.5.x).

https://github.com/robsaunders/winit-vst

It's a fairly sloppy port (I should clean it up a bit) but it works, I'm porting the newer version now though but the api has changed so it might be a few days. I sincerely doubt that winit will ever support this in the main distribution as the mac module had to be entirely re-written, it's not as simple as the windows equivalent. Any discussions that had been started here, you can see they go back a while #159 , weren't paid much attention to, so it's not on the winit teams radar.

I can go into detail as to why you can't just PR an addition to the current module, if you need, but it wasted weeks of my time trying to work out a way that wouldn't require a complete re-write of the mac portion, and it's not a good fit due to the way hosts control the window (creating their own delegate already) and how winit works (wanting to create it's own delegate and suck events from it). Cocoa has a different mechanism for pulling events if you're working with views than with windows.

You'll need to know a lot about cocoa and objc and how to use the objc crate if you wish to make any real progress. It's not light rust and it's very unsafe.

I am working on a vst gui project and it might save you a lot of time to look over my github. I've gotten a few other gui libs working (imgui, conrod, cocoa itself with native controls, and glium) and written some examples in conrod, but since decided conrod is really poorly written and not suited to vst windows at all, and most users won't want to take the time to learn it anyway, so I'm looking at new options.

Lastly I'd point out that rust guis are all very very primitive at the moment, and winit/glutin/glium change their api almost with each version meaning unpicking a lot of what you've done. It's rough going. You'll probably end up wanting to write your own GUI layer. I've been at this about three months and I have a wealth of knowledge about it, but looking back I might have suggested to myself to try dplug instead.

Hope this saves you some time.

[glowcoil]

Thank you for all the information! I ended up deciding that my own GUI layer was the best option. So far I have OSX working, but I'm planning to extend to Windows and Linux. I will probably pull it out into a really small library (not as flexible as Glutin and Winit) for using OpenGL with VSTs.

[monomadic]

I concluded that too but I still use winit and glium for window + opengl instantiation - as glium is gold (and should not be abandoned imo) and requires a backend like winit. I recommend you at least try to use winit+glium over recreating a bare-bones graphic rendering layer, though with winit there's not much there once you re-write the mac core.

Conrod however is a different story, and so far implementing a gui lib from scratch is sooooo much easier than trying to wrangle it into something usable.

Are you going software or hardware accelerated?

[madsmtm]

glutin is now decoupled from winit using raw-window-handle, so you might be able to use that.

winit itself is not going to support being handed an arbitrary NSView/NSWindow and then work from there, we simply have too much state and delegate handlers on those for that to work (and have e.g. overridden NSApplication to fix various issues).