<NOTE> Active fork libui-ng

[enderger]

This project appears to be inactive. Due to this, a fork exists at https://github.com/libui-ng/libui-ng. Due to the fact that network doesn't appear to show this and the fact that linking in a PR would likely prove fruitless, I've created this issue to hopefully aid in documenting its existence.

[marcotrosi]

I'm watching libui for years now, and I knew that this would happen someday.
Of course it would have been nice to see the original creator working on it. But we all have our priorities due to whatever circumstances, and this is for sure nobody else's business. But libui is also one of the most important projects on Github and that's why I knew that someday someone will fork it and continue working on it. Also the 4 years in which nothing happened shows that everyone hoped to have Pietro back working on it. So the community waited patiently until the need for libui became too big. And here we are now and I'm glad that @cody271 is the one. This increases the chances of continuing the project with the same or a similar vision. I wish you all the best @cody271 and I think the project is in good hands.

[andlabs]

There was activity in the past 4 years, just not on the main branch.

It's a good thing I came to open an issue here, because I have been wanting to work on this again, but the pandemic absolutely drained me and work has started to kick taking my time back into overdrive.

But things have happened that have re-ignited my interest in working on the project again. I might actually start to do things later.

In the meantime we'll see how this goes; good luck. The reason it does not show up in the Github network is because it's not an explicit fork, but rather a new repository.

[AndyObtiva]

@andlabs It's good to hear back from you. One recommendation I have to beat time management issues is to simply split releases into much smaller chunks. For example, if you add support for displaying an image under an area for Windows, Mac, and Linux, then release right away as alpha5 (or alpha 4.2). Afterwards, if you add support for triggering events when clicking table columns (e.g. for sorting) on Windows, Mac, and Linux, again, release immediately as a very tiny alpha6 (or alpha 4.3) release. Sure, you will end up with a lot of mini releases, but this will ensure that any efforts you undertake are very small and managable no matter your work schedule, and you also ensure that consumers of the project continue to receive value from the project via small releases even if you end up with very little time to work on the project. This is the process I followed while building Glimmer DSL for LibUI in Ruby by the way. I documented my process as the Glimmer Process, which is inspired by Toyota lean manufacturing processes, like Kanban. In any case, I look forward to your continued support of libui. Glimmer DSL for LibUI won a Fukuoka Ruby 2022 Special Award from the creator of Ruby himself and the Fukuoka Ruby committee as they were truly impressed by libui in addition to the Glimmer DSL for LibUI high-level Ruby binding. I'm sure they'd appreciate libui's continued progress going forward, in addition to other consumers of the project who would benefit from its continued support too!

[rubyFeedback]

That is the power of forks - people can continue (ok, they need to have kowledge of things, e. g. different platforms perhaps, C, C++, Go or any other "low" level language and what not). People come, people go, it happens, no problem really. Take hisham (https://github.com/hishamhm) who bootstrapped GoboLinux and htop. Eventually he no longer had time due to other priorities and htop was forked. He still maintains the lua-specific parts like LuaRocks and I think they also work on some new programming language. Priorities shift over time. It happens.

If you ever decide to update some code, if you can and if it is not too much work perhaps it can be synced or notified with libui-ng and vice versa. I guess most people are happy with the original idea behind libui, even if libui-ng may (possibly?) not have 100% identical use cases, but people would still appreciate any enhancements, no matter if in libui, libui-ng or any other projects with a similar focus. The cross-platform idea was really good. Hopefully people can also think about some minor enhancements; font handling is still a gripe I have. :D