Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap: 0.1 release #14

Closed
5 of 9 tasks
dhardy opened this issue Nov 26, 2019 · 8 comments
Closed
5 of 9 tasks

Roadmap: 0.1 release #14

dhardy opened this issue Nov 26, 2019 · 8 comments

Comments

@dhardy
Copy link
Collaborator

dhardy commented Nov 26, 2019

A priority list for making a somewhat usable release:

@nilsmartel
Copy link

I really like this roadmap.
However, you might keep kas as simple and possible and move the implementation of widgets into another crate.

This might encourage developers to contribute to both crates and other than that spawn a whole ecosystem of widgets. (or at least encourage this)

Just a thought. Keep up the great work

@dhardy
Copy link
Collaborator Author

dhardy commented Nov 26, 2019

Hey, thanks for the comment; I believe you're the first to do so on this repo!

Moving widget implementations into a separate crate should be easy given that these are already in a dedicated sub-module, however KAS is not yet close to API stability (for internals), thus co-versioning of the crates would be required. Given that, is there any point (yet)?

Actually, "custom widgets" is already on this road-map, which should go some way to ensuring a usable API for this.

@nilsmartel
Copy link

Glad I've commented then, this is an honor for KAS surely will have an interesting future.

I mainly commented because I've felt this would be a great opportunity to leverage rusts ecosystem and have a less 'monolithic' (probably using this word slightly wrong) approach at Crate design.
Though I myself don't have experience publishing own crates yet.

API instability is a good argument against this. Having two different crates would slow down development and might even discourage putting the effort in.
In question is if one can refactor widgets when the 1.0 release comes, without causing too much chaos in (then) existing projects.

I think one can mark functions as depreciated, which then might be the right move.

looking forward to seeing how kas will grow

@dhardy
Copy link
Collaborator Author

dhardy commented Nov 28, 2019

With the rand* libs we went with a multi-crate approach; it does have certain advantages (separation of APIs, modular with-respect-to replaceable implementations, stabilising components independently). There is definitely reason to do this with some of KAS too, e.g. the kas-wgpu component should be replaceable (perhaps for better integration on some platforms, or integration within a game), and the layout code may become a re-usable component (in other GUI libs). I'm less sure about the widgets though; these are quite tightly integrated with the core library.

@dhardy
Copy link
Collaborator Author

dhardy commented Dec 3, 2019

In the interests of an earlier release, I am considering postponing non-trivial items (e.g. custom widgets and dynamic layouts).

@dhardy
Copy link
Collaborator Author

dhardy commented Dec 7, 2019

Custom widgets will now be in this release. In fact there should be nothing special about the included widgets, aside from a limited and specialised drawing API (to be improved in a later release). This would allow an external widget crate as @sombrastudios suggested although I'm still not convinced such a micro-crate approach is valuable.

Dynamic widgets may be included too if the recent trait redesign does not get in the way. Some other items on the list might be dropped due to time limits.

After this release I will make some effort to facilitate community contribution and likely switch to making changes via PR.

@dhardy
Copy link
Collaborator Author

dhardy commented Dec 17, 2019

Pre-release 0.1.0-pre-1 is out.

At this point the main blockers to a 0.1 release is testing. The remaining items above likely will not make 0.1.0.

@dhardy
Copy link
Collaborator Author

dhardy commented Dec 22, 2019

Version 0.1.0 is published.

The remaining items are not considered worth blocking the release on. The multi-window example should already be possible (although event-triggered creation is not: #28).

@dhardy dhardy closed this as completed Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants