| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
