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
|
85e4a1a9dd133abb879ec211ce8dd385004edf22 |
|
08-Aug-2012 |
Xavier Ducrohet <xav@android.com> |
Refactor common.jar Move resources and com.android.util.Pair into layoutlib_api where they belong since layoutlib depends on them and we need to control the API. Made a copy of Pair to stay in common.jar but moved it to com.android.utils.Pair (the one in com.android.util.Pair is marked as deprecated to prevent usage where applicable). Also moved XmlUtil and PositionXmlParser to com.android.utils to match Pair. Change-Id: I21d7057d3f2ce604f86a3bb1fa3c130948c93b89
|
fb6d52d71a7461cb1ac4149f4f71d6a63e7436da |
|
04-Apr-2012 |
Tor Norbye <tnorbye@google.com> |
GridLayout support work Lots of miscellaneous fixes to the GridLayout support in ADT. The changes include using the GridLayout state (via reflection) to populate the model; caching the grid model for performance, and a bunch of fixes to the code which handles insertions and removals. There are also some new unit tests. This is not done, but is an improvement over the current state. Change-Id: I4851153d3e409630c2d2024c4894d1ad1535fb47
|
cb3758e42389a933203262f9109454c091574d30 |
|
05-Jun-2012 |
Tor Norbye <tnorbye@google.com> |
32745: Lack of warning of using duplicated IDs for element. This changeset adds a validator to the assign/edit id dialog used in the layout editor such that the user gets a warning if picking an id which is already defined within the same layout. Also cleans up the Rules API for adding a validator and makes the generic resource validator handle both the case of requiring a unique name and requiring an existing name. Change-Id: Id9642c3bcd326f9734cf98c98f6799b67e11a4ae
|
7e4b8e9d595e45baa9d87cdb8282f02759e73abc |
|
30-May-2012 |
Tor Norbye <tnorbye@google.com> |
Fix nullness annotations Eclipse 4.2 includes analysis support for @Nullable and @NonNull annotations. However, it requires these annotations to be *repeated* on every single method implementing or overriding a superclass or interface method (!). This changeset basically applies the quickfixes to inline these annotations. It also changes the retention of our nullness annotations from source to class, since without this Eclipse believes that a @NonNull annotation downstream is a redefinition of a @Nullable annotation. Finally, the null analysis revealed a dozen or so places where the nullness annotation was either wrong, or some null checking on parameters or return values needed to be done. Change-Id: I43b4e56e2d025a8a4c92a8873f55c13cdbc4c1cb
|
a881b0b34678ad76c9f5eba62fac7a00a22ac606 |
|
20-May-2012 |
Tor Norbye <tnorbye@google.com> |
Move XML code to the common library The ManifestMerger library needs to look up the prefix to use for the Android namespace, and the Document.lookupPrefix method is not implemented by the Eclipse DOM implementation (which throws an exception). However, we have an implementation of this in the ADT plugin. This changeset creates a new XmlUtils class in the common/ library (which is accessible by both ADT and the manifest merger, and the anttasks where the manifest merger is used), and moves the namespace prefix lookup code in there. It also moves the XML escape methods into that class. It also adds a new method to the ManifestMerger for merging directly from documents (rather than files), and makes sure that all the merging code goes via the prefix utility method rather than calling the document.lookupPrefix method. Finally, it moves the various string constants associated with XML namespaces into the single XmlUtils class, since these were spread across several different classes before (and many of them are needed in the XmlUtils class). The vast majority of the diffs in this changeset are related to simple import statement changes to reflect the new locations of these constants. Change-Id: Ib8f3d0e5c89e47e61ea509a23925af7b6580abee
|
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
|
bb54cce6ded6e5f95388b3352797bfc85e1eb838 |
|
22-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Add package support for Rules API and Detector API When writing custom view rules, and custom detectors, you may need access to the package name of the application (in order to produce the right namespace to look up custom attributes for). This changeset adds new methods to the two APIs such that clients can look up the application package. For lint, it also changes things such that the manifest file is always processed and information stashed in the Project object. This meant I could also remove the icon detector code to look up the manifest info directly. Change-Id: Id8eec96e2788f6d27481d7dcab0c544ea6e0a06d
|
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
|
e287bc8580e19d72a911615475b353790cf000eb |
|
16-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Layout editor property menu improvements This changeset adds two forms of view attribute metadata: * First, it records the most commonly used attributes for each view. This was determined by gathering statistics on as many layout files as I could find and then picking those that are used 10% or more. * Second, it records in the attribute metadata which View defines a given attribute. The context menu uses the above information to present the available attributes in several ways: * In the top level menu, where we had "Edit ID", and if applicable "Edit Text", it now lists the top attributes instead. For example, for a RatingBar the first handful of menu options are "Edit ID...", "Edit NumStars...", "Edit StepSize...", "Edit Style..." and "IsIndicator" (a boolean pull-right menu). Incidentally this automatically handles some cases which were manually handled before, so the code in LinearLayoutRule to add an "Orientation" menu is no longer needed; it's just one of the two common attributes handled by the new attribute list. * The "Properties" menu is now called "Other Properties", and instead of showing all properties, it has a new level of menus: * "Recent". This is initially empty, but as you edit other attributes, it gets populated (in most recently used order, kept up to date) with recently edited properties. * One submenu for each defining View super class listing exactly the attributes defined by that view. This is useful for browsing and editing related attributes. If you are looking at a textual view like a Button for example, you can look at the "TextView" menu to find all the text related options (TextColor, TextSize, etc). These menus are listed from the nearest to the further superclass, so for example if you right click on a CalendarView you'll see these menus: Recent > ---------------------------- Defined by CalendarView > Inherited from FrameLayout > Inherited from ViewGroup > Inherited from View > ---------------------------- Layout Parameters > ---------------------------- All By Name > * As you can see from the above, there are two more menus below the inherited menu items. "Layout Parameters" lists all the layout parameters available for the selected nodes (which is defined not by the view itself but the view that it is contained within). And finally there is "All By Name", which is a complete menu containing all available attributes for the view (and this is what the Properties menu used to contain). * The code which computes a display name from an attribute was also tweaked to capitalize not just the first letter but any first word letter, so for example when you look at the possible values for Gravity you now see "Clip Vertical" instead of "Clip vertical". * The edit property dialog for the properties menus now uses @string or @style resource choosers for the text, hint and style attributes (used to just be a plain text box.) Change-Id: I3b30d48b85fd13f0190c760756bf383a47b3f4a5
|
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
|
8c3f16ae7d66cedf70c494de3a38a54e90f2a54e |
|
10-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Merge 0b95acc1 from master to r12. do not merge. RelativeLayout: Assign ids dynamically, handle multi-drag, bugs This CL fixes three issues with the new relative layout interaction: (1) Assign ids dynamically. Before this changeset you couldn't attach to a node which does not have an @id attribute, since layout params need to name the constraint by id. This changeset changes this such that you can attach to any arbitrary edge, and when you commit the drag, a unique id is generated on the fly and assigned to the node. (2) Handle dragging multiple nodes at the same time. The new constraints code was unconditionally applying the same constraints to all the dragged nodes, which meant they ended up on top of each other. This fixes things such that the first node is assigned the new constraints, and then all subsequent nodes are attached one next to the other, in a direction depending on which edge you attached to (e.g. attaching on the right will arrange the siblings towards the left out from the edge.) (3) Fix a bug in the code to detect and prevent cycles. Change-Id: I3da16903ffac6c34a0d5efee52a87824fb9e04fb
|
0b95acc1693f67140e988567211c13ca2eb9f926 |
|
10-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
RelativeLayout: Assign ids dynamically, handle multi-drag, bugs This CL fixes three issues with the new relative layout interaction: (1) Assign ids dynamically. Before this changeset you couldn't attach to a node which does not have an @id attribute, since layout params need to name the constraint by id. This changeset changes this such that you can attach to any arbitrary edge, and when you commit the drag, a unique id is generated on the fly and assigned to the node. (2) Handle dragging multiple nodes at the same time. The new constraints code was unconditionally applying the same constraints to all the dragged nodes, which meant they ended up on top of each other. This fixes things such that the first node is assigned the new constraints, and then all subsequent nodes are attached one next to the other, in a direction depending on which edge you attached to (e.g. attaching on the right will arrange the siblings towards the left out from the edge.) (3) Fix a bug in the code to detect and prevent cycles. Change-Id: I157d45e117d3229f285870517b85ed902607b966
|
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
|
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
|
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
|
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
|
0757ce4af2764e4dd564acc0b1a013e910abc8da |
|
18-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
More refactoring work: Convert hierarchy, and change type A lot of work on the "Change Layout" refactoring to improve conversion to a Relative Layout. First, add a "Flatten Hierarchy" option which can take an entire hierarchy of layout widgets and flatten it down to a single top level RelativeLayout where the constraints attempt to reflect the original layout. (This isn't always possible, since some layout managers offer features not possible to express in RelativeLayout, such as a LinearLayout with multiple different weights) but it often works or is at least a good start. (This work is ongoing, but since my changeset is getting large I want to check in this snapshot since the functionality is better than what is in the trunk.) This changeset also adds a new refactoring: Change Widget Type. This can be applied to a selection of elements, and it will convert the widget type to the new target widget type. It will also remove any attributes that are not valid for the new layout. It also improves the wizards which display the possible target types. For Change Widget Type, it will first offer "related" widgets, so for an AnalogClock it will first offer Digital Clock, for a checkbox it will offer a checked text view and a radio button, etc. In addition, it will list Views and Layouts that it finds in any library jars (except for the builtin Android ones), and any custom view classes in the project. There is also now some preliminary support for refactoring unit tests. These tests must be run as Eclipse plugin tests, since they utilize the XML model (and the XML model cannot be mocked). The test infrastructure reads source XML files, applies the refactoring change list to them, and diffs the output with the known expected output (also stored as result XML files in the test project). Finally, there are a number of fixes and improvements to the shared refactoring code. Change-Id: I0974653e530dfb4feb625e0eef8257c29d50614b
|
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
|
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
|
f7eafda210e3eb3fbe8f1cb9c0bd61807f1a05c5 |
|
30-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Replace hand-written mocking classes with EasyMock calls This changeset removes the various hand-written mock implementations of key Eclipse interfaces (IProject, IFile, IFolder, etc) and replaces them with EasyMock proxy objects. This makes our codebase buildable on Eclipse 3.6+. (Also fix a couple of test warnings for abstract testcase classes which were missing tests) Change-Id: I70553ab95dc9386da1c7eed139d3ef587d929478
|
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
|
bfcbad18934be1f51ae03d4b6255cfe2d7239aaf |
|
24-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Extract layout constants into a separate constants class 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
|
ccabacfacfcc90e1725f0342b2e6d273d0bc744e |
|
24-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Unit test fixes First, the AddonsListFetcherTest#testLoadSample_1 was failing on the Mac, because the source code contained non-ASCII unicode characters, and the encoding differs between Windows, Linux and Mac -- and on the Mac the characters were garbage (not the intended Japanese characters). Fixed by using unicode escape sequences to define the expected output instead. Second, rename the AbstractLayoutTest to LayoutTestBase; the test runner (for plugins, not unit tests) was assuming this was a test case (even though it's an abstract class!) so it was emitting a warning about the class containing no test cases. This is simply a base class for all the individual layout tests defining a bunch of useful inherited shared behavior, so rename to avoid the warning. Change-Id: I6e29316c5644db35051218aef8b99ac41ab0cda4
|