| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \
| |/
| |
| | |
Change-Id: I28389184c1de4efadd20533825221119d8baa7f1
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you have certain types of errors in your project, then rendering
will fail with messages that may be confusing.
This changeset attempts to identify some of these common scenarios and
offer detailed explanations to guide the user in the right direction.
Specifically:
1. If the project contains aapt errors (which means aapt did not run
successfully), AND the rendering failed with an error related to
resource lookup, then begin the render error message with an
explanation in bold that this project contains resource errors that
could explain the below rendering errors, and to investigate those
resource errors first.
2. If the project contains javac errors, AND the rendering failed
after the custom project class loader has been consulted, then
display a message stating that compilation errors could have
caused the failure and to investigate those errors first.
3. If a custom view is loaded, and it does not provide a 2- or 3-
argument constructor (which takes an AttributeSet), emit a warning
that XML attributes on the view will not work.
In addition, this changeset cleans up a few other related things:
- Tags are no longer displayed as part of the error message; these are
intended for internal checking only (for example to identify
resource errors from other errors)
- The error display text can now show a vertical scrollbar if the text
is longer than the available space.
- The code which marks the project class loader as used is marked used
as soon as it's asked to resolve a class name, rather than at the
completion of a successful load, since we want to know about failing
custom classes as well.
Change-Id: Ib37a329eed44719ecf741b96ff96747ec4f92ad0
|
| |\ \
| |/
| |
| | |
Change-Id: If87bb7e1e0adfe107c1a26132d63f7d779a06a3b
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This changeset changes the default text and id attributes of newly
dropped widgets in the following ways:
1. Use the node class name rather than the id as the initial text. In
other words, the default label for a button is "Button" rather than
"@+id/Button01". This is a more common convention in other GUI
builders, and you typically don't want the actual label to be
"@+id"-something, you want it to be "@string"-something, so the @id
prefix is slightly confusing for beginners.
2. The id uses method name capitalization rather than class name
capitalization, e.g. "checkBox" rather than "CheckBox". This seems
to be the convention I see in handwritten layouts, which makes
sense given that the reference will be compiled to and referenced
as a Java field.
3. In the case of conflicts, don't use a leading 0; in other words,
rather than button01, button02, button03 we have button1, button2,
button3. It's unlikely that the user will have ten or more unnamed
widgets (and if they do the leading zero still isn't needed.) The
code which looks for name conflicts now also performs case
insensitive comparisons.
Change-Id: Ie7f2c5dd8e9852acec2c2e154ee20142b8ece9a6
|
| |/
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some scenarios where rendering failures (such as an NPE in
the layout lib) will not appear in the error display, and it will not
appear in the Error Log.
In addition, we now get fidelity warnings from the layout library
(warning about Android code using graphics operations not supported by
the layout preview), and these should all be displayed to the user
with a proper explanation.
To solve these problems, this changeset replaces the layout logger
with a new logger which:
(1) Writes all exceptions to the AdtPlug.log(Throwable) method, which
results in the full exception being captured in the Error Log
(2) Accumulates all errors, warnings and fidelity warnings
(3) Provides a summary of ALL the problems at the end, such that they
are all displayed (in decreasing order of severity) for the user
rather than the last one clobbering them all.
The logger also records whether exceptions were logged, and if so, the
last line of the error display indicates that further details can be
found in Window > Show View > Error Log.
Finally, the old logger was a member of the GraphicalEditorPart, but
this is a lightweight object so there is no need to cache it, and in
fact we don't want other types of rendering (such as preview
rendering) popping open the error display area.
Change-Id: Ia00978a725cb7e7ec2dcfbf9e868df2a5136efc0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an "Extract As Include" action to the context menu which lets you
extract a set of selected views and move them into a separate layout
file of their own, and insert an <include> reference to the new view
in place.
You can select multiple items as well (provided they are adjacent
siblings) and in that case the newly extracted layout will use the
<merge> tag as the root element.
This changeset also adds a name validator for resource names, used
both in the new-name entry field for extracted include layouts, as
well as in the New XML File wizard. It enforces that the name (except
for the .xml suffix) is a valid Java identifier name (since otherwise
the R file will have compilation errors.)
This changeset also extracts various inlined String constants like
"xmlns", "android" (as used in namespace prefixes), "@id/" etc and
replaces them with constants.
Change-Id: I3eca8b6afd23f22ca9299ff22c614b4ffd3299bf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have support in the layout library for handling included views
where the include tag is associated with the root elements rendered in
that included view.
However, there are various scenarios where this is not adequate:
1) including <merge> views (see issue 13288)
2) older layout libraries
This changeset fixes the above scenarios, as well as an additional
scenario (where rendering included content in an outer layout did not
work properly if the included elements were not at the root level).
It does this by moving the CanvasViewInfo construction into a set of
factory methods which handle various different hierarchy types of
ViewInfos. ViewInfos with null keys at the top are handled one way;
ViewInfo subtrees that introduce null keys further down are handled
another, and it attempts to match up elements in the UiViewElementNode
hierarchy with ViewInfo objects. If it cannot match them one to one,
it will create a single "bounding box" view containing all unmatched
ViewInfos. This will for example produce a single box out of included
<merge> views.
This changeset also handles multiple includes. The "overlay mask"
could earlier only handle a single include whereas the rewritten code
can handle multiple "holes" in the mask by computing the set of
subrectangles remaining after punching out the include holes.
Change-Id: I163413c7fc301f25c4523b0ee03690f983a05322
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in issue 13042, it's possible to add views into
AdapterViews such as ListView. This causes a rendering error.
The root issue is that we were relying on
ElementDescriptor#hasChildren() to determine whether a particular view
is willing to accept children, but that isn't entirely correct, since
all subclasses of AdapterView (such as ListView, Spinner, etc) will
throw an exception if you do that.
To fix this, I've added a new method to DescriptorUtils,
"canInsertChildren", which performs additional checking beyond
hasChildren(). If it has an actual view object, it will walk up the
super class chain and see if the view extends AdapterView, and if no
view object is available, it will filter out the known subclasses of
AdapterView (well, it doesn't have to filter out Spinner since that
class doesn't report that it has children).
Change-Id: I663b18fcfbe97a10c8f1aaa2d75552fb8fb148d5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds "Move Up" and "Move Down" context menu items to
the outline, as well as keyboard shortcuts for these: + and -. The
actions apply only when the Outline window has focus. Thus, to reorder
an item you can select it, then press + repeatedly to move it down in
the hierarchy or - to move it back up.
In addition, this changeset fixes a selection syncing issue which also
affected drag & drop: It will now correctly always select the target
dropped tree items after a drag or reorder.
Change-Id: I11ce4fd302e537b86a614a7cbe59f1ac47f61aa5
|
| |
|
|
| |
Change-Id: I40abba4c4f786755c2a1c0e70df4d7bc08e2bcde
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds Android-related hyperlinks to Java files. If you for example
have this code in your Activity:
setContentView(R.layout.main);
and you control click on "main", this will now offer (in addition to
the normal "Declaration" hyperlink) go to "XML Declaration"), which
will then warp to the main.xml file.
You can add in the second modifier key to directly jump to the Android
resource and bypass the normal Java declaration (which would take you
into the R file). The Android Java hyperlink works from R file field
declarations too by the way.
This now also works for id attributes defined inline, so if you for
example jump to R.id.Button01, and this will open the first
@+id/Button01 element found in the layout directory.
You can also open non-XML references, such as @drawable/icon. This
will run the Eclipse open command on the icon.
The processing of XML regions is improved, so it will now only
highlight say the value part of an XML attribute, or the name part or
the element tag name part.
Finally, the hyperlink resolvers can now jump into @android resource
files (as found in the SDK data directory). Thus, you can warp into
(say) @android:drawable/alert_dark_frame.
Change-Id: I83fcd1ffb08590f7f587b90f5c64784fe8ce5f67
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current support for includes are limited to including a view
within the "base" layouts (defined in layouts/). This changeset
generalizes this to track ALL include-sources (such as an include from
the landscape version) and offers to let you view and edit the current
view within each of those specific configurations. The configuration
will be switched to one that is compatible with the outer, including
view. It is possible that this will switch to a different inner view;
that seems better than trying to force editing an inner view in an
outer view that won't actually be shown at runtime.
We should enhance the configuration chooser such that it will only
offer options in its various combo boxes that are compatible with the
inner view as well. That is not addressed by this changeset.
Change-Id: Id5171d367cf65e2403bbac1640a179de4b420bd6
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 adds basic hyperlink handling to Android XML files
(such as AndroidManifest.xml and layout xml files).
It registers a hyperlink detector for our XML files, and the hyperlink
detector looks up the XML model and finds the node and attributes
under the cursor. If found. it then checks these attributes for a set
of patterns that it can link to:
* If it finds an <activity> element, it looks up the activity name and
the package on the root element, and lets you jump to the activity.
Ditto for services.
* If it finds a @layout attribute value, it attempts to open the
corresponding layout file in the res/ folder in the project. Ditto
for other per-file resources like @drawable, etc.
* If it finds a value resource, like @string, @dimen, etc, it will
search through the various XML files in values/ and open up the
corresponding XML declaration in the editor with the declaration
selected.
Note that the resolver does NOT use proper full resource resolution
based on the SDK parsing that we have in use within the layout editor
etc. That's the natural next step.
Change-Id: I5880878fe67f26fb8d3b08b808c02baa1049f2c5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add improved support for includes. You can now view and edit a layout
within another containing layout. On a page with includes, you can
double click to warp into the included layout, and it will be shown
within the container layout (but with a semi-translucent mask to make
it obvious that you are editing only the included content, not the
container.)
You can also right click on a view and choose "Show Included In",
which is a pull-right which lists all the other layouts that are
including this view. (If there are no such views, the menu item will
be empty).
In addition, this changeset adds code to detect if there are cycles in
the includes, and if so adds a problem marker in the Problems view
listing the offending chain of includes.
This is all managed by a new "IncludeFinder" class, which listens for
resource file edits (so it only kicks in when you save an XML file,
not after each XML edit). It scans layout XML files for includes and
maintains a map of file includes. This is done such that it can very
quickly provide a list of all files that are including a given target
file. This list is also persisted across IDE sessions via a project
property.
Also fixes outline-expansion to ensure that the outline always shows
the top level children.
Note: The include-relationships are based on the base layouts (the
ones in layouts/, not in customized versions in layout-land,
layout-port, etc.)
Change-Id: I710560f03f7e214219669af8ffba91874d9881b9
|
| |
|
|
|
|
|
|
|
|
|
| |
They are not technically new, but we never really
needed them. Turns out we do now (some are used by some widgets).
Also added an assert to detect new types of resources, and a test
to make sure that all resource types and folder types are added
to the folder-res relationship maps.
Change-Id: Ie4b6786ea6de9c69776794750732303b8d68b7bb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you drag in the canvas, show a drag image for the view being
dragged. The drag image is using 30% translucency such that it does
not obscure the drag feedback below it.
We're grabbing the image data right out of the rendered scene and just
copying out the rectangles for the bounds of each selected item. This
has to take the canvas zoom into effect too.
While in the zoom code I modified the Zoom In and Zoom Out buttons to
only zoom by a factor of 20% rather than 100%.
I cleaned up the Pair class slightly; in an earlier version of this
fix I was using it to pass back two results from the rectangle
painting function; I don't do that anymore but the Pair might as well
be cleaned up.
(By the way, as suggested in review #19035 I rewrote the FIXME comment
related to resource lookup and put it in this CL rather than revising
the other one.)
Change-Id: Iabe6e29c4073252f5046e3c26b56f4e7674a3f3a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, the AddonsListFetcherTest#testLoadSample_1 was failing on the
Mac, because the source code contained non-ASCII unicode characters,
and the encoding differs between Windows, Linux and Mac -- and on the
Mac the characters were garbage (not the intended Japanese
characters). Fixed by using unicode escape sequences to define the
expected output instead.
Second, rename the AbstractLayoutTest to LayoutTestBase; the test
runner (for plugins, not unit tests) was assuming this was a test case
(even though it's an abstract class!) so it was emitting a warning
about the class containing no test cases. This is simply a base class
for all the individual layout tests defining a bunch of useful
inherited shared behavior, so rename to avoid the warning.
Change-Id: I6e29316c5644db35051218aef8b99ac41ab0cda4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ADT descriptors have no notion of XML ordering.
We modify the concept of "mandatory" descriptor to
have normal mandatory descriptors versus "mandatory last" ones.
("mandatory" elements are virtual reserved slots that are
always present in the UiModel even if they have no real
counterpart in the XML model. These elements ensure they can
be manipulated in the UI even before their XML is created.)
Then we try our best to ensure the "last" ones remain at the
end of the UiNode model. There are 2 cases:
- in UiElementNode, when constructing the UINode model when
parsing an existing XML model, we try to reorder the nodes
at the end if possible.
- in UiActions, when adding a new element to the UiModel, we
try to place it before the first "mandatory last" element.
SDK Bug 3197310
Change-Id: I6a7d9502a95ebe92ff82e07f3f3249a0d25c2154
|
| |
|
|
|
|
|
|
|
|
| |
There were some test failures because unit tests were relying on
AdtPlugin's logger, which appears to be null during unit test
runs. Use a new test logger instead, which fails the current test if
anyone logs an error message, and dumps warnings to standard error and
prints to standard output.
Change-Id: I8e52fed554d49e98f7d6c8990d41831998f44640
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following issues:
- All methods must use the palette mask to compare RGB values.
- Use a non-trivial default color for testing. The previous
choice of 0xFF00FF00 would not allow detecting RGB <-> BGR
mixups and the 0xFF alpha mask prevented from noticing the
fill operation was pre-multiplying the colors.
- Assert the converted image as the expected transparency type.
Change-Id: I1dc7518a7d7000bce75e1c4166a9921ba40a43cb
|
| |
|
|
| |
Change-Id: I275b526670ca6e60cfc4f8749631dff2ef240b96
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The AdtPluin was used just for logging. Instead the
AttrsXmlParser takes an ILogger (AdtPlug implements
ILogger and can be used directly in unit tests too).
For unit tests there is a new StdSdkLog convenience
class that prints to stdout/stderr (formerly MockStdLogger
from the Sdk Manager was doing that.)
Change-Id: I658af61d04efb19ad6e3bf9c0bf471452372885a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a pure-refactoring CL that moves AttrsXmlParser
into an ide.common.resources.platform package. In a next CL,
the parser should be cleanup to remove some references to
external classes (e.g. adtplugin is only used for logging so
it will become an ILog reference.)
The goal of the resources.platform package is to allow other IDEs
to parse the manifest schema. An utility class would be provided
here that would then be used by AndroidTargetParser. The rest of the
data parsing (widgets, resources, etc.) is a non-goal. Maybe later.
Change-Id: I4fb8eb5d168b75ef8bfab57d0b2883aea85b6167
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add in a drop shadow to items dragged from the palette. The primary
reason we need this is that some views (in some themes) only render
light content on top of a transparent background, which makes them
nearly impossible to see on a gray background (e.g. over the palette,
when you initiate the drag). The drop shadow helps add contrast. It
also makes the drag look better since it helps the drag preview image
stand out from the background and visually appear to be lifted on top
of it.
Since we're doing more image processing now, I moved the existing
non-SWT image manipulation methods into a separate ImageUtils class.
This changeset also fixes the way we pick the color to crop out when
using older layout libraries (without transparency support). We now
pick a pixel closer to the bounds of the rendered view such that we
for example can handle themes like the dialog theme.
Change-Id: Ifcbb840ef715bf26a9609f6996a4f136de5ca754
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use the view bounds from the layout result as an initial cropping
size. This saves us from looking at a lot of empty pixels when we
render small views. This also means we can attempt rendering a larger
surface for the preview, which makes accidentally cropping large views
less likely.
(Also fix a couple of other suggestions from previous commit)
Change-Id: I9215f00db14adc42950897637e9f66aa921d484e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This checkin renders previews of Android views as you drag them from
the palette, using the current theme settings you have for the
associated editor. If you are using version 5 or later of the layout
library, you get full alpha-blending on the rendered views (so for
example in an analog clock you see right through it), and on older
version it simply crops out the edge color.
The preview image is semi-translucent, and the image is centered under
the mouse pointer. The drag feedback operations all relate to the top
left corner of the dragged item, so they are passed in the mouse
cursor minus the delta to the top left corner of the image.
The size of the preview is also used to provide bounds for the drag
feedback, such that we can show a preview rectangle rather than just
the insert point over layouts that support drop feedback.
Some views can't be rendered (e.g. QuickContactBadge), and some views
don't have any pixels painted (e.g. all the empty layouts), and in
that case we fall back to showing the palette item itself (the icon
and label) as you're dragging.
There's also a new utility class for SWT common utilities, like image
conversion.
Change-Id: I315c2dd733317bbada8dae89f57280ced2d7bb51
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When 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
|
| |\ \
| |/
|/|
| | |
Change-Id: Ife4981cc78290d77662064cd3f6f9317f45a29ec
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously DDMS used the adb location to find the location of other tools,
but adb moved to a different tool folder.
adbLocator extension changed to toolsLocation and provide explicit
locations for all the tools DDMS cares about. This way the logic
of the tools location is only in ADT instead of being duplicated
in DDMS.
Change-Id: I87f19c7705cb822dc793264f11e680ba09eb7f40
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ADT now exclusively use the new API.
The older platforms that still use the old API are
accessed through a compatibility layer provided by the class
LayoutBridgeWrapper that converts the old to the new API (both
input and output).
The wrapper and the loading code for the bridge have moved
to layoutlib_utils, but into the ide.common package.
Layoutlib_utils is to be renamed ide-common later.
.sdk.LoadStatus has moved into .ide.common too since
it's used by the bridge loading code. As we'll move
more code into ide-common it's ok to have it there anyway.
Also did some minor fix to the API:
- missing implementation of ViewInfo
- Made a singleton for SUCCESS state of SceneResult.
Change-Id: I5e7130ca03b92ad71dc9c293b2ffc40566df645c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When you add a new container, such as a LinearLayout, it is usually
invisible. The reason for this is that an empty layout has 0 width and
0 height. There are two existing features in the layout editor to deal
with this: (1) Outline mode, which renders rectangles around all
views, and (2) Padding mode, which adds 10 pixels of padding to all
views. In combination, these two modes will create a rectangle for
empty layouts making them visible and user-manipulatable -- you can
for example select or drop into them.
This changeset attempts to make dealing with these types of containers
easier and more discoverable. It adds a new temporary mode where empty
containers (and only empty containers) are automatically padded and
have their outlines painted. And more importantly, this is only done
in some limited scenarios: When you drag into, or drag within, the
layout canvas. As soon as you finish the drag, empty containers
disappear again.
Unlike padding mode, we don't enlarge the design surface itself, since
this mode comes and goes easily and frequently.
In addition to this, there is special handling for selection. If you
select a zero-sized element (which for example is automatically done
when you drop a new layout, and which can also be done by clicking in
the outline), then the element is also revealed similar to the
show-empty mode, but in this case only the selected item and not any
other invisible containers are shown.
Change-Id: Ibf3ec6a080a50a8f0f55919c3d3e6c4d2890468d
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This checkin adds support for gestures and overlays. Gestures are
sessions of mouse/keyboard activity, and this is documented in the
javadoc for the new Gesture class. Overlays are units of graphics, and
these are documented in the Overlay javadoc. The gesture architecture
lets us isolate the logic for each different type of operation
(marquee, resize, move, etC), and with associated overlays we don't
attempt to for example paint drag feedback during a resize operation,
etc.
The checkin also adds marquee selection (as a second gesture, in
addition to the existing drag & drop based move gesture), along with
some associated changes in how the root view is treated.
As part of isolating the mouse handling and painting related to
gestures, painting etc., I also refactored the code quite a bit.
LayoutCanvas which used to be a large class has been split into a
number of new classes, one for each area of responsibility:
- The mouse listener and drag & drop code has been moved into a
GestureManager. (A lot of the drop handling code also came from the
CanvasDropListener class.)
- Code related to maintaining the set of rendered views, and
performing searches in the views, has been moved into a
ViewHierarchy class.
- Code related to selection has been moved into a SelectionManager.
- Various individual painting pieces (outline, hover, etc) have been
moved into individual Overlay classes such as OutlineOverlay,
HoverOverlay, SelectionOverlay, etc. This also moved associated
resource allocation and cleanup into the overlays.
- New coordinate classes, ControlPoint and LayoutPoint, are used
instead of ints and plain Points to make it really clear which
methods require coordinates in the layout (such as the
ViewHieararchy search methods) and which ones require coordinates in
the canvas control (such as paint methods). There are factory methods
to automatically construct the right kind of coordinate from
different types of mouse events, as well as methods to convert
between the two.
I also tweaked the visual appearance of selection a bit more, and
some other misc cleanup.
Change-Id: I666aabdcd36720bebe406b68237e8966d985fb8f
|
| |\ \
| |/
| |
| | |
Change-Id: I90eeb2def2e3d3f0ee6f34b0a3f710f966808a7a
|
| | |
| |
| |
| |
| |
| | |
SDK Bug: 3125910
Change-Id: I00450b13d10cbe4f32cbfbd6e1945985b599920f
|
| |\ \
| |/
| |
| | |
Change-Id: Id7dbdfae280b98547f9a80e07cc5d80d7f9f92f7
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Change-Id: I744833ec03d0d379ea526c193549f99f25f6811a
|
