1. 20 Nov, 2019 1 commit
  2. 18 Nov, 2019 1 commit
    • Greg Spencer's avatar
      Add command key bindings to macOS text editing and fix selection. (#44130) · 21158d83
      Greg Spencer authored
      This adds support for the command key for text selection/editing on macOS. I had ported the text editing code (in #42879), but forgot to add support for the command key itself. This also adds a test that tests the text editing on multiple platforms instead of just testing Android.
      
      There appears to still be a bug (filed #44135) where we're losing key events sometimes on macOS, leaving some keys "stuck" on, but this PR at least allows the right key combinations to be used.
      21158d83
  3. 16 Nov, 2019 1 commit
  4. 15 Nov, 2019 1 commit
  5. 14 Nov, 2019 1 commit
  6. 13 Nov, 2019 1 commit
  7. 11 Nov, 2019 1 commit
  8. 05 Nov, 2019 1 commit
  9. 28 Oct, 2019 1 commit
  10. 18 Oct, 2019 1 commit
  11. 17 Oct, 2019 2 commits
    • Jaumard's avatar
    • Greg Spencer's avatar
      Re-implement hardware keyboard text selection. (#42879) · a7aa6616
      Greg Spencer authored
      This re-implements keyboard text selection so that it will work on platforms other than Android (e.g. macOS, Linux, etc.).
      
      Also, fixed a number of bugs in editing selection via a hardware keyboard (unable to select backwards, incorrect conversion to ASCII when cutting to clipboard, lack of support for CTRL-SHIFT-ARROW word selection, etc.).
      
      Did not address the keyboard locale issues that remain, or add platform specific switches for the bindings. All that will need some more design work before implementing them.
      
      Related Issues
      Fixes #31951
      a7aa6616
  12. 15 Oct, 2019 2 commits
  13. 10 Oct, 2019 1 commit
  14. 09 Oct, 2019 2 commits
    • Greg Spencer's avatar
      Enables setting of semantics focused and focusable attributes within Focus widgets. (#41814) · 89d6c8d9
      Greg Spencer authored
      This adds a Semantics node to the Focus and FocusScope widgets, setting the focused and focusable attributes so that the accessibility subsystem can be told when a control has the input focus.
      
      Includes an engine roll to flutter/engine@77252d2, and the following 8 engine changes:
      
      flutter/engine@77252d2 Greg Spencer Add missing focusable testing info (flutter/engine#13013)
      flutter/engine@0e42a29 skia-flutter-.. Roll src/third_party/skia 54548626a977..e27a503a0a21 (1 commits) (flutter/engine#13024)
      flutter/engine@6b56ed7 gaaclarke Refactor: FlutterDartProject (flutter/engine#13006)
      flutter/engine@393480c skia-flutter-.. Roll src/third_party/skia 77dde599c98a..54548626a977 (1 commits) (flutter/engine#13023)
      flutter/engine@080b89d skia-flutter-.. Roll src/third_party/skia 2b1a25a4d324..77dde599c98a (1 commits) (flutter/engine#13021)
      flutter/engine@90b0f30 Ben Konyi Roll src/third_party/dart f4a72bfc64..bb04f145b2 (18 commits) (flutter/engine#13020)
      flutter/engine@049fb89 skia-flutter-.. Roll fuchsia/sdk/core/linux-amd64 from q_uYX... to cknsi... (flutter/engine#13019)
      flutter/engine@6925b2a skia-flutter-.. Roll fuchsia/sdk/core/mac-amd64 from wuAtw... to u0JpE... (flutter/engine#13018)
      
      Related Issues
      Addresses #40101
      
      Landing on red in order to fix the build: it's red because of the needed engine roll.
      89d6c8d9
    • Kate Lovett's avatar
      Incorporating Link Semantics (#41327) · 1ec44a0c
      Kate Lovett authored
      1ec44a0c
  15. 08 Oct, 2019 1 commit
  16. 02 Oct, 2019 1 commit
  17. 30 Sep, 2019 1 commit
  18. 28 Sep, 2019 1 commit
  19. 27 Sep, 2019 1 commit
  20. 26 Sep, 2019 1 commit
    • Greg Spencer's avatar
      Fix mouse hover to not schedule a frame for every mouse move. (#41014) · 05097916
      Greg Spencer authored
      This fixes the mouse hover code to not schedule frames with every mouse move.
      
      Before this, it would schedule a post frame callback, and then schedule a frame immediately, even if there was nothing that needed to be updated. Now it will schedule checks for mouse position updates synchronously, unless there's a new annotation, and skip scheduling a new frame in all cases. It has to be async in the case of a new annotation (i.e. a new MouseRegion is added), since when the annotation is added, it hasn't yet painted, and it can't hit test against the new layer until after the paint, so in that case it schedules a post frame callback, but since it's already building a frame when it does that, it doesn't need to schedule a frame.
      
      The code also used to do mouse position checks for all mice if only one mouse changed position. I fixed this part too, so that it will only check position for the mouse that changed.
      05097916
  21. 24 Sep, 2019 3 commits
  22. 19 Sep, 2019 1 commit
  23. 18 Sep, 2019 1 commit
  24. 17 Sep, 2019 3 commits
  25. 16 Sep, 2019 1 commit
  26. 10 Sep, 2019 1 commit
  27. 06 Sep, 2019 1 commit
  28. 03 Sep, 2019 2 commits
  29. 29 Aug, 2019 1 commit
  30. 26 Aug, 2019 1 commit
  31. 23 Aug, 2019 1 commit
    • Greg Spencer's avatar
      Normalize assert checking of clipBehavior (#38568) · 365f577c
      Greg Spencer authored
      I noticed that we were pretty inconsistent with the way that we checked the value of clipBehavior in the framework, so I normalized the usages and updated docs where necessary.
      
      This is a breaking change if you used to pass null explicitly to FlatButton, OutlineButton or RaisedButton constructors, expecting to get Clip.none. It will now assert if you do that. Existing implementations that pass null implicitly by not specifying clipBehavior won't need to change their call sites. It always implicitly defaulted to Clip.none before, and it will continue to do that, it's only places where it was explicitly set to null in order to get the implicit default that it will fail.
      365f577c
  32. 21 Aug, 2019 1 commit