Add support for BackgroundAssets framework

[silvanshade]

No description provided.

[madsmtm]

Sure, this seems simple enough to support

[silvanshade]

Sure, this seems simple enough to support

Just out of curiosity, do you have a list of frameworks you would ultimately like to support or is it basically just "as much as possible"?

I'm also wondering what the plan is regarding more of the "core" frameworks that you alluded to earlier.

I made a quick attempt a little while ago to rewrite most of tao and wry using icrate (with the WebKit additions) and there's still quite a few parts of it that rely on definitions coming from the core-graphics crates, some of which overlap with the bits already included in `icrate.

[madsmtm]

Just out of curiosity, do you have a list of frameworks you would ultimately like to support or is it basically just "as much as possible"?

I think the plan is mostly just "if people need it". So well, at some point that might be everything.

I'm also wondering what the plan is regarding more of the "core" frameworks that you alluded to earlier.

I'm still unsure! Ideally, I'd like to integrate with the rest of the ecosystem, and use crates like core-foundation and core-graphics; but on the other hand, when auto-generating stuff, everything from a framework needs to be available for us to be able to use it; so I suspect it will still need a lot of manual fixes, and then it might just be better to re-implement it (which also gives us the benefit of getting availability attributes on those frameworks, and other improvements that might come to icrate).

There's also the question of how much we should try to make it safe, ideally something like CGContextRef would be translated to a class-like structure CGContext with methods and a destructor, just like it is in Swift.

I'm considering redoing header-translator the "proper" way, which is to use the existing code that Swift uses, see #345 - so possibly CoreFoundation-like structs will only happen after that.

[silvanshade]

I think the plan is mostly just "if people need it". So well, at some point that might be everything.

That seems reasonable enough. I guess what I'm wondering then is whether you mind if I just create PRs for the various frameworks as I'm able to run them through the translator and figure out what needs to be skipped for now. I think the more that is available in the crate, the more likely it might be that someone will actually use it, rather than asking for it to be supported. That also seems to provide more opportunity to figure out ways the tooling and translation process can be improved, as issues are encountered.

I'm still unsure! Ideally, I'd like to integrate with the rest of the ecosystem, and use crates like core-foundation and core-graphics; but on the other hand, when auto-generating stuff, everything from a framework needs to be available for us to be able to use it; so I suspect it will still need a lot of manual fixes, and then it might just be better to re-implement it (which also gives us the benefit of getting availability attributes on those frameworks, and other improvements that might come to icrate).

Yeah... I think integration would also be nice but I'm also not sure how practical it will be to coordinate given those observations.

I'm considering redoing header-translator the "proper" way, which is to use the existing code that Swift uses, see #345 - so possibly CoreFoundation-like structs will only happen after that.

That sounds like a really cool idea actually!

[madsmtm]

That seems reasonable enough. I guess what I'm wondering then is whether you mind if I just create PRs for the various frameworks as I'm able to run them through the translator and figure out what needs to be skipped for now. I think the more that is available in the crate, the more likely it might be that someone will actually use it, rather than asking for it to be supported. That also seems to provide more opportunity to figure out ways the tooling and translation process can be improved, as issues are encountered.

Hmm, I think I'd like to get iOS up n' running first, since we'll probably need to do a lot of manual fixes there, and the less frameworks we have that we have to do it for, the easier that task will be.

But then again, the work has to be done at some point anyhow, so I'd probably merge your PRs if you do it.

I'm considering redoing header-translator the "proper" way, which is to use the existing code that Swift uses, see #345 - so possibly CoreFoundation-like structs will only happen after that.

That sounds like a really cool idea actually!

Yeah, and also quite daunting since I know so little C++ 😁

---

Relatedly, I'm feeling a tinge of burnout, so I'll probably try to do something other than objc2 (or just not touch my computer at all) for the next few days, so if I'm a bit slow to answer that's why ;)