| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changeset pulls out the API classes from the plugin sources and
into a separate standalone .jar library. The library depends on the
common.jar library.
With the separate view API it should be possible to build designtime
helpers (view rules) for custom views to improve editing behavior in
the layout editor.
Change-Id: I20bb511668de2fe52910e5fe0bbd3ec2a18b5a08
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset changes the Actions mechanism for view rules to add
support for the following:
* Delayed computation of submenu contents. Before this, a view rule
would have to produce the full tree of actions to be shown in menus
and submenus - for example including all the properties, and in turn
all the enumerated values for those properties and so on. Now
there's a Provider interface which can be used to compute these menu
items only when the menu is actually opened. The properties menu now
takes advantage of this.
This was also necessary to implement the following new feature:
* The layout editor context menu now also lists not just the
properties for the currently selected views, but also the
properties for the parents. For example, if you open the context
menu, you'll see the properties for the button you just right
clicked on, but there will also be a "frameLayout1" submenu
containing the actions for the <FrameLayout> parent of the button,
and a "linearLayout1" submenu for the parent linear layout. This
is useful when a parent layout doesn't have blank space on its own
so it is difficult to target.
A future CL will use the lazy initialization to add more options to
the properties menu.
* Support for arbitrary nesting. Submenus can contain submenus can
contain other submenus etc.
* Custom ordering. This changeset moves the "sort priority" concept
(which was already used for layout actions) up to all actions, which
makes it easier for rules to cooperate on ordering because instead
of appending or prepending to the superclass' context menu result,
actions can now just be initialized with a sorting priority value
which makes it trivial to interleave actions regardless of who adds
them. This also makes it a lot easier to use custom ordering in
choice menus where the ordering used to be alphabetically sorting on
keys.
* Improved support for multiselection. The callback interface now
takes a list of nodes to apply the callback to, and actions can
indicate whether they support multiple nodes. This makes it possible
for actions to more directly support the case where you apply an
action to multiple nodes. As before, the available actions in the
context menu is limited such that it only shows the actions common
to all. But now those actions can do something specific. For
example, if you select "Edit Text..." on many nodes, you will get
the input-string dialog once, and then the value is applied to
all. Similarly, if you select "Edit Id..." it will ask for a
separate id for each value (and you can cancel out of this loop).
There are various API changes too. Since the Choices action (which had
a map-based set of values) was removed, the OrderedChoices is now
renamed Choices. The Actions subclass of MenuAction which all actions
also extended has simply been moved up to the top level MenuAction.
And MenuAction has been renamed to RuleActions since they are used
not just for menus but for toolbars etc and the key thing about this
interface is that they are intended for use by rules.
Change-Id: If49f75213f2041ebfef7e84254d70d219bb766ab
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds tooltip drag feedback for RelativeLayout. During
dragging, the matched edge can quickly change from the left side to
the right side or the top to the bottom edge, so the tooltip support
now allows a client to specify where to align the tooltip not just at
creation but also during updates. This is particularly important for
RelativeLayout where we need to ensure that the tooltips do not
obscure the constraint feedback arrows. And to prevent flicker, it
uses a timer to ensure that there is at least 750 ms between the
repositioning of the tooltip (but it will apply a side change
immediately if it has been 750 ms since the last time the alignment
changed).
Change-Id: I8817db67844ad13c651d343ad310d8646e34dfca
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some layouts, such as LinearLayout, when you drag widgets into the
layout, we automatically adjust the widths and heights of some
widgets, such as text fields (to make them fill the full width in a
vertical linear layout, and so on).
However, this was also done when dragging a widget from one place to
another within that same layout. In that case, we should leave the
dimensions and weights alone, since the user may have deliberately
changed these.
This requires splitting the InsertType.MOVE into two, since we still
want to apply default sizing when you move a widget from a different
layout into this one. The InsertTypes are now MOVE_INTO and
MOVE_WITHIN, and we only apply default size styling if we are not
moving within the same layout.
Change-Id: I73ace89aff8111417bd6635e13397e7f027bab0a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds basic support for grid layouts:
- Freeform mode where you can drag & drop anywhere in the layout, and
guidelines are offered to align with other left boundaries, right
boundaries, baseline vertical alignment and center layout horizontal
alingment. In addition, it also offers "preferred spacing"
positioning, using the recommended distance between widgets.
Also, during a drag a regular 16x16 grid is also (faintly) shown and
(when there are no alignment matches as explained above) the
position snaps to this grid.
We also show the grid-structure (rows and columns, not the regular
snapping grid) during drags to make it more obvious that behind the
scenes there is a grid (because some other operations might shift
rows and columns so it's important to present the right user model.)
The freeform grid layout editor will automatically create rows and
columns and size them using spacers which are hidden from the user,
and on deletion these are automatically cleaned up as well.
- Grid mode where you can drag to any given cell, or between any two
rows or columns.
- Some layout actions for manipulating the grid (add/remove row and
column, adjust the gravity, toggle modes.)
This CL also contains various diagnostics code for the grid mode, and
does not yet correctly support dragging multiple views simultaneously.
Change-Id: Ie9ec54805039645e3db78d19095da86b04e44ca0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a "tooltip" during resize operations close to the
mouse cursor which displays feedback about the current resize
dimensions.
The feedback window is similar in appearance to a tooltip, but unlike
SWT tooltips it moves with the cursor and updates the text
dynamically, and appears immediately rather than being tied to mouse
motion timeouts. It is also partially translucent and uses a slightly
smaller font.
Change-Id: I6b663510f078f325d2f7b168c887aeff14de31b8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds the basic plumbing for supporting insets, such
that selection handles can reflect the true bounds of a widget, and
such that guidelines which show adjacent matches can show and measure
the correct visual distance between the widgets.
The actual insets data is not available (though there are some
commented out measurements for some of the most important widgets,
like buttons), so the purpose of this changeset is to put the APIs in
place such that the various view rules can correctly account for these
deltas when they become available.
Change-Id: I326bfa22f0d239d76685b371d38bb8eac594a53b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds a deletion hook to the view rule interface which
lets specific layouts perform cleanup when some of its children are
removed. This is vital for GridLayout where various rows and columns
need to be cleaned up.
In this changeset, this is used by RelativeLayout to remove constraint
references to widgets that have been deleted. Without this, you could
have Button2 reference Button1, then delete Button1, and when you drop
a new button, it will be assigned the now available name "Button1" and
the old constraint would kick back in!
Change-Id: Ic5829228cff38bfdc291988b1a2ef172e9aa4de5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL fixes three issues with the new relative layout interaction:
(1) Assign ids dynamically. Before this changeset you couldn't attach
to a node which does not have an @id attribute, since layout
params need to name the constraint by id.
This changeset changes this such that you can attach to any
arbitrary edge, and when you commit the drag, a unique id is
generated on the fly and assigned to the node.
(2) Handle dragging multiple nodes at the same time. The new
constraints code was unconditionally applying the same constraints
to all the dragged nodes, which meant they ended up on top of each
other. This fixes things such that the first node is assigned the
new constraints, and then all subsequent nodes are attached one
next to the other, in a direction depending on which edge you
attached to (e.g. attaching on the right will arrange the siblings
towards the left out from the edge.)
(3) Fix a bug in the code to detect and prevent cycles.
Change-Id: I157d45e117d3229f285870517b85ed902607b966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RelativeLayout now has both drop/move and resize guidelines, and
existing constraints are visualized for the selection.
LinearLayout resizing now uses weights to change the size of nodes
rather than setting width/height.
All resize operations offer guidelines to snap to their "wrap_content"
size.
Various bug fixes in related areas as well.
Change-Id: I817e34c6e67ce61cfb137eb067076d91f69f99e9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds "resizing" support to the layout editor.
First, the normal selection overlay is replaced with a selection
rectangle which also has "selection handles" in the corners and in the
middle of each edge. Moving the cursor over one of the selection
handle will show a directional resize cursor, and dragging the handle
will initiate a new resizing gesture. (This also made it possible to
remove the selection fill we've used until now, so the layout editor
will "interfere" less with the visual look of the layout.)
During the resizing operation, the current size is displayed in the
Eclipse status bar.
The resizability of widgets is determined by metadata, so for example
a ZoomControls widget is not resizable, a rating bar is only
horizontally resizable, a TableRow is only vertically resizable, and
most widgets are resizable in any direction.
The parent layout is involved in the resizing operation. Currently,
the resizing gestures will only update the width and height properties
(except for absolute layout, which will also set the x and y
properties if you are dragging a left or top edge). In a follow up
changeset this will be extended to for example make RelativeLayout
allow resize dragging to snap to new edges and the resize will be
applied as a set of new constraints on the "resized" widget. Thus,
you'll be able to drag the right hand side of a widget and drag it
over to attach to some other widget or edge, independent of what the
left edge or vertical edges are bound to.
This changeset also adds the ability for ViewRules to provide a
message or error message back to the IDE during a drag or resize
operation. For resizing this is used to display the new size. However,
it is now also used to display more useful messages in a couple of
older scenarios:
* Attempting to drag anything into a ListView will display a message
that AdapterViews much be configured via Java code
* Attempting to drag anything into or within an AbsoluteLayout will
warn that AbsoluteLayouts are deprecated.
Note that resizing will currently set the size to specific pixel (dip)
sizes. In the next changeset I will add guidelines which (in addition
to those described for RelativeLayout above) will add guidelines for
significant sizes such as the parent size, the preferred
(wrap_content) size of the widget, and possibly other hardcoded sizes
in the same layout.
Change-Id: Ie4f3367e81b24259a106c649c944008f4a3d31ec
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds preliminary support for fragments:
* Add <fragment> to the palette, along with a drop handler which pops
up a class chooser to pick the Fragment class; all project
implementations of android.app.Fragment and
android.support.v4.app.Fragment are listed.
* Adds a fragment descriptor such that code completion works for
<fragment> elements
* Fix project callback such that it does not complain about a missing
class "fragment".
* Fix outline to display the name of the fragment rather than the
fragment tag name.
* This changeset also centers the label in MockViews since those are
still used to render fragments
Change-Id: I6e062970b335d9c95870f181ed408960978c423e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layout actions bar shows actions of two types:
* Actions which edit attriubutes of the "current layout"; typically
the parent of the currently selected views. For example, the
"orientation" or "baseline" attributes of a LinearLayout.
* Actions which edit the layout parameters of the selected views. For
example, the "weight" attribute of children in a LinearLayout.
One thing which was missing is adding in layout actions for views that
are children. For example, the TableView now has an "Insert Row"
action. If you select the table itself, rather than a child within
the table, you would not see the Insert Row action. Similarly, if you
drop a new LinearLayout, you cannot toggle its orientation attribute;
it won't be shown, or if it is within another LinearLayout, you will
see an orientation toggle but it controls the parent, not the newly
selected LinearLayout.
This changeset addresses this by adding a new section of actions on
the right hand side of the actions bar, which contains the layout
actions which apply to the selection, regardless of the parent type.
For example, if you have a LinearLayout containing a TableLayout, and
you have selected the TableLayout, you will first see the LinearLayout
actions, then the LinearLayout layoutparams actions (which will be
applied to the TableLayout), and finally the TableLayout layout
actions (insert and remove row).
This changeset also improves the TableLayout insert row action to
insert the row before the current selected row (if any) rather than
unconditionally appending it to the end. It also selects the table
after creation to make it more obvious where it was added. The new
ability to select nodes from layout rules is also used in a couple of
other places.
Change-Id: I7cd8f75e61fc916bc75ed5ad156440f0f8cbd786
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the mouse is over a rectangle, we highlight this "hover"
rectangle by painting a semitranslucent white rectangle on top of it.
When a view is selected, we highlight it by painting a semitranslucent
blue rectangle over it.
This means that if you move the mouse over the selection, you get both
of these effects added together, which dilutes the underlying selected
widget too much.
This changeset tries to improve this situation by defining a different
visual style to be used for the combination of hover and selection,
where the opacity is much lower for the hover in this case.
This changeset also reduces the existing hover by about 30% opacity.
Change-Id: I63ffe8a9d756dcae29b2009a1a1cd6b9ffb6fbe7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
| |
|
|
|
|
|
| |
Move all the resource query methods that returned an array of 2 Strings
to return a pair of ResourceType and String.
Change-Id: I6b8447aa27005de786e2defef81ad88a72363523
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, fix absolute layout such that it properly handles both screen
scaling as well as various screen resolution densities when it
computes the dip positions.
Second, pass the bounds surrounding the mouse position when a drag is
initiated to the view rules. This is used by both absolute layout and
relative layout to properly handle dragging bounds. In particular, in
relative layout this is used to match a border not only when the mouse
cursor gets near the edge, but when the bound edges also get near the
edge. In absolute layout this is used to show a correct bound
rectangle that has the proper offset from the original drag position
(which may not be the center, which until now it was assuming).
Third, in RelativeLayout, when there are no children, offer a left
alignment regardless of where you are within the rectangle. This is
similar to how LinearLayout works.
In addition, two internal changes:
* Factor the various RelativeLayout string constants into the
LayoutConstants class. This had the nice side effect of revealing a
typo where we were referencing a non-existing value! Constants FTW!
* Make the RulesEngine log the exceptions, not just the error
messages, thrown by IViewRule calls. That way the full stack trace
is available in the Error Viewer, including line numbers etc.
Change-Id: I0b83df71b36741e65a1eb2003ed044157eb6f0cd
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes issue 13051: New layout editor always insert "match_parent",
even on older platform.
View rules can now look up the API level of the current project, and
based on that choose to use match_parent or fill_parent when they need
to manipulate the layout attributes.
Change-Id: I861e1f7f7409c40c05b1472268f120806667025c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset moves the painting of selection bounds and selection
hints out of the view rules and into the core IDE. The reason for this
is that the visual appearance of the selection shouldn't be up to each
rule; for one thing the selection highlight should be consistent and
not vary from view to view (and in fact there was only a single
implementation of the paint selection method among the view rules),
and for another the view rules are in theory sharable among IDEs
whereas the selection appearance is going to be IDE specific. There
was also painting of "hints" in the RelativeLayout; rather than having
the visual appearance of this dictated by the rule, this is also moved
into the IDE such that the rules only provide the hint text and the
hints are displayed by the IDE itself.
The above refactoring also fixes selection feedback for <include>'ed
views, which were not visually selectable because there was no
corresponding ViewRule, so nobody to paint selection. With these
changes selection painting is now independent of the rules.
Change-Id: I22dd926102128634a443b8bafb54d4764f1eda41
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset adds support for adding custom-logic to initialize
views, both to add children and default attributes and to customize
layout attributes when added to a new parent.
First, there is a new "onCreate" hook which is called to notify a view
rule that an instance of its corresponding view has been created. This
lets the ViewRule perform custom initialization of the object. The
ViewRule is told what type of insertion occurred, such that it can
distinguish between a newly created view, a view that is the result of
a copy/paste, and a view that is part of a move operation.
The changeset adds a number of new ViewRules which take advantage of
this:
- A TabHost rule creates the various skeleton children that are
required, such as a TabWidget child with id @android:id/tabs and a
FrameLayout child with id @android:id/tabcontent
- A DialerFilter rule creates the mandatory EditText children ("hint"
and "primary")
- The HorizontalScrollView rule creates a horizontal LinearLayout child
- The ImageButton and ImageViewButtons initialize the "src" attribute
to a sample image
- The MapViewRule initializes the apiKey attribute
In addition, views are also notified when a new view is added as a
child, such that they can perform additional customizations, in the
form of an "onInsert" event.
The most important application of this is LinearLayoutRule, which uses
this to set reasonable defaults for the layout_width and layout_height
parameters. It uses metadata (which is currently built into ADT but
would ideally migrate into our XML config files) to determine whether
a given child prefers to grow horizontally, grow vertically, both, or
neither, depending on the surrounding parent context. For example, an
EditText will default to filling the parent width if it is in a
vertical LinearLayout, but it will not grow vertically in a horizontal
linear layout. And so on. Various other rules also use the onInsert
event to tweak children attributes. A ScrollView will for example
always initialize its single child to match parent.
Views can now also add plain menu items into the context menu, and the
TableViewRule adds one such action: "Add Row", which appends a new row
into the table.
The Palette Preview code also invokes these creation hooks, such that
if you for example drag a DialerFilter it can properly render since
the mandatory children are created up front. This required various
changes to the preview code to be able to handle XML edits by the
rules.
Finally, this changeset includes various other misc changes that I
performed at the same time:
- Removed SWT dependency from the ViewRule classes (SWT Rectangle use
in Rect)
- Fixed AbsoluteLayout unit test (issue 3203560)
- Fixed positioning of the preview outline in LinearLayout when only
one of the dimensions are clipped due to a smaller target layout
Change-Id: I5956fe4e7a31a20b8dd2f9d9b0c1f90e2f75d68a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for loading 3rd party .jars providing additional layout
rules. This can be configured by adding a property referencing the
jars to be loaded as part of your build.properties, like this:
default.properties:
...
layoutrules.jars=chart-rules.jar:graph-rules.jar
...
This will create a class loader referencing chart-rules.jar and
graph-rules.jar (as well as the visual editor's plugin class loader as
a fallback), and this class loader is used to load IViewRule
implementations.
In addition, this plugin rips out the various remaining Groovy hooks
and references that were earlier used to load Groovy scripts as layout
rules, and removes groovy from the load path and build symlinking
scripts.
Change-Id: Ia17a60259559ec86270726add258382a879117dc
|
|
|
We had a number of layout implementations in the tool written in
Groovy; these were hard to deal with because of lack of good tool
support (debugging didn't work, refactoring didn't work, code
completion didn't (always) work, go to declaration didn't work,
semantic checks like unused code didn't work, etc. etc.)
Since these layout helpers are only getting larger, replace them by
equivalent Java code to make development easier.
This checkin also moves the API classes formerly used by Groovy
scripts into a new package (next to the Java layout rules) under
com.android.ide.common (api and layout) since this code isn't Eclipse
specific and could be used by other IDE vendors.
These interfaces were left identical (only the package statements and
directory location changed), with two exceptions: I added a new method
called "in" to IAttributeInfo.java, and I added a parameter to
IViewRule's onInitialize method.
The Groovy code was kept as close to the original as possible; I
copied in the Groovy code, and then replaced the Groovy-specific
constructs (closure-iteration on collections, literal map syntax, etc)
with equivalent Java code. The only tricky part was ensuring that
Groovy's handling of the == and != operators were translated into
.equals calls.
Change-Id: Idf7660ddea3766eac0a4a65ce6524d3f5119f7b2
|
