Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixed compiler warning about block declarations with no arguments #99

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bamwu
Copy link
Contributor

@bamwu bamwu commented Jun 27, 2020

On some versions of xcode/clang CLANG_WARN_STRICT_PROTOTYPES defaults to YES which results in warnings for all function prototypes and block declarations with empty params.

If '(void)' is annoying to you stylistically (it is to me a little), I'm more than happy to set CLANG_WARN_STRICT_PROTOTYPES to NO in the target settings instead. Just let me know.

@jeff-h
Copy link
Member

jeff-h commented Jun 27, 2020

Oddly enough, I'm not an Obj-C guy so I'm happy to bow to your experience on this. Given the age of this code, it's probably pragmatic to commit this PR and ignore style just a little — what do you think?

Can I ask what your use case is for MacGap? I often throw around the idea of writing a v3 in Swift, but I'm very unsure whether it's worth jumping through the hoops necessary to make WKWebView really work well for MacGap.

@bamwu
Copy link
Contributor Author

bamwu commented Jun 27, 2020

The '() vs (void)' thing is so subjective and in this case such a minor annoyance to me, I would just go with what is likely to be the consensus opinion, which if I had to guess is likely to put voids in there.

The use case is the typical one: cross-platform UI using well-understood technologies: HTML/JS/CSS, but can't (without jumping thru a bunch of hoops I'm not willing to jump thru) use the single-threaded node.js runtime.

We did something very similar to this at a previous company I worked for, but on a much smaller scale (not as a product itself, but to facilitate a small feature in a larger cross-platform product).

Re Swift: I'm not really a Swift guy, but I'm sure Swift developers would love to use MacGap right out of the box without having to jump thru any hoops to make it happen.

I would treat the WebView-to-WKWebView switch as a separate issue.

It's actually not a very difficult transition. We went thru the same switch on that project I mentioned above. I think it only took a few days to get it right.

It might be a good idea to make that switch first and then look into adding Swift support — hopefully without dropping Obj-C support. ;)

Happy to help with all non-Swift tasks, as it'd be an easier pitch to management if it's up-to-date and humming along nicely.

Any idea if there's something like this for Windows?

@jeff-h
Copy link
Member

jeff-h commented Jun 28, 2020

Thanks for the clarification re the PR; I will roll that in now.

I'm still unsure I understand your use-case. Specifically, given your skillset, why not roll your own webkit wrapper?

The WKWebView upgrade challenge is mainly because the only option is for purely asynchronous communication (although I've successfully trialled a hack that gets around this), but also because arguably WKWebView isn't even finished (eg printing).

I've not come across anything similar to MacGap for Windows; I do wonder whether it's a peculiarity of Mac users to be aware of the deeper aesthetics of an app, such as its resource usage, and thus to favour something lightweight like MacGap over Electron.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants