| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: Ic139e6f942e835dda4b7ef0303556aef014a60d3
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Instead of processing drag events using the top left corner of the
drag image, use the mouse cursor coordinate, and fix the absolute
layout rule to compute the top left corner instead.
Change-Id: I4d5096bfd04ac0abb2148196ac7e6d9d52797712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Mark internal strings as NON-NLS in rule classes. This code was
initially written in Groovy which is why it didn't have NON-NLS
markers.
Change-Id: I74517771271e54f165332543092a9d29fc2bc52a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Add layout unit tests, and some infrastructure for testing. Also fix
some formatting errors (>100 column lines) in the previous commit.
Change-Id: I3eabf30998ab7deb84df57e4d0c10cf57ee399d5
|
|
|
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
|
