| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: Id3628f87569cab8df14f885274137a332a074550
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The XML pretty printer was moved up from the Eclipse plugin
into common (such that for example the resource merger can
use it).
This CL removes the old XML pretty printer and replaces it
by a subclass which customizes the formatter slightly (in
particular, taking advantage of the Eclipse DOM's ability
to remember whether an XML tag was an empty tag such at
<this/> rather than <this></this>.)
Change-Id: Ie0865c3c35f1340fa4dcaf42253599f278ce4997
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds custom view completion to the content assist.
Code completion for elements (e.g. from text context or inside a <)
should now include custom views found in the project, and prefix
typing should work as well.
Similarly, code completing inside a <fragment> name attribute or a
<view> class attribute should complete fragment and view classes.
It will display javadocs for these classes, if available.
It also hooks up class completion in manifest files, so completing
<activity>, <application>, <receiver> etc android:name attributes
should show matching classes corresponding to the tag being edited.
The completion will also always complete theme references (?) even
when there is no known metadata for the tag, such as for an arbitrary
custom view.
Also fix descriptor metadata such that <view> and <requestFocus> show
up in code completion, works properly for layout editor palette drag
(with a class selection popup) and with a suitable outline icon.
Also tweak refactoring such that it handles both class= and
android:name usage for <fragment> elements.
Finally, for the LinearLayout automatically added inside new
ScrollViews, set the vertical attribute since that's usually what you
want.
Change-Id: Ifc98c19607ddc4e69d7645f2720120ce72d0cd95
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds support for renaming resources.
There are several new hooks for initiating a resource rename:
(1) You can use the same keybinding as in Java files from XML files to
initiate refactoring; for example, place the caret somewhere in
@+id/foo or @string/bar and hit the refactoring keybinding, and a
rename resource refactoring dialog shows up.
(2) Invoking Quick Assistant in an XML file (Ctrl/Cmd 1) will offer to
rename the resource, if the caret is over a resource name.
(3) Renaming an XML or bitmap resource file, such as
res/drawable-hdpi/foo.png, will now initiate the same XML resource
naming machinery as above to update all resource references, plus
it will also update all the other versions of the same file
(e.g. in res/drawable-mdpi, res/drawable-xhdpi, etc.). Assuming an
R field exists (e.g. the project has been built), it will also
optionally update all Java field references.
(4) Invoking renaming in the layout editor (via the rename keybinding,
or via the context menu, or via the property sheet's "..." button)
will also initiate id resource refactoring. Editing the id
directly in the inline editor for the id will pop up a dialog
asking whether to update references as well, along with a "Do not
ask again" checkbox.
(5) Finally, there is a renaming participant registered which will
discover whether an R field is renamed, so if you go and rename
R.layout.foo from Java, this will also kick in all of the above
machinery - renaming layout files, updating resource references,
etc.
If the renamed resource is in a library project, the refactoring
will also look at all the including projects and offer to update
references there as well.
Finally, this CL goes and fixes a few bugs in the existing refactoring
operations; in particular, making sure that they not only look at
files in layout/ but in all folder configurations containing layout
files. It also adds refactoring unit tests.
Change-Id: Ie88511a571b414fdc5be048e781fe29a34063cbf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset moves most constants into the SdkConstants
class, and gets rid of AndroidConstants and LintConstants.
It also migrates all non-ADT specific constants from
AdtConstants into SdkConstants. It furthermore moves various
other constants (such as those in XmlUtils and ValuesDescriptors)
into the constants class. It also fixes the modifier order
to be the canonical modifier order (JLS 8.x).
Finally, it removes redundancy and combines various constant
aliases such that we don't have both NAME_ATTR and ATTR_NAME
pointing to "name", etc.
Change-Id: Ifd1755016f62ce2dd80e5c76130d6de4b0e32161
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
The visual refactoring for converting a LinearLayout with a <TextView>
and an <ImageView> adjacent into a single <TextView> using a compound
drawable, needed to properly handle spacing between the two
widgets. This changeset updates it to convert margins between the
views into a single drawablePadding attribute.
Change-Id: Idb077e3324c279d41fdc0baa68008fe862d8181a
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ManifestMerger library needs to look up the prefix to use for the
Android namespace, and the Document.lookupPrefix method is not
implemented by the Eclipse DOM implementation (which throws an
exception). However, we have an implementation of this in the ADT
plugin.
This changeset creates a new XmlUtils class in the common/ library
(which is accessible by both ADT and the manifest merger, and the
anttasks where the manifest merger is used), and moves the namespace
prefix lookup code in there. It also moves the XML escape methods
into that class. It also adds a new method to the ManifestMerger for
merging directly from documents (rather than files), and makes sure
that all the merging code goes via the prefix utility method rather
than calling the document.lookupPrefix method.
Finally, it moves the various string constants associated with XML
namespaces into the single XmlUtils class, since these were spread
across several different classes before (and many of them are needed
in the XmlUtils class).
The vast majority of the diffs in this changeset are related to simple
import statement changes to reflect the new locations of these
constants.
Change-Id: Ib8f3d0e5c89e47e61ea509a23925af7b6580abee
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset fixes some miscellaneous in the GridLayout support.
The gravity handling code (which creates a bitmask for gravity from
XML attribute values) was pulled out of the change layout refactoring
such that it can also be used by the GridLayout. This is done to
figure out where cells are not bound to the top or left corners, in
which case they should not be considered when computing a suitable
right or bottom edge for splitting a cell.
There's also fixes for a problem where certain negative constraints
would be offered, there were tooltips when only one of the two
dimensions produced suggestions (and you can only drop when both are
valid).
When removing children back to a blank layout, reset the columCount
to 2.
And finally there were some problems where the columnCount was larger
than the number of actual used columns in the table, where dragging
near top/left corner would use some of the later columns rather than
the first available one.
Change-Id: Ice22754fb14659812b54019452aeca6daaeede10
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 changes the Actions mechanism for view rules to add
support for the following:
* Delayed computation of submenu contents. Before this, a view rule
would have to produce the full tree of actions to be shown in menus
and submenus - for example including all the properties, and in turn
all the enumerated values for those properties and so on. Now
there's a Provider interface which can be used to compute these menu
items only when the menu is actually opened. The properties menu now
takes advantage of this.
This was also necessary to implement the following new feature:
* The layout editor context menu now also lists not just the
properties for the currently selected views, but also the
properties for the parents. For example, if you open the context
menu, you'll see the properties for the button you just right
clicked on, but there will also be a "frameLayout1" submenu
containing the actions for the <FrameLayout> parent of the button,
and a "linearLayout1" submenu for the parent linear layout. This
is useful when a parent layout doesn't have blank space on its own
so it is difficult to target.
A future CL will use the lazy initialization to add more options to
the properties menu.
* Support for arbitrary nesting. Submenus can contain submenus can
contain other submenus etc.
* Custom ordering. This changeset moves the "sort priority" concept
(which was already used for layout actions) up to all actions, which
makes it easier for rules to cooperate on ordering because instead
of appending or prepending to the superclass' context menu result,
actions can now just be initialized with a sorting priority value
which makes it trivial to interleave actions regardless of who adds
them. This also makes it a lot easier to use custom ordering in
choice menus where the ordering used to be alphabetically sorting on
keys.
* Improved support for multiselection. The callback interface now
takes a list of nodes to apply the callback to, and actions can
indicate whether they support multiple nodes. This makes it possible
for actions to more directly support the case where you apply an
action to multiple nodes. As before, the available actions in the
context menu is limited such that it only shows the actions common
to all. But now those actions can do something specific. For
example, if you select "Edit Text..." on many nodes, you will get
the input-string dialog once, and then the value is applied to
all. Similarly, if you select "Edit Id..." it will ask for a
separate id for each value (and you can cancel out of this loop).
There are various API changes too. Since the Choices action (which had
a map-based set of values) was removed, the OrderedChoices is now
renamed Choices. The Actions subclass of MenuAction which all actions
also extended has simply been moved up to the top level MenuAction.
And MenuAction has been renamed to RuleActions since they are used
not just for menus but for toolbars etc and the key thing about this
interface is that they are intended for use by rules.
Change-Id: If49f75213f2041ebfef7e84254d70d219bb766ab
|
| |
|
|
|
|
|
|
|
| |
I changed the code which draws drop feedback recently to use a more
efficient call (calling drawRect(x1,y1,x2,y2) directly instead
of constructing a new Rectangle object and calling drawRect(Rect).
Some golden files checking graphics output needs to be updated.
Change-Id: I369fed9cb0756ff4f3aa970c1bdd552d0f55faaa
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset modifies the layout editor such that it writes
attributes in a certain order:
* id
* style
* layout_width
* layout_height
* other layout_ attributes, sorted alphabetically
* other attributes, sorted alphabetically
The layout editor will produce attributes in this order when
- New widgets are dragged into the layout
- Widgets are moved in the layout
- It will also insert attributes in the right place when they are set
as the result of (for example) using the context menu actions.
Note that this ordering is applied unconditionally - there is no user
setting to turn it off. However, note that the current behavior is
random - moving a view for example will scramble the attributes (in an
order which is related to hashkeys in a map), so the option would be
"sort attributes logically" versus "sort attributes randomly"; if we
want an option to "leave attribute order alone" that will need to be
implemented.
Limitations:
- This does not yet modify the formatter to reorganize attributes.
Thus, Ctrl-Shift-F to reformat the XML will not change attribute
order.
- It does not fix the problem that the XML model updater does not
respect the formatting settings (such as one newline per attribute)
when manipulating attributes.
This will be addressed/worked around in subsequent CLs.
Implementation Note:
The Eclipse XML model updater will unconditionally *append* any new
attributes. We take advantage of this to perform attribute sorting by
ensuring that we always insert new attributes in the right order. We
also check for existing attributes and any which fall
lexicographically later than the new attributes are removed and
reinserted in the right sequence. In order to avoid performing these
removals and additions repeatedly on a node when we set multiple
attributes, and to avoid flushing attribute changes *immediately*
(which was the case until this), we now queue up all pending attribute
values in the nodes and apply them at the end when all attribute
changes for a given node are known.
Change-Id: If39f8c29f26e281f7c6622a31e11ba49724d274a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Fix 18298: ADT r12 layout editor uses locale specific decimal
separator leading to unparsable XML
Change-Id: Ideae319e41f8a7e34075065c63247d50cdf830c5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 preliminary support for fragments:
* Add <fragment> to the palette, along with a drop handler which pops
up a class chooser to pick the Fragment class; all project
implementations of android.app.Fragment and
android.support.v4.app.Fragment are listed.
* Adds a fragment descriptor such that code completion works for
<fragment> elements
* Fix project callback such that it does not complain about a missing
class "fragment".
* Fix outline to display the name of the fragment rather than the
fragment tag name.
* This changeset also centers the label in MockViews since those are
still used to render fragments
Change-Id: I6e062970b335d9c95870f181ed408960978c423e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout actions bar shows actions of two types:
* Actions which edit attriubutes of the "current layout"; typically
the parent of the currently selected views. For example, the
"orientation" or "baseline" attributes of a LinearLayout.
* Actions which edit the layout parameters of the selected views. For
example, the "weight" attribute of children in a LinearLayout.
One thing which was missing is adding in layout actions for views that
are children. For example, the TableView now has an "Insert Row"
action. If you select the table itself, rather than a child within
the table, you would not see the Insert Row action. Similarly, if you
drop a new LinearLayout, you cannot toggle its orientation attribute;
it won't be shown, or if it is within another LinearLayout, you will
see an orientation toggle but it controls the parent, not the newly
selected LinearLayout.
This changeset addresses this by adding a new section of actions on
the right hand side of the actions bar, which contains the layout
actions which apply to the selection, regardless of the parent type.
For example, if you have a LinearLayout containing a TableLayout, and
you have selected the TableLayout, you will first see the LinearLayout
actions, then the LinearLayout layoutparams actions (which will be
applied to the TableLayout), and finally the TableLayout layout
actions (insert and remove row).
This changeset also improves the TableLayout insert row action to
insert the row before the current selected row (if any) rather than
unconditionally appending it to the end. It also selects the table
after creation to make it more obvious where it was added. The new
ability to select nodes from layout rules is also used in a couple of
other places.
Change-Id: I7cd8f75e61fc916bc75ed5ad156440f0f8cbd786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the include tag back into the palette, and add special drop
support for it such that when it is drop, a resource chooser pops up
and asks you which layout to include. A new validator prevents any
layouts from being chosen that would result in a cyclic
dependency.
This requires some infrastructure changes: First, drop handlers must
distinguish between a view getting created as part of a previewing
operation and getting created interactively. Second, in order to
support cancel removing an inserted include if the user decides not to
set an include, the node wrappers need to support removing an element.
Also, use the metadata originally intended for the preview icon
factory to also bypass palette drag previews for widgets that don't
have UI.
Change-Id: I1bdd1766ca4cfa2fdbca25b77c50c74e9c332cbd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Move all the resource query methods that returned an array of 2 Strings
to return a pair of ResourceType and String.
Change-Id: I6b8447aa27005de786e2defef81ad88a72363523
|
| |
|
|
|
|
|
|
|
|
| |
When editing the text property (via "Edit Text..."), show the
ResourceChooser (assigned to ResourceType.STRING) instead of the more
generic ReferenceChooser.
Some minor tweaks to incorporate feedback on an earlier CL.
Change-Id: I935456075910acd59cedbfeb4cb43680038e412d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have context menu items for editing the properties of the currently
selected view, but it is only available for boolean and enumerated
properties.
This changeset makes it possible to edit these properties in three
ways:
1. It adds in all the other properties to the Property context menu,
but instead of pullright menus, the actions have "..." as a suffix,
and when selected will open a dialog asking for the new value.
(This is similar to how custom layout width/height values are
handled.)
If the attribute represents a reference-type, then the Reference
Chooser (also used by the property sheet) is shown, and if not just
a plain text field.
(This context-menu feature was requested by external users.)
2. It adds the "ID" property as a top level item that can be edited
directly via an "Edit ID..." menu item, right next to the "Layout
Width" and "Layout Height" properties which are also special-cased
at the top level.
3. For Views that have a "Text" property, this property is also added
at the top level to be able to set it quickly and conveniently. As
soon as we get inline editing we can consider whether this is still
needed.
In addition, the changeset extracts constants for the various ids used
for action identity, and makes a common function for setting a
particular node attribute.
Change-Id: Ib86a8a5412c39117fe250ce5788d8457a0e3fbe8
|
| |
|
|
| |
Change-Id: I5c37e4b4dd83bc239ed242709ede70982f14705f
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the "Custom..." items from the menus (which were not hooked up
anyway).
If there is a custom value (e.g. not fill_parent, match_parent or
wrap_content), add it into the menu directly (such as "42dip"), and
show it as selected.
In addition, always add a "Other..." menu item at the end. Invoking
Other will pop up a dialog asking you to enter a new custom value,
which is then applied.
This addresses issue #2 in multi-issue bug
13134: Eclipse layout editor contains many bugs
Change-Id: Ic1a84a789c53dd3a15b807a29461b80dc1b49c9f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, fix absolute layout such that it properly handles both screen
scaling as well as various screen resolution densities when it
computes the dip positions.
Second, pass the bounds surrounding the mouse position when a drag is
initiated to the view rules. This is used by both absolute layout and
relative layout to properly handle dragging bounds. In particular, in
relative layout this is used to match a border not only when the mouse
cursor gets near the edge, but when the bound edges also get near the
edge. In absolute layout this is used to show a correct bound
rectangle that has the proper offset from the original drag position
(which may not be the center, which until now it was assuming).
Third, in RelativeLayout, when there are no children, offer a left
alignment regardless of where you are within the rectangle. This is
similar to how LinearLayout works.
In addition, two internal changes:
* Factor the various RelativeLayout string constants into the
LayoutConstants class. This had the nice side effect of revealing a
typo where we were referencing a non-existing value! Constants FTW!
* Make the RulesEngine log the exceptions, not just the error
messages, thrown by IViewRule calls. That way the full stack trace
is available in the Error Viewer, including line numbers etc.
Change-Id: I0b83df71b36741e65a1eb2003ed044157eb6f0cd
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes issue 13051: New layout editor always insert "match_parent",
even on older platform.
View rules can now look up the API level of the current project, and
based on that choose to use match_parent or fill_parent when they need
to manipulate the layout attributes.
Change-Id: I861e1f7f7409c40c05b1472268f120806667025c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset contains only renaming of some classes (and a couple
of >100 column adjustments), no semantic changes.
The name changes are:
BaseView => BaseViewRule
BaseLayout => BaseLayoutRule
ScaleInfo => CanvasTransform
CanvasSelection => SelectionItem
PropertySheetPage2 => PropertySheetPage
OutlinePage2 => OutlinePage
Change-Id: I14d8c711b12154f4fcb2169129fd553e31fdab84
|
| |
|
|
|
|
|
|
|
| |
Combine the constants in BaseView and a LayoutConstants class over in
the internal packages into a new LayoutConstants class, and reference
these constants elsewhere (statically imported). This was suggested by
in the feedback to review #18971.
Change-Id: I40b76f8f6045c34a98f7a2363f96d2942360d1f3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you have a small and empty linear layout, and you drag something
larger (such as a button) into it, the drop feedback is a bit
confusing: The drop feedback rectangle is larger than the linear
layout, so the bounds are outside the layout. This changeset addresses
this by forcing the bounds of the drop preview to be at most the
dimensions of the LinearLayout itself.
Second, the fix I applied last week to show the last insert position,
did not work in all cases - in particular when the drag originates
outside the canvas itself. To determine if we are inserting at the
last position, look at the number of target node children, rather than
the number of potential insert positions, since in some cases the
number of insert positions will be smaller than the number of
children.
Finally, there was a theoretical bug that if one of the dragged
elements did not non-zero bounds, then the insert position would be
wrong. This is also fixed by this changeset.
Change-Id: Ia30e99f7a3aa45b8091855b69aaef86ec3699405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we have bounds for the dragged items, we show a preview rectangle
where the item will appear after the drop. We show this rectangle
midway between the two siblings that share the insert
position. However, when you are inserting *after* the last item in the
LinearLayout, there is no reason to show the item midway, since at
this point nothing below the insert position needs to be shifted
down. This checkin changes this such that for the last insert
position, we show the rectangle fully below the insert line (or to the
right of it in case of a horizontal layout).
This changeset also fixes a bug where the last (available, not active)
dropzone would not be shown on a palette drag.
Change-Id: If449b43582e072c9e0ad6d7741afbe8e845e8df9
|
|
|
Add layout unit tests, and some infrastructure for testing. Also fix
some formatting errors (>100 column lines) in the previous commit.
Change-Id: I3eabf30998ab7deb84df57e4d0c10cf57ee399d5
|
