Is this project still under development?

[TapGhoul]

This project hasn't had a commit for over a year, and the 0.3.0 release is more than 2 years behind trunk at time of writing (0.3.0 in 14 jun 2018, trunk at 9 aug 2020). What's the status of this project?
It looks promising, but with the large gap between a release and a crates.io update (or even github marked release), it's hard to justify using this at current without some idea of how future maintenance is going to be handled, if any.

[NoraCodes]

Development on this repo is awaiting further development on the upstream (libui).

[TapGhoul]

Any specific issues that are being tracked on upstream that I can watch? I can't find anything in issues for this repo (or I may have missed something) that shows what's being waited on.

[NoraCodes]

The specific issues in question are around the memory model and the lack of a lot of useful - even necessary - components. In addition, the original reason I paused development is that the upstream promised an "overhaul" of the API, meaning any work done today would have to be redone in the future anyway.

Given that development on the upstream has been dormant for so long, we could potentially look into making a 0.4 release without an overhauled ownership model on this end, although there remain some serious bugs that we would need to find a way to resolve.

[enderger]

It appears as though some people have forked libui, see https://github.com/libui-ng/libui-ng

[NoraCodes]

That's very good to know, thank you! I'll look into adapting our -sys crate to use one of these forks.

[cody271]

That's very good to know, thank you! I'll look into adapting our -sys crate to use one of these forks.

There is already a -sys crate for the new fork here: libui-ng-sys. Although I don't know if its compatible.

[nptr]

libui-ng can be used pretty much as drop-in replacement. I did so for my fork. No libui-ng-sys crate necessary. If this library gets some attention again I'd be happy to provide some of my changes.

[NoraCodes]

That's really nice work, @nptr. As it looks like libui-ng is actually maintained, I'd love to chat some time later this month (when I'll be off work) to see about merging that back into this repo and see what we can do around scrollable views and better controls management!

[nptr]

Great! Until then I'll line up the most basic and uncontroversial changes in self-contained PRs. The rest can be on pick and choose basis after deliberation I'd say. It's not too much anyways, mostly quick wins.

Hi! I've been maintaining libui-ng-sys. Let me know if I can help with anything, too. I think ui-sys/iui seems a more complete UI solution than libui-ng-sys/boing (the safe analogue to libui-ng-sys), so I'd love to see it receive support for libui-ng.

[nptr]

@NoraCodes, I hope you had a restful holiday.
As you may have seen, I lined up a few PRs (#121, #122, #123). Especially the libui-ng one would serve as basis for further work. Do you have any feedback on them yet?

[Tim-Paik]

Great crates! Hope to see libui-ng merged to trunk and release 0.4!

[NoraCodes]

@nptr unfortunately, as you say in #121, AppVeyor is currently broken. Therefore I am waiting on the delivery of a Windows 10 machine from my old house to test things manually for your larger PR. However, having reviewed it over the break, it looks great and I really appreciate your help.

I will also try to fix AppVeyor, but it's a race to see which happens first :)

[nptr]

Good to hear. Personally I'd like to see a quick 0.4.0 with libui-ng and some of its new features added to this rust wrapper. Which is what I am working on in my fork at the moment. Then, a 0.5.0 with an API change where the UI context argument is removed from most of the calls. It should be possible although I haven't really tried. But that is for another day.

[Abrahamh08]

@nptr What are you using to ensure that everything is done on the main thread, since you removed passing the ui context to most of the calls as a token?