Conversation
…ion in Scroll, improved documentation Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
refactored scroll.rs Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
… to make it more efficient Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
maan2003
left a comment
There was a problem hiding this comment.
Some minor nits for now. haven't carefully reviewed default_scroll_to_view_handling logic yet. hope to get that done tomorrow
|
On Desktop this should be fine, but it probably will cause problems on mobile. For an example focusing a textbox, will first update the scroll positions and then request the virtual-keyboard, which results in a layout change and therefore the text box is might be hidden again. |
|
I think the fundamental problem is "the focused should stay in view" or "the focused widget should come in view once". maybe Scroll widget keeps track of a "focused" rect that will stay in view unless manually scroll away |
|
for this PR, I would just add |
|
Ok |
- show scrollbar when clip is moved Signed-off-by: Christoph <xarvix@web.de>
A focused region that stays in in view until scrolled away sounds good, but i think keeping the rect wont be enough. If we have a two |
Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
Signed-off-by: Christoph <xarvix@web.de>
Co-authored-by: Manmeet Maan <49202620+Maan2003@users.noreply.github.com>
This PR adds the
scroll_to_viewandscroll_area_to_viewmethods toUpdateCtx,LifecycleCtxandEventCtx, which can be used to bring specific parts of a widget into view.There are still some things to discuss:
UpdateCtxorLifecycleCtx, but i am not sure this is the right way to do it.supress_warningsflag in Notification?