| 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
|
| 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
|
| 654dc86699080b7c7b9931ad35f823c848eb2e9c |
|
14-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Add new InsertType for widget moves within the same layout
For some layouts, such as LinearLayout, when you drag widgets into the
layout, we automatically adjust the widths and heights of some
widgets, such as text fields (to make them fill the full width in a
vertical linear layout, and so on).
However, this was also done when dragging a widget from one place to
another within that same layout. In that case, we should leave the
dimensions and weights alone, since the user may have deliberately
changed these.
This requires splitting the InsertType.MOVE into two, since we still
want to apply default sizing when you move a widget from a different
layout into this one. The InsertTypes are now MOVE_INTO and
MOVE_WITHIN, and we only apply default size styling if we are not
moving within the same layout.
Change-Id: I73ace89aff8111417bd6635e13397e7f027bab0a
|
| 44689550b4868e50e48a403c7891c20215c14db7 |
|
12-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Highlight current drop target in the outline
During a canvas drag & drop operation, highlight the current target
node in the outline. This helps make it obvious which target you are
hitting in cases where it's ambiguous, such as when you have a
hierarchy of parents with mostly overlapping bounds, such as a
TableLayout with TableRows inside.
Change-Id: I7fc4aa23afccb7da4ab5eba14730c7a2c8064782
|
| ebbff9bf4dec8f224183f67bbded34698e90c4c4 |
|
28-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Prevent adding children into AdapterViews
As reported in issue 13042, it's possible to add views into
AdapterViews such as ListView. This causes a rendering error.
The root issue is that we were relying on
ElementDescriptor#hasChildren() to determine whether a particular view
is willing to accept children, but that isn't entirely correct, since
all subclasses of AdapterView (such as ListView, Spinner, etc) will
throw an exception if you do that.
To fix this, I've added a new method to DescriptorUtils,
"canInsertChildren", which performs additional checking beyond
hasChildren(). If it has an actual view object, it will walk up the
super class chain and see if the view extends AdapterView, and if no
view object is available, it will filter out the known subclasses of
AdapterView (well, it doesn't have to filter out Spinner since that
class doesn't report that it has children).
Change-Id: I663b18fcfbe97a10c8f1aaa2d75552fb8fb148d5
|
| fe2c646b1bd033dea4c45e31630ffc9c5703e1f9 |
|
28-Dec-2010 |
Raphael Moll <ralf@android.com> |
Enable code specific to Eclipse 3.5
Change-Id: I29f6d1d74ce2979882988c18bc3e79d995445015
|
| 3f6c2e7d3f6417985aac9eb65fa0f3b5a31b2578 |
|
22-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Add Move Up/Down Actions
This changeset adds "Move Up" and "Move Down" context menu items to
the outline, as well as keyboard shortcuts for these: + and -. The
actions apply only when the Outline window has focus. Thus, to reorder
an item you can select it, then press + repeatedly to move it down in
the hierarchy or - to move it back up.
In addition, this changeset fixes a selection syncing issue which also
affected drag & drop: It will now correctly always select the target
dropped tree items after a drag or reorder.
Change-Id: I11ce4fd302e537b86a614a7cbe59f1ac47f61aa5
|
| 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
|