Update to bevy 0.15 (& 3D support)

[ActuallyHappening]

I'm working on a PR

[ActuallyHappening]

I have a few questions about the current design.

1. Do we need the CosmicSource component? Whats wrong with requiring that the CosmicBuffer component be on the same entity that renders the associated Handle<Image>?
2. I want to generalize the input gathering (hover, click Vec2) and output rendering so that I can implement 3D support, either builtin or as a plugin
3. Using required components, I think it simple to seperate out mentioning Sprite in the CosmicEditBundle

I would like my associated PR #166 to cover all these goals, but that's mostly because I'm not productive (or confident) with maintaining more than one git branch to seperately address each individual problem. I'll talk more here after I've actually implemented the MVP for bevy 0.15 though

[ActuallyHappening]

As bevy 0.15 is a breaking update I don't think me making some 'minor' (subjective) design changes is too extreme, but I wanted to hear from other people consuming / maintaining this library before I go and stomp on existing design decisions that may be important to others

[ActuallyHappening]

My current API prototype:

let sprite_edit = (
Sprite,
CosmicEditBuffer::new_foo(),
);
let ui_edit = (
ImageNode::default(), // these two bevy builtin components may be squashed in some cosmic_edit 
Button, // specific type like maybe `TextEdit` to mirror `bevy::ui::Text`
CosmicEditBuffer::new_bar(),
);
// idk yet
let 3d_edit = (
Mesh3d::new_plane(), // will work out a way of rendering in 3d
CosmicEditBuffer::new_baz(),
);

I think the CosmicEditBuffer (renamed from CosmicBuffer as bevy::text::CosmicBuffer now exists) should be able to be placed anyway, and its output is automatically transfered (i.e. Handle<Image> is copied ideally once) to any supporting output scheme, including Sprite for 2d and ImageNode for UI (btw which is new in 0.15)

[Dimchikkk]

Sorry I don't have much capacity to look into it right now but I am open to any refactorings.

3d support is really great to bring... I think we already tried it in the past: #104 :)

[ActuallyHappening]

Yeah I briefly saw that old PR, I'm only interested in plane 3D geometry plus bevy::picking is now builtin so raycasting should be a lot easier

[ActuallyHappening]

Whats the difference between CosmicEditor and CosmicBuffer in terms of ECS semantics?
Should all Buffers have an editor? Is Editor an optional extra component? Is editor only on the focussed Buffer? I can't tell @Dimchikkk from what documentation I've seen in the source code, but I may be missing something

[Dimchikkk]

There were couple of refactorings so I don't really remember ECS semantics but how I see it:

cosmic-text has 2 main abstractions:

• buffer : read-only
• editor (wrapper around buffer) : read/write

It corresponds to CosmicBuffer and CosmicEditor wrappers around cosmic-text abstractions.

So, if user wants to create read-only text it makes sense to use buffer, if user wants to have text input - editor. Focused editor/buffer is another thing afaik... imagine user have 2 editors and 2 buffers... focused can be only one editor/buffer so user can type/select text only from one editor/buffer at time. Not sure it helps, not sure it is accurate :)

[ActuallyHappening]

Ahh OK that helps a lot thanks

[ActuallyHappening]

Yes, the Editor component is only on focussed buffers as I suspected

[ActuallyHappening]

Can we get a publish? We can remove TODO.md and the bevy_editor_pls dev dependencies if thats holding it back

[Dimchikkk]

Can we get a publish? We can remove TODO.md and the bevy_editor_pls dev dependencies if thats holding it back

published