| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
This fixes a bug where the insert-line for the last position is not
always *drawn* (the suggestion was there and the feedback rectangle
would snap to it, but the dashed line was not painted because the code
to suppress self-dragging was interfering.)
Change-Id: I601d2f747357d42b7a797a1ed30b723830d03520
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset fixes the following issues with LinearLayout:
* Correctly position the last insert position in the linear layout
when the layout has children.
* When you drag a widget which is already in this LinearLayout, don't
show insert positions before and after this element, and show a
match position exactly where it already is.
* Show the best-matching lines not only when you don't have bounds
(which it was already doing) but also in conjunction with the bounds
outlines. When the dragged bounds are much larger than the widgets
around the drop position, it was a bit hard to figure out where
exactly the proposed drop position is, and this change makes it a
lot clearer.
* Fix positioning of the drop rectangle. Before this change we were
positioning the drop rectangle using its existing deltaX,deltaY in
its old parent; this does not work well both in multi-document cases
as well as cases where you are dragging from one layout to
another. We are now simply positioning it at delta=0 in the new
layout; the next enhancement here would be to consider the
layoutGravity.
Change-Id: I1c71c3c48a4c104a5cde7382fb1f9a21e57122bc
|
| |
|
|
|
|
|
|
|
| |
If you open a LinearLayout where the orientation has not been
specified in XML, then the context menu will say that the orientation
is vertical, but visually the layout is actually horizontal. (The
default value for LinearLayout is documented to be horizontal.)
Change-Id: Id16797d9226b19eb53c2b59249844e2406b049e4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you drag from the palette over a linear layout view, you get drop
feedback. However, if you drag outside the linear layout and then back
in, you often don't get any more feedback. This happens pretty easily
with nested layouts.
The problem is that the feedback object is initialized and reset in
onDropEnter, but the actual guideline computation happens in
onDropMove (since only drop move is handed the mouse coordinates). The
bug happens because when you leave and return to the drop zone, the
feedback object is reset, and then the drop feedback is painted - all
before the onDropMove code has been called again.
The fix is simple: On drop enter, also call onDropMove immediately
such that the layout helpers are given a chance to initialize
themselves with the entry mouse position, before they are consulted
for drop feedback data.
This changeset also contains a fix for LinearLayouts: When there are
no children, place the guideline at x=0 or y=0 (depending on whether
the layout is horizontal or vertical). Without this fix, the line is
placed in the center of the view, which is misleading since that is
not where the view will be placed upon drop.
Change-Id: Ib5e17a2d9d3818677e4209126233bbde527207c8
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove Groovy Closures from the tool integration API, and replace with
dedicated single-method-interfaces (which can also be invoked as
closures from Groovy - but which also would allow non-Groovy
implementations to work as View handlers).
Also add warning to the javadoc for the interfaces that this is
neither a public nor a final API.
Change-Id: Ia146e1e150c2d47f95ff5bbb0771efc0e3aaa5ad
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changeset makes a number of adjustments to the visual feedback
shown during layout dragging & dropping, selection, etc.
These are:
1. Render text on top of a translucent mask (white on a transparent
gray rectangle). This ensures that the text is readable regardless of
what content is under the text. We can't just use the background color
for the normal SWT drawString for two reasons: First, we need to
control the alpha of the background only (since we want the text to be
opaque and the background to be translucent), and second, we often
want to draw multiple lines of text, so we need to manually draw a
background rectangle which accommodates the maximum width of ALL the
lines such taht we don't have a ragged background.
2. Paint the outline mode lines using solid, translucent lines. And
adjust the bounding box computation in this case by 1 pixel such that
when you have adjacent boxes (such as in LinearLayout), you don't end
up with two thin lines next to each other creating a thick line.
3. Change the DrawingStyle internal API from "foreground" and
"background" colors to "stroke" (border) and "fill" (interior), with
individual alphas. This makes the color definitions simpler (for
example we don't need two separate styles, one for the selection
border and one for the selection interior).
4. Make the hover more subtle, using no border and just a light
translucent gray rectangle to only slightly draw attention to the view
under the mouse.
5. Change the appearance of selection to light blue and use a long
dashed border around it. The anchor lines are more faint and more
translucent to make them stand out less.
6. Change the appearance of the drop-preview to use a dash patterned
border identical to the selection border, but colored orange instead.
The matching border pattern will hopefully reinforce that the
drop-preview line is where the selection (also dashed) will go.
7. Use green to show available drop zones (the grid surrounding a
target in RelativeLayout, and the positions between elements in
LinearLayout).
8. For invalid drops, use a white X on a red background as the overlay
fill.
9. I replaced the oval+X pattern from the LayoutHelpers and replaced
them with the orange dashed insert-position lines. I also adjusted the
LinearLayout to draw the bounding boxes such that the middle of the
bounding box, rather than the top left edge, are aligned with the
insert position.
Change-Id: I85c77b9fa84b732a78aac635442f96e7ccfc3983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pull color constants out of the specific layout helper classes (groovy
scripts) and the canvas editor and use a generic style enum instead in
the interface, and associate the visual attributes (color, line style,
thickness, alpha) with a swt-specific enum on the editor side. There
is a single new API method which takes an enum parameter, which should
let us add drawing styles over time. By having the color definitions
on the tool side rather in the specific layout helpers it's not only
easier to change the colors but also easier to ensure that the
different helper all stay consistent as we change color schemes.
In the immediate term (next integration) I'll change some of the
colors; after that we should make the colors adapt to the chosen
theme, and eventually these should be provided via the SDK from the
themes themselves.
This changeset doesn't actually change the colors used for the various
types of visual feedback (selection, hover, drop-zone, etc) - I'll
investigate that next. For that reason I also didn't replace all the
various client-side color usage in the RelativeLayout.
Change-Id: Iddf4ace9006ec02d9907c3c37d539ab7414f1371
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Context menu now shows some view properties:
- for all views, quick access to layout width/height.
- for LinearLayout, quick access to orientation.
- for all views, quick access to all boolean, enum or flag attributes.
Some follow up will be necessary in another CL, namely:
- booleans must be tri-states (true, false, cleared).
- need a way to clear enum and flags rather than just change the value.
Change-Id: Ie7451c21f0781f0efb0a1bbc676abef80027c4f7
|
| |
|
|
| |
Change-Id: Ib9f3473d49bc27dfb87d29855a832a21bdcf3100
|
| |
|
|
|
|
| |
First pass. There are some details to take care of later.
Change-Id: Ic9ac3d34ce4061ed2a8c257ce6bd40ea30497eb8
|
| |
|
|
| |
Change-Id: I64959e27f2c08c459e15323d7c8d2cdb041ba9dd
|
| |
|
|
| |
Change-Id: Iee6868e65ebdb98a8b62dd07d8490e5363e6f3af
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
1- Fix computation of scrolled drop coordinates: margin constant
should not be used directly and is now private to the Scaling
helper class. The Drop class now defers to the Canvas to convert
display coordinates into canvas image coordinates.
2- Fixed a small bug when LinearLayout was computing the
insertion point when there were no children.
3- Added a basic FrameLayout for drop support.
Change-Id: Iaf1305bd3df16b62fe29568eb811d36704f86482
|
| | |
|
| |
|
|
| |
Change-Id: I6ed9f1d89f61caf6141f23708854a01247ab5518
|
| |
|
|
| |
Change-Id: Ic737d5273b55a4ec78c1d9789616e1e296b77b00
|
| |
|
|
| |
Change-Id: Icd8ac13e91b575c7133c5c0256a46e3c16e5fae8
|
| |
|
|
|
|
| |
With implementation for AbsoluteLayout and LinearLayout.
Change-Id: If8d6301abcc848574b3ab5d8894396a0246b1275
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reconfigures the Groovy engine:
- The user projects /gscripts folder is added to the groovy class path
(so user can import their own local classes.)
- The IViewRule package is added as a default import (using the
import .* syntax), which means the scripts don't have the specify
every single import anymore.
- Our scripts can now extend each others -- as long as the classes are
in our package they will be resolved and loaded.
Change-Id: I79dabf7d1317a1bf4a0fc04ee8ba0987dca7da15
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Details:
- This moves the selection drawing from the LayoutCanvas to
the groovy script.
- There's a single IViewRule "onSelected" method. The script
which implement it return a closure (aka an anonymous method)
that does the actual drawing.
- onSelected is called during the actualy selection or when
the canvas is refreshed. The rendering closure is actually called
later during the canvas onPaint.
Here I am mostly testing the logic of having a script callback
handle an event (the selection) and returning a closure that
does the drawing later (during onpaint).
The main rationale for separating them is that the GC needed to
draw isn't available during the actual selection event.
I plan to reuse this mechanism for drag'n'drop & co.
TODO: layout selection is broken and will be fixed in another CL.
TODO: onChildSelected will be next.
TODO: Originally I had plans for onSelected(isMultipleSelection),
which I'm not sure I'll actually add later anyway., I fail to
see the point in implementation.
Change-Id: Ibc5fecbd107429df1f53b2b8172aba55e6289795
|
| |
|
|
|
|
|
|
| |
This adds BaseViewRule (better name welcome) that is basically
an empty IViewRule so that groovy classes don't have to
systematically redefine the same empty boilerplate.
Change-Id: Ibf9a03d3aa0ca8a42534f5693792235c31100273
|
| |
|
|
|
|
|
| |
Moving the public API from com.android.ide.eclispse.adt.gscripts
to ...adt.editors.layout.gscripts.
Change-Id: Idf5b979d47dbbbe2514cce8cc3c688eb273bcce6
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a *temporary* CL just to get some things out of the way:
- it adds some method to create some XML from groovy
- it uses the new dropStart/dropFinish API.
However after this is submitted I'll change the IViewRule API as
we discussed so all this code will need to change. Again.
Change-Id: Ie9c7eebf0f9e1d48e364467fbaac5615b4c42f21
|
|
|
So right now we have:
- some GRE/GLE code in internal that uses the scripts
- the "public" bases client classes in ADT src/gscripts (not internal)
- the "client scripts" in ADT /gscripts.
- projects use their own /gscripts folder.
Change-Id: I899d272233f35f493317a56fde60eb7e4a257c7a
|
