- 08 Aug, 2015 1 commit
-
-
Ian Fischer authored
-
- 06 Aug, 2015 1 commit
-
-
Matt Perry authored
We only use them for the transition to dismissed.
-
- 04 Aug, 2015 1 commit
-
-
James Robinson authored
This introduces the notion of event disposition and allows event targets (widgets and render objects) to consume events that should not be processed further. This is needed by the Switch component in the Drawer in the stocks example. The Switch is embedded in a DrawerItem. The Switch handles the gesture tap event to toggle its state and should handle pointer events to allow swiping and draw its own radial reaction. The DrawerItem also handles gesture taps to allow toggling the switch value when tapping anywhere on the drawer and to draw its own ink splash. When tapping on the switch, both the switch's render object and the DrawerItem's listener are in the event dispatch path. The Switch needs to signal in some fashion that it consumed the event so the DrawerItem does not also try to toggle the switch's state.
-
- 28 Jul, 2015 3 commits
-
-
Matt Perry authored
SnackBar, and PopupMenu instead of custom statuses.
-
Chinmay Garde authored
-
Chinmay Garde authored
-
- 25 Jul, 2015 1 commit
-
-
Hixie authored
Scoped focus, so you can have a dialog with input controls and not lose your focus in the background. This introduces a GlobalKey registry so that you can tell when a key has gone away (so you can unfocus dead dialogs). Also I added an assert that you're not calling setState() during a build. It turns out that doing so means you have a bug, because since you're dirty already (you're building), you won't get rebuilt. The focus code itself is gnarly. It uses a Component and an internal Inherited TagNode to manage the focus state, and does crazy things like updating its state during build to pretend retroactively that it was built with some other state, once someone asks for focus the first time (i.e. the first time it's examined, so you can't tell that it was in a different state before). It does this so that it can autofocus controls which otherwise wouldn't be focused. This moves all the focus management into Navigator and showDialog(), so the complexity is all buried deep and not visible to apps, hopefully. To do something like two tabs that each have an Input widget that needs to be focused when you switch panes, you'd need to have two Focus objects, one in each tab, and you need to set their autofocus to true (maybe that should be the default?).
-
- 24 Jul, 2015 1 commit
-
-
Jim Simon authored
Converted demo launcher example to library Converted fitness example to library Converted hello world example to library Converted mine digger example to library Converted stocks example to library
-
- 23 Jul, 2015 2 commits
-
-
Hixie authored
-
Eric Seidel authored
This patch provides a class to manage focus, Focus, and a class to manage ownership of the keyboard, KeyboardHandle. Inherited (in widgets.dart) is adjusted to support subclasses that need to copy state from instance to instance. A GlobalKey key type is introduced that is basically the same as UniqueKey. Component classes that need a globally-unique key can specify that their 'key' constructor argument is a GlobalKey. Focus ----- You can use `Focus.at(this)` to determine if you, a Component, are currently focused. You can use `Focus.moveTo(this)` to take the focus or give it to a particular component. For this to work, there has to be a Focus class in the widget hierarchy. Currently, there can only be one Focus class, because nested scopes aren't supported. We should add support for that in a future patch. See issue #229. KeyboardHandle -------------- Instead of directly interacting with the keyboard service, you now ask for a KeyboardHandle using `_keyboard.show(client)`. This returns a KeyboardHandle class. On that class, you can call `handle.release()` when you want to hide the keyboard. If `handle.attached` is still true, and you need to reshow the keyboard after the user hid it, then you can can `handle.showByRequest()`. The point of this is that the `keyboard.show()` method maintains the invariant that only one KeyboardHandle is live at a time. There are some issues with the keyboard service that I filed as a result of doing this patch: #226 #227
-
- 22 Jul, 2015 2 commits
-
-
Matt Perry authored
-
Matt Perry authored
-
- 21 Jul, 2015 2 commits
-
-
Hixie authored
Route (named routes) no longer have a key, and have their own storage for their names. RouseState no longer has a key, and uses an owner field pointing to a StatefulComponent instead. As such, RouteBase no longer has a key. HistoryEntry no longer uses a global int to ensure uniqueness. Propagated this to stocks app.
-
Matt Perry authored
-
- 16 Jul, 2015 1 commit
-
-
Collin Jackson authored
-