- 27 Oct, 2015 3 commits
-
-
Adam Barth authored
Previous these callbacks were leaking the implementation detail that they were triggered by taps. In a later patch, we're going to add a parameter to GestureTapCallback that these callbacks won't have. Related to #1807
-
Hixie authored
Instread of an explicit 'enabled' bool, this uses the presence of the event handler to determine if a widget is enabled or not. This means that if you've not passed a handler, your widget will be disabled, which makes sense, since it wouldn't work anyway. Adds this feature to checkbox, and ports raised button, flat button, and radio buttons to this new model. Adds a checkbox to card_collection that can be disabled. Hide a (basically bogus) hint from the (soon to be disabled) strong hint mode in the analyzer that this reveals.
-
Hixie authored
-
- 16 Oct, 2015 1 commit
-
-
Adam Barth authored
The goal is to follow the guidelines in https://github.com/flutter/engine/blob/master/sky/specs/style-guide.md#packages Fixes #1638
-
- 10 Oct, 2015 1 commit
-
-
Adam Barth authored
-
- 09 Oct, 2015 2 commits
-
-
Adam Barth authored
-
Adam Barth authored
These are now part of material.dart.
-
- 08 Oct, 2015 1 commit
-
-
Hixie authored
Also, have dialog buttons use the accent colour. Also, generally rationalise some of this stuff to match Material better.
-
- 06 Oct, 2015 1 commit
-
-
Adam Barth authored
In the vast majority of cases, folks should be interacting with the Widget rather than its State. Fixes #267
-
- 03 Oct, 2015 1 commit
-
-
Adam Barth authored
After this patch, InkWell is driven by gesture recognizers, which lets us cleanly cancel splashes when the user actually scrolls. I've also refactored all the clients of InkWell to use InkWell to detect gestures instead of wrapping InkWell in a GestureDetector. Fixes #1271
-
- 01 Oct, 2015 1 commit
-
-
Adam Barth authored
-
- 18 Sep, 2015 1 commit
-
-
Adam Barth authored
Also, introduce Colors and Typography to hold the material colors and the typography declarations. Previously we expected clients of these libraries to import them into a namespace, but that doesn't play nice with re-exporting them from material.dart.
-
- 02 Sep, 2015 1 commit
-
-
Adam Barth authored
Code outside of package:sky should import this code using package:sky/rendering.dart package:sky/widgets.dart Moving this code into the "src" directory is a convention that signifies that and it cleans up the generated dartdoc because the libraries in the src directory aren't included in the generated documentation. Instead, the classes are documented in the widgets.dart and rendering.dart libraries.
-
- 28 Aug, 2015 1 commit
-
-
Hixie authored
Stop exporting framework.dart from basic.dart, since we now have widgets.dart exporting all of framework.dart.
-
- 28 Jul, 2015 2 commits
-
-
Chinmay Garde authored
-
Chinmay Garde authored
-
- 22 Jul, 2015 1 commit
-
-
Hixie authored
This fixes some theoretical bugs whereby we were using hashCode to try to get unique keys for objects, but really we wanted object identity. It also lays the groundwork for a new GlobalKey concept. I tried to keep the impact on the code minimal, which is why the "Key" constructor is actually a factory that returns a StringKey. The code has this class hierarchy: ``` KeyBase | Key--------------+---------------+ | | | StringKey ObjectKey UniqueKey ``` ...where the constructors are Key and Key.stringify (StringKey), Key.fromObjectIdentity (ObjectKey), and Key.unique (UniqueKey). We could instead of factory methods use regular constructors with the following hierarchy: ``` KeyBase | LocalKey---------+---------------+ | | | Key ObjectIdentityKey UniqueKey ``` ...with constructors Key, Key.stringify, ObjectIdentityKey, and UniqueKey, but I felt that that was maybe a more confusing hierarchy. I don't have a strong opinion on this.
-
- 16 Jul, 2015 1 commit
-
-
Collin Jackson authored
-