egui
rand
egui | rand | |
---|---|---|
3 | 29 | |
1 | 1,578 | |
- | 1.1% | |
0.0 | 8.3 | |
29 days ago | 7 days ago | |
Rust | Rust | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
egui
-
Why Rust?
Anyone who's interested in the AccessKit integration can play with my work-in-progress branch: https://github.com/mwcampbell/egui/tree/accesskit
It's currently Windows-only, and I'm working on the big missing feature, which is text editing support.
-
UIs are not pure functions of the model
> A core premise of Cocoa, and MVC in general, is that UIs are a projection of data into a different form of data, specifically bits on a screen.
This is a tangent, but the implicit assumption that the UI is visual is just begging for a response from an accessibility perspective, so here goes.
Accessibility is very much an afterthought in native GUIs, not only in Cocoa, but also in Windows with the UI Automation API, and AFAIK with other native accessibility APIs as well. With these APIs, the assistive technology (e.g. screen reader) pulls information from the application (usually via the GUI toolkit), through repeated calls to methods defined by the accessibility API. Often the AT has to do several such calls in a row (and those often translate to multiple IPC round trips, making things slow). And the UI might change between such calls; there's no guaranteed way to get a consistent snapshot of the whole thing, as there is with a visual frame. On the application/toolkit side, these methods may return different responses from one call to the next, and the application or toolkit has to fire the right events when things change.
The web improves on this, in that accessibility information is conveyed through HTML tags and attributes. And yes, this is included in the output of a React component's render function. So while in practice, implementing accessibility may still be an afterthought, it's not an architectural afterthought as it is in native platforms.
One of my goals in AccessKit [1] is to work around this shortcoming of native accessibility APIs, particularly for developers of cross-platform non-web GUI toolkits. In AccessKit, the toolkit pushes a full or incremental accessibility tree update to the AccessKit platform adapter, which maintains the full tree in memory and uses that to implement the platform accessibility API. This even works for immediate-mode GUIs, as one can see in my proof-of-concept integration with the Rust egui toolkit [2].
[1]: https://github.com/AccessKit/accesskit
[2]: https://github.com/mwcampbell/egui/tree/accesskit
-
Raygui – A simple and easy-to-use immediate-mode GUI library
I can also report some modest progress on my own work on accessibility of immediate-mode GUIs. I have a branch of the Rust egui library [1] that has basic accessibility on Windows using my AccessKit project [2]. I do have a long way to go to make this fully usable and ready to submit upstream, especially when taking non-Windows platforms into account.
[1]: https://github.com/mwcampbell/egui/tree/accesskit
[2]: https://github.com/AccessKit/accesskit
rand
-
We have getrandom at home
Making compatibility promises for distributions means they cannot take advantage of potential advancements in the field.
-
Blog Post: On Random Numbers
Defining an error type that is meaningful, portable, and compatible with no-std isn't straightforward. If the std lib's getrandom requires std, then just like that, rand and many other crates won't use it anyway. Using io::Result seems to me to face this challenge.
-
Hey Rustaceans! Got a question? Ask here (52/2022)!
Some wasm targets can’t generate random numbers at all but in the case of the book because you are using wasm in a browser you can use JS to generate random numbers. I believe there’s a way to get the rand crate to use JS as the backend for generating rand but its a bit more convoluted than the easy one-liner that the book suggests.
- Data-driven performance optimization with Rust and Miri
-
What crates are considered as de-facto standard?
rand
- Why Rust?
-
[Media] Nebulabrot rendered with Rust — Explanations in the comments
This uses rand and xcomplex to handle the mathematics, png to write image files, and dialoguer and indicatif for some pretty prompts and progress bars.
-
Do you ever use unsafe { .. } when not implementing custom data structures or interacting with external C code?
You can often achieve this without any unsafe by putting an assert!() on the length before the hot loop. For example, I got rid of some unsafe in rand that way.
-
Original source of `(seed * 9301 and 49297) % 233280` random algorithm?
This is a widely used method to map random integers to floating point numbers, but it has the disadvantage of wasting 1 bit of float mantissa precision.
On modern CPUs, its computational advantage over full-precision mapping methods, such as multiplication by a float, is not always clear [1].
[1] https://github.com/rust-random/rand/issues/416
-
Any plans for built-in support of Vec2/Vec3/Vec4 in Rust?
In fact, there are a lot of crates in Rust where in other programming languages, it would be included in the standard library. Examples are regex, random number generators, additional iterator methods, macros for other collections, num traits, loggers, HTTP libraries, error handling, async runtimes, serialization and deserialization, date and time, and many more.