-
Notifications
You must be signed in to change notification settings - Fork 10
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
buffer does not update while widget is focused, other CosmicEditBundle
components lag without input
#145
Comments
if we want to maintain the invariant that focused widgets cannot be modified, we can emulate a lock with components/events to give consumers a chance to react to an imminent focused widget before the focus is applied although i would rather just allow the buffer to be modified 😅 |
Yeah currently the "focused" buffer is separate to the editor buffer (borrow checker skill issue reasons lol) and keeping them synchronised currently only works one-way, on unfocus. Guess I didn't have programmatic editing of a focused editor buffer in mind when I designed around the 0.11 version of In an ideal world the editor would work directly on the buffer contained in the bevy entity rather than cloning it. It seems like Making this change would simplify a whole lot of the code in this plugin! If you wanna have a look, the offending line is Line 37 in 4066c69
If that clone could become a mutable borrow or an This change would also fix #138, which I think is caused by the same underlying issue |
Tested the repro in the linked PR, seems to work :) On closer inspection, background works when focused, but changing text still only works unfocused 🤔 |
repro, modifying the
basic_ui
exampleclicking or pressing enter does not change the text to "Bananas" with a black color
additionally, clicking or pressing does change the fill color to grey, but only after a second or two, unless one adds some mouse clicking/dragging
both these behaviors disappear when the widget is unfocused (e.g. by pressing escape), and the buffer and fill color update as expected
this is problematic for consumers that react to the
FocusedWidget
resource to modify the state of the widget, e.g. if one wants to modify the text/fill color of a just focused widget, they can't because that would require knowing which widget were focused beforeresource_changed::<FocusedWidget>
could be reacted to, at which point the target widget is already focused and can't be modifiedThe text was updated successfully, but these errors were encountered: