CEFDemo outdated about cef.swift

[infrom-software]

Though, in this particular example, it doesn't matter.

[lvsti]

thanks for spotting it, fixed it for branch 3202

[infrom-software]

In CEFDemo, in createApplication(), Nib stuff creates an unnecessary extra-window. Nib not needed here since top-level window is created by CEF.

[infrom-software]

Is that cef_application_mac_capi.h file really needed? I mean, can be moved into CEF.swift?

[lvsti]

well so far I have been trying to keep the codebase free from AppKit (using Foundation only), but since the CEF framework already links against pretty much all the application frameworks (AppKit included), I guess I could move that file as well into the swift package

[infrom-software]

What about creating CEFDemo Helper in swift (as a dependency target for CEFDemo target)?

[lvsti]

Makes sense, I've made some progress on it but got stuck with some module import issues. ETA probably this weekend.

[lvsti]

Check out the 3202 branch which now has a CEFApplication class that wraps the common required functionality for event dispatch, and also a CEFDemo Helper (Swift) target in the sample project which makes it unnecessary to build the sample helpers in the CEF binary distribution. There is one caveat: if you implement the helper app in Swift, it gets packaged with the Swift standard libraries which means an additional 11 MB in the binary size. If you don’t do anything special in the render process, I recommend using the CEFDemo Helper (C) target which does the exact same thing, just in 10 KB. :)

[infrom-software]

Elegant!

[infrom-software]

Things from cef_application_mac_capi.h can be absorbed in CEFApplication.swift, can't they? I mean @objc protocol ...

[infrom-software]

Agree, CEFDemo Helper (Swift) is currently worthless (and keeping it alongside (C) target is rather confusing ). Maybe Swift runtime will not be copied anymore in the future.

[infrom-software]

I use 10.13, why not ?

[lvsti]

ok so can we close this issue now?

[infrom-software]

Few lines of code in CEFApplication.swift and cef_application_mac_capi.h not needed at all. CEFDemo.xcodeproj needs some tweaks.
It's up to you.

[lvsti]

1. You use 10.13 but others might not. There is no harm in having 10.9 as the deployment target
2. Which lines do you think are not needed in cef_application_mac_capi.h? CefAppProtocol conformance is a must for any NSApplication subclass to work properly with CEF

[infrom-software]

1. Ok.
2. My mistake: Put few lines of code in CEFApplication.swift and then cef_application_mac_capi.h file won't be needed at all.

May be these...

@objc protocol CrAppProtocol {
    func isHandlingSendEvent() -> Bool
}

@objc protocol CrAppControlProtocol: CrAppProtocol {
    func setHandlingSendEvent( handlingSendEvent: Bool)
}

protocol CefAppProtocol: CrAppControlProtocol {
}

P.S.
UnderlayOpenGLHostingWindow is kind of bogus.

[lvsti]

I didn't think of that but it actually makes sense for the protocols. As for UnderlayOpenGLHostingWindow, Swift doesn't support forward declarations but I can sneak it into the framework header so I can eventually skip the cef_application_mac_capi.h hack. Thanks for the suggestion.

[lvsti]

btw I have a PR for CEF (https://bitbucket.org/chromiumembedded/cef/pull-requests/129) that will make it possible to include the cef_application_mac.h in the module, which will make the above workaround unnecessary.

[infrom-software]

Even better.

p.s. only to complete the workaround:
UnderlayOpenGLHostingWindow's implementation does nothing but checks in init that window's contentRect it's not zero width or height. (It seems it did more in the past.) And it's not exposed elsewhere. Presuming it won't change, it can be easily reimplemented in CEFApplication.swift or... simply neglected (It's more of convenience: keep in mind to use UnderlayOpenGLHostingWindow vs. be aware to check not zero.) So, no need to touch the framework header.

[infrom-software]

I think CEFDemo looks better now; can we close this issue?
(apart from some small tweaks in CEFDemo.xcodeproj)

[lvsti]

How UnderlayOpenGLHostingWindow works and what it does is an implementation detail that CEF.swift should not know/care about. If the framework states that browser windows should inherit from it, CEF.swift should make that possible, even if the class is just an empty subclass. So I'm leaving it there for now.