| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Change-Id: I9c5ea5183e115582e0b805ca3ec75aad70e4a65c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Also moved the capitalize() method from DescriptorsUtils
to the AdtUtils method with the other general string
utilities.
Change-Id: Iffdbd906c5a4ecbd89c2f037d95f007e44733513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a first cut of previews in the Resource Chooser and the
Reference Chooser. When the selected resource is a drawable or a
color, then a tray is shown on the right hand side of the dialog with
a preview of the given drawable or color. If the color is a state
list, then the fallback color is shown.
The previews only work for resource/reference choosers associated
with a layout editor (because it looks up the associated rendering
configuration from that editor). This should be made more generic
such that it can work for example when bringing up the resource
chooser from a manifest form editor.
Change-Id: I9f2896cb7ce1468076a3ca83f820be7e9affcda6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Also update the IProjectCallback to handle expandableListView.
Change-Id: I36ca8733182bbd9d169fee3e709ebc532fef7b1e
|
| |
|
|
|
|
|
|
|
| |
Since endianess can change between an input and output
image in SwtUtils, it's important to not test pixels as
pure int values but instead use the correct RGB palette
mapping.
Change-Id: Icd3aad499a5cc069e8cc804af7511c95849a78a6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset changes the way the layout editor picks themes when a
layout is opened. It used to just pick the first available theme in
the theme chooser.
Now it performs the following checks, in order:
* Does this layout have a persisted theme setting from a previous run
of the tool? If yes, use it.
* Can the activity for this layout be determined? If so, look at the
manifest registration for the corresponding activity, and if it
specifies a theme, use it.
* If not, does the manifest specify a default theme for the project?
If so, use it.
* If not, is the target SDK version (or the minimum SDK version, if
the target is not specified) at least API level 11 or higher? If so,
the default theme is "Theme.Holo"
* If not, the default theme is "Theme".
* If the file to be opened is included from some other layout, use
the no-decorations versions of the default layouts, e.g.
Theme.NoTitleBar or Theme.Holo.NoActionBar.
* At the end of this resolution, the computed theme is stored as the
persisted theme setting for this layout, so the above algorithm will
only be computed once. We might want to tweak this such that it
distinguishes between a default computation of a theme and a manual
user choice of a theme.
* If the file is opened as "Show Included In" (e.g. rendered within an
outer file) then the theme chosen is the one for the outer file.
During startup, this information will be asked for each and every
layout being reopened, so there is now a "ManifestInfo" class attached
to the project which keeps manifest information around. It checks the
timestamp of the AndroidManifest.xml file and refreshes its
information lazily if necessary.
All themes mentioned in the manifest are listed in a special section
at the top of the theme chooser (below the entry for the default
computed described above).
The code to look up the associated Activity of a layout is using a
simple heuristic: it looks for usages of the corresponding R.layout
field, and prefers references from methods called onCreate or in
classes whose superclass name ends with Activity. I tried a different
approach where I searched for usages of Activity.setContentView(int)
but this failed to identify a number of cases where the activity was
doing some simple logic and didn't pass the layout id directly as a
parameter in setContentView, so I went back to the basic approach.
Change-Id: Ibd3c0f089fefe38e6e6c607d65524990699c86d3
|
| |
|
|
| |
Change-Id: Ie4ccd0d05a85ebbb03fefb9ba1e31dfbde1a89be
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout editor is passed a ViewInfo hierarchy by the layout
library. For older versions of the layout library, it can be handed
hierarchies where the view cookies (which point back to XML model
objects corresponding to the rendered views) that are missing or
ambiguous. For that reason, it has various algorithms to try to piece
things back together, and for example handle <merge> scenarios as best
it can.
This isn't necessary with layout lib version 5 and higher, since as of
version 5 these scenarios are handled on the layout lib side and the
layout editor is passed back special cookies like the MergeCookie to
properly handle the various scenarios.
This fix makes the layout editor look up the layoutlib version, and if
dealing with version 5 or higher, it takes a simpler path to build up
the hierarchy.
This is also necessary to deal with the latest version of layoutlib
which passes a new type of view cookie which the older algorithm
couldn't handle.
Change-Id: I98c3ba5d17ad9d639eb118e4709c0b6bbf815b0a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds support to the Go To Declaration code for styles.
Style strings are a bit different from resource URLs - they can have
an @android: prefix, but they don't specify a resource type. For
example, go to declaration can now jump to the value in the parent
attribute:
<style name="BrowserTheme" parent="@android:Theme.Black">
This will show the Theme.Black style definition in the SDK's
styles.xml document.
In addition, the hyperlink resolver can now also link to fragments of
an attribute value. In particular, in the above, if you point anywhere
to the left of the ".", only the @android:Theme range will be
selected. This lets you go to parents, since styles inherit from other
styles by adding to them with dots.
Third, the hyperlink resolver can now link to resource urls that is in
the content part of XML documents (e.g. a text node, not an element
name or attribute value). As an example, you can now jump to the color
defined inside this style element:
<style name="CustomTheme" parent="android:Theme.Light">
<item name="android:bg">@color/custom_theme_color</item>
</style>
Finally, this changeset adds unit/plugin tests for the hyperlink
resolver, which asserts the expected list of matches, and the expected
editor context when the default link is opened.
Change-Id: I73757ec78405f7c711e13387d0bb046f698799f1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tweak the "New XML File" creation code to insert a new line inside the
created root element, indent, and place the cursor there. This means
that you end up with:
<LinearLayout>
|
</LinearLayout>
instead of (where | denotes the initial caret position):
|<LinearLayout>
</LinearLayout>
This means you can instantly press Ctrl-Space to complete on the
elements, etc., and is similar to how Eclipse creates new method
bodies from templates, adding newlines such that you can instantly
write code there instead of having to "open them up".
All the diffs for this are in NewXmlFileWizard.java; the other
modifications in this changeset are simple move refactoring
operations as described next:
The second change in this changeset is moving some code around such
that common utility methods live in more natural places rather than
where they were first needed.
In particular:
Hyperlinks.openUrl => AdtPlugin
Hyperlinks.openJavaClass => AdtPlugin
Hyperlinks.openFile => AdtPlugin
AndroidContentAssist.getAndroidXmlEditor => AndroidXmlEditor
ResourceChooser.canCreateResource => ResourceHelper
ResourceChooser.createResource => ResourceHelper
Hyperlinks.parseResource => ResourceHelper
ResourceNameValidator.isValueBasedResourceType => ResourceHelper
ResourceNameValidator.isFileBasedResourceType => ResourceHelper
Change-Id: If7690df9ce59c709c1d909ffd9f74c2684f3dd46
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a new category to the palette, "Custom & Third
Party Views", which is populated with android.view.View subclasses
found in the current project (or any of its libraries), and in any
jars included by the project. They can be dragged directly to the
canvas, and control clicking on the palette entries will jump to the
source.
There are a bunch of adjustments in various places to make working
with custom views better - from ensuring that we don't use fully
qualified class names in default ids, to showing the Java class icon
for custom views in outline and elsewhere, to making zero-sized view
highlight and expand when selected like we do for laoyuts - since with
custom views it's quite easy to end up with an "invisible" view that
you can't see after dropping it.
There are also some fixes to the code which looks up third party and
custom views (which was already used by the Wrap In refactoring) - to
handle inner classes, to filter out non public or abstract classes,
and most importantly to only include views reachable from the current
project (since the view search necessarily is workspace wide.)
Change-Id: If1d8c7e5c7dd907a68d8d0962e85c5144e911503
|
| |
|
|
| |
Change-Id: I464fe3f94e701e619b474f82aaf84ee04d158e71
|
| |
|
|
|
|
|
|
|
| |
ResourceFolder/File and children classes (single/multi file)
ResourceItem and children classes
ResourceRepository (base and framework, project stays in ADT for now)
All the ResourceQualifiers and FolderConfiguration
Change-Id: I5adc9bdc4886a8fa0ab44860763d594cf7af4bd5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Move the SWT based getIcon from the resource qualifier and use a static
helper instead.
- Make a new enum ResourceDeltaKind to replace the IResourceDelta
integer constants, and use the same helper class to convert from
one to the other.
- Make ResourceRepository exclusively use the IAbstractFile/Folder
- Use the ILogger in place of AdtPlugin (which implements ILogger)
Change-Id: I0011c01ac2064b07d28c980112c47cfa433ee372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, fix code completion for @android: resources such that if you
type @android: the various resource types (@android:drawable/,
@android:layout/, etc) are offered.
Second, fix completion for the @android: token itself such that if you
type "@a" then "@android:" is offered as a completion.
Finally, make resource name completion work even for attributes that
aren't marked in the metadata as allowing resource references. This
will not be done for empty completion context, but if the user
-explicitly- types a "@" in the value field, then resource completion
will work. This is necessary for some attributes where our metadata is
wrong, such as android:minHeight, where code completion currently
refuses to complete a @dimen/ completion prefix.
Change-Id: I175c8f7230d56987b9a945a2b791a2eb3e018a7c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, add support for the "Extract as Include" refactoring to update
all identical code fragments in configuration variations of the same
file. For example, if you have a particular subtree of XML elements
in a file that you have then duplicated into say a landscape mode,
then applying the Extract as Include refactoring will locate the same
code fragment in both files, and replace *both* code fragments with an
include (and this is optional with a checkbox in the wizard
dialog). This only happens when the extracted code fragment is
"identical" in both files. The code fragments can vary in terms of XML
formatting and attribute order (and namespace prefix choice), but the
element hierarchy order, names, attributes defined and attribute
values must be identical.
Second, make fixes to the Change Layout and Change Widget Type
refactorings such that when the id of the converted element is
changed, then references to that id are updated as well.
Third, ensure that the refactorings are enabled even when there is no
text selection; in that case the refactoring will apply to the element
containing the caret.
Some test infrastructure improvements.
Change-Id: Idb4ba40f4217dba2b13881b3d06e269c80ba4b97
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
| |
Change-Id: I258d393b5297d916b58ed3574b77f521968a13c0
|
| |
|
|
|
|
|
|
|
| |
If you've typed "android:textsi" on a TextView, you currently get no
matches. This changeset makes the code completion case insensitive
(the way it is in Java) such that it for example will match
"android:textSize".
Change-Id: I0f698c2a4ee983d6c0fbcce272b851b2710c9a61
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: I3a151d2fadd1c1e34177cb729fe5545fa754849a
|
| |
|
|
|
|
|
| |
This is better as we can return unmodifiable list instead of
arrays that could be overriden.
Change-Id: Id473925ee6355b2bedeb2d2575bc4ca4f949acb3
|
| |
|
|
|
|
|
| |
Moved some constants from sdklib (which is not a dependency
of common but instead depends on common) into common.
Change-Id: I6fdfbad4e77813a9f2a2ca9ea0d740692d8bce5b
|
| |
|
|
| |
Change-Id: I59a7b770071707ed058aa104bab8a16aa8950d56
|
| |
|
|
|
|
|
|
| |
Incorporate some feedback from
https://review.source.android.com//#change,21341
Disallow uppercase chars in file-based resource names
Change-Id: I078b30be64e1aeb984f26d5c8b2976aa0083fcf4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Modifies the resource name validator (used from the New XML File
wizard) to consider the resource type. While value-based resources
(like ids) can contain uppercase characters, they are not allowed in
file-based resource names, like layouts, animations, etc.
Also hooks up the resource name validator to the Resource Chooser's
"New Resource" dialog.
Change-Id: Ic5b948d73e9a8b17c6fdaa11cc38189202b04dc2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a new "Select" context menu. In addition to Select
All and Select None, there are new actions to select the parent of the
currently selected item, an action to select all its siblings, and an
action to select all widgets in the layout of the same type. For
example, invoking this on a button will select all buttons in the
layout. Select Parent is bound to Escape and is particularly useful
when you want to target a layout widget that has children and no free
space, since any mouse click will target one of its children. With
Select Parent you click on the child and hit Escape to reach the
container.
In addition, this changeset fixes selection synchronization for
context menus. Until now, you had to FIRST select an item, THEN right
click on it to see its context menu items. The root cause for this is
an SWT bug (eclipse issue 26605), but we can work around it with a
MenuDetectListener, which is run when the menu is posted and gives us
a chance to sync the selection.
Change-Id: If3e15c335c372a6ee8a3c8c357b48bb80fbbb40c
|
| |
|
|
|
|
|
|
|
|
| |
When you show a view as included within another layout, there should
be a semi-translucent mask over the surrounding context. This did not
work in all cases (in particular, when there was no merge cookie).
This changeset makes it work in non-mergecookie scenarios as well.
Change-Id: I724fa3a0f0bfd612c4d4a8850c307a5664200d10
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout editor has special handling for the "root" element, which
for example suppresses hover-highlighting for the root and a click
will initiate a marquee selection rather than a drag.
Some layouts wrap the layout inside a GestoreOverlayView. This does
not work well since the "real" root is its child, which will not be
treated as a proper root.
This changeset fixes this situation by handling this scenario such
that both the gesture overlay and its child is treated as the root.
Also make fix such that the icon in the outline also works for the
gesture overlay.
Change-Id: Ia96d2bc402958b44f9f82646ff0fc4552ab0cf14
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Palette previews are rendered on top of the default theme
background. For certain custom themes, where a gradient or image is
used, this can look terrible, since the preview images will include
portions of the gradient or image.
This changeset improves this situation by taking advantage of
layoutlib 5's ability to override the background. It now uses theme
resolution to find the background color, and paints the previews with
the custom background override to force this color. In addition, if
the theme background is not a color (but a gradient etc), it uses
layoutlib5's new render-drawable support to generate the background,
and it extracts a suitable color from it (currently, the center
pixel.)
This fix also ensures that the foreground color (used to paint labels
for the widgets that cannot be rendered, such as layouts) has a
suitable contrast with the background. After computing the background,
it computes the brightness, and if the foreground and background
differ less than 25% in brightness, then the foreground color is
forced to white or black depending on whether the background is light
or dark.
This changeset also contains a bugfix for a palette initialization
problem where in some cases the palette could come up empty (because
the code which attempts to avoid doing extra work when reloadPalette
is called repeatedly could be tricked by a scenario where the SDK
target does not change but its "have target data" status did.)
The open palette category is now preserved across palette refreshes
(which occur when you change palette modes or category/sorting
options, along with theme and render target changes).
Finally, the changeset also turns off the new window decorations
(system bar, action bar, etc) when generating preview images for both
palette previews and for drag & drop.
Change-Id: I8b8766ad45f2cb6a4a6b79a24c31ed0f08d1e826
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows the layoutlib to render system/title/action bars
as a window decor like it would look on the device.
This can be disabled with RenderParams.setForceNoDecor().
(BTW, Params was renamed RenderParams too)
Also minor update to the API by replacing an int with Density
since the enum is now accessible to the API and layoutlib.
Change-Id: Ic37770a9276d12af90c60199a84b04cb64e7c3a1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset contains various improvements around usage of the
<merge> tag. Some of these fixes require layoutlib 5.
* Use the new layoutlib support for rendering multiple children at the
root level - they now show up in the Outline (provided you are
running layoutlib 5), can be selected in the layout editor, etc.
* Add a drop handler such that you can drag into the <merge> view and
get drop feedback (similar to the FrameLayout)
* If the <merge> is empty, we don't get any ViewInfos, so in that case
manufacture a dummy view sized to the screen. Similarly, if we get
back ViewInfos that are children of a <merge> tag in the UI model,
create a <merge> view initialized to the bounding rectangle of these
views and reparent the views to it.
* Support highlighting multiple views simultaneously when you select
an include tag that renders into multiple views (because the root of
the included layout was a <merge> tag). Similarly, make "Show
Included In" work properly for <merge> views, and make the overlay
mask used to hide all included content also reveal only the primary
selected views (when a view is included more than once.) (Also tweak
the visual appearance of the mask, and use better icon for the view
root in the included-root scenario.)
* Improve the algorithm which deals with render results with null
keys. Use adjacent children that -do- have keys as constraints when
attempting to match up views without keys and unreferenced model
nodes. This fixes issue
http://code.google.com/p/android/issues/detail?id=14188
* Improve the way we pick views under the mouse. This used to search
down the view hierarchy in sibling order. Instead, search in reverse
sibling order since this will match what is drawn in the layout. For
views like FrameLayout and <merge> views, the children are painted
on top of ech other, so clicking on whatever is on top should choose
that view, not some earlier sibling below it.
* Fix such that when you drag into the canvas, we *always* target the
root node, even if it is not under the mouse. This is particularly
important with <merge> tags, but this also helps if you for example
have a LinearLayout as the root element, and the layout_height
property is wrap_content instead of match_parent. In that case, the
LinearLayout will *only* cover its children, so if you drag over the
visual screen, it looks like you should be able to drop into the
layout, but you cannot since it only covers its children. With this
fix, all positions outside the root element's actual bounds are also
considered targetting the root.
* Fix broken unit test, add new unit tests.
Change-Id: Id96a06a8763d02845af4531a47fe32afe703df2f
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If you have zoomed your layout, which is going to be common when
designing for 10" screens, then the drag preview shown when dragging
from the palette is not sized correctly. It assumes a 100% zoom.
This changeset looks at the current canvas zoom and scales the preview
image such that it matches the canvas zoom, so if you're zoomed in
then the preview will be larger, and vice versa.
Change-Id: I471b4d8ae459aad79d50a2b54ecca6bd7d7cf943
|
| |
|
|
|
|
|
| |
Move all the resource query methods that returned an array of 2 Strings
to return a pair of ResourceType and String.
Change-Id: I6b8447aa27005de786e2defef81ad88a72363523
|
| |
|
|
|
|
|
|
|
| |
Move ResourceType into resources.jar so that it's accessible
to layoutlib.jar
This is cleaner and allows us to us more efficient EnumMap objects.
Change-Id: If11cbc69ae3ca8bd6c96e6d0ef402570a07af16f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Look up the theme background and foreground colors using theme
resources, if possible. These theme resources are then used to set
the foreground and background colors on the labels used as a
fallback for non-previewable widgets. In other words, when you're
looking at a dark theme, the layouts such as LinearLayout is now
shown using a white label on a dark background, making the palette
view more consistent visually.
2. Configure scrollbar increments properly such that scrolling the
views with scrollwheels or mouse gestures works better.
3. Fix a bug in the way preview images were copied out of the rendered
image; the root coordinates were not taken into account, which
matters for themes like Theme.Dialog.
Change-Id: I4832166a0560d33fe4e4dd8079c82a180e07e897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now only the screen size is needed. We can add more to Params
as needed.
Since we should use the existing enum classes for this, I moved
all the current enum from sdklib into a new jar file called
resources.jar.
ADT, sdklib, layoutlib_api all depend on it.
Changes to resources should always be API compatible and the result
should be copied into the in-dev platform branch in prebuilt, similar
to layoutlib_api. See the README.txt files in layoutlib_api/ and
resources/
Change-Id: I877ba3cad555ec497954bb0866639e51e7751020
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset contains some background work for the palette preview
work, separated out to make that changeset smaller.
First, it creates a new metadata XML file, which augments the metadata
provided by the platform, defining things like palette categories, a
natural order for the views within each category. The older code-based
metadata for fill preferences (used to decide how to set the width and
height attributes on drop) are also moved into this XML file. There
will be more metadata added to this file in the next changeset, where
for example XML fragments defining how to render a view for preview
purposes will be defined there.
Second, change the signature on the view and layout descriptor lists
passed around such that we don't have to do instanceof
ViewElementDescriptor in various places.
Fix sentence capitalization for a couple of undo label strings.
Change-Id: I66191ccf4cc0f4105c2331d496f3674ac1ad8b9d
|
| |\
| |
| |
| | |
Change-Id: I31a8c35fb21a68f099059d34e4f01a2e3437f884
|
| | |
| |
| |
| | |
Change-Id: If6c972fdb379e67686dfaf5af0bcbd6cb4aa4b9c
|
