Disclaimer: I work on Vello[0], but not on the Skia integration directly
My understanding, having not dug into it too much, is that the Skia integration does exist, but isn't enabled by default/any clients at the moment. That is, I don't know that this integration is shipping anywhere.
Vello still has some definite rough edges at the moment, so I'm not sure I'd recommend using it in a production application at the moment. We also don't have a C API, which might rule it out for some cases where you'd be considering Skia.
WGSL (the shading language for WebGPU) has something similar[1].
For example, `a + b << c` will fail to parse in a conforming implementation, as will `a << b << c` and `a && b || c`. Note however that `a && b && c` does parse. I find these rules to be well-thought through.
> From a Rust-on-WASM perspective, it might be useful to limit the entity id's to ~52 bits or less, since native JavaScript numbers are doubles.
Since compiling to web uses WebAssembly, we can just use native 64 bit integers for our entities. In general, we avoid introducing differences between web and native targets, and this is no exception.
If you do need to round-trip full entities using JavaScript, you should either store them in one of the native non-broken integer types (such as `BigInt` or `BigUint64Array`), or just store the `index` and `generation` as seperate `number`s. It's worth recognising that in most cases, you should only need to exchange the entity `id` with different systems, as the `generation` is mainly used to panic on use-after-free conditions.
In unfamiliar UIs, I often find myself accidentally triggering keyboard shortcuts and getting into weird states, so 1) leading to 2). A classic example is changing into override mode[0] in Microsoft Word or similar[1].
You end up in a mode where typing no longer adds characters, but replaces them. If you're at the end of the document, it would still add characers, but you stay in override mode. Meaning that once you're in this mode, it doesn't strike until you start editing or try to fix a typo, when the computer. WordPad doesn't even have any visual distinction.
Visual Studio Code's solution to this is nice. If you enter `Tab Moves Focus` mode, with <kbd>Ctrl</kbd>+<kbd>M</kbd>, the info bar shows the text `Tab Moves Focus` in a (tastefully) highlighted button, clicking which disables that mode. So you will have a moment of confusion upon pressing tab, inadvertently entering the mode, however the situation of 2) is avoided as a helping hand is visible.
Perhaps another UI is to have a log of activated keyboard shortcuts always visible, with 'new' shortcuts highlighted more obviously (perhaps with some estimation of decaying familiarity). I'm not familiar with this being implemented anywhere, but I think it at least merits consideration.
[0] This is activated with <kbd>Insert</kbd>; https://en.wikipedia.org/wiki/Insert_key
[1] In the version of Word I currently have installed, this behaviour seems to be disabled/removed. However, Wordpad still changes into override mode upon pressing Insert.
To copy from another comment[0] elsewhere in the thread from cart:
> The story is similar for networking. Ultimately we will have a built in api, but we're focused on more fundamental things at the moment. There are _tons_ of community-developed networking plugins though: https://bevyengine.org/assets/#networking
That is, we do definitely want to make multiplayer work properly, and our data design should give us inherent advantages here. But it hasn't been a priority so far, as we've had other more pressing requirements (e.g. animation this release).
But a lot of what you want should in the medium term be provided by external crates; our use of systems as the unit of logic should make this viable, as behaviour implemented by the engine is not special. These external crates could potentially be made official if that made sense, but that's for much longer time scales.
Yes, indeed. This was mentioned in 0.6's release notes[0]. However, this is the first actual stop of the train, so we probably could have mentioned it in these release notes as well.
A change I find interesting in this release is the addition of `Deref`/`DerefMut` derives[0]. It addresses a very real pain point in bevy, due to `#[derive(Component)]`'s interaction with the orphan rules requiring newtypes[^1].
But it's potentially not idiomatic within the Rust language, at least at the moment (as mentioned in the OP). However, I think that the tide is likely to turn on that; for example, in the api-guidelines repo, there's a PR[2] to remove this advice. This appears to have stalled, although that appears to be not for reasons of it being controversial, just lack of reviews; the discussion had broad support.
We have discussed (in Discord[3]) a kind of 'internal' `Deref`, which would use lenses to do automatic unwrapping for queries. See #4413 [4] for an example of what this would look like. I'm not sure how necessary that is if we can just use `Deref[Mut]`, but it's definitely another angle we could go down long-term.
I don't think this is actually a problem, since when casting from `&mut T` to `*mut T`, the returned pointer can only access the data (the T value) directly behind the reference.
The raw pointer would be synthesised with the capability for only the pointee of the original reference.
One potential option I haven't seen mentioned is to make references (i.e. `&[mut] T`) not use capabilities, but raw pointers (`*(mut|const)`) to use capabilities. Since the compiler already guarantees that references are used correctly, at least theoretically this is best of all worlds.
Now it's possible that CHERI would make this impossible, but it's definitely an angle worth recognising.
I can't speak for cart here, but from my perspective as a contributor to `bevy`, it's extremely useful having freedom from backwards compatibility concerns to improve our APIs.
For example, we want to rework our input handling, asset handling and UI; supporting this current UI solution indefinitely would be frustrating when we hope to make something much better once we can focus on that. As an example of this, we massively changed our rendering APIs for this release, allowing the improvements listed in the blog post to be implemented.
You can either use rust-analyzer[1] (for which vscode is most well supported), or IntelliJ Rust [2]. Personally, I use `rust-analyzer` with vscode as a bevy developer.
My understanding, having not dug into it too much, is that the Skia integration does exist, but isn't enabled by default/any clients at the moment. That is, I don't know that this integration is shipping anywhere.
Vello still has some definite rough edges at the moment, so I'm not sure I'd recommend using it in a production application at the moment. We also don't have a C API, which might rule it out for some cases where you'd be considering Skia.
[0]: https://linebender.org/blog/xilem-2024/