Direction of the project

[not-jan]

Continued from #345

Sorry for hijacking this issue - I guess it's where my research ended up. My original project was to mess with ScreenCaptureKit, which ended me up at this crate. I've then found out that while ScreenCaptureKit is supported - the actual API I want to use, captureImage, is not. I've noticed that we need CoreGraphics for that which I was able to "somewhat" add until I've encountered that it required Dispatch which ended me up with an error I can't really figure out with my limited MacOS/ObjC experience.

I have a bit of experience with working with LLVM from Rust so actually adding support for CoreGraphics wasn't the hard part. What's kind of hard for me was testing my changes and figuring out in which direction I should be going now. Should I be adding more framework crates using the current header-translator when the Swift mode is being planned?

Same goes for the async issue. Working with callbacks is a huge pain point in my current objc2 experience as it's very verbose. Does it make sense implementing a temporary (?) solution if the codegen backend will be switched in the foreseeable future? I suppose this is the least important issue at the moment.

Does it make sense working on automatic documentation import if header-translator is about to experience a big rewrite?

I do have some time I can spend on this project, but I'd like to spend it on something sustainable.

[simlay]

Does it make sense working on automatic documentation import if header-translator is about to experience a big rewrite?

I tried this with #435. It's been a year since I authored it. I don't recall if I managed to get reasonable documentation. I personally think that automatic documentation generation with header-translator would be super helpful. Feel free to take up from where I left off.

[madsmtm]

Hey @not-jan, thanks for the offer to help out! I'm a bit mentally busy the last few and next few days, and am not really organized to accept help at the moment, but would really like to become so!

Would you be able to do an online meeting over Matrix, Discord, Google Meet, or some other such platform? I'm free at 18:00 UTC Wednesday, 20:00 UTC Thursday, 15:00 UTC Friday or 6:00 to 13:00 UTC Saturday? That might make it easier to talk a few things through, though I realize it's a bit of a big ask / may break some social norms for what's expected on the internet, if you don't feel comfortable doing so, then that's totally fine.

Thinking about it, I'd actually also like to invite @silvanshade and @simlay, I've been wanting to "meet" you people anyway ;)

In any case then I'll try to respond here about my plans for the project in more detail soon.

[simlay]

Would you be able to do an online meeting over Matrix, Discord, Google Meet, or some other such platform? I'm free at 18:00 UTC Wednesday, 20:00 UTC Thursday, 15:00 UTC Friday or 6:00 to 13:00 UTC Saturday?
I've been wanting to "meet" you people anyway ;)

Sure!

Wednesdays at 18 UTC, Thursdays at 20 UTC or Fridays at 15 UTC are amenable to me. I tend to be doing non-computer stuff on the weekends but can make an exception if that's better for everyone. I'm simlay#3120 on discord, @simlay on matrix and firstname.lastname at gmail if google meet is suggested.

[silvanshade]

Sure I could do an online meeting.

I'm UTC-6 but those times are generally fine for me. If on Saturday, I could probably do UTC 12.

I'm silvanshade on discord, @ darinmorrison:matrix.org, or same firstnamelastname at gmail.

[not-jan]

Hi, I'm not sure I'll be able to make a meeting on the weekend but just getting in a chat together would probably already be beneficial :p I've created a room with @silvanshade and @simlay on Matrix. I'm @jan:chaos.jetzt on Matrix, DM me your handle or post it here and I'll add you as well @madsmtm

[jan]

@not-jan so we finally meet.

[madsmtm]

What's kind of hard for me was testing my changes and figuring out in which direction I should be going now. Should I be adding more framework crates using the current header-translator when the Swift mode is being planned?
I do have some time I can spend on this project, but I'd like to spend it on something sustainable.

Returning to this after now almost a year, things have changed; I no longer intend to rewrite header-translator to using ClangImporter, instead, I plan to merge its functionality into bindgen.

That said, I believe that improvements to header-translator are still valuable, especially regarding improvements to the Objective-C mapping (perhaps less so the C mapping), as the code would be fairly directly applicable to bindgen.

I'm going to close this issue, as that's the answer to the originally posed question. Feel free to continue the discussion, either here or on Matrix. (If nothing else, we did end up getting the Matrix workspace out of this discussion, so thanks a lot for your input here in any case!)

---

For completeness, responding to specific points:

My original project was to mess with ScreenCaptureKit, which ended me up at this crate. I've then found out that while ScreenCaptureKit is supported - the actual API I want to use, captureImage, is not. I've noticed that we need CoreGraphics for that which I was able to "somewhat" add until I've encountered that it required Dispatch which ended me up with an error I can't really figure out with my limited MacOS/ObjC experience.

All of ScreenCaptureKit, CoreGraphics and Dispatch are now supported (at least when I release it), and the API you mention is mapped.

Same goes for the async issue
Does it make sense implementing a temporary (?) solution if the codegen backend will be switched in the foreseeable future?

The hard part here isn't really changing the codegen, that's just a matter of detecting some common cases, and mapping that to async fn with a shorter name.

It seems to me to be more of an issue with actually implementing the continuation helper (i.e. the actual mapping from closure to async would have to be implemented in block2). I described it a bit in #279 (comment), reach out if you're interested, I think I have a draft implementation lying around somewhere.

Does it make sense working on automatic documentation import if header-translator is about to experience a big rewrite?

I finished this in 581f098, though it's still pretty bad (tracked in #309).

Work would definitely still be appreciated here, whether by improving header-translator's understanding of it, building a crate capable of properly parsing Sphinx syntax, or working to improve it in upstream libclang. All of these would be useful in the migration to bindgen.