1. 19 Mar, 2024 3 commits
    • Mitchell Goodwin's avatar
      Widget state properties (#142151) · 6190c5ee
      Mitchell Goodwin authored
      Fixes #138270.
      
      Moves the majority of the logic of MaterialStateProperties down to the widgets layer, then has the existing Material classes pull from the widgets versions.
      6190c5ee
    • goodmost's avatar
      chore: fix some comments (#145397) · 3236957f
      goodmost authored
      fix some comments
      3236957f
    • Bruno Leroux's avatar
      Activate shortcuts based on NumLock state (#145146) · 6f61f613
      Bruno Leroux authored
      ## Description
      
      The PR updates `SingleActivator` in order to add a parameter for specifying that a shortcut depends on <kbd>NumLock</kbd> key state. 
      
      Somewhat similarly to what is possible with common modifiers expect that a boolean is not enough in this case because: by default, a shortcut should ignore the <kbd>NumLock</kbd> state and it should be possible to define shortcuts that require <kbd>NumLock</kbd> to be locked and other that require it to be unlocked.
      
      @gspencergoog I considered defining a new `ShortcutActivator` implementation for this, but I thinks that adding the feature directly to `SingleActivator` results in a cleaner API.
      
      ## Related Issue
      
      Fixes https://github.com/flutter/flutter/issues/145144
      Preparation for https://github.com/flutter/flutter/issues/144936
      
      ## Tests
      
      Adds 3 tests.
      6f61f613
  2. 18 Mar, 2024 2 commits
  3. 15 Mar, 2024 1 commit
  4. 14 Mar, 2024 1 commit
  5. 13 Mar, 2024 4 commits
    • LongCatIsLooong's avatar
      Revert "Add `FocusNode.focusabilityListenable` (#144280)" since the feature is... · 4f786841
      LongCatIsLooong authored
      Revert "Add `FocusNode.focusabilityListenable` (#144280)" since the feature is no longer needed (#145102)
      
      This reverts commit 726e5d28.
      
      *Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
      
      *List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
      
      *If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
      4f786841
    • Nate's avatar
      Turning `if` chains into shorter `switch` statements (#144977) · b9e53733
      Nate authored
      This pull request is part of the effort to solve issue #144903.
      
      In the past, my efforts to reduce line length involved refactoring away from switch statements, but unlike [yesterday's PR](https://github.com/flutter/flutter/pull/144905), this one is full of switch statements that make things more concise!
      b9e53733
    • Victoria Ashworth's avatar
      Set cacheExtent for SliverFillRemaining widget (#143612) · 825e901e
      Victoria Ashworth authored
      When a Sliver with items is outside of the Viewport, but within the Viewport's `cacheExtent`, the framework should create SemanticNodes for the items even though they are out of view. However, for this to work, the Sliver's geometry must have a `cacheExtent` (how much space the sliver took up of the Viewport's `cacheExtent`) greater than 0, otherwise it is [excluded](https://github.com/flutter/flutter/blob/f01ce9f4cb41beff7b85122b5fcf1228bb655a87/packages/flutter/lib/src/rendering/viewport.dart#L311-L315).
      
      `SliverFillRemaining` widgets that fall outside the viewport did not have this set and therefore were being excluded when SemanticNodes were created, even if they were within the Viewport's `cacheExtent`. This PR sets the `cacheExtent` for `SliverFillRemaining` widgets.
      
      In addition, `RenderSliverFillRemainingWithScrollable` would get dropped from the semantic tree because it's child had a size of 0 when outside the remaining paint extent. To fix, we give the child a `maxExtent` of the sliver's `cacheExtent` if it's outside the remaining paint extent but within the viewport's cacheExtent.
      
      Fixes https://github.com/flutter/flutter/issues/142065.
      
      Definitions:
      * `RenderViewport.cacheExtent`:
        ```dart
        /// The viewport has an area before and after the visible area to cache items
        /// that are about to become visible when the user scrolls.
        ///
        /// Items that fall in this cache area are laid out even though they are not
        /// (yet) visible on screen. The [cacheExtent] describes how many pixels
        /// the cache area extends before the leading edge and after the trailing edge
        /// of the viewport.
        ///
        /// The total extent, which the viewport will try to cover with children, is
        /// [cacheExtent] before the leading edge + extent of the main axis +
        /// [cacheExtent] after the trailing edge.
        ///
        /// The cache area is also used to implement implicit accessibility scrolling
        /// on iOS: When the accessibility focus moves from an item in the visible
        /// viewport to an invisible item in the cache area, the framework will bring
        /// that item into view with an (implicit) scroll action.
        ```
      * `SliverGeometry.cacheExtent`:
        ```dart
        /// How many pixels the sliver has consumed in the
        /// [SliverConstraints.remainingCacheExtent].
        ```
      * `SliverContraints.remainingCacheExtent`:
        ```dart
        /// Describes how much content the sliver should provide starting from the
        /// [cacheOrigin].
        ///
        /// Not all content in the [remainingCacheExtent] will be visible as some
        /// of it might fall into the cache area of the viewport.
        ///
        /// Each sliver should start laying out content at the [cacheOrigin] and
        /// try to provide as much content as the [remainingCacheExtent] allows.
        ```
      825e901e
    • xubaolin's avatar
      [New feature]Introduce iOS multi-touch drag behavior (#141355) · c83237f3
      xubaolin authored
      Fixes #38926
      
      This patch implements the iOS behavior pointed out by @dkwingsmt at #38926 , which is also consistent with the performance of my settings application on the iPhone.
      
      ### iOS behavior (horizontal or vertical drag)
      
      ## Algorithm
      When dragging: delta(combined) = max(i of n that are positive) delta(i) - max(i of n that are negative) delta(i)
      It means that, if two fingers are moving +50 and +10 respectively, it will move +50; if they're moving at +50 and -10 respectively, it will move +40.
      
      ~~TODO~~
      ~~Write some test cases~~
      c83237f3
  6. 12 Mar, 2024 2 commits
  7. 06 Mar, 2024 1 commit
    • Greg Price's avatar
      Fill in SliverConstraints fields missing from ==, hashCode, toString (#143661) · 6b9d3ea4
      Greg Price authored
      I was doing some debugging on a RenderSliver subclass, and found
      that SliverConstraints.toString was missing the precedingScrollExtent
      field.
      
      Add that, and add both that field and userScrollDirection to the
      `==` and hashCode implementations, which had been skipping them,
      so that all three methods now handle all the class's fields.
      6b9d3ea4
  8. 05 Mar, 2024 1 commit
  9. 29 Feb, 2024 4 commits
  10. 28 Feb, 2024 1 commit
    • auto-submit[bot]'s avatar
      Reverts "Cache `FocusNode.enclosingScope`, clean up `descendantsAreFocusable` (#144207)" (#144292) · 45050686
      auto-submit[bot] authored
      Reverts flutter/flutter#144207
      
      Initiated by: CaseyHillers
      
      Reason for reverting: b/327301206 - Breaking a customer test
      
      Original PR Author: LongCatIsLooong
      
      Reviewed By: {gspencergoog}
      
      This change reverts the following previous change:
      Original Description:
      `FocusNode.canRequestFocus` was doing a double traversal if no ancestor disallows focus. The last for loop only has to reach as far as the enclosing scope.
      
      Also this caches the `FocusNode.enclosingScope` since the getter access happens much more frequently than node reparenting.
      45050686
  11. 27 Feb, 2024 1 commit
  12. 26 Feb, 2024 1 commit
  13. 23 Feb, 2024 3 commits
  14. 22 Feb, 2024 1 commit
  15. 21 Feb, 2024 4 commits
    • Jonah Williams's avatar
      Disable color filter sepia test for Impeller. (#143861) · d699bcb4
      Jonah Williams authored
      This test is still unstable with the debug banner disabled. the Icon in the FAB appears to be shifting.
      d699bcb4
    • Jonah Williams's avatar
    • Jonah Williams's avatar
      Disable debug banner to stabilize impeller goldens. (#143794) · 1e822ca2
      Jonah Williams authored
      Fixes some of https://github.com/flutter/flutter/issues/143616 by disabling the debug banner, which does not appear to be a critical part of the golden.
      1e822ca2
    • auto-submit[bot]'s avatar
      Reverts "Changing `TextPainter.getOffsetForCaret` implementation to remove the... · f9b3b84d
      auto-submit[bot] authored
      Reverts "Changing `TextPainter.getOffsetForCaret` implementation to remove the logarithmic search (#143281)" (#143801)
      
      Reverts flutter/flutter#143281
      
      Initiated by: LongCatIsLooong
      
      Reason for reverting: https://github.com/flutter/flutter/issues/143797
      
      Original PR Author: LongCatIsLooong
      
      Reviewed By: {justinmc, jason-simmons}
      
      This change reverts the following previous change:
      Original Description:
      The behavior largely remains the same, except:
      
      1. The EOT cursor `(textLength, downstream)` for text ending in the opposite writing direction as the paragraph is now placed at the visual end of the last line. 
        For example, in a LTR paragraph, the EOT cursor for `aA` (lowercase for LTR and uppercase for RTL) is placed to the right of the line: `aA|` (it was `a|A` before). 
        This matches the behavior of most applications that do logical order arrow key navigation instead of visual order navigation. 
        And it makes the navigation order consistent for `aA\naA`:
      ```
        |aA    =>  aA|  => aA|  => aA  => aA   => aA 
         aA        aA      aA     |aA     aA|     aA|     
         (1)       (2)     (3)    (4)    (5)      (6)
      ```
      This is indeed still pretty confusing as (2) and (3), as well as (5) and (6) are hard to distinguish (when the I beam has a large width they are actually visually distinguishable -- they use the same anchor but one gets painted to the left and the other to the right. I noticed that emacs does the same). 
      But logical order navigation will always be confusing in bidi text, in one way or another.
      
      Interestingly there are 3 different behaviors I've observed in chrome:
      - the chrome download dialog (which I think uses GTK text widgets but not sure which version) gives me 2 cursors when navigating bidi text, and 
      - its HTML fields only show one, and presumably they place the I beam at the **trailing edge** of the character (which makes more sense for backspacing I guess). 
      - On the other hand, its (new) omnibar seems to use visual order arrow navigation
      
      Side note: we may need to update the "tap to place the caret here" logic to handle the case where the tap lands outside of the text and the text ends in the opposite writing direction. 
      
      2. Removed the logarithmic search. The same could be done using the characters package but when glyphInfo tells you about the baseline location in the future we probably don't need the `getBoxesForRange` call. This should fix https://github.com/flutter/flutter/issues/123424.
      
      ## Internal Tests
      
      This is going to change the image output of some internal golden tests. I'm planning to merge https://github.com/flutter/flutter/pull/143281 before this to avoid updating the same golden files twice for invalid selections.
      f9b3b84d
  16. 20 Feb, 2024 3 commits
    • xubaolin's avatar
      Change `ItemExtentBuilder`'s return value nullable (#142428) · 6707f5ef
      xubaolin authored
      Fixes https://github.com/flutter/flutter/issues/138912
      
      Change `ItemExtentBuilder`'s return value nullable, it should return null if asked to build an item extent with a greater index than exists.
      6707f5ef
    • LongCatIsLooong's avatar
      Changing `TextPainter.getOffsetForCaret` implementation to remove the logarithmic search (#143281) · 3538e4c7
      LongCatIsLooong authored
      The behavior largely remains the same, except:
      
      1. The EOT cursor `(textLength, downstream)` for text ending in the opposite writing direction as the paragraph is now placed at the visual end of the last line. 
        For example, in a LTR paragraph, the EOT cursor for `aA` (lowercase for LTR and uppercase for RTL) is placed to the right of the line: `aA|` (it was `a|A` before). 
        This matches the behavior of most applications that do logical order arrow key navigation instead of visual order navigation. 
        And it makes the navigation order consistent for `aA\naA`:
      ```
        |aA    =>  aA|  => aA|  => aA  => aA   => aA 
         aA        aA      aA     |aA     aA|     aA|     
         (1)       (2)     (3)    (4)    (5)      (6)
      ```
      This is indeed still pretty confusing as (2) and (3), as well as (5) and (6) are hard to distinguish (when the I beam has a large width they are actually visually distinguishable -- they use the same anchor but one gets painted to the left and the other to the right. I noticed that emacs does the same). 
      But logical order navigation will always be confusing in bidi text, in one way or another.
      
      Interestingly there are 3 different behaviors I've observed in chrome:
      - the chrome download dialog (which I think uses GTK text widgets but not sure which version) gives me 2 cursors when navigating bidi text, and 
      - its HTML fields only show one, and presumably they place the I beam at the **trailing edge** of the character (which makes more sense for backspacing I guess). 
      - On the other hand, its (new) omnibar seems to use visual order arrow navigation
      
      Side note: we may need to update the "tap to place the caret here" logic to handle the case where the tap lands outside of the text and the text ends in the opposite writing direction. 
      
      2. Removed the logarithmic search. The same could be done using the characters package but when glyphInfo tells you about the baseline location in the future we probably don't need the `getBoxesForRange` call. This should fix https://github.com/flutter/flutter/issues/123424.
      
      ## Internal Tests
      
      This is going to change the image output of some internal golden tests. I'm planning to merge https://github.com/flutter/flutter/pull/143281 before this to avoid updating the same golden files twice for invalid selections.
      3538e4c7
    • Polina Cherkasova's avatar
      Clean leaks. (#142818) · 39befd81
      Polina Cherkasova authored
      39befd81
  17. 18 Feb, 2024 2 commits
  18. 17 Feb, 2024 2 commits
  19. 14 Feb, 2024 1 commit
  20. 13 Feb, 2024 2 commits