rust-native-ui / libui-rs

Rust bindings to the minimalist, native, cross-platform UI toolkit `libui`
Apache License 2.0
926 stars 74 forks source link

Is this project still under development? #116

Open TapGhoul opened 2 years ago

TapGhoul commented 2 years ago

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 commented 2 years ago

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

TapGhoul commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

NoraCodes commented 2 years ago

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

cody271 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

ghost commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

NoraCodes commented 1 year ago

@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 commented 1 year ago

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 commented 11 months ago

@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?

nptr commented 11 months ago

@Abrahamh08 Nothing at the moment. I pass the responsibility to the user instead. It's a tradeoff to have a clean interface.