a11y: implement new SemanticsAction "showOnScreen" #11135
Conversation
goderbauer
force-pushed
the
showOnScreen2
branch
from
f576faf to
9864898
Compare
| @@ -11,6 +11,8 @@ import 'package:flutter/painting.dart'; | |||
| import 'package:vector_math/vector_math_64.dart'; | |||
|
|
|||
| import 'node.dart'; | |||
| import 'object.dart'; | |||
| import 'viewport.dart'; | |||
There was a problem hiding this comment.
we can't import viewport.dart here. That's a layering violation.
The rendering library has several layers. At the bottom is object.dart, layer.dart, node.dart, semantics.dart -- features that are coordinate system agnostic.
Below that we have RenderSliver, RenderBox, and the like, which know about coordinate systems but are agnostic to specific layout algorithms.
Below that we have things like flex.dart, proxy_box.dart, the various slivers, etc. They introduce specific opinions about layout and paint and so on.
There was a problem hiding this comment.
Can you document this extended layer cake somewhere so people can refer to it? According to the layer cake in https://flutter.io/technical-overview/ this is all in the same layer.
There was a problem hiding this comment.
Sure, feel free to copy-paste the above into a README or object.dart or whatever. Not sure where it should go.
Sorry it wasn't written down before, it kind of grew organically in Adam and I's head.
FWIW, the other libraries have similar inner layers, e.g. widget has framework.dart at the base, with basic.dart on top, and everything else on top of that. In theory, anyway; that one has some cross-talk currently via debug.dart.
Fundamentally though this is just a manifestation of the more concrete best practice of avoiding reference cycles. It's a general truism that a good architecture has a dependency graph that's a DAG, with the units being as small as possible (ideally much smaller than 1000 lines of Dart, based on our experience so far). Cycles usually indicate a bug factory. Files larger than 1000 lines usually indicate a bug factory. (And yes, we have plenty of bug factories, unfortunately. We should try to minimise them.) This is one reason we stopped using part, it encourages designs that turn into bug factories.
I've considered trying to enforce our dependency graph being a DAG. We do enforce it at the library level now (e.g. widgets can't depend on material). I suspect that enforcing it at the library level today would involve a few weeks of disentangling. cc @a14n in case you're interested in creating a lint for this. :-)
goderbauer
added
the
a: accessibility
This action is triggered when the user swipes (in accessibility mode) to the last visible item of a scrollable list to bring that item fully on screen.
This requires engine rolled to flutter/engine#3856.
I am in the process of adding tests, but I'd like to get early feedback to see if this approach is OK.