| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Turns off the ability to use @SuppressWarnings with optional
errors is available, but off by default (see Eclipse issue 392875).
This turns that off, makes missing enums in switch statements a
warning, and synchronizes the settings file to all projects (except
tests.)
Change-Id: Iad7060523b6ee2cbbca97e0a6ffedb264b185222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new layout algorithm which tries to do a more optimal fit
if all the configuration previews can fit on the current screen
without scrolling. (However, it still doesn't scale up these previews
to fit all available space, that's coming in a later CL).
It also delays rendering previews and performing layout until the
layout is actually painted, and improves the error rendering a bit.
It's also more deliberate in how preview renderings are scheduled,
performing them in visual order etc.
There's a new brief animation when you switch to a preview.
Finally, there are some preview zoom controls now.
Change-Id: Iea503a3fd57dfcaea7656e47b946bfcfea3eecb1
|
| |
|
|
|
|
|
|
| |
For now, text-oriented widgets declare their default action to
be to set the text attribute. Also hook up the default rename
keybinding to setting the id.
Change-Id: I14e8e06d0842759b1ac05e7e9494deb30b3cc40f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset improves the way the RelativeLayout editing support in
the layout editor handles deletions and moves.
First, during a move, if the move is simply within the same layout,
then the layout constraints are left alone such that if you for
example have
A
v
B < C < D
and you move B up to be next to A, you end up with
A < B < C < D
(It will however remove cycles if the move would result in them.)
Second, it now handles deletion better where deleting a view will
cause all references to any deleted views to be replaced by transitive
constraints.
For example, if you hve
A < B < C < D
and you delete B and C, you end up with
A < D
Change-Id: Icb9d3552e60aee20192f7941fe52be71ba52557f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move resources and com.android.util.Pair into layoutlib_api
where they belong since layoutlib depends on them and we need
to control the API.
Made a copy of Pair to stay in common.jar but moved it to
com.android.utils.Pair (the one in com.android.util.Pair is
marked as deprecated to prevent usage where applicable).
Also moved XmlUtil and PositionXmlParser to com.android.utils
to match Pair.
Change-Id: I21d7057d3f2ce604f86a3bb1fa3c130948c93b89
|
| |
|
|
|
|
|
|
|
|
|
| |
Lots of miscellaneous fixes to the GridLayout support in ADT. The
changes include using the GridLayout state (via reflection) to
populate the model; caching the grid model for performance, and a
bunch of fixes to the code which handles insertions and
removals. There are also some new unit tests. This is not done, but is
an improvement over the current state.
Change-Id: I4851153d3e409630c2d2024c4894d1ad1535fb47
|
| |
|
|
| |
Change-Id: I7121b5f0e3714fec705387603f641bc14ed0ab3e
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a validator to the assign/edit id dialog used in
the layout editor such that the user gets a warning if picking an id
which is already defined within the same layout.
Also cleans up the Rules API for adding a validator and makes the
generic resource validator handle both the case of requiring a unique
name and requiring an existing name.
Change-Id: Id9642c3bcd326f9734cf98c98f6799b67e11a4ae
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, update our various project-specific Eclipse compiler settings
configuration files to include the new Eclipse 4 flags.
Second, turn off the "Unchecked conversion from non-annotated type to
@NonNull" warnings; there are hundreds or thousands of these, and
there isn't much we can do about them when they're coming from
platform and library APIs.
Third, make the lint projects warning-clean again by addressing
various warnings Eclipse found (such as some unclosed resources and
some null handling issues; yesterday's null annotation fixes only
addressed errors, not warnings.)
Change-Id: If75f7401a1cbeef1bf58b47ccaa9ad17bede7f91
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eclipse 4.2 includes analysis support for @Nullable and @NonNull
annotations. However, it requires these annotations to be *repeated*
on every single method implementing or overriding a superclass or
interface method (!).
This changeset basically applies the quickfixes to inline these
annotations. It also changes the retention of our nullness
annotations from source to class, since without this Eclipse believes
that a @NonNull annotation downstream is a redefinition of a @Nullable
annotation.
Finally, the null analysis revealed a dozen or so places where the
nullness annotation was either wrong, or some null checking on
parameters or return values needed to be done.
Change-Id: I43b4e56e2d025a8a4c92a8873f55c13cdbc4c1cb
|
| |
|
|
|
|
| |
This reverts commit 27dac06bfc4297dc9a018edc534f44ecf96cd724.
Change-Id: I6708bd4091f0cb677484669479357d479b9db5fa
|
| |
|
|
| |
This reverts commit a7621238bf0202419677380ee3a268142358df83.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The WindowBuilder propertysheet has been extracted and added as a
library in external/eclipse-windowbuilder/.
This changeset removes the old propertysheet code (which used the
builtin Eclipse property sheet page), and replaces it with the
WindowBuilder one, along with new code to aggregate the properties
into some categories, as well as tagging some of the properties as
advanced. (This was computed by running the same analysis scripts used
to produce the most-frequent attributes (sdk/attribute_stats) and
instead computing which attributes are used very infrequently or not
at all in some representative sample code.)
The WindowBuilder propertysheet gives us the following new features:
- Highlighting (bold) of important attributes
- Masking (and when included, shown in gray italic) of advanced
attributes
- "Complex" attributes with nesting, used to for example aggregate all
the layout parameters into a single node, and the margin layout
attributes within those
- Tooltips over the attribute names, not values, so they never obscure
content
In addition, this changeset adds custom implementations of properties,
property editors and property dialogs for the core Android property
types (XML strings, flags and booleans), which adds the following new
features:
- Preview rendering of color and image resources inline
- Display of -default- attributes (those not specified in XML) using
the layoutlib facility getDefaultProperties() to render the implied
attributes. For example, if you look at a Button, it will show you
that the implied value of "Text Color Link" is
"@android:color/holo_blue_light" even though it is not set.
NOTE: This only happens for attributes that were actually queried by
the widget during rendering. Attributes that are not used by the
widget have no (displayed) value. Thus, EditText-specific attributes
in a TextView are not shown when a non-EditText TextView is
selected.
- Evaluation of the attributes. In the above example, in addition to
showing @android:color/holo_blue_light, it will chase down the value
of this to for example render a blue square next to the value. For
drawables it will render a thumbnail, and for String resources it
will display the actual value in parentheses.
- Field completion in text fields, completing all resource strings
(@string, @android:string, etc), as well as flag values. Enum values
are chosen in a dropdown.
- Checkbox support for boolean values, allowing you to click through
the three values true, false and null.
- Our custom version of the Property Sheet Page allows you to
expand/collapse all properties, and it also has an option letting
you switch between Alphabetical Sort (where all attributes are in a
flat table, sorted alphabetically by property value), or
hierarchical sorted "by category". Currently the categories are
simply the defining views, plus 2 more (layout parameters and
deprecated attributes). When we get more metadata, it would be nice
to switch these to more logical categories, such as "text",
"scrolling", "focus", etc. (There is some preliminary support for
this in the code, but since the defining-view categories seem to
work better those are used instead right now.)
Change-Id: Ie4959a3a2c36c083dcc1ba19a70f24b33739fe2f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset changes the signature of AttributeInfo.getFormats()
from returning a Format[] to returning an EnumSet<Format>.
Furthermore, it defines a number of constants for the various common
format sets such that they can be reused.
Nearly all uses of the getFormats() method was really just trying to
see "is format X among the formats", so using enumsets is more natural
since it has a contains method. This also lets us replace some
attribute init code which was building up a set from the array for
this exact same purpose just reuse the format set directly.
In the attribute parser, rather than computing the uppercase version
of each format string ("dimension"=>"DIMENSION") and then doing a
Format.valueOf("DIMENSION"), we now compute a map for all the format
constants as lowercase to the corresponding format instance, and use
that map when parsing the attrs.xml file.
Note that there is a small semantic change from having an array of
formats to using an enumset: The format specified an
ordering. However, it does not look like any code depended on this,
and it's also not clear that the ordering in attrs.xml is
intentional. For example, it contains both "color|reference" and
"reference|color", and in both cases the intent is that the attribute
can specify an actual color or a reference to a color. Now with an
enum set, the order used when traversing the formats will always be in
their natural order, and for this purpose the REFERENCE type is moved
to the end since it's the least specific.
Change-Id: I1170cff48086f5cc13e4b70a35deea1f9979c883
|
| |
|
|
| |
Change-Id: If7b6d7b505476676c5683ab4966fa5f587b15d1e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a new @NonNull annotation, to match our existing
@Nullable annotation, and it adds configuration settings for Eclipse
3.8 / Eclipse 4.2 which configures the new null analysis there to use
our own annotations. Note that the annotations only have source
retention so there is no extra size or class-loading overhead. (To use
findbugs you'll need to temporarily change retention to class-level.)
In upcoming CL's I'll use these annotations to clarify the Lint API
and other APIs.
Change-Id: I99096d8b8a7e25ef002624d592da7700195a5872
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset makes the SDK codebase compile with source=1.6 (which
means it also requires JDK 6). This means that methods implementing an
interface requires @Override's. It also means we can start using APIs
like the ArrayDeque class and methods like String#isEmpty().
This changeset looks big but the change is trivial: it's basically
adding @Override in all the places that need it, along with some other
automatic Eclipse cleanup in certain files (such as reordering imports
where they were incorrectly ordered (because older versions of Eclipse
didn't always handle inner classes right)), as well as cleaning up
trailing whitespace and removing some $NON-NLS-1$ markers on lines
where there aren't any string literals anymore.
This changeset also sets the source and target JDK level to 6 in the
Eclipse compiler .settings file, and synchronizes this file to all the
other Eclipse SDK projects.
Change-Id: I6a9585aa44c3dee9a5c00739ab22fbdbcb9f8275
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds the Guava library to ADT and lint. (It is also a
prerequisite for the Lombok AST library which is added by a later CL.)
This changeset also uses the library in a few simple ways: It replaces
some custom I/O and collections code with calls into the equivalent
Guava methods, and it also adds the @Beta annotation on the various
"API" classes which are not yet stable.
Change-Id: I2f50febfa075c32818404e888578a2e1e447d408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing custom view rules, and custom detectors, you may need
access to the package name of the application (in order to produce the
right namespace to look up custom attributes for).
This changeset adds new methods to the two APIs such that clients can
look up the application package. For lint, it also changes things
such that the manifest file is always processed and information
stashed in the Project object. This meant I could also remove the icon
detector code to look up the manifest info directly.
Change-Id: Id8eec96e2788f6d27481d7dcab0c544ea6e0a06d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout editor already supports providing a classpath of jar files
to check for custom views (via the layoutrules.jars property in
project.properties). However, once a view rule has been initialized it
is never updated.
This changeset makes the view rule loader more dynamic, such that it
checks the file timestamps of the jar files, and when the jar files
are changed it unloads the old rule instances and creates new
instances. This makes it a lot easier to develop view rules since you
can just update the .jar file and the layout editor automatically
picks up the changes (within a couple of seconds; for performance
reasons it checks the filestamps at most every couple of seconds (and
this is only done lazily of course, so there isn't a file change
listener; it just makes sure that if rule loading requests come in
more frequently than that it just uses the current class loader).
This changeset also adds an AbstractViewRule which implements the
IViewRule interface. Without this, implementing a custom view rule
will require dozens of methods to be stubbed out (and for the
developer to figure out what the methods are and what to do with
them).
Change-Id: I5f2b84e32e47611fff2d4211411f3039d16eb815
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset updates the GridLayout support to consider the state of
a rendered GridLayout when deciding where the rows and columns
are. This information is already available in the GridLayout object,
so if one is provided use that data rather than inferring it from the
bounds of the views in each row and column.
This required changing the view rules API a bit to pass the view
objects in to the key entry points (drawing selection, drag & drop and
resize).
Change-Id: If8484f7f7181c65d0a2fdf629ffd515edd05448b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds two forms of view attribute metadata:
* First, it records the most commonly used attributes for each
view. This was determined by gathering statistics on as many layout
files as I could find and then picking those that are used 10% or
more.
* Second, it records in the attribute metadata which View defines a
given attribute.
The context menu uses the above information to present the available
attributes in several ways:
* In the top level menu, where we had "Edit ID", and if applicable
"Edit Text", it now lists the top attributes instead. For example,
for a RatingBar the first handful of menu options are "Edit ID...",
"Edit NumStars...", "Edit StepSize...", "Edit Style..." and
"IsIndicator" (a boolean pull-right menu).
Incidentally this automatically handles some cases which were
manually handled before, so the code in LinearLayoutRule to add an
"Orientation" menu is no longer needed; it's just one of the two
common attributes handled by the new attribute list.
* The "Properties" menu is now called "Other Properties", and instead
of showing all properties, it has a new level of menus:
* "Recent". This is initially empty, but as you edit other attributes,
it gets populated (in most recently used order, kept up to date)
with recently edited properties.
* One submenu for each defining View super class listing exactly
the attributes defined by that view. This is useful for browsing
and editing related attributes. If you are looking at a textual
view like a Button for example, you can look at the "TextView"
menu to find all the text related options (TextColor, TextSize,
etc). These menus are listed from the nearest to the further
superclass, so for example if you right click on a CalendarView
you'll see these menus:
Recent >
----------------------------
Defined by CalendarView >
Inherited from FrameLayout >
Inherited from ViewGroup >
Inherited from View >
----------------------------
Layout Parameters >
----------------------------
All By Name >
* As you can see from the above, there are two more menus below the
inherited menu items. "Layout Parameters" lists all the layout
parameters available for the selected nodes (which is defined not
by the view itself but the view that it is contained within). And
finally there is "All By Name", which is a complete menu
containing all available attributes for the view (and this is what
the Properties menu used to contain).
* The code which computes a display name from an attribute was also
tweaked to capitalize not just the first letter but any first word
letter, so for example when you look at the possible values for
Gravity you now see "Clip Vertical" instead of "Clip vertical".
* The edit property dialog for the properties menus now uses @string
or @style resource choosers for the text, hint and style attributes
(used to just be a plain text box.)
Change-Id: I3b30d48b85fd13f0190c760756bf383a47b3f4a5
|
|
|
This changeset pulls out the API classes from the plugin sources and
into a separate standalone .jar library. The library depends on the
common.jar library.
With the separate view API it should be possible to build designtime
helpers (view rules) for custom views to improve editing behavior in
the layout editor.
Change-Id: I20bb511668de2fe52910e5fe0bbd3ec2a18b5a08
|
