aboutsummaryrefslogtreecommitdiffstats
path: root/eclipse/dictionary.txt
Commit message (Collapse)AuthorAgeFilesLines
* Speed up loadPublicResources()Tor Norbye2012-03-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FrameworkResources method which loads in the public resources takes about ~500ms of the target loading time. This changeset optimizes this down to < 50ms using the following three optimizations: 1) Precompute a map from names to ResourceItems before processing the public names. Before this, it would search sequentially through the name list, which when done n times meant O(n^2); we can construct the map in O(n) and then perform n lookups in O(1) => O(n). Also, be smart about which maps we precompute names for: the ResourceType.PUBLIC and ResourceType.DECLARE_STYLEABLE types have about 2,000 items, none of which are public, so skip precomputing maps for these two. (However, keep the linear search around such that if any are exported in the future the code will work correctly. Similarly, we know "roughly" the size of the final public maps, so initialize them in the right size range such that they don't have to do any internal resize+copy operations as we insert into them. 2) In android-15 there are 1500 new <java-symbol> elements in the public xml file, which were being processed, doubling the number of exported symbols. Limit the processing to only the <public> tags. 3) Switch from DOM parsing to pull parsing. This helps since more than half the file consists of <java-symbol> elements, and we can ignore whitespace and id attributes etc, so there is much less object creation involved. Change-Id: I4761e1182b9bc0c50fe94aea7dcd9690754c7908
* Handle the android support gridlayout library automaticallyTor Norbye2012-03-081-0/+1
| | | | | | | | | | | | | | | | | | | | | This changeset adds support for the android support library's GridLayout library project. When you create a new layout with the GridLayout, or when you drop a GridLayout, the IDE checks whether you need the compatibility version of GridLayout (e.g. min sdk < 14), and if so, offers to install it. This will then first run the SDK manager to install the android support package into extras, and then it creates a local library project in the Eclipse workspace, and updates the library dependency to reference it. Finally, it rewrites tags such that the layout will use the compatibility package for the <GridLayout> and <Space> tags. This is done in the node handler, so client rule code will automatically get the right compatibility tag; they don't need to handle it there. Change-Id: I6da926eee7ffa956832ddd311d4180e8ff38ae07
* Make the lint string-format check ignore date stringsTor Norbye2012-02-071-0/+1
| | | | | | | | | | | | | | | | The string format lint check might be processing strings not intended for String.format (but intended for example for android.text.format.Time#format), in which case it will be wrong about whether two conversions are incompatible. (This does not fix all scenarios; if a date string looks like a String.format in the sense that all of its formatting characters are defined by String.format then the string will assume to be intended for String.format.) This changeset attempts to recognize this, and also make the "is incompatible" check a bit more nuanced: it will now consider "d" compatible with "x" for example. Change-Id: I63ce082f40169e4033809d25cae3cf116c9e2044
* Lint HTML improvementsTor Norbye2012-02-011-0/+1
| | | | | | | | | | | This changeset makes various improvements to the Lint error report: the styles are now in a separate stylesheet, and the default style is Holo-like. Paths are handled better when linting multiple projects such that the report title includes the root-relative project path, and all filenames are then relative to the project root. The table of contents is now a table, and includes error and warning icons. Change-Id: I4e49f7b226bfa4d7b46e3a29e006fe78a504e9ef
* Add @SuppressLint support for Java parse tree detectorsTor Norbye2012-01-311-0/+1
| | | | | | | This changeset adds support for suppressing lint warnings by annotatating variable declarations, fields, methods and classes. Change-Id: If274d65bccdc5c7d6426566c635245d6b3aae147
* Write lint overview report for multi-reportTor Norbye2012-01-311-0/+1
| | | | | | | | | | | If lint writes out multiple HTML reports (e.g. when specifying a directory to the --html flag), and there are more projects than just one, write an overview doc which contains a table of all the projects and the corresponding error and warning counts in decreasing order, with links to the individual reports. Also ensure that there are no case-insensitive filename clashes. Change-Id: I4dcda14a625863e71022734088a027fc8ac357d0
* Add lint checks: String format, Casts, Security, Imports, /sdcardTor Norbye2012-01-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds several new Java parsetree-based lint detectors: (1) String format checker. This checks several issues related to formatting strings (%1$s), such as - Is the string format valid? - Is the string format consistent between different translations, e.g. if argument #1 is of type "s" in locale A, is it also of type "s" in locale B? - Is the string format being called from Java with arguments of the right type? - Are strings which are not supposed to be formatted (e.g. ends with a %) passed to String.format? (2) View Cast checker. Looks at the views associated with specific id's in layouts, and makes sure that any casts to views returned by findViewById in Java is cast-compatible with the type in the layout. For example, if you have a layout containing a <Button id="foo">, then a cast to an EditText of findViewById(R.id.foo) would be invalid. (3) A security check which flags file creation calls that pass a context of world-writeable. (4) An "import android.R" checker. This looks for "import android.R" in .java files and warns that this is potentially confusing. (5) A hardcoded "/sdcard" string checker which looks for this prefix in string literals and when found warns that the method Environment.getExternalStorageDirectory().getPath() should be used instead. Change-Id: I14a4656f0ff6a58f25cde1b4bb23f6c47c47fdba
* Lint View ImprovementsTor Norbye2012-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset makes a bunch of changes to the Lint Window in Eclipse: * First, it changes the view from a flat table into a hierarchical tree. For any given type of error, there is one top level tree node, and its children are the remaining occurrences of the same error. This makes it much easier to quickly skim through the different issues without having to scroll; if you see an error you want to fix, you can expand the node to jump to all the various occurrences. The top level labels also include a count in the form of "(2 items)" after the error message so you can get a sense of how many warnings were found for each type. * Second, it adds a bunch of new actions to the Lint View toolbar: expand, collapse, configure (more on that later), settings, and ignore file and ignore project (ignore global was already there). It also updates the icons for some of the existing actions; the lint toolbar action and window should look a bit better now. * Third, it adds more columns (such as priority and category) to the lint view, and makes the set of visible columns configurable. You can click on the Configure toolbar action to bring up a dialog to show which columns are included, and this selection is persisted across IDE sessions (and it also persists the column sizes). Furthermore, instead of separate file, path and line number columns, there is now a new "Location" column, which is shown by default instead of the separate file, path and line number columns. This column displays combined info for all three: the file name, the line number, the parent folder and the project name. This includes all the relevant information in a more compact format such that there is more room for the error message. * Fourth, the table now supports sorting: you can click on any column header, and the table will be sorted using that column as a key. (This is not alphabetical but a logical sort defined for each column; for line number and priority it's obviously numerical, but for the default column it continues to be a combination of severity, priority, issue type etc.) Change-Id: I42695988780b493ad90aff5aeb5895e0fd8d3998
* Lint Library SupportTor Norbye2012-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | This changeset adds support for library projects to lint. Lint now checks all the library projects for errors as well, and projects that depend on global analysis (such as the unused resource detector) will properly handle resource declarations and references across projects. This changeset also cleans up the multi-project handling for the Lint window in Eclipse. The "Run Lint" toolbar action, in addition to operating on multiple selection, now has a dropdown menu for choosing which projects to check (and there are also actions for checking all projects, the current file, and clearing markers). Running lint on a project will also automatically include dependent library projects. Finally, some misc UI improvements: The Lint preference dialog includes buttons for quickly enabling and disabling all the checks; the Lint View includes a Project column which is shown when more than one project is checked, and the file and linenumber columns are now blank when the location does not correspond to a specific file. Change-Id: I733f5258102dfb0aebbc2b75cb02b9ba6ef974e8
* Extract positional XML parser into common and fix encoding issuesTor Norbye2012-01-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The XML DOM parser used by the lint CLI driver (which tracks positions) is needed outside of lint, so pull it out of the lint/cli project, and refactor it such that it does not directly reference the lint Position APIs (but can utilize them when subclassed in lint). In addition, handle non-UTF-8 file encodings. XML files can be encoded in other character sets, and can specify this via the encoding attribute in the XML prologue. Until now, the CLI lint runner would just read the XML file contents in using the default encoding and parse this. Now there's a new utility method which takes a byte[] and infers the desired encoding and uses that to convert the byte[] into a string using the correct encoding. (We can't just pass an InputStream and let the SAX parser handle this on its own because the XML parser needs to access the character stream in order to assign correct node offsets.) This code now also handles the byte order mark more cleanly. There are some new unit tests too to check the new encoding, BOM and offset handling. Change-Id: Ib0badbbe72172e3408c6d5af2413be51280a7724
* Add Java Classfile supportTor Norbye2011-12-051-0/+1
| | | | Change-Id: Ifcc1d88dabb07dc05b2e5c934743ad52f9b6dc1d
* Lint infrastructure improvementsTor Norbye2011-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset fixes a bunch of issues in the infrastructure: (1) It cleans up the Context class quite a bit. It had some hardcoded XML stuff in it, which is now in a separate XmlContext class (and there will be a JavaContext class in the Java support CL). It also hides a bunch of public fields, cleans up some unused stuff, and introduces a couple of wrapper methods to make detector code cleaner; in particular, rather than calling context.client.report(context, ... you can now just call context.report(... and similarly there are wrappers for logging and checking for disabled issues. (2) The IParser interface is renamed to IDomParser since in the next CL there will also be an IJavaParser. Some other related cleanup. (3) There is now a "Location.Handle" interface. This allows detectors to create light-weight location holders, and later on call handle.resolve() to create a full-fledged Location. This is useful when detectors don't yet know whether they'll need a location for a node, but want to store it for later in case they do. As an example, the unused resource detector creates location handles for declaration and only resolves full locations for those that are found to be unused. Locations can now carry custom messages. For example, for a duplicate id error, the secondary location now contains a "original declaration here" message. And the CLI and HTML reports now include alternate locations in the output. Some other location cleanup too; using factory methods to make the code cleaner, some default implementations that can be shared, etc. (4) There's a new SDK info class intended to provide SDK information from a tool client (such as resource resolution). It currently just contains parent-view information, used for the ObsoleteLayoutParams detector and an upcoming CL for a ViewTypeDetector. (5) The Detector class now provides dummy implementations for the inner-interfaces, so we no longer need the adapter classes. This makes it easy to implement the XmlScanner or JavaScanner interfaces without needing to also stub out a bunch of methods. Change-Id: I4b3aaabe51febb25b000f9086703653bea6cf7c9
* Merge "Typography lint checker"Tor Norbye2011-11-231-0/+1
|\
| * Typography lint checkerTor Norbye2011-11-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds a new typography detector. This looks at the strings defined by the application and makes various suggestions to make the text look better typographically, such as - suggesting directional single and double quotes instead of straight single or or double quotes - suggesting typographical apostrophes instead of straight ones - suggesting n-dashes instead of hyphens in number ranges - suggesting m-dashes instead of --'s - suggesting fractional characters instead of strings like 1/2 - suggesting the ellipsis character instead of "..." - suggesting the copyright symbol instead of (c) There is also an Eclipse quick fix for these issues. Change-Id: If3912f9d34841faf069174f291911f73e6b78c28
* | Automatically fix up editor bindings on project load (once)Tor Norbye2011-11-231-0/+1
|/ | | | | | | | | | | | | | | | This changeset adds a follow-up fix for 21124. The fix for that issue fixes the problem where newly discovered files aren't assigned an editor binding. However, it does not *retroactively* fix up editor bindings for files that it didn't correctly initialize. This changeset fixes that. It adds a project open hook which scans through the resource folders and reassigns the editor type of any .xml files based on the resource type. This hook is only run once - it uses a project persistent property to ensure that it only performs this check once (or whenever we rev the version number associated with the scan.) Change-Id: Id843a8a174c84e3794e88a1c108b67d4000a3e69
* Add support for NTLM proxy authentication.Siva Velusamy2011-11-121-0/+1
| | | | Change-Id: Ia8375444bf99b33396616a57e781adb22d82175d
* Add duplicate icon detectorTor Norbye2011-11-081-0/+1
| | | | | | | | | | | | | | | | | This changeset adds a detector which finds two types of icon duplication: - Unrelated drawable resources which have the exact same bitmap. This could mean that the wrong icon was checked in, or that you could potentially consolidate to using a single resource. - Resources which have the same bitmap for multiple different configurations, such as the same icon in both -mdpi and in -hdpi. Unlike the various dip size checking methods, this also works for nine patch files. Change-Id: Ibe2d0900cecb66c2589400f24c2af9a76ad8dabe
* New lint icon detectorTor Norbye2011-11-071-0/+10
| | | | | | | | | | | | | | | | | | | | This changeset adds a new image detector which looks for various issues related to icons: (1) Are there bitmap icons in the densityless res/drawable/ folder? (2) Do the icons appear in all the density folders (except, optionally, ldpi) (3) Are the launcher/notification/etc icons of the expected size? (For example a launcher icon should be 48x48 in mdpi). This issue is disabled by default. (4) Do the various bitmaps roughly have the same density-adjusted sizes across all the densities for the same configuration parameters? This will catch cases where assets are placed in the wrong place. (5) It warns about using .gif files since that format is supported but discouraged. Change-Id: Ibe0f97cba7cada5ac0deee244310a38dbc721873
* Lint infrastructure fixesTor Norbye2011-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset makes a number of infrastructure fixes to lint. It also has some user visible aspects: (1) The "run lint on export" option, which aborts Export APK if fatal errors are found, now only checks for fatal issues, which should be significantly faster (since it skips expensive detectors like the unused resource detector). (2) The command line lint tool lets you specify not just issue ids, but categories to enable or disable as well. In addition to the --enable and --disable flags to add or remove checks, there is also a --check flag which runs the exact specified checks. Thus you can for example run "lint --check Security" to run the security related lint checks. When using --show to display the available id's, they are organized and described under category labels. I also cleaned up the categories a bit; "Layout" isn't a category anymore, and instead the layoutopt options are placed in other categories like "Performance" or "Usability". (3) From the command line you can now also specify multiple projects or even search a directory for projects contained recursively within it. This required a bunch of infrastructure changes to handle partitioning up the arguments into related projects (since checks have before-project and after-project hooks that need to run properly). (4) On the infrastructure side the "scope" concept was changed to become a scope set, and a detector can declare that an issue requires analysis of any of {manifest, resource file, java source file, resource folder, ...} etc. When lint runs it determines which detectors are applicable (for example, for a single-file lint run it will ignore detectors which require a wider scope). And when applicable, a detector will be called for all the various scopes it requires. Therefore, the unused resource detector, which used to have to manually scan the manifest file on its own, now automatically gets called as part of the manifest file parse, the resource file parses, and the java file scan. Single-file linting is still only supported for XML files. Change-Id: I49a5e2b27f8f6da22904085089aa0c4d2eee67f6
* Two new lint warnings: array-size check, and manifest orderTor Norbye2011-10-261-1/+2
| | | | | | | | | | | | | | | | | | | | | This changeset adds two warnings: (1) A new lint warning which checks the sizes (number of items) in arrays of the same name across the various resource files and warns if the number of items differ. (2) A new "manifest order" detector which looks for element ordering problems in manifest files, such as placing <uses-sdk> after the <application> element. It also cleans up the way XML detectors were handled such that a detector can be an XML detector without being a resource detector (such as the manifest detector for example). Finally it also moves classpath initialization into the tool context where it belongs. Change-Id: I02fee56bfdbe1064874acf70f18db79897d8a908
* Static analyzerTor Norbye2011-10-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds a static analyzer, "lint", which looks for various potential bugs in Android projects. It has 3 parts: (1) A library which performs the actual static checks. This library is standalone: it does not depend on Eclipse. (Technically the library has two halves: an API half, for use by third party developers to write additional detectors, and an actual implementation of a bunch of built-in checks.) (2) A command line driver, "lint", which runs the static checks and emits any warnings to standard out. This can be thought of as a replacement for the layoutopt tool. (3) Eclipse integration. Lint errors are added to the Problems view as well as shown as editor annotations. There's an options panel for controlling which detectors are enabled. There's also a quickfix for disabling errors directly within the editor and a marker resolution for disabling them via the Problems view. The static checks are run on an XML file right after it has been saved. (This is optional via a toggle on the same preference page as the detector list.) The static checks are also run when you export an APK, and if any fatal errors are found the export is abandoned. (This is also optional via an option). Finally you can run a full lint through the Android Tools menu, and there's also an action to clear all the lint markers there. There's also a new indicator on the layout editor which shows whether there are lint errors on the associated file, and when clicked brings up a dialog listing the specific errors. This changeset also includes a number of checks: * An accessibility detector which warns about images missing contentDescriptions * A drawable selector detector which warns about state lists where not all states are reachable (e.g. it is not the case that only the last item in the list omits a state qualifier) * A detector finding duplicate ids, not just in the current layout but across included layouts (transitively) as well * All the layoutopt ones ported to Java + DOM * Unit tests for the above. The focus here is on getting the infrastructure in place, and it currently focuses on XML resource files and analyzing them efficiently. See the comment in XmlVisitor for details on that. Change-Id: Ic5f5f37d92bfb96ff901b959aaac24db33552ff7
* More GridLayout FixesTor Norbye2011-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset fixes various issues in the GridLayout support: (1) Add custom Paste support for GridLayout. The default copy/paste handler just treats a paste as a drag into (0,0) followed by a drop. That doesn't work well for GridLayout since it ends up writing the dragged elements into row/column 0,0. This changeset adds a custom override of the paste handler such that it adds the pasted elements into successive table cells instead. It still needs to adjust the column spans to avoid changing the current table structure; that will be done in a followup CL. (2) Clean up the Layout Actions Bar a bit for GridLayout. Separate out the "Show Structure" and "Grid Mode" actions, and make grid-operations (Add/Remove Row/Column) only show up in Grid Mode, and similarly only show Snap to Grid in Free Mode. (3) The hidden <Space> widgets should also be hidden when selected via Select All. Also fix a remaining issue with the action enablement of Select All. (4) Fix a bug where the preview bounding rectangle was drawn at the wrong place when showing a center-horizontal proposal. (5) Remove an assertion encountered during GridLayout conversion which is not always true. Change-Id: I8c4c0cac5052e59c5943e535b2f790f420303f9d
* Refactoring quick fix adjustments to caret and selection handlingTor Norbye2011-09-301-0/+1
| | | | | | | | | | | | | | | | This changeset changes the logic in the refactoring quickfix (which adds the Android refactorings based on the current caret position, lexical context and selection). It now allows some of the refactorings to be run when there is a selection (this fixes "20393: Extract string functionality in Android XML files"), and it makes other refactorings work when there is no selection (it implicitly selects the surrounding element). It also ensures that the Extract Style refactoring won't be listed at the top if the attribute under the cursor is not a stylable attribute, and it makes some other adjustments to the proposal order. Change-Id: I0714bb652032aa19e6c2502dc1af7bb5e4adf308
* Grid Layout and Convert to Grid Layout improvementsTor Norbye2011-09-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First, some improvements to Grid Layout handling: (1) When dropping a new widget, look up the sizing metadata and use it to determine what fill gravity to set. For example, a button will use gravity left, and a text field will use gravity fill_horizontal. (2) Don't warn about reflection problems when failing to find GridLayout layout data; this probably means the layout is being attempted opened in an unsupporting SDK. There's a fallback case to compute the data instead already. Second, improvements to the conversion to GridLayout handling: (1) It now looks at the layout_gravity values to see whether each row and column is flexible, and if there's no flexible column in each of the horizontal and vertical dimensions, it will insert a special <Space> element to absorb any available extra space. This avoids constraints warnings from GridLayout. (2) It treats layout_width or layout_height attributes of match_parent or fill_parent as the same as a fill gravity (and removes it) and uses this in the flexibility computation above. (3) It removes unsupported layout params for all children (earlier this would only remove unsupported layout params on the direct children of the layout, which isn't enough when a hierarchy is being flattened.) (4) It's smarter about computing implicit rows and columns, so it avoids writing out redundant layout_row and layout_column attributes in some cases. (5) It avoids throwing refactoring errors in cases where an attribute is removed twice (6) Fixes a bug where the root layout was included when computing the set of used x and y coordinates, which means you'd often end up with a blank row and column 0. (7) Various refactoring to make the code cleaner. (8) More unit tests and updates to existing unit tests to reflect the new behavior such as an absorbing spacer and removal of redundant attributes. Change-Id: Iee44c3ca749eefc107b83545669cc9d7f84615b1
* Welcome WizardTor Norbye2011-09-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds a new "Welcome Wizard" which is shown the first time a user runs Eclipse with the ADT plugin. The welcome wizard asks for two pieces of information: (1) The location of the SDK. (2) Whether the user agrees to gathering usage statistics. We've needed this information before, but collection of the data had been more ad-hoc: The usage data permission dialog would show up on its own, and the SDK information would be requested the first time some code path touched it (e.g. opening a layout or opening the preference dialog's Android page etc). In addition, the wizard also offers to *install* SDKs if you don't already have one. It gives the option between the latest available platform, and one supported by a large majority of devices (currently API level 7), or both. If you select this option, then when finishing the wizard the SDK manager is run in a special mode where it installs the required packages with a progress dialog. This changeset also starts recording the chosen SDK location in the ~/.android settings file. This allows us to detect when you're running Eclipse in a brand new workspace and you've already gone through the SDK selection before, and we don't need to ask again -- we'll just use the most recently known location. The wizard will only be shown once. If you bypass or cancel out of the wizard, you can still configure your SDK the old way - via the Preference dialog. Note also that the usage permission page is only shown if the user has not already opted in via say ddms. NOTE: If you want to test this, make sure you haven't set the environment variable ADT_TEST_SDK_PATH (as some of us do for running unit tests) since it is treated as the user having selected the given SDK root, and in particular it means the wizard won't be shown even if you've wiped adtUsed=true from your ~/.android/ddms.cfg etc. Change-Id: I0a4e2c4efce84aca9beae394ce67e4c145cbb000
* New Project Wizard overhaulTor Norbye2011-09-131-0/+1
| | | | | | | | | | | | | | | | | | | | | This changeset splits the New Project Wizard into multiple logical wizards (a separate one for samples, testing and plain projects), and each wizard contains multiple pages - such as a separate page for SDK selection, a separate page for Sample selection, a separate page for Test target selection, and so on. In addition, sample projects are now copied into the workspace itself such that they can be modified and deleted without affecting the mater copy in the SDK install directory. Samples can also be accessed from a new separate entry in the New wizard. The SWT code is now maintained with WindowBuilder. Most of the code in NewProjectWizard was related to actually building the projects, and this code is preserved in the new NewProjectCreator class which is used by unit tests etc such that we don't need to create a stub wizard and stub wizard page anymore. Change-Id: I64872722e320a109870403d25fdf051270b526ed
* Add support for remaining asset types in Asset Studio WizardTor Norbye2011-09-011-0/+2
| | | | | | | | | | | | | | | | | | | | This changeset ports the remaining graphic generators from the HTML5 version (notifications, tabs, action bar), and hooks up wizard support for them. It also adds unit tests for the generators which generates images and compares them to known good versions. I ran these tests comparing them to the output from the HTML5 version of Asset Studio and all but 3 of the images varied less than 5% (and I verified the remaining manually and they're all fine and the difference is due to the images being aligned slightly differently.) The icon wizard is now also hooked up to the "New" button in the Resource Chooser for drawable resources, and this changeset also fixes a few related issues ("New" didn't work for file-based resources, and newly created resources weren't showing up in the selection list.) Change-Id: I48c49f1d5de452aa5b78e491d9b07e7156397fa9
* Workaround for Linux painting issueTor Norbye2011-08-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes: http://code.google.com/p/android/issues/detail?id=19447 Turns out that on Linux, painting an image with a scale transform can be extremely expensive - it can take multiple seconds, which makes for example interactive dragging in a RelativeLayout over a zoomed canvas appear not to work at all (because in some cases each drag update takes up to ten seconds). We rely on scaling image painting when the canvas is zoomed. To work around this, we "prescale" the images instead: Using the source AWT image, apply a scale once (whenever the image or the zoom level has changed), and then store the scaled image as a plain SWT image which we can then paint on each paint refresh using a normal (not scaling) image paint. This change also revealed that during a palette drag, the source image would get trashed by the palette preview code because the editor XML model was marked as modified. This is not necessary, so during preview painting the editor is instructed to ignore XML model updates. Change-Id: I78f3adb77754d4f9b0daaeeb662d53f1d7ed6042
* Action API improvementsTor Norbye2011-08-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add tag-handling for Go To Matching in XML documentsTor Norbye2011-08-031-0/+1
| | | | | | | | | | | | | | | | Eclipse has a Go to Matching feature, bound to Ctrl-Shift-P. However, for XML documents it only works on the character level, so if the caret is inside a tag it does nothing, and if you place it on an angle bracket, it just jumps to the opposite angle bracket for the same tag. This changeset adds a new character pair matcher which works at the tag level, so if you for example place the caret anywhere in an end tag, it will highlight the first character of the opening tag, and if you jump it will jump to that opening tag. Similarly, if you place the caret next to the < or tag name of an opening tag, it will jump to the closing tag. Change-Id: Id25487b24616abf79c71de5eec21f8c0f07e68cc
* Improve smart-indent handling in XML filesTor Norbye2011-08-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds a new "auto edit strategy" for Android XML files, which replaces the default XML auto-indenter (which just copied the indentation of the previous line.) The new indenter instead uses the lexical information to indent based on the tag and bracket balance. For example, if the | represents the caret position, then the following shows how the edits are transformed: <foo name="value"/>| => <foo name="value"/> | <foo name="value">| => <foo name="value"> | <foo <foo attr1 = "value1"|> => attr1 = "value1" |> <foo <foo attr1 = "value1"/>| => attr1 = "value1"/> | It can also modify the text after the caret, as in the following transformation: <foo>|</foo> => <foo> | </foo> See the unit test for more cases. Change-Id: Ia99ecf6573ff4a9473970aa2fd481d2228ddf45d
* Add a new XML formatter, new options, and format on saveTor Norbye2011-08-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds a custom XML formatter for the Android XML editors. There is an option for turning off this formatter and using the standard XML formatter instead. The new custom formatter offers the following features: * By default, it formats files following the Android conventions for XML formatting. This means not only that it indents with 4 space characters (instead of the Eclipse default of one tab character), but it places attributes on a line of their own, it adds blank lines in certain places, and so on. * It sorts attributes (logically, alphabetically, or none) * It formats files with different styles depending on the context. For example, in layout files it always places a single blank line between view elements, whereas in manifest files it only places blank lines between elements of different types such that for example the <uses-permission> elements all form a logical group, separated from <uses-sdk> and so on. The fact that strings.xml and layout.xml are usually formatted with different flavors is one of the reasons setting up the old Eclipse XML formatter to do the right thing was not possible. In addition, there are various user options added to the Editors preference page where you can tweak the behavior of the formatter, such as turning off blank lines completely, controlling whether there is a space before the > or /> closing characters, and you can also tell the formatter to use Eclipse's indentation setting (indentation size and whether to use spaces or tabs). Finally, there is a new "Format on Save" option which behaves just like Format on Save for Java files: when you press Ctrl-S to save a file, the XML content will be formatted before the file is saved. Change-Id: Ic6f05c768ab063b09f6f0248f60fbe8722fb149d
* Add Java Quick Assistant for Extracting StringsTor Norbye2011-07-291-0/+3
| | | | | | | | | | | This changeset adds a Quick Assistant to Java files in Android projects, which proposes "Extract String" when the caret is within a String literal. It also moves a couple of utility methods from the Hyperlinks class to the AdtUtils class. Change-Id: Ica5ff40e32e3e145481d6c895178109289ed1d9b
* Grid Layout Support.Tor Norbye2011-07-111-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* RelativeLayout: Assign ids dynamically, handle multi-drag, bugsTor Norbye2011-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Suggest similar class names or missing pkgs in the error consoleTor Norbye2011-06-081-0/+1
| | | | | | | | | | | | | | | | | | | If the layout XML file contains typos, the rendering will fail and the canvas will list the missing classes along with hyperlinks to create a new class, configure the build path etc. This changeset looks for "typos" in the view names and if it finds a similar real view class, either among the Android views or among the custom views in the current project, then it will add a hyperlink suggestion to fix the XML by editing the name to the correct spelling. It also handles the scenario where you have typed in a custom view class name correctly, but have forgotten to include its package. In a followup changeset this functionality will be available from the XML editing quick assistant as well. Change-Id: Iaefd3f503795e25e6eb38353c60c645061d4814e
* Improve error handling for missing and broken custom view classesTor Norbye2011-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a view class cannot be found during rendering, the error log lists the class as missing, and presents the class as a hyperlink. Clicking the link will open the New Class wizard. This CL changes this such that there are multiple links instead: - "Fix Build Path": This opens the Java Build Path preference page in the Options dialog for the current project where you can fix the build path of the project, since a more common source of missing classes is a problem with the class path. - "Edit XML": This switches to the XML tab where you can edit the name of the custom view tag: A "missing" view is often a typo in the view name - "Create Class": This opens the create class wizard as before. Similarly, for broken classes (where the class is found, but cannot be instantiated correctly) the following hyperlinks are offered: - "Open Class", which shows the class in the editor - "Show Error Log", which will open the IDE error log where you typically can find a full stack trace from the failed invocation. In addition, this CL fixes 14546: Creating a custom view from the error output of the layout editor creates it in gen by ensuring that the gen/ folder is not one of the fragment roots presented to the New Class wizard. Change-Id: I06b8969800caaea719e4b52608a7ed130c91837d
* Resize & Guideline SupportTor Norbye2011-06-011-0/+6
| | | | | | | | | | | | | | | 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
* Add Resize Support to the Layout EditorTor Norbye2011-06-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't apply default attributes in a move/copyTor Norbye2011-05-241-0/+1
| | | | | | | | | | | | 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
* Custom View handling improvementsTor Norbye2011-05-131-0/+1
| | | | | | | | | | | | | | | | | First and foremost, allow custom views to accept children such that you can drag & drop children into the custom view in the outline. Second, prevent an NPE which can occur if you drag into a layout where the root element is a custom view. Third, handle <view> (not <View>) better: provide a custom icon, and inline the view class name in the outline label. Fourth, allow double clicks (in addition to ctrl-click which is already supported) on the custom views in the palette to allow jumping to the custom view code. Change-Id: I13c2bf2f4169185c9fcc893ce487f2abdac46802
* Add code completion support for drawables, animations and colorsTor Norbye2011-04-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds in descriptor metadata and XML editors for: - Drawables (res/drawable/) - Animations (res/anim/) - Animators (res/animator/) - Colors (res/color) These types have also been added to the New XML File wizard. There is some specialized completion support for animators: - Completing on the propertyName property of <objectAnimator> will offer the various integer and float properties in views - Completion for the interpolator property shows the framework interpolators immediately and on top (instead of having to complete the individual resource paths @android: and anim/ first There is also a new quickfix and marker resolution for the AAPT error which complains about an unbound prefix. This will insert a xmlns:android="http://schemas.android.com/apk/res/android" attribute declaration on the root element. This CL also includes a fix to make the New XML File Wizard preselect the current project in more scenarios. NOTE: This changeset adds new XML editors for these resource types. It does not attempt to update previous editor bindings for files of the given type, so to test this you may need to use "Open With" in the package explorer to pick the right file type. A subsequent CL will try to migrate settings over to these editors, but that work will tie into another effort: merging all these different editors into a single editor class that does its own content type switching and different viewparts for the other tabs. Change-Id: I4b12bafd8fd068176c41bac1e345bb74ccdb8b6f
* Code completion in style definitions & other improvementsTor Norbye2011-03-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds code completion support to resource files where <style> elements are defined. In particular, you get two types of completion: - Completion on names: <style><item name="|" > Here you get offered ALL matching attribute names from any view descriptors. - Completion on values: <style><item name="android:gravity">|</item> Here you get offered all values that correspond to the attribute named as the value of the name attribute of the surrounding item element. Unrelated to styles, code completion will now also move the caret outside the attribute value quotes when you enter one of the value alternatives (unless the value is a flag type or a resource token). Also, run-on attributes are also handled more gracefully: if you complete properties with the caret immediately following another attribute, a separating space is added into the match as a prefix such that the new attribute is separated and the XML valid. There are a lot of diffs in this changeset. In order to allow the ResourcesContentAssist to extend code completion to add its style- specific logic, the content assist code had to be split up a bit. Doing completion in text nodes, or potential text nodes (e.g. if you have <item>|</item> you should get text completion at that caret offset even though there is no text node child of the item element until you insert actual text there) also required some changes. There are many new unit tests. I also changed the golden file format slightly to show the caret in the before-view such that it's more obvious how the caret was affected by inserting the new item. Change-Id: Ia985db7e848fea33e93ac8a70b2c3b4dbfd9056a
* Add Quickfix and Quick Assistant for creating resourcesTor Norbye2011-03-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds two related features: - A "marker resolution" which adds a quickfix to aapt errors for nonexistent resources. This means that you can right click on the error in the Problems view to create the associated missing resource. - A "quick assistant" which looks for a missing resource on the current line and if found adds a fix handler for it, similar to the quickfix above. When a fix is invoked, it will create the new file or value, and open it in the editor with the relevant value section selected. The quick assistant can be invoked by the normal Ctrl-1 (Cmd-1). The quickfix must be invoked from the Problems view; the Java editor seems to add an extra level of integration with a lightbulb in the editor margin but we don't get that in XML. The quickfixes work for all value-based resources, as well as some file-based ones (in particular, those supported by the New XML File wizard, which it reuses.) This changeset also adds unit tests for quickfixes along with a few infrastructure changes to support it. Change-Id: I962bcf6c98934685e4d74389469d0903115a75e3
* XML code completion improvementsTor Norbye2011-03-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset contains a number of improvements to the code completion in XML files. (1) Add suffix completion in attribute values. For dimensional attributes, this will add in (or complete prefixes of) units like "dp", "sp", etc. For fractional attributes, the % and %p suffixes are completed. (In both cases, there is also a tooltip message provided shown in the completion documentation popup). In addition, for flag values, when completing at the end of a flag, then the separator character (|) along with the other flag values (except those already set) are offered. (2) Handle completion when the caret is not at the end. For example, if you have the following source: layout_w^idth="wrap_content" (^ = caret position) then if you invoke code completion you will also be offered the attribute layout_weight, and selecting it will -replace- the layout_width attribute with layout_height, it will not insert layout_weight in the middle of layout_width. This handling is done not just for attribute names as shown here but for attribute values and element tag names as well. (3) Improve @resource/ completion sorting. When completing resources, consider which attribute is being completed, and use that information to sort the resources. For example, if completing a "text" attribute then @string/, and @android:string/ resources will be listed first. For attributes like margins @dimen will be first, for include layout the @layout attributes will be listed first, and so on. Also, the resources are sorted alphabetically as the second sort key. (4) Hide some builtin Eclipse code completion items. In particular, the default code completion provider for Eclipse will always add the current attribute value as a completion. This is extremely confusing since if you have a typo, code completion will tell you that what you have is okay. I personally witnessed this confusing a user who had typed something from memory and code completion seemed to him to "confirm" that he had it right. To fix this, the code which installs completion providers, will identify the builting WST completion provider, and when found, replace it with a "filtering" wrapper. This completion provider delegates all its calls to the WST completion provider, but it recognizes a few patterns, in particular the above attribute value completion proposal as well as some namespace and schema ones, and removes these. (The reason we only filter out these items instead of removing it completely is that the completion provider also appears to be responsible for inserting code templates defined by the user, and we don't want to neuter those if defined by the user.) (5) Fix a bunch of corner cases - flags could only have a single separator (|), resource attribute completion items were missing icons, and completion in some positions was not working. (6) Unit tests. There are now comprehensive unit tests for code completion. Each unit test points to a particular source file and a particular position within the source file, and code completion is invoked for that position. A set of unit tests dump out the allowed completion items for each such position, and these are compared against golden files. A second set of unit tests then specify a particular code completion item among the choices to be applied, and then applies that completion item to the document. This, along with the caret position (indicated as ^) is written into a golden file and used for comparisons. To make it easy to see what these tests do, the golden file is actually recorded as a diff, so in the test you will see something like this: Code completion in completion1.xml for android:gravity="left|b^ottom" selecting bottom: < android:gravity="left|bottom" --- > android:gravity="left|bottom^" (6) There are some other misc changes. We had some code which used "dip" for device indepdendent pixels (such as the AbsoluteLayout handler). Since "dp" seems to be preferred, the code will now use that instead. Change-Id: I8bd5c8336d8747dac1f10a9269ea4197f304cb70
* Underline the error range for aapt errorsTor Norbye2011-03-111-0/+2
| | | | | | | | | | | | Currently, aapt errors only show up as an error icon in the left hand margin, and the user has to figure out from the error message where on the line the error occurred. This changeset uses information in the error message to identify the specific range of text on the line that is affected, and underlines it. Change-Id: I322a8193af4e90bb972276aee80124771b6a46cd
* More refactoring work: Convert hierarchy, and change typeTor Norbye2011-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactoring: Wrap in Container, Change Layout Type, ExtractTor Norbye2011-02-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make layout editor margins compress when necessaryTor Norbye2011-02-081-0/+1
| | | | | | | | If there isn't enough room to show the margins, make the margins smaller. This gives more useful layout room when you are dealing with large screens. Change-Id: I6f967dbe6b18ca5ee85cc04db88d903cb976e851
* Default the render target to Android 3.0 for newly opened layoutsTor Norbye2011-02-071-0/+1
| | | | | | | | | When opening new layouts, or opening layouts saved with older versions of ADT, pick a render target that supports layoutlib 5. Many features (such as layout rendering, palette previews etc) work much better with layoutlib 5. Change-Id: I0c577e76a2447985be0ab9bd2603618e8f152873
generated by cgit v1.1 at 2024-09-14 17:21:07 +0000