@gbutler69 Good idea, but I think the library is simply too young for contributors. I've often seen it that young libraries create issues, then random people join in, then the dicussion gets bogged down in details and in the end, nobody writes any code. I've seen it happen so often, I think I'll have to do it alone, at least for the 0.1 version. Most of the concepts may look good in discussions, but then in practice they don't work well and I'm faster experimenting with this on my own than explaining what I mean to a different person.
Ex. I plan to implement animatable / dynamic properties using a special CSS syntax like:
#my_div {
width: {{my_custom_id | 400}}px;
}
and then:
get_dom() { dom.window[window_id].css.set_animatable_property("my_custom_id", 300); }
(400px being the default, 300 px set by the Rust code, avoids re-parsing the CSS + webrender has special APIs for dynamic properties). But caching all that, implementing the webrender bindings, generating hit IDs / implementing that into the callback model... it simply takes experimentation. I have a rough idea of how I can solve it, and I think it'll work this way, but I couldn't really explain someone how to exactly code it.
There are issues unrelated to the code that would be great to be resolved - ex. the windows-gnu target doesn't build because of a cmake error in a dependency. And the code coverage is displayed as 0% because codecov has a bug and coveralls doesn't work at all, no matter what I try. That would be good issues to help out with...
@doomy Contributions are great, but I am a bit hesistant to accept PRs before 0.1 - I don't want anyone to waste their time with a possibly vaporware project. It's just that the library changes so quickly right now that I simply need to experiment with what works / what doesn't. After 0.1 - yeah, I'll happily accept PRs, because then people can somewhat see a certain architecture, then it'll mostly be about fixing bugs. I don't think the API will change much after 0.1, it'll mostly be bug fixes.
As for financial support - I don't really need money. If this library ever hits 0.1 I will have a product that uses this library. Maps4Print is my company, so if I can get this library done, I'll have more money than I could ever get from patreon, because then I'll have an actual product to sell. So that's what'll keep this library financially afloat (post-0.1). I've made this library for a specific purpose, not as a hobby project.
A large problem I see with many GUI libraries is that their authors don't use them. They just create them, theorize about a hypothetical API that works in isolation, but don't try to build a non-Hello-World product in it. Ex. Epic Games used their own engine to create games first and the success of these games then made the engine popular. Because they could show people: hey, you can actually build something large in this. So I'd first like to be sure that you can do that (build a maintainable product) before I go out and ask them to contribute.
As for a time limit... hopefully before October / November this year. If I'm not done by then, I'll probably have another job and you can consider the project dead. Or fork it or whatever. But right now I don't think I'll need that long to release 0.1.
)
:
