| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
Similar to the <include> tag handling, when you drop an image a
resource chooser inputting @drawable resources pops up and lets you
pick the drawable to be shown in the image. If you cancel, then the
default image will be set instead.
Change-Id: Id09801a877acbeb437f518cefe60062ac92e7e7c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you drop a text field in a vertical linear layout, then the *width*
of the text field is automatically set to fill. This uses metadata to
check what the fill preference is of each dropped view.
This changeset extends this scheme to also grow text fields in a
horizontal linear layout. However, instead of using fill_parent on the
layout_width, this uses a layout_weight instead. This means that the
text field will fill, but it will not push subsequent children out of
the way the way a fill_parent would.
This changeset also changes the default orientation of a LinearLayout
that is created in new XML files. (I looked around and noticed most
layouts that have a LinearLayout at the root will use a vertical
LinearLayout.)
Change-Id: I52eec4841e4bac076da655c603235547cfd46b73
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds new items to the palette which are just variations
of an existing widget but with different initial attributes. In
particular:
* Instead of just LinearLayout there are two versions of it:
LinearLayout (Vertical) and LinearLayout (Horizontal)
* The ProgressBar has 3 variations: Large, Small, and Horizontal. The
horizontal ProgressBar looks like the SeekBar, without at thumb, so
the SeekBar is moved next to the progress bar.
* There is a new palette category, "Text Fields", which contains a
number of different initializations of the EditText's "inputType"
attribute - for textual and numeric passwords, for names and e-mail
and postal addresses, for phone numbers, for negative and decimal
numbers, etc.
* Since LinearLayout is so common, the outline handles it specially to
ensure that we show a horizontal or a vertical icon depending on the
orientation attribute of the specific element rather than the
generic descriptor icon.
There are various changes to the palette icon preview and drag preview
etc to handle these changes. In particular, the category
initialization code had to be rewritten to be able to handle
variations (since for example the text field appears in multiple
categories, so the old assumption that each view had an assigned
category was no longer true.)
This changeset also extracts a constant for the "android:" literal
used in many places in the code, and renames the existing "android"
namespace constant.
Change-Id: Ibbc3dbd34c551594421c3de034cdccea6a66eba0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Adds a drop handler to the FrameLaoyut rule which looks up the
metadata for the dropped child, and sets the width and/or height to
fill based on that metadata. For example, a LinearLayout dropped into
a FrameLayout (or say a ViewFlipper which inherits from it), then the
layout will fill. A button on the other hand will not fill, and an
EditText will fill horizontally but not vertically, and so on.
Change-Id: I65a9379fa7128cc9c68d9bfd1849b0f1dc0f4a86
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 fixes a couple of layout actions bar issues:
(1) Refresh the actions bar after running one of the layout
actions. This for example fixes the issue that if you click to
toggle the layout orientation then the baseline button will appear
for horizontal layouts.
(2) Fix an issue with the lazy-initialization of dropdown menus; they
weren't actually initialized lazily because the code to determine
whether a choice list should be a dropdown or a radio group would
cause initialization.
(3) Fix layout gravity on RelativeLayouts; it was reading/writing the
attribute "layout_gravity" instead of "gravity".
Change-Id: Ic41158257b3938a2e6daa8714dcd15d6bf21fa2f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new toolbar above the layout canvas (and to the right of the
palette). This toolbar shows various layout-related actions on its
left, and the canvas zoom controls on the right. The zoom controls
have been moved from the configuration panel, which has also been
reorganized a little with three of the dropdowns moved up to make more
horizontal width and take the place of the old zoom controls.
The toolbar items vary based on which layout is "active". The active
layout is the parent layout of the selection, or the root layout in
the canvas if there is no selection.
Some examples:
- In a LinearLayout, there are radio-button icons for switching
between horizontal and vertical orientation, and for toggling
baseline alignment
- There are toggle buttons for toggling between wrap_content and
match_parent (or fill_parent) for the layout_width and layout_height
properties
- There is a dropdown menu in LinearLayout and RelativeLayout which
lets you set the layout_gravity to one of the dozen gravity settings
- There is an action button which brings up a margin chooser dialog
where you can configure the margin settings for the currently
selected elements for layouts that support margins
There will be additional actions here in the future.
This changeset also adds a few new MenuAction subclasses and factories
to make it possible to do ordered lists of choices. It also adds
sorting keys to make it easier for parents and children to interleave
their actions with simple sorting keys rather than having to append,
prepend or merge their respective result lists. In a follow-up
changeset I will replace the context menu code to use these, as well
as attempt to make all actions stateless such that they can be cached
and reapplied for different targets.
Some misc cleanup.
Change-Id: I6a87144fcfd1d359e5561829bd5d63c852f16970
|
| |
|
|
|
|
|
|
|
|
| |
This uses the JDT to search for method names matching the required
signature for XML-declarations of method handles, and opens the
method.
It searches first in the Activity classes, then globally.
Change-Id: I378a3abaf16aee28fb6fe6dc304ed061942c3774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Move AbsoluteLayout out of the Layout category in the palette, and
into the "Advanced" category. Also add selection hints for the
absolute which explains that AbsoluteLayout is deprecated.
Change-Id: I2b1633e90794bdec7b7a0d3171f9a29eb25dd258
|
| |
|
|
|
|
|
| |
Move all the resource query methods that returned an array of 2 Strings
to return a pair of ResourceType and String.
Change-Id: I6b8447aa27005de786e2defef81ad88a72363523
|
| |
|
|
|
|
|
|
| |
Don't set the image src attribute on drop (which was done by the
ImageViewRule since QuickContactBadge extends ImageView), and don't
use the mail contact image in the render-config.
Change-Id: I182c5e253bb754d8ae5fc54583f6a06ad3415ad0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Instead of creating a single tab, create 3 tabs instead, and pick a
better id since it's used as the tab label by the designtime TabSpec
creator.
Change-Id: I35ecb4ec8642431ff76a02d52f5194efd5909774
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Ib923c5ab4fc6e0e0916645c09506d334a8d68d63
|
| | |
| |
| |
| |
| |
| | |
Add a dummy child to the TabHost on drop.
Change-Id: I0f00dda449b81025c24933b6e1578b6b1a431272
|
| |\ \
| |/
| |
| | |
Change-Id: I02dd4e2e9d540dbac8f06986e96b9c2417efbb96
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ZoomButton extends ImageButton so it was picking up the
default image, but for ZoomButtons use one of the builtin
zoom images instead.
Change-Id: Iadb4f16cc5e3bc137c25ed7fc3872a0b19bd38d6
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a drop handler for radiogroup which puts a few radio buttons in
it.
Make WebView default to match parent in both dimensions.
Also fix superclass of the SlidingDrawerRule.
Change-Id: I05467bd06f074692603c236b9f3fd947fe7e63fc
|
| |\ \
| |/
| |
| | |
Change-Id: Ie6bd188e272f8415f73fcd6a3e7613581a0d694a
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add a drop handler for SlidingDrawers such that when dropped from the
palette they create the mandatory handle and content
children. (Without this, you get a rendering error instead.)
Change-Id: Icb521fca9cdbb1da14693d4872ef3fb00187d8f7
|
| |\ \
| |/
| |
| | |
Change-Id: I68c6498ffe1dbcd78bef71b85046501a25cf5231
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This changeset fixes several issues with the Extract As Include
operation:
1) Transfer all the layout_ attributes to the include
itself. Generally the layout attributes are particular to the
inclusion context, they are not shared among the different uses of
the include. For example, in layout1, the include may be in a
linear layout and have a layout weight, and in another layout the
included may need relative layout attachments.
2) Generate a new id for the included tag itself
3) For any layout references to the old extracted id, use the include
tag id instead
4) Generate the new layout in the same folder as the source of the
extract operation, since it may depend on properties only defined
there
Change-Id: I515a56fe07cc0ffc1b4fcb6eec8d3a10d383915e
|
| |/
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Fix 13880: Dialog opened by contextual properties menu item should be
the reference chooser.
Change-Id: I88d994271217c96985a0e18c84efc16a232c2bd4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The input-dialog for setting the text property was requiring the
string to be non-empty, or it would reject the input. That's not right
- it should be possible to set the text to blank (which is common for
text fields for example), since blank will clear the attribute.
This code was just cut & pasted from the similar code for inputting
id's where the id -should- be nonempty.
The code was also not handling the case where the user cancels the
dialog for custom string properties; we need a null check.
Change-Id: I31a2ae07b99ebc59d15b76f68c514d97294a736b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Make the outline use StyledStrings such that we can use different
colors for different elements in the outline. Use the decorations
color for the element type that follows the id.
2. For elements that define a "text" property, include the text (or a
prefix of it if it is long) in the outline. Thus, for a Button you
might see something like "Button01 - "Submit Order").
3. For elements that define a "src" property, show the
source. Therefore, for an ImageView you might see "ImageView - logo".
4. For <include> elements, show the name of the included layout.
Change-Id: Ibd4c8339ea0e03c969ccaec1a67bc64436ed67af
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an "Extract As Include" action to the context menu which lets you
extract a set of selected views and move them into a separate layout
file of their own, and insert an <include> reference to the new view
in place.
You can select multiple items as well (provided they are adjacent
siblings) and in that case the newly extracted layout will use the
<merge> tag as the root element.
This changeset also adds a name validator for resource names, used
both in the new-name entry field for extracted include layouts, as
well as in the New XML File wizard. It enforces that the name (except
for the .xml suffix) is a valid Java identifier name (since otherwise
the R file will have compilation errors.)
This changeset also extracts various inlined String constants like
"xmlns", "android" (as used in namespace prefixes), "@id/" etc and
replaces them with constants.
Change-Id: I3eca8b6afd23f22ca9299ff22c614b4ffd3299bf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have support in the layout library for handling included views
where the include tag is associated with the root elements rendered in
that included view.
However, there are various scenarios where this is not adequate:
1) including <merge> views (see issue 13288)
2) older layout libraries
This changeset fixes the above scenarios, as well as an additional
scenario (where rendering included content in an outer layout did not
work properly if the included elements were not at the root level).
It does this by moving the CanvasViewInfo construction into a set of
factory methods which handle various different hierarchy types of
ViewInfos. ViewInfos with null keys at the top are handled one way;
ViewInfo subtrees that introduce null keys further down are handled
another, and it attempts to match up elements in the UiViewElementNode
hierarchy with ViewInfo objects. If it cannot match them one to one,
it will create a single "bounding box" view containing all unmatched
ViewInfos. This will for example produce a single box out of included
<merge> views.
This changeset also handles multiple includes. The "overlay mask"
could earlier only handle a single include whereas the rewritten code
can handle multiple "holes" in the mask by computing the set of
subrectangles remaining after punching out the include holes.
Change-Id: I163413c7fc301f25c4523b0ee03690f983a05322
|
| |
|
|
| |
Change-Id: I5c37e4b4dd83bc239ed242709ede70982f14705f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the drag source and drop target listeners for the Outline. The
drop target listener now uses the SWT Tree support for drag & drop
(such that you for example get drop position feedback lines between
siblings). You can now drag items within the outline to do precise
reordering, as well as target particular positions during drops,
either within the outline or from the canvas or the palette.
This changeset also fixes a number of other issues I ran into at the same time:
- Fix keyboard shortcuts such that they map to the same context as the
canvas (e.g. when you activate the outline it shows the same undo
context as if you click in the associated canvas)
- Fix a bug with context menu code when none of the options are
selected in the XML
- Fix selection dispatch. If you had two side by side canvases,
selecting items in the Outline would show highlights in both
canvases; it now only causes selection syncing with the associated
canvas.
Change-Id: I00c3c38fabf3711c826a3bc527356cbc77ad4a7e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |\ |
|
| | |
| |
| |
| | |
Change-Id: I5641a9238129558b269c3f8a27a5b4de54e9db44
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The property context menus in the layout editor lets you choose
between True and False (for booleans), and between the various
possible enum values for enum properties. You can also reset the
values back to whatever the defaults were.
The menu label for this was "Clear". This changeset changes this to
"Default" instead, since "Clear" sounds more like an action than a
persistent choice among many, and when this option is chosen you are
removing a local override of the property and picking up whatever the
default is.
Change-Id: Id3ea9618612ac44e2b965e77c9e84751364cf813
|
| |
|
|
|
|
|
|
| |
Dragging something into a ScrollView wasn't working,
because a ScrollView was not inheriting layout behavior
from its parent rule.
Change-Id: Id8c11fb033921d86a57d0f34bd7c677dbe229cac
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
On double click, if the clicked area originates from an <include>'ed
XML file, open the included layout in the editor. Also opens
files in the @android: namespace if available, for example if you
inculde @android:layout/select_dialog_multichoice.
Change-Id: I215c411257717f7b97e7b0ee1d5498c318cdb04d
|
