| 474bd94478a8ced503e292b17c7e5962de414d99 |
|
30-Nov-2012 |
Tor Norbye <tnorbye@google.com> |
Code completion improvements for custom views and themes
This changeset adds custom view completion to the content assist.
Code completion for elements (e.g. from text context or inside a <)
should now include custom views found in the project, and prefix
typing should work as well.
Similarly, code completing inside a <fragment> name attribute or a
<view> class attribute should complete fragment and view classes.
It will display javadocs for these classes, if available.
It also hooks up class completion in manifest files, so completing
<activity>, <application>, <receiver> etc android:name attributes
should show matching classes corresponding to the tag being edited.
The completion will also always complete theme references (?) even
when there is no known metadata for the tag, such as for an arbitrary
custom view.
Also fix descriptor metadata such that <view> and <requestFocus> show
up in code completion, works properly for layout editor palette drag
(with a class selection popup) and with a suitable outline icon.
Also tweak refactoring such that it handles both class= and
android:name usage for <fragment> elements.
Finally, for the LinearLayout automatically added inside new
ScrollViews, set the vertical attribute since that's usually what you
want.
Change-Id: Ifc98c19607ddc4e69d7645f2720120ce72d0cd95
|
| 12d4581faa6438941e65a9dc83213be34c6ca970 |
|
13-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Constants refactoring.
This changeset moves most constants into the SdkConstants
class, and gets rid of AndroidConstants and LintConstants.
It also migrates all non-ADT specific constants from
AdtConstants into SdkConstants. It furthermore moves various
other constants (such as those in XmlUtils and ValuesDescriptors)
into the constants class. It also fixes the modifier order
to be the canonical modifier order (JLS 8.x).
Finally, it removes redundancy and combines various constant
aliases such that we don't have both NAME_ATTR and ATTR_NAME
pointing to "name", etc.
Change-Id: Ifd1755016f62ce2dd80e5c76130d6de4b0e32161
|
| f25890ca71100673ba58c343a211fc838cc59706 |
|
31-May-2012 |
Tor Norbye <tnorbye@google.com> |
Default action for view rules.
For now, text-oriented widgets declare their default action to
be to set the text attribute. Also hook up the default rename
keybinding to setting the id.
Change-Id: I14e8e06d0842759b1ac05e7e9494deb30b3cc40f
|
| 0cb8e647ef345f5c2a6b7eb08b517421131bca4e |
|
07-Aug-2012 |
Tor Norbye <tnorbye@google.com> |
Improvements to relative layout move and delete operations
This changeset improves the way the RelativeLayout editing support in
the layout editor handles deletions and moves.
First, during a move, if the move is simply within the same layout,
then the layout constraints are left alone such that if you for
example have
A
v
B < C < D
and you move B up to be next to A, you end up with
A < B < C < D
(It will however remove cycles if the move would result in them.)
Second, it now handles deletion better where deleting a view will
cause all references to any deleted views to be replaced by transitive
constraints.
For example, if you hve
A < B < C < D
and you delete B and C, you end up with
A < D
Change-Id: Icb9d3552e60aee20192f7941fe52be71ba52557f
|
| 3e75d4f79a8328ed18505830c786402369082efa |
|
06-Mar-2012 |
Tor Norbye <tnorbye@google.com> |
Make GridLayout support work with the support library
Also fix the paste operation to target the parent if
the paste target does not accept children.
Change-Id: Id084db376e5ff9b4a374e6d2145bc890a925a078
|
| e50549f54810c29bffc681e39d33158ab2a8f26e |
|
10-Jan-2012 |
Raphael <raphael@google.com> |
ADT: Change LayoutEditor to use new editor delegates.
Change-Id: I5624d8f5c393a74a808d98e465f0ebc6db91d741
|
| ab36f4e7488358dea4ab6b54ee2b7bef3da0232b |
|
21-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Update SDK codebase to JDK 6
This changeset makes the SDK codebase compile with source=1.6 (which
means it also requires JDK 6). This means that methods implementing an
interface requires @Override's. It also means we can start using APIs
like the ArrayDeque class and methods like String#isEmpty().
This changeset looks big but the change is trivial: it's basically
adding @Override in all the places that need it, along with some other
automatic Eclipse cleanup in certain files (such as reordering imports
where they were incorrectly ordered (because older versions of Eclipse
didn't always handle inner classes right)), as well as cleaning up
trailing whitespace and removing some $NON-NLS-1$ markers on lines
where there aren't any string literals anymore.
This changeset also sets the source and target JDK level to 6 in the
Eclipse compiler .settings file, and synchronizes this file to all the
other Eclipse SDK projects.
Change-Id: I6a9585aa44c3dee9a5c00739ab22fbdbcb9f8275
|
| 326c61cbd946e77d4de08130d9bde55f7785daf0 |
|
13-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Support for custom view rule jars
The layout editor already supports providing a classpath of jar files
to check for custom views (via the layoutrules.jars property in
project.properties). However, once a view rule has been initialized it
is never updated.
This changeset makes the view rule loader more dynamic, such that it
checks the file timestamps of the jar files, and when the jar files
are changed it unloads the old rule instances and creates new
instances. This makes it a lot easier to develop view rules since you
can just update the .jar file and the layout editor automatically
picks up the changes (within a couple of seconds; for performance
reasons it checks the filestamps at most every couple of seconds (and
this is only done lazily of course, so there isn't a file change
listener; it just makes sure that if rule loading requests come in
more frequently than that it just uses the current class loader).
This changeset also adds an AbstractViewRule which implements the
IViewRule interface. Without this, implementing a custom view rule
will require dozens of methods to be stubbed out (and for the
developer to figure out what the methods are and what to do with
them).
Change-Id: I5f2b84e32e47611fff2d4211411f3039d16eb815
|
| fadd53c9ef6d046a60919e89eed1380696b67b7a |
|
21-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
Misc GridLayout handling fixes
This changeset fixes some miscellaneous in the GridLayout support.
The gravity handling code (which creates a bitmask for gravity from
XML attribute values) was pulled out of the change layout refactoring
such that it can also be used by the GridLayout. This is done to
figure out where cells are not bound to the top or left corners, in
which case they should not be considered when computing a suitable
right or bottom edge for splitting a cell.
There's also fixes for a problem where certain negative constraints
would be offered, there were tooltips when only one of the two
dimensions produced suggestions (and you can only drop when both are
valid).
When removing children back to a blank layout, reset the columCount
to 2.
And finally there were some problems where the columnCount was larger
than the number of actual used columns in the table, where dragging
near top/left corner would use some of the later columns rather than
the first available one.
Change-Id: Ice22754fb14659812b54019452aeca6daaeede10
|
| bf9db3ba5053c8f22a07ee748b2cb41d374d8642 |
|
24-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Use GridLayout state to determine exact row and column boundaries
This changeset updates the GridLayout support to consider the state of
a rendered GridLayout when deciding where the rows and columns
are. This information is already available in the GridLayout object,
so if one is provided use that data rather than inferring it from the
bounds of the views in each row and column.
This required changing the view rules API a bit to pass the view
objects in to the key entry points (drawing selection, drag & drop and
resize).
Change-Id: If8484f7f7181c65d0a2fdf629ffd515edd05448b
|
| 94986e745141118cace0391da1b4dc8533408751 |
|
10-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Action API improvements
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
|
| 44879568a09668fcf11073840d8e1cc397135ff0 |
|
15-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Allow GridLayout to exist in project packages
Change-Id: Ia455a9c9de853dcc0e5152a8b24a09192c39b3b4
|
| 6a4ee36d267574fc94e5f87118f9a15d8d87abf5 |
|
15-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Fix undo problems in the XML editor (issue #15901)
We've had a recurring problem where in difficult-to-reproduce
circumstances the Undo button doesn't seem to work: After making some
edits like dropping a button, each press of the Undo button will each
individual edit of the compound operation, such as undoing each
attribute set, each element add, and so on -- just as if the entire
edit operation did not run under an undo lock.
This changeset fixes this issue - or at least one scenario of it
(tracked in http://code.google.com/p/android/issues/detail?id=15901 )
It turns out that Eclipse in some cases decides to "cancel" the current
Undo operation. This is done in reaction to selection changes, and the
logic for that is related to a user using a form editor to switch
between various attribute fields, and expecting each text field edit
to be separate. In the above issue I've listed a thread dump which
shows one such cancellation which is definitely not desirable.
To fix this bug we add a workaround: In our code which sets up the
undo recording, we call "beginRecording" -repeatedly- (say 4 times).
Since undo units are allowed to be nested, this means we're nesting
our own undos 4 times, and when we're finished with the editing
operation we simply call endRecording a corresponding number of
times. This means that when the offending code comes around and calls
StructuredTextUndoManager.forceEndOfPendingCommand it will subtract
the command count by one, but we'll still be in one of our nested
contexts (and the editor does allow extra endRecording calls to be
called).
Change-Id: Ic4dde029efcb18def3c9daa5d3676c49a815d804
|
| 271993a2368361fb1f67ea9c1388a352e9df43f5 |
|
15-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Sort XML attributes logically
This changeset modifies the layout editor such that it writes
attributes in a certain order:
* id
* style
* layout_width
* layout_height
* other layout_ attributes, sorted alphabetically
* other attributes, sorted alphabetically
The layout editor will produce attributes in this order when
- New widgets are dragged into the layout
- Widgets are moved in the layout
- It will also insert attributes in the right place when they are set
as the result of (for example) using the context menu actions.
Note that this ordering is applied unconditionally - there is no user
setting to turn it off. However, note that the current behavior is
random - moving a view for example will scramble the attributes (in an
order which is related to hashkeys in a map), so the option would be
"sort attributes logically" versus "sort attributes randomly"; if we
want an option to "leave attribute order alone" that will need to be
implemented.
Limitations:
- This does not yet modify the formatter to reorganize attributes.
Thus, Ctrl-Shift-F to reformat the XML will not change attribute
order.
- It does not fix the problem that the XML model updater does not
respect the formatting settings (such as one newline per attribute)
when manipulating attributes.
This will be addressed/worked around in subsequent CLs.
Implementation Note:
The Eclipse XML model updater will unconditionally *append* any new
attributes. We take advantage of this to perform attribute sorting by
ensuring that we always insert new attributes in the right order. We
also check for existing attributes and any which fall
lexicographically later than the new attributes are removed and
reinserted in the right sequence. In order to avoid performing these
removals and additions repeatedly on a node when we set multiple
attributes, and to avoid flushing attribute changes *immediately*
(which was the case until this), we now queue up all pending attribute
values in the nodes and apply them at the end when all attribute
changes for a given node are known.
Change-Id: If39f8c29f26e281f7c6622a31e11ba49724d274a
|
| 4eacdfbcc84ad11f599020b12ad76aebed70537f |
|
07-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Grid Layout Support.
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
|
| 7834ca1b6dce0b2d70927f3806e731fbb02c4199 |
|
07-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Add deletion hooks for view rules
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
|
| 1fc114798082030e38eaa3dbc53b11235dfdcadb |
|
02-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Extract client rules engine into top level class
The IDE-side implementation of the IClientRulesEngine interface was
nested within the RulesManager class, and has grown a lot over
time. This changeset moves it out as its own top level class. There
are no semantic changes, just a straightforward refactoring operation.
Change-Id: Ica072e8f7a06b822c6bde28e37b10ec86e05a402
|
| c435c632e01767c7d1757a394dc395683525e156 |
|
01-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Move rendering code into RenderService class
This CL moves the various rendering-related code in
GraphicalEditorPart into a separate RenderService class, which can be
configured for different purposes:
- Rendering a layout shown in the canvas
- Rendering palette previews
- Rendering a preview of a node during a drag from a palette
- Rendering a theme drawable
- Rendering layout-only to measure preferred sizes
Once configured, the rendering service can be used repeatedly and off
the UI thread to for example render all the palette previews without
blocking editor startup. This will be addressed in a follow-up CL.
Change-Id: I851148d80c3a4dc9e4b5b66c9838ae49809ea03c
|
| 80d9301c2e874b29889c41adb0623666cf534fa0 |
|
10-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Resize & Guideline Support
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
|
| 429ae88878cf781753d8261d350ad89fe5864169 |
|
07-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Add Resize Support to the Layout Editor
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
|
| 6baa2f2159c190d8d1c6f883e03862af81b3d829 |
|
24-May-2011 |
Tor Norbye <tnorbye@google.com> |
Don't apply default attributes in a move/copy. DO NOT MERGE
There is a method in the layout editor which fills in required default
attributes like id, width and height, as well as some optional
attributes like a default text attribute.
This code was called unconditionally whenever a new child is added to
a layout. However, this should only be done when a new widget is
created, not during moves or copies from existing elements.
Change-Id: I2b437ef609a168f1bb1b7698d3a954a4d2f5faa0
|
| 01ed60dd2b22c98bf05f52594308c0b7a5a9111a |
|
24-May-2011 |
Tor Norbye <tnorbye@google.com> |
Don't apply default attributes in a move/copy
There is a method in the layout editor which fills in required default
attributes like id, width and height, as well as some optional
attributes like a default text attribute.
This code was called unconditionally whenever a new child is added to
a layout. However, this should only be done when a new widget is
created, not during moves or copies from existing elements.
Change-Id: Ic04dec746c70359eca38454bacfdcdb87891719f
|
| d9cceddf012ef3284cf939773edc7b6e291fba21 |
|
21-May-2011 |
Tor Norbye <tnorbye@google.com> |
Offer to install fragment compatibility library
This changeset changes the popup displayed when you drop a fragment
tag in a pre-API-11 project. Instead of just displaying an error
message, you now get a dialog which asks if you want to install the
project, and if you click the "Install" button it invokes the SDK
manager to install the right package, and then copies it into the
project.
In addition, the fragment selector now has a "Create New" action which
invokes the New Class wizard pre-configured with the right fragment
class.
Change-Id: I4ce1b51fbfe939a21e91379eb6b77ff722c13f0f
|
| cd05e93b1194c89fe9eca1ee4b999d2991334f4b |
|
15-May-2011 |
Tor Norbye <tnorbye@google.com> |
Basic fragment support
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
Conflicts:
eclipse/plugins/com.android.ide.eclipse.adt/src/com/android/ide/eclipse/adt/internal/editors/layout/descriptors/LayoutDescriptors.java
Change-Id: I6f39f0c29a0cf21799fa8a55406eeae1e3beb57f
|
| 46d0ebd2126fad6b1480fa5c8121e4638c463c73 |
|
15-May-2011 |
Tor Norbye <tnorbye@google.com> |
Basic fragment support
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
|
| 40c1413a861cefb3bfb2cd200c89ffdf84fdc308 |
|
12-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Custom listview layouts
This changeset adds support for user-configured layouts in ListViews
and ExpandableListViews.
There is a new "Preview List Content" pullright menu when you right
click on a ListView in the layout canvas. The menu contains links to
configure
- the layout to use for list view items
- the layout to use as a header
- the layout to use as a footer
- as well as a number of pre-configured framework layouts for common
arrangements like 2-item list, 1-item list, checked list, etc.
The selected layout is persisted as an inline comment in the layout
XML. (Current bug: When you drag elements around in the layout,
comment nodes are not preserved, meaning you will lose your list view
render type as well.)
This changeset also adds "Clear" to the resource chooser, which makes
it possible to clear a previously set value (until this, choosing
nothing would simply abort the selection.) This makes it possible to
remove a chosen header/footer.
Change-Id: I611b00f627c5773f3fe2443a6e16c29388687b36
|
| dbf316fc2f61902ab2c249b0de6abc625ffc505b |
|
06-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Add list view preview
Use the new layoutlib facility to specify adapter view bindings to
assign default listview item layouts to ListViews and
ExpandableListViews. This is also used to provide a preview of
ListViews in the palette.
Note that the list preview is always showing the default list view
items. A later changeset will add the ability to pick a custom layout
to be used for listview rendering.
This changeset also contains a refactoring which pulls the cyclic
dependency validator out into a standalone class; this validator will
be used not just for include drop support but also for the layout
selector when picking layouts to preview in a listview.
Finally, the CalendarView has a new IViewRule which sets its default
width and height to fill parent.
Change-Id: If4fdec8d5439af69a34b029cb36a940fac953f86
|
| 3c345391ac54b9bff1e15766b6126bcbea4f449f |
|
11-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Usability fix for the layout actions bar
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
|
| 026ba97e98e0527d910e15c4e1512893a777a8d2 |
|
18-Mar-2011 |
Xavier Ducrohet <xav@android.com> |
Move classes to ide-common
ResourceFolder/File and children classes (single/multi file)
ResourceItem and children classes
ResourceRepository (base and framework, project stays in ADT for now)
All the ResourceQualifiers and FolderConfiguration
Change-Id: I5adc9bdc4886a8fa0ab44860763d594cf7af4bd5
|
| adee9788a5ac646a39b516abe4cdd1022911a3f5 |
|
09-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Add drop-support for include tags
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
|
| da02c18ad5b54d97a1fcfd5f6633062b0c873c22 |
|
01-Mar-2011 |
Xavier Ducrohet <xav@android.com> |
Resource management refactoring and clean-up.
- (I)ResourceRepository is now a common class instead of an
interface. This contains most of the code to control
a repository (which was extracted from ProjectResources)
ProjectResources extends it adding minor features such as
library support, and inline ID definition.
FrameworkResources extends it adding support for public
resources (which used to be duplicated and dispersed
in weird places).
Changed the way resources are reloaded on resource change event.
Instead of marking the resources as modified (using
Resource.touch()), the resources are now parsed as the files are
processed during the resource delta visitor. This makes more sense
as there are now other listeners to the resource changes (hyperlinks)
that access the resource list in their listeners, which wouldn't work
previously.
This also makes the code cleaner as the previous method had to query
the repo for items and return a list of new ones, which was kinda
crappy. The new code is much simpler, as is the post update process.
- ResourceItem is now the base class for resource items. It includes
all the small methods that were added by all the child classes or
interfaces.
Project/ConfigurableResourceItem are merged into the based class.
IIdResourceItem and IdResourceItem are gone and replaced by a
simpler InlineResourceItem.
FrameworkResourceItem is a simple override for framework resources.
- Also improved the API of a bit for the resource repository, making
more use of unmodifiable lists and emptyList/Map()
Change-Id: Ie3ac1995213fed66153c7e7ecbdd170ec257be62
|
| 05f8e41f9b1535dd65f1b51c4fe83083885fdb31 |
|
17-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Add framework resources to the Resource Chooser
Reenable system resources in the Resource Chooser.
Adds code to AndroidTargetData which on demand loads data from public.xml
such that it can provide a list of public resource names.
Also uses this data to filter out non-public resources from code
completion.
Change-Id: I98611668473543aaec56ce3bc2e28e6606c867fd
|
| 8dc4366bbaad39d56e1c2ded4046c86a95a17666 |
|
14-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Refactoring: Wrap in Container, Change Layout Type, Extract
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
|
| a7da09b74d5f41667823ddf36c0cd7f145f54a2d |
|
01-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Add Layout Actions toolbar
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
|
| 3cf5ce58a324efb926b862b16ad8b18d033f5be9 |
|
07-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Improve handling for GestureOverlayView
The layout editor has special handling for the "root" element, which
for example suppresses hover-highlighting for the root and a click
will initiate a marquee selection rather than a drag.
Some layouts wrap the layout inside a GestoreOverlayView. This does
not work well since the "real" root is its child, which will not be
treated as a proper root.
This changeset fixes this situation by handling this scenario such
that both the gesture overlay and its child is treated as the root.
Also make fix such that the icon in the outline also works for the
gesture overlay.
Change-Id: Ia96d2bc402958b44f9f82646ff0fc4552ab0cf14
|
| 9155df4effaf2079215d5f77dc2e70dd145a6fdf |
|
24-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Cluster of improvements for merge tag views
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
|
| 3bd45f0b16f5ebfafd8080a0f17f71d85c9840ed |
|
28-Jan-2011 |
Xavier Ducrohet <xav@android.com> |
Change APIs using String instead of ResourceType.
Move ResourceType into resources.jar so that it's accessible
to layoutlib.jar
This is cleaner and allows us to us more efficient EnumMap objects.
Change-Id: If11cbc69ae3ca8bd6c96e6d0ef402570a07af16f
|
| d5cd92b446e43e8de625142415f560ee54636317 |
|
20-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Add palette category metadata
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
|
| cc157b83f6783679c93d43ec287117604d7dcc2d |
|
11-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Use ResourceChooser for Strings
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
|
| c889d55f9ae61c886318c6c5c713b39a57bdbb13 |
|
05-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Support for editing id, text, string and reference properties
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
|
| a5d2bf173d15b74a6bcf57220c4e73b971bd09ab |
|
17-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Rewrite Outline drag & drop handler
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
|
| c43764d6220a421949766506c73a5a4a4cc43c98 |
|
14-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Various layout fixes
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
|
| fe3eebe57ba2925642cc1b257cb03ba617d298af |
|
09-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Issue 13051: Use match_parent or fill_parent based on API level
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
|
| 9672aa7c01849cbc4e11c1bd73c682fa4fc3241e |
|
20-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Refactor selection painting to fix highlighting of included views
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
|
| 1834544e4a46d2d4941545d8f8ff4d7503feacfd |
|
19-Nov-2010 |
Raphael Moll <ralf@android.com> |
GLE: Remove obsolete IGraphicalLayoutEditor interface.
Change-Id: I96f929ce9386e88f80d15195b2ff6a498e374554
|
| a2d7874ed23bfc2fa7665cc84901e0f4781b4e51 |
|
16-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Add per-view custom initialization logic
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
|
| 797aebac4aa55532cc42125e8f09e46e2b52879d |
|
18-Nov-2010 |
Raphael Moll <ralf@android.com> |
Cleanup GRE preload.
GRE used to preload the groovy BaseView rule to improve
the first selection speed. We don't need that now that we
switched to a non-groovy engine.
Change-Id: Ib29272f28df6285137d62c45441cd9ac72efd10f
|
| 912d8df0ed1a06c559efeefb1a0958ba989178e3 |
|
25-Oct-2010 |
Tor Norbye <tnorbye@google.com> |
Support 3rd party layout rule loading, and rip out Groovy support
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
|
| 2be70bde5a6dcd6447c32ef55866020be372f96c |
|
18-Oct-2010 |
Tor Norbye <tnorbye@google.com> |
Port layout rules to Java
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
|
| 7c40249b63abe2b620b366c8ba99ea4f42d816a8 |
|
07-Oct-2010 |
Tor Norbye <tnorbye@google.com> |
Remove Groovy Closures from the tool integration API.
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
|
| f983fc0565386bb8db0c3a8b55eb24bd06a29ef3 |
|
08-Oct-2010 |
Raphael Moll <ralf@android.com> |
ADT: use annotations from sdklib
The removes Nullable and VisibleForTesting from ADT
and replaces them by their new versions from sdklib.
Change-Id: I2784e9d044a29a70dcd6258bb45e553246dfd477
|
| 13bbd4f3631ee307bad27b0a6332997386dc9ba3 |
|
08-Sep-2010 |
Raphael Moll <ralf@android.com> |
GLE2: perform all context menu edits in the same undo session.
Change-Id: I9516066edaa1704725ab234f1a65664d5eabfb39
|
| cae6f3d2d35e8e8e2e644634034e682ade5cffce |
|
03-Sep-2010 |
Raphael Moll <ralf@android.com> |
GLE2: Let scripts display message dialog & input dialog.
Change-Id: I0d07d5f7e672d3ef6b077c5cf24ba5f20fe1dabb
|
| eaba401355cb2258c4ccc0e2456fe1931f272c78 |
|
27-Aug-2010 |
Raphael Moll <ralf@android.com> |
GLE2 context menu support.
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
|
| 422412f1d46006ab6f0c72e54b0cbb7a47e78fbd |
|
19-Aug-2010 |
Raphael Moll <ralf@android.com> |
ADT GLE unit tests.
There isn't as much as would want to here.
I need to refactor the RulesEngine to make it more testable,
the major block is that it uses the static AdtPlugin to find
the groovy files path and that doesn't exist in the UT.
Change-Id: I96c0821252d5b777665ed68153fde63d140d0ee5
|
| 4cb1c5ad7f7b7e2211d1dc4e3cef8b8bc247bdc8 |
|
23-Jul-2010 |
Raphael Moll <ralf@android.com> |
ADT GLE2: Properly handle custom classes.
This makes it possible to drag'n'drop or paste a custom
class in a project that doesn't have the class. The paste
operation will succeed and the layout rendering will provide
a clear error indicating the class is missing.
Change-Id: I80bbc70cfdba68277120dff3e770ce31651e7ebc
|
| 3af3a210c0cb8e92404b18874774d695a3733b5e |
|
22-Jul-2010 |
Raphael Moll <ralf@android.com> |
ADT GLE2: implementation paste operation.
Change-Id: Ifc7b150eefd810a7c615fd9d3f26904e59c6c4aa
|
| cc2cf183f6e73a20b2580db743ca467e8932a841 |
|
21-Jul-2010 |
Raphael Moll <ralf@android.com> |
ADT GLE2: Let groovy rules access a public API of the RulesEngine.
This is done by injecting a property in the groovy rule instance
with a new interface, the IClientRulesEngine. The client callback
currently has 2 useful methods: debugPrintf (which has been moved
out of INode) and loadRule(). This last one is the key here, it
allows one rule to request another one to be loaded and get its
object.
Change-Id: I2881854e33cd3b41565dd1e16aaba1484ef765db
|
| 51c30746b6fa8020c8db11796d07bde93057c8f5 |
|
20-Jun-2010 |
Raphael Moll <ralf@android.com> |
ADT GLE2: drag'n'drop in RelativeLayout.
First pass. There are some details to take care of later.
Change-Id: Ic9ac3d34ce4061ed2a8c257ce6bd40ea30497eb8
|
| f7ac8c8f101712a2a2a437ac7f77b5d3588cebca |
|
04-Jun-2010 |
Raphael Moll <ralf@android.com> |
ADT GLE2: Generate items on drop in AbsoluteLayout.
Change-Id: Iaf943b476db553cd39f5c3ee4f9c47ad3cdc6246
|
| 671636a1a16dbe4fb73509b5e3cb92ca96a778c7 |
|
25-Mar-2010 |
Raphael <raphael@google.com> |
ADT GLE2: Drag from canvas
The groovy scripts need to be changed and will be
part of the next CL (only the base view one has been
adapted here.)
Change-Id: If91602b36a3b147f6a18c9c9538d6d9bec5ecea0
|
| f7ba3919fbe4073a528b65ec9a77300a163f77f3 |
|
09-Mar-2010 |
Raphael <raphael@google.com> |
ADT GLE: pass dragged FQCN to IViewRules
Change-Id: Iee6868e65ebdb98a8b62dd07d8490e5363e6f3af
|
| d4963dc4347c871be5faa76920709001490e1d2a |
|
24-Feb-2010 |
The Android Open Source Project <initial-contribution@android.com> |
snapshot
|
| 711b740554e21080f2ed5358d14027fddda3dc80 |
|
18-Feb-2010 |
Raphael <raphael@google.com> |
ADT GLE: new IViewRule interface for Drag'n'drop.
With implementation for AbsoluteLayout and LinearLayout.
Change-Id: If8d6301abcc848574b3ab5d8894396a0246b1275
|
| d315a6c76d627b5a9d4392dd5cec7bf200d88c68 |
|
10-Feb-2010 |
Raphael <raphael@google.com> |
ADT GRE: Resolve gscripts groovy imports.
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
|
| 9aefc33d152479079646809e1572541aab1ced10 |
|
09-Feb-2010 |
Raphael <raphael@google.com> |
ADT GLE2: Implement IViewRule.onChildSelected.
Revamp the IViewRule.on[Child]Selected to not return a closure.
There is no actual event at selection time.
Instead the callback is called directly to paint the canvas.
Change-Id: I2b50fbdff734b9c1a2c581ca5958bac43e5f325f
|
| 218e0a497a51f26a91c4f1c7bbfc9fc040b89644 |
|
05-Feb-2010 |
Raphael <raphael@google.com> |
GLE2: IViewRule callback for selection.
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
|
| 1a9d30498bb489a8a7704a86eeb6effd92f35f3b |
|
15-Jan-2010 |
Raphael <raphael@google.com> |
ADT GRE: Move gscripts package.
Moving the public API from com.android.ide.eclispse.adt.gscripts
to ...adt.editors.layout.gscripts.
Change-Id: Idf5b979d47dbbbe2514cce8cc3c688eb273bcce6
|
| fc6cb68ea4bdeb408a97dcfd2fb6a35df90e63c0 |
|
08-Jan-2010 |
Raphael <raphael@google.com> |
ADT GLE: Support drop in AbsoluteLayout and create XML node.
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
|
| cff0d285d79844c31be56ae49837d83e8742e512 |
|
08-Jan-2010 |
Xavier Ducrohet <xav@android.com> |
ADT/GLE: Fix issue with the locale list refresh in the ConfigComposite
One of the problem stemmed from the ResourceMonitor sending removed
resource events to the ResourceManager first and then to other listeners.
Other listeners then failed to get a corresponding ResourceFolder
or ResourceFile since it was deleted by the ResourceManager.
Solution: add a resource-specific change listener in the ResourceManager.
Using this listener is much more efficient as the ResourceFolder/File
do not need to be figured out by the listener from the IFolder/IFile.
Also renamed the ResourceMonitor as it's confusing (it listens to
Eclipse resource changes, not Android project resource changes).
Since it deals mostly with projects and their resources, and is
global and used by other monitor, it's now called GlobalProjectMonitor.
Also cleaned up the ResourceManager and LayoutReloadMonitor to
implements their interface as internal classes so that the
methods do not show up in their public API.
Change-Id: I1967a48364fd946c98d9eee5bd4a333fc01bea2d
|
| 26ecc760b9abbd827c6587a9bb61ca29a6bc95ae |
|
04-Jan-2010 |
Raphael <raphael@google.com> |
ADT GRE: move scripts to ADT /gscripts.
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
|
| 8fbb33e21e7b6c0d13c9b368c4a24f6c13809027 |
|
02-Jan-2010 |
Raphael <raphael@google.com> |
ADT GRE (Groovy Rules Engine), drag'n'drop.
Start support for drag'n'drop. with visual feedback.
Change-Id: I27f896c2e954dec0cb43103417d888d8df5a288e
|
| 4b26e04436587890f9245eda631f643d21f28d0d |
|
26-Dec-2009 |
Raphael <raphael@google.com> |
ADT GRE (Groovy Rules Engine), part 1.
This CL adds the new "Groovy Rules Engine" (GRE) to the GLE2.
The rules engine can load groovy files located in the ADT
namespace or the project associated with the current GLE2.
Each groovy file defines a class with callbacks invoked
by the LayoutCanvas.
Project rules are reloaded when they change.
Change-Id: I168234da739b2120374d3eb4552169f7dd36439d
|