| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds basic support for grid layouts:
- Freeform mode where you can drag & drop anywhere in the layout, and
guidelines are offered to align with other left boundaries, right
boundaries, baseline vertical alignment and center layout horizontal
alingment. In addition, it also offers "preferred spacing"
positioning, using the recommended distance between widgets.
Also, during a drag a regular 16x16 grid is also (faintly) shown and
(when there are no alignment matches as explained above) the
position snaps to this grid.
We also show the grid-structure (rows and columns, not the regular
snapping grid) during drags to make it more obvious that behind the
scenes there is a grid (because some other operations might shift
rows and columns so it's important to present the right user model.)
The freeform grid layout editor will automatically create rows and
columns and size them using spacers which are hidden from the user,
and on deletion these are automatically cleaned up as well.
- Grid mode where you can drag to any given cell, or between any two
rows or columns.
- Some layout actions for manipulating the grid (add/remove row and
column, adjust the gravity, toggle modes.)
This CL also contains various diagnostics code for the grid mode, and
does not yet correctly support dragging multiple views simultaneously.
Change-Id: Ie9ec54805039645e3db78d19095da86b04e44ca0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL fixes three issues with the new relative layout interaction:
(1) Assign ids dynamically. Before this changeset you couldn't attach
to a node which does not have an @id attribute, since layout
params need to name the constraint by id.
This changeset changes this such that you can attach to any
arbitrary edge, and when you commit the drag, a unique id is
generated on the fly and assigned to the node.
(2) Handle dragging multiple nodes at the same time. The new
constraints code was unconditionally applying the same constraints
to all the dragged nodes, which meant they ended up on top of each
other. This fixes things such that the first node is assigned the
new constraints, and then all subsequent nodes are attached one
next to the other, in a direction depending on which edge you
attached to (e.g. attaching on the right will arrange the siblings
towards the left out from the edge.)
(3) Fix a bug in the code to detect and prevent cycles.
Change-Id: I157d45e117d3229f285870517b85ed902607b966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the layout XML file contains typos, the rendering will fail and the
canvas will list the missing classes along with hyperlinks to create a
new class, configure the build path etc.
This changeset looks for "typos" in the view names and if it finds a
similar real view class, either among the Android views or among the
custom views in the current project, then it will add a hyperlink
suggestion to fix the XML by editing the name to the correct spelling.
It also handles the scenario where you have typed in a custom view
class name correctly, but have forgotten to include its package.
In a followup changeset this functionality will be available from the
XML editing quick assistant as well.
Change-Id: Iaefd3f503795e25e6eb38353c60c645061d4814e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a view class cannot be found during rendering, the error log
lists the class as missing, and presents the class as a
hyperlink. Clicking the link will open the New Class wizard.
This CL changes this such that there are multiple links instead:
- "Fix Build Path": This opens the Java Build Path preference page in
the Options dialog for the current project where you can fix the
build path of the project, since a more common source of missing
classes is a problem with the class path.
- "Edit XML": This switches to the XML tab where you can edit the name
of the custom view tag: A "missing" view is often a typo in the view
name
- "Create Class": This opens the create class wizard as before.
Similarly, for broken classes (where the class is found, but cannot be
instantiated correctly) the following hyperlinks are offered:
- "Open Class", which shows the class in the editor
- "Show Error Log", which will open the IDE error log where you
typically can find a full stack trace from the failed invocation.
In addition, this CL fixes
14546: Creating a custom view from the error output of the layout
editor creates it in gen
by ensuring that the gen/ folder is not one of the fragment roots
presented to the New Class wizard.
Change-Id: I06b8969800caaea719e4b52608a7ed130c91837d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RelativeLayout now has both drop/move and resize guidelines, and
existing constraints are visualized for the selection.
LinearLayout resizing now uses weights to change the size of nodes
rather than setting width/height.
All resize operations offer guidelines to snap to their "wrap_content"
size.
Various bug fixes in related areas as well.
Change-Id: I817e34c6e67ce61cfb137eb067076d91f69f99e9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds "resizing" support to the layout editor.
First, the normal selection overlay is replaced with a selection
rectangle which also has "selection handles" in the corners and in the
middle of each edge. Moving the cursor over one of the selection
handle will show a directional resize cursor, and dragging the handle
will initiate a new resizing gesture. (This also made it possible to
remove the selection fill we've used until now, so the layout editor
will "interfere" less with the visual look of the layout.)
During the resizing operation, the current size is displayed in the
Eclipse status bar.
The resizability of widgets is determined by metadata, so for example
a ZoomControls widget is not resizable, a rating bar is only
horizontally resizable, a TableRow is only vertically resizable, and
most widgets are resizable in any direction.
The parent layout is involved in the resizing operation. Currently,
the resizing gestures will only update the width and height properties
(except for absolute layout, which will also set the x and y
properties if you are dragging a left or top edge). In a follow up
changeset this will be extended to for example make RelativeLayout
allow resize dragging to snap to new edges and the resize will be
applied as a set of new constraints on the "resized" widget. Thus,
you'll be able to drag the right hand side of a widget and drag it
over to attach to some other widget or edge, independent of what the
left edge or vertical edges are bound to.
This changeset also adds the ability for ViewRules to provide a
message or error message back to the IDE during a drag or resize
operation. For resizing this is used to display the new size. However,
it is now also used to display more useful messages in a couple of
older scenarios:
* Attempting to drag anything into a ListView will display a message
that AdapterViews much be configured via Java code
* Attempting to drag anything into or within an AbsoluteLayout will
warn that AbsoluteLayouts are deprecated.
Note that resizing will currently set the size to specific pixel (dip)
sizes. In the next changeset I will add guidelines which (in addition
to those described for RelativeLayout above) will add guidelines for
significant sizes such as the parent size, the preferred
(wrap_content) size of the widget, and possibly other hardcoded sizes
in the same layout.
Change-Id: Ie4f3367e81b24259a106c649c944008f4a3d31ec
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There is a method in the layout editor which fills in required default
attributes like id, width and height, as well as some optional
attributes like a default text attribute.
This code was called unconditionally whenever a new child is added to
a layout. However, this should only be done when a new widget is
created, not during moves or copies from existing elements.
Change-Id: Ic04dec746c70359eca38454bacfdcdb87891719f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First and foremost, allow custom views to accept children such that
you can drag & drop children into the custom view in the outline.
Second, prevent an NPE which can occur if you drag into a layout where
the root element is a custom view.
Third, handle <view> (not <View>) better: provide a custom icon, and
inline the view class name in the outline label.
Fourth, allow double clicks (in addition to ctrl-click which is already
supported) on the custom views in the palette to allow jumping to the
custom view code.
Change-Id: I13c2bf2f4169185c9fcc893ce487f2abdac46802
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds in descriptor metadata and XML editors for:
- Drawables (res/drawable/)
- Animations (res/anim/)
- Animators (res/animator/)
- Colors (res/color)
These types have also been added to the New XML File wizard.
There is some specialized completion support for animators:
- Completing on the propertyName property of <objectAnimator> will
offer the various integer and float properties in views
- Completion for the interpolator property shows the framework
interpolators immediately and on top (instead of having to complete
the individual resource paths @android: and anim/ first
There is also a new quickfix and marker resolution for the AAPT error
which complains about an unbound prefix. This will insert a
xmlns:android="http://schemas.android.com/apk/res/android" attribute
declaration on the root element.
This CL also includes a fix to make the New XML File Wizard preselect
the current project in more scenarios.
NOTE: This changeset adds new XML editors for these resource types.
It does not attempt to update previous editor bindings for files of
the given type, so to test this you may need to use "Open With" in the
package explorer to pick the right file type.
A subsequent CL will try to migrate settings over to these editors,
but that work will tie into another effort: merging all these
different editors into a single editor class that does its own content
type switching and different viewparts for the other tabs.
Change-Id: I4b12bafd8fd068176c41bac1e345bb74ccdb8b6f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds code completion support to resource files where
<style> elements are defined. In particular, you get two types of
completion:
- Completion on names: <style><item name="|" >
Here you get offered ALL matching attribute names from any view
descriptors.
- Completion on values: <style><item name="android:gravity">|</item>
Here you get offered all values that correspond to the attribute
named as the value of the name attribute of the surrounding item
element.
Unrelated to styles, code completion will now also move the caret
outside the attribute value quotes when you enter one of the value
alternatives (unless the value is a flag type or a resource token).
Also, run-on attributes are also handled more gracefully: if you
complete properties with the caret immediately following another
attribute, a separating space is added into the match as a prefix such
that the new attribute is separated and the XML valid.
There are a lot of diffs in this changeset. In order to allow the
ResourcesContentAssist to extend code completion to add its style-
specific logic, the content assist code had to be split up a bit.
Doing completion in text nodes, or potential text nodes (e.g. if you
have <item>|</item> you should get text completion at that caret
offset even though there is no text node child of the item element
until you insert actual text there) also required some changes.
There are many new unit tests. I also changed the golden file format
slightly to show the caret in the before-view such that it's more
obvious how the caret was affected by inserting the new item.
Change-Id: Ia985db7e848fea33e93ac8a70b2c3b4dbfd9056a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds two related features:
- A "marker resolution" which adds a quickfix to aapt errors for
nonexistent resources. This means that you can right click on the
error in the Problems view to create the associated missing
resource.
- A "quick assistant" which looks for a missing resource on the
current line and if found adds a fix handler for it, similar to the
quickfix above.
When a fix is invoked, it will create the new file or value, and open
it in the editor with the relevant value section selected.
The quick assistant can be invoked by the normal Ctrl-1 (Cmd-1). The
quickfix must be invoked from the Problems view; the Java editor seems
to add an extra level of integration with a lightbulb in the editor
margin but we don't get that in XML.
The quickfixes work for all value-based resources, as well as some
file-based ones (in particular, those supported by the New XML File
wizard, which it reuses.)
This changeset also adds unit tests for quickfixes along with a few
infrastructure changes to support it.
Change-Id: I962bcf6c98934685e4d74389469d0903115a75e3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset contains a number of improvements to the code
completion in XML files.
(1) Add suffix completion in attribute values. For dimensional
attributes, this will add in (or complete prefixes of) units like
"dp", "sp", etc. For fractional attributes, the % and %p suffixes
are completed. (In both cases, there is also a tooltip message
provided shown in the completion documentation popup). In
addition, for flag values, when completing at the end of a flag,
then the separator character (|) along with the other flag values
(except those already set) are offered.
(2) Handle completion when the caret is not at the end. For example,
if you have the following source:
layout_w^idth="wrap_content" (^ = caret position)
then if you invoke code completion you will also be offered the
attribute layout_weight, and selecting it will -replace- the
layout_width attribute with layout_height, it will not insert
layout_weight in the middle of layout_width. This handling is done
not just for attribute names as shown here but for attribute
values and element tag names as well.
(3) Improve @resource/ completion sorting. When completing resources,
consider which attribute is being completed, and use that
information to sort the resources. For example, if completing a
"text" attribute then @string/, and @android:string/ resources
will be listed first. For attributes like margins @dimen will be
first, for include layout the @layout attributes will be listed
first, and so on. Also, the resources are sorted alphabetically
as the second sort key.
(4) Hide some builtin Eclipse code completion items. In particular,
the default code completion provider for Eclipse will always add
the current attribute value as a completion. This is extremely
confusing since if you have a typo, code completion will tell you
that what you have is okay. I personally witnessed this confusing
a user who had typed something from memory and code completion
seemed to him to "confirm" that he had it right.
To fix this, the code which installs completion providers, will
identify the builting WST completion provider, and when found,
replace it with a "filtering" wrapper. This completion provider
delegates all its calls to the WST completion provider, but it
recognizes a few patterns, in particular the above attribute value
completion proposal as well as some namespace and schema ones, and
removes these.
(The reason we only filter out these items instead of removing it
completely is that the completion provider also appears to be
responsible for inserting code templates defined by the user, and
we don't want to neuter those if defined by the user.)
(5) Fix a bunch of corner cases - flags could only have a single
separator (|), resource attribute completion items were missing
icons, and completion in some positions was not working.
(6) Unit tests. There are now comprehensive unit tests for code
completion. Each unit test points to a particular source file
and a particular position within the source file, and code completion
is invoked for that position. A set of unit tests dump out the
allowed completion items for each such position, and these are
compared against golden files. A second set of unit tests then
specify a particular code completion item among the choices to
be applied, and then applies that completion item to the document.
This, along with the caret position (indicated as ^) is written
into a golden file and used for comparisons. To make it easy
to see what these tests do, the golden file is actually recorded
as a diff, so in the test you will see something like this:
Code completion in completion1.xml for android:gravity="left|b^ottom"
selecting bottom:
< android:gravity="left|bottom"
---
> android:gravity="left|bottom^"
(6) There are some other misc changes. We had some code which used
"dip" for device indepdendent pixels (such as the AbsoluteLayout
handler). Since "dp" seems to be preferred, the code will now
use that instead.
Change-Id: I8bd5c8336d8747dac1f10a9269ea4197f304cb70
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, aapt errors only show up as an error icon in the left hand
margin, and the user has to figure out from the error message where on
the line the error occurred.
This changeset uses information in the error message to identify the
specific range of text on the line that is affected, and underlines
it.
Change-Id: I322a8193af4e90bb972276aee80124771b6a46cd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of work on the "Change Layout" refactoring to improve conversion
to a Relative Layout. First, add a "Flatten Hierarchy" option which
can take an entire hierarchy of layout widgets and flatten it down to
a single top level RelativeLayout where the constraints attempt to
reflect the original layout. (This isn't always possible, since some
layout managers offer features not possible to express in
RelativeLayout, such as a LinearLayout with multiple different
weights) but it often works or is at least a good start. (This work
is ongoing, but since my changeset is getting large I want to check in
this snapshot since the functionality is better than what is in the
trunk.)
This changeset also adds a new refactoring: Change Widget Type. This
can be applied to a selection of elements, and it will convert the
widget type to the new target widget type. It will also remove any
attributes that are not valid for the new layout.
It also improves the wizards which display the possible target types.
For Change Widget Type, it will first offer "related" widgets, so for
an AnalogClock it will first offer Digital Clock, for a checkbox it
will offer a checked text view and a radio button, etc.
In addition, it will list Views and Layouts that it finds in any
library jars (except for the builtin Android ones), and any custom
view classes in the project.
There is also now some preliminary support for refactoring unit
tests. These tests must be run as Eclipse plugin tests, since they
utilize the XML model (and the XML model cannot be mocked). The test
infrastructure reads source XML files, applies the refactoring change
list to them, and diffs the output with the known expected output
(also stored as result XML files in the test project).
Finally, there are a number of fixes and improvements to the shared
refactoring code.
Change-Id: I0974653e530dfb4feb625e0eef8257c29d50614b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds refactoring support for 3 visual refactoring
operations:
(1) Wrap in Container. This can be invoked on one or more sibling
views (or the root view) to add a new layout container into the
hierarchy which "wraps" the views. The refactoring can also update
the layout attributes (such as RelativeLayout attachments) such
that they refer to the new container instead. If invoked on the
root element, the namespace declarations are migrated from the old
root to the new root.
(2) Change Layout. This can be invoked on a layout view to change the
type of layout. In addition to editing the XML type declaration,
it also removes layout parameters that no longer apply, and
depending on which layout you are converting from and converting
to, it may attempt to perform some translation to preserve the
layout characteristics. In particular, if you convert from a
LinearLayout to a RelativeLayout, then it will use RelativeLayout
params to emulate the old LinearLayout by attaching items below
(for vertical layouts) or to the right of (for horizontal layout)
the previous sibling, and if the baseline property was set on the
LinearLayout it will also add baseline constraints on the
RelativeLayout. (It also adds default ids on any elements that
need it.)
There is a LOT more we can do to support layout transformations;
this is just a beginning.
(3) Extract as Include. We already had this feature, but it performed
its own XML document manipulation. This code has been rewritten
to use the Eclipse refactoring support (which the other two
refactorings are implemented to use as well), which among other
things means that you get Preview support - you can press Preview
from the refactoring dialog to see the edits before they are
made. This rewrite is also necessary to support an upcoming
feature: the ability to replace occurrences in other
configuration-variations of this layout; for that we need to
ability to do multi-file changes which the refactoring support is
ideal for.
Change-Id: I50b142645f14c29c798fc02df6df69bad5b9426c
|
| |
|
|
|
|
|
|
| |
If there isn't enough room to show the margins, make the margins
smaller. This gives more useful layout room when you are dealing with
large screens.
Change-Id: I6f967dbe6b18ca5ee85cc04db88d903cb976e851
|
| |
|
|
|
|
|
|
|
| |
When opening new layouts, or opening layouts saved with older
versions of ADT, pick a render target that supports layoutlib 5. Many
features (such as layout rendering, palette previews etc) work much
better with layoutlib 5.
Change-Id: I0c577e76a2447985be0ab9bd2603618e8f152873
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new toolbar above the layout canvas (and to the right of the
palette). This toolbar shows various layout-related actions on its
left, and the canvas zoom controls on the right. The zoom controls
have been moved from the configuration panel, which has also been
reorganized a little with three of the dropdowns moved up to make more
horizontal width and take the place of the old zoom controls.
The toolbar items vary based on which layout is "active". The active
layout is the parent layout of the selection, or the root layout in
the canvas if there is no selection.
Some examples:
- In a LinearLayout, there are radio-button icons for switching
between horizontal and vertical orientation, and for toggling
baseline alignment
- There are toggle buttons for toggling between wrap_content and
match_parent (or fill_parent) for the layout_width and layout_height
properties
- There is a dropdown menu in LinearLayout and RelativeLayout which
lets you set the layout_gravity to one of the dozen gravity settings
- There is an action button which brings up a margin chooser dialog
where you can configure the margin settings for the currently
selected elements for layouts that support margins
There will be additional actions here in the future.
This changeset also adds a few new MenuAction subclasses and factories
to make it possible to do ordered lists of choices. It also adds
sorting keys to make it easier for parents and children to interleave
their actions with simple sorting keys rather than having to append,
prepend or merge their respective result lists. In a follow-up
changeset I will replace the context menu code to use these, as well
as attempt to make all actions stateless such that they can be cached
and reapplied for different targets.
Some misc cleanup.
Change-Id: I6a87144fcfd1d359e5561829bd5d63c852f16970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset makes the Go To Declaration hyperlink resolver produce
a list of possible jump targets. Therefore, if you for example point
at @android:string/ok, you will get a popup listing all the various
string.xml files that define a translation for this string. If there
is a current configuration (which would be the case if you are
pointing at a resource url from a layout file, but not from a Java
file or a manifest file) then the declaration which best matches the
configuration is listed first, followed by everything else in
alphabetical order by the folder name.
This uses the resource maps which the IDE is already maintaining for
rendering, so it can compute the set of hyperlinks cheaply.
In addition, the hyperlink resolver now goes to the direct declaration
of the given resource. This definition can in turn reference another
resource url.
There is one exception to the instant resolution of files: ids. In
layouts it's common to define ids in place (via @+id), and these are
not available in the resource map. Therefore, if no id is found
defined in a value folder, then the search is deferred until the link
is actually clicked. The search will now search not just the base
layout folder, but all layout folders, starting with the same folder
as the link source, followed by all configuration-compatible folders,
followed by all folders.
Change-Id: I20fd4f5836e41e5a9839124b7be3a3230f5198f4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset contains the following improvements to the palette:
1. Display modes. The palette now supports several different view
modes, and you can switch these via the context menu. The modes
are:
a. Previews. This renders previews for all the views using the
current SDK platform, theme, screen density, etc.
b. Small Previews. This is like (a), but scaled down to 75% size.
c. Tiny Previews. Like (a), but scaled down to 50% size.
d. Text + Icon. This shows an icon and the name of the view; this
is the same as what the palette has looked like before this
changeset.
e. Icons only.
All the modes, except for the Text+Icon mode, will lay out the
views in a row (with vertical centering) to fit as much as possible
in the available space for that category.
The view mode, along with other view flags described below, are
preserved across IDE sessions.
2. An accordion view. The palette is now using an Accordion control,
which means it by default will keep a single category open, and it
will always ensure that ALL the category labels are visible in the
current view without scrolling. Via the context menu you can turn
off the auto-close of the previous category. The accordion view
uses vertical scrollbars within each category content area, if
necessary.
The accordion view renders the category headers using open/close
folder icons, a bold font, and a background gradient which varies
between the normal and hovered states.
3. Categories. The category metadata is now used to organize the views
into a handful of different categories. The categories can be
enabled and disabled via the context menu. When you turn off
categories, you get all the views in a single large list.
4. Alphabetical sorting. By default, the views are now sorted
"naturally" (e.g. the metadata provided order, where important
views are listed first). You can switch it to alphabetical order
via the context menu, in which case the items are listed in
alphabetical order, either within their individual categories, or
if categories are turned off, the global view list.
This changeset also adds a new SWT ImageControl. This is necessary to
display the preview images, because the CLabel, which is usually used
to display images in SWT, is hardcoded to hide the icon if there is
not enough horizontal space to display the full label (even when it
has no text label), so for wide preview images the images would simply
disappear when the palette was resized.
Change-Id: I1e1fe051947809206ef9f3a2dfa2fbeae0341107
|
| |
|
|
|
|
| |
Add a dummy child to the TabHost on drop.
Change-Id: I0f00dda449b81025c24933b6e1578b6b1a431272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have certain types of errors in your project, then rendering
will fail with messages that may be confusing.
This changeset attempts to identify some of these common scenarios and
offer detailed explanations to guide the user in the right direction.
Specifically:
1. If the project contains aapt errors (which means aapt did not run
successfully), AND the rendering failed with an error related to
resource lookup, then begin the render error message with an
explanation in bold that this project contains resource errors that
could explain the below rendering errors, and to investigate those
resource errors first.
2. If the project contains javac errors, AND the rendering failed
after the custom project class loader has been consulted, then
display a message stating that compilation errors could have
caused the failure and to investigate those errors first.
3. If a custom view is loaded, and it does not provide a 2- or 3-
argument constructor (which takes an AttributeSet), emit a warning
that XML attributes on the view will not work.
In addition, this changeset cleans up a few other related things:
- Tags are no longer displayed as part of the error message; these are
intended for internal checking only (for example to identify
resource errors from other errors)
- The error display text can now show a vertical scrollbar if the text
is longer than the available space.
- The code which marks the project class loader as used is marked used
as soon as it's asked to resolve a class name, rather than at the
completion of a successful load, since we want to know about failing
custom classes as well.
Change-Id: Ib37a329eed44719ecf741b96ff96747ec4f92ad0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a new dynamically populated context menu named "Play Animation", which
contains 4 sections:
- First, the most recently played animation name. This is initially
empty, but once you've played an animation, the most recently one is
listed there.
- "Create...". This is a shortcut which opens the "New Android XML
File" wizard, pre-configured to point at the current project and
with the Animation category selected.
- "Android Builtin >". This is a submenu (also lazily populated) which
lists all the builtin Android framework animations alphabetically.
- The animations in the current project, if any, listed
alphabetically.
Selecting any of the project or framework animation names will cause
the animation to be played once. During the animation, selection and
hover overlays are temporarily hidden.
This is just a start; we should play/rewind/stop buttons, maybe a loop
toggle button, etc somewhere on the screen when you've selected an
aniation. We should also try to filter out animations (especially
framework ones) that have no effect on the current selection.
Finally, error messages need to be handled better since we are reusing
the render session from the editor.
Change-Id: If113b02d458972b5cc2cb253dd9e6c312b8302a9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IPath#makeRelativeTo(IPath) was not supported on Eclipse 3.4, so we
had a local version of it in our sourcebase, as
Sdk#makeRelativeTo(IPath,IPath). However, our version only works
correctly for directories, not plain files, but I had been using it
for files as well.
Now that we no longer need to support Eclipse 3.4, remove our local
version and use the builtin path conversion method.
(Fixed some invalid javadoc too)
Change-Id: I233875e1ecc758eb1ed333686b319b138eb47c4a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Make the outline use StyledStrings such that we can use different
colors for different elements in the outline. Use the decorations
color for the element type that follows the id.
2. For elements that define a "text" property, include the text (or a
prefix of it if it is long) in the outline. Thus, for a Button you
might see something like "Button01 - "Submit Order").
3. For elements that define a "src" property, show the
source. Therefore, for an ImageView you might see "ImageView - logo".
4. For <include> elements, show the name of the included layout.
Change-Id: Ibd4c8339ea0e03c969ccaec1a67bc64436ed67af
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an "Extract As Include" action to the context menu which lets you
extract a set of selected views and move them into a separate layout
file of their own, and insert an <include> reference to the new view
in place.
You can select multiple items as well (provided they are adjacent
siblings) and in that case the newly extracted layout will use the
<merge> tag as the root element.
This changeset also adds a name validator for resource names, used
both in the new-name entry field for extracted include layouts, as
well as in the New XML File wizard. It enforces that the name (except
for the .xml suffix) is a valid Java identifier name (since otherwise
the R file will have compilation errors.)
This changeset also extracts various inlined String constants like
"xmlns", "android" (as used in namespace prefixes), "@id/" etc and
replaces them with constants.
Change-Id: I3eca8b6afd23f22ca9299ff22c614b4ffd3299bf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have support in the layout library for handling included views
where the include tag is associated with the root elements rendered in
that included view.
However, there are various scenarios where this is not adequate:
1) including <merge> views (see issue 13288)
2) older layout libraries
This changeset fixes the above scenarios, as well as an additional
scenario (where rendering included content in an outer layout did not
work properly if the included elements were not at the root level).
It does this by moving the CanvasViewInfo construction into a set of
factory methods which handle various different hierarchy types of
ViewInfos. ViewInfos with null keys at the top are handled one way;
ViewInfo subtrees that introduce null keys further down are handled
another, and it attempts to match up elements in the UiViewElementNode
hierarchy with ViewInfo objects. If it cannot match them one to one,
it will create a single "bounding box" view containing all unmatched
ViewInfos. This will for example produce a single box out of included
<merge> views.
This changeset also handles multiple includes. The "overlay mask"
could earlier only handle a single include whereas the rewritten code
can handle multiple "holes" in the mask by computing the set of
subrectangles remaining after punching out the include holes.
Change-Id: I163413c7fc301f25c4523b0ee03690f983a05322
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset removes the various hand-written mock implementations
of key Eclipse interfaces (IProject, IFile, IFolder, etc) and replaces
them with EasyMock proxy objects.
This makes our codebase buildable on Eclipse 3.6+.
(Also fix a couple of test warnings for abstract testcase classes
which were missing tests)
Change-Id: I70553ab95dc9386da1c7eed139d3ef587d929478
|
| |
|
|
|
|
|
|
| |
The Show Include facility doesn't work properly until we backport
layoutlib to all the 2.x SDK layoutlibs. The Play Animation test
isn't yet productized.
Change-Id: Ib4cd0f0cff029fe23ffaca72a96561a0d748f86f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds Android-related hyperlinks to Java files. If you for example
have this code in your Activity:
setContentView(R.layout.main);
and you control click on "main", this will now offer (in addition to
the normal "Declaration" hyperlink) go to "XML Declaration"), which
will then warp to the main.xml file.
You can add in the second modifier key to directly jump to the Android
resource and bypass the normal Java declaration (which would take you
into the R file). The Android Java hyperlink works from R file field
declarations too by the way.
This now also works for id attributes defined inline, so if you for
example jump to R.id.Button01, and this will open the first
@+id/Button01 element found in the layout directory.
You can also open non-XML references, such as @drawable/icon. This
will run the Eclipse open command on the icon.
The processing of XML regions is improved, so it will now only
highlight say the value part of an XML attribute, or the name part or
the element tag name part.
Finally, the hyperlink resolvers can now jump into @android resource
files (as found in the SDK data directory). Thus, you can warp into
(say) @android:drawable/alert_dark_frame.
Change-Id: I83fcd1ffb08590f7f587b90f5c64784fe8ce5f67
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds basic hyperlink handling to Android XML files
(such as AndroidManifest.xml and layout xml files).
It registers a hyperlink detector for our XML files, and the hyperlink
detector looks up the XML model and finds the node and attributes
under the cursor. If found. it then checks these attributes for a set
of patterns that it can link to:
* If it finds an <activity> element, it looks up the activity name and
the package on the root element, and lets you jump to the activity.
Ditto for services.
* If it finds a @layout attribute value, it attempts to open the
corresponding layout file in the res/ folder in the project. Ditto
for other per-file resources like @drawable, etc.
* If it finds a value resource, like @string, @dimen, etc, it will
search through the various XML files in values/ and open up the
corresponding XML declaration in the editor with the declaration
selected.
Note that the resolver does NOT use proper full resource resolution
based on the SDK parsing that we have in use within the layout editor
etc. That's the natural next step.
Change-Id: I5880878fe67f26fb8d3b08b808c02baa1049f2c5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add improved support for includes. You can now view and edit a layout
within another containing layout. On a page with includes, you can
double click to warp into the included layout, and it will be shown
within the container layout (but with a semi-translucent mask to make
it obvious that you are editing only the included content, not the
container.)
You can also right click on a view and choose "Show Included In",
which is a pull-right which lists all the other layouts that are
including this view. (If there are no such views, the menu item will
be empty).
In addition, this changeset adds code to detect if there are cycles in
the includes, and if so adds a problem marker in the Problems view
listing the offending chain of includes.
This is all managed by a new "IncludeFinder" class, which listens for
resource file edits (so it only kicks in when you save an XML file,
not after each XML edit). It scans layout XML files for includes and
maintains a map of file includes. This is done such that it can very
quickly provide a list of all files that are including a given target
file. This list is also persisted across IDE sessions via a project
property.
Also fixes outline-expansion to ensure that the outline always shows
the top level children.
Note: The include-relationships are based on the base layouts (the
ones in layouts/, not in customized versions in layout-land,
layout-port, etc.)
Change-Id: I710560f03f7e214219669af8ffba91874d9881b9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you drag in the canvas, show a drag image for the view being
dragged. The drag image is using 30% translucency such that it does
not obscure the drag feedback below it.
We're grabbing the image data right out of the rendered scene and just
copying out the rectangles for the bounds of each selected item. This
has to take the canvas zoom into effect too.
While in the zoom code I modified the Zoom In and Zoom Out buttons to
only zoom by a factor of 20% rather than 100%.
I cleaned up the Pair class slightly; in an earlier version of this
fix I was using it to pass back two results from the rectangle
painting function; I don't do that anymore but the Pair might as well
be cleaned up.
(By the way, as suggested in review #19035 I rewrote the FIXME comment
related to resource lookup and put it in this CL rather than revising
the other one.)
Change-Id: Iabe6e29c4073252f5046e3c26b56f4e7674a3f3a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, the AddonsListFetcherTest#testLoadSample_1 was failing on the
Mac, because the source code contained non-ASCII unicode characters,
and the encoding differs between Windows, Linux and Mac -- and on the
Mac the characters were garbage (not the intended Japanese
characters). Fixed by using unicode escape sequences to define the
expected output instead.
Second, rename the AbstractLayoutTest to LayoutTestBase; the test
runner (for plugins, not unit tests) was assuming this was a test case
(even though it's an abstract class!) so it was emitting a warning
about the class containing no test cases. This is simply a base class
for all the individual layout tests defining a bunch of useful
inherited shared behavior, so rename to avoid the warning.
Change-Id: I6e29316c5644db35051218aef8b99ac41ab0cda4
|
| |
|
|
|
|
|
|
|
| |
On double click, if the clicked area originates from an <include>'ed
XML file, open the included layout in the editor. Also opens
files in the @android: namespace if available, for example if you
inculde @android:layout/select_dialog_multichoice.
Change-Id: I215c411257717f7b97e7b0ee1d5498c318cdb04d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds support for adding custom-logic to initialize
views, both to add children and default attributes and to customize
layout attributes when added to a new parent.
First, there is a new "onCreate" hook which is called to notify a view
rule that an instance of its corresponding view has been created. This
lets the ViewRule perform custom initialization of the object. The
ViewRule is told what type of insertion occurred, such that it can
distinguish between a newly created view, a view that is the result of
a copy/paste, and a view that is part of a move operation.
The changeset adds a number of new ViewRules which take advantage of
this:
- A TabHost rule creates the various skeleton children that are
required, such as a TabWidget child with id @android:id/tabs and a
FrameLayout child with id @android:id/tabcontent
- A DialerFilter rule creates the mandatory EditText children ("hint"
and "primary")
- The HorizontalScrollView rule creates a horizontal LinearLayout child
- The ImageButton and ImageViewButtons initialize the "src" attribute
to a sample image
- The MapViewRule initializes the apiKey attribute
In addition, views are also notified when a new view is added as a
child, such that they can perform additional customizations, in the
form of an "onInsert" event.
The most important application of this is LinearLayoutRule, which uses
this to set reasonable defaults for the layout_width and layout_height
parameters. It uses metadata (which is currently built into ADT but
would ideally migrate into our XML config files) to determine whether
a given child prefers to grow horizontally, grow vertically, both, or
neither, depending on the surrounding parent context. For example, an
EditText will default to filling the parent width if it is in a
vertical LinearLayout, but it will not grow vertically in a horizontal
linear layout. And so on. Various other rules also use the onInsert
event to tweak children attributes. A ScrollView will for example
always initialize its single child to match parent.
Views can now also add plain menu items into the context menu, and the
TableViewRule adds one such action: "Add Row", which appends a new row
into the table.
The Palette Preview code also invokes these creation hooks, such that
if you for example drag a DialerFilter it can properly render since
the mandatory children are created up front. This required various
changes to the preview code to be able to handle XML edits by the
rules.
Finally, this changeset includes various other misc changes that I
performed at the same time:
- Removed SWT dependency from the ViewRule classes (SWT Rectangle use
in Rect)
- Fixed AbsoluteLayout unit test (issue 3203560)
- Fixed positioning of the preview outline in LinearLayout when only
one of the dimensions are clipped due to a smaller target layout
Change-Id: I5956fe4e7a31a20b8dd2f9d9b0c1f90e2f75d68a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add in a drop shadow to items dragged from the palette. The primary
reason we need this is that some views (in some themes) only render
light content on top of a transparent background, which makes them
nearly impossible to see on a gray background (e.g. over the palette,
when you initiate the drag). The drop shadow helps add contrast. It
also makes the drag look better since it helps the drag preview image
stand out from the background and visually appear to be lifted on top
of it.
Since we're doing more image processing now, I moved the existing
non-SWT image manipulation methods into a separate ImageUtils class.
This changeset also fixes the way we pick the color to crop out when
using older layout libraries (without transparency support). We now
pick a pixel closer to the bounds of the rendered view such that we
for example can handle themes like the dialog theme.
Change-Id: Ifcbb840ef715bf26a9609f6996a4f136de5ca754
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This checkin renders previews of Android views as you drag them from
the palette, using the current theme settings you have for the
associated editor. If you are using version 5 or later of the layout
library, you get full alpha-blending on the rendered views (so for
example in an analog clock you see right through it), and on older
version it simply crops out the edge color.
The preview image is semi-translucent, and the image is centered under
the mouse pointer. The drag feedback operations all relate to the top
left corner of the dragged item, so they are passed in the mouse
cursor minus the delta to the top left corner of the image.
The size of the preview is also used to provide bounds for the drag
feedback, such that we can show a preview rectangle rather than just
the insert point over layouts that support drop feedback.
Some views can't be rendered (e.g. QuickContactBadge), and some views
don't have any pixels painted (e.g. all the empty layouts), and in
that case we fall back to showing the palette item itself (the icon
and label) as you're dragging.
There's also a new utility class for SWT common utilities, like image
conversion.
Change-Id: I315c2dd733317bbada8dae89f57280ced2d7bb51
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you add a new container, such as a LinearLayout, it is usually
invisible. The reason for this is that an empty layout has 0 width and
0 height. There are two existing features in the layout editor to deal
with this: (1) Outline mode, which renders rectangles around all
views, and (2) Padding mode, which adds 10 pixels of padding to all
views. In combination, these two modes will create a rectangle for
empty layouts making them visible and user-manipulatable -- you can
for example select or drop into them.
This changeset attempts to make dealing with these types of containers
easier and more discoverable. It adds a new temporary mode where empty
containers (and only empty containers) are automatically padded and
have their outlines painted. And more importantly, this is only done
in some limited scenarios: When you drag into, or drag within, the
layout canvas. As soon as you finish the drag, empty containers
disappear again.
Unlike padding mode, we don't enlarge the design surface itself, since
this mode comes and goes easily and frequently.
In addition to this, there is special handling for selection. If you
select a zero-sized element (which for example is automatically done
when you drop a new layout, and which can also be done by clicking in
the outline), then the element is also revealed similar to the
show-empty mode, but in this case only the selected item and not any
other invisible containers are shown.
Change-Id: Ibf3ec6a080a50a8f0f55919c3d3e6c4d2890468d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The icons shown in the palette do not have transparency applied to
them, which means that you end up with white squares on a white
background. This looks okay in the outline view where the icons are
shown on a white background, but it does not look good in the palette
where they are on a gray background.
This changeset fixes the icon generation a bit such that it records a
transparent pixel for these icons. It's not an ideal solution since we
only have on/off transparency, not an alpha channel, which means that
we can't have a smoothly anti-aliased edge of the circles regardless
of the background. Luckily, a light color seems to work fine for both
cases.
While I was at it I also adjusted the font positioning slightly on the
Mac platform for some letters that needed it.
Change-Id: Idf5a4f6709096935122bfe05cfecffc63e74a863
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset improves the formatting of XML edited by the layout
editor in two ways:
(1) It improves the way the layout editor handles insertion and
deletion into the XML document; it looks up the indentation of the
sibling and parent elements and attempts to correctly indent new
elements based on the existing surrounding formatting, and it also
attempts to clean things up correctly on element deletion.
(2) It adds a new user option for turning on automatic XML
formatting. When this is on, it will invoke the Eclipse XML formatter
on portions of the XML after each edit. This will ensure that the
document adheres to the user's preferred formatting settings (maximum
line width, tabs versus spaces, line breaks before attributes, etc.
Change-Id: I74f9a4240a8c5ca4295c01f3b55751ef10b1c1b0
|
| |
|
|
|
|
|
|
| |
Mark internal strings as NON-NLS in rule classes. This code was
initially written in Groovy which is why it didn't have NON-NLS
markers.
Change-Id: I74517771271e54f165332543092a9d29fc2bc52a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This checkin adds support for gestures and overlays. Gestures are
sessions of mouse/keyboard activity, and this is documented in the
javadoc for the new Gesture class. Overlays are units of graphics, and
these are documented in the Overlay javadoc. The gesture architecture
lets us isolate the logic for each different type of operation
(marquee, resize, move, etC), and with associated overlays we don't
attempt to for example paint drag feedback during a resize operation,
etc.
The checkin also adds marquee selection (as a second gesture, in
addition to the existing drag & drop based move gesture), along with
some associated changes in how the root view is treated.
As part of isolating the mouse handling and painting related to
gestures, painting etc., I also refactored the code quite a bit.
LayoutCanvas which used to be a large class has been split into a
number of new classes, one for each area of responsibility:
- The mouse listener and drag & drop code has been moved into a
GestureManager. (A lot of the drop handling code also came from the
CanvasDropListener class.)
- Code related to maintaining the set of rendered views, and
performing searches in the views, has been moved into a
ViewHierarchy class.
- Code related to selection has been moved into a SelectionManager.
- Various individual painting pieces (outline, hover, etc) have been
moved into individual Overlay classes such as OutlineOverlay,
HoverOverlay, SelectionOverlay, etc. This also moved associated
resource allocation and cleanup into the overlays.
- New coordinate classes, ControlPoint and LayoutPoint, are used
instead of ints and plain Points to make it really clear which
methods require coordinates in the layout (such as the
ViewHieararchy search methods) and which ones require coordinates in
the canvas control (such as paint methods). There are factory methods
to automatically construct the right kind of coordinate from
different types of mouse events, as well as methods to convert
between the two.
I also tweaked the visual appearance of selection a bit more, and
some other misc cleanup.
Change-Id: I666aabdcd36720bebe406b68237e8966d985fb8f
|
|
|
Eclipse has the ability to spellcheck comments, and it ships with an
English dictionary. However, many valid terms in our codebase is not
in this dictionary. This checkin adds a dictionary file which contains
many of the valid spelling words used in our codebase.
(Unfortunately, Eclipse does not support "project dictionaries" like
some other IDEs where individual user dictionaries are merged with
shared project dictionaries. However, this new dictionary should be
useful for developers who use a dedicated workspace for Android
development.)
This changeset also fixes some typos.
Change-Id: Ied6647f6cb550460c0087498f8c94fa6624e3b4e
|
