aboutsummaryrefslogtreecommitdiffstats
path: root/eclipse/plugins/com.android.ide.eclipse.tests/unittests/com
Commit message (Collapse)AuthorAgeFilesLines
...
* Add isSame on IDragElement, and sort primary to frontTor Norbye2012-06-071-1/+5
| | | | Change-Id: I7121b5f0e3714fec705387603f641bc14ed0ab3e
* 32745: Lack of warning of using duplicated IDs for element.Tor Norbye2012-06-052-2/+29
| | | | | | | | | | | | 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
* Fix nullness annotationsTor Norbye2012-05-306-60/+73
| | | | | | | | | | | | | | | | | | | 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
* New Template Wizard supportTor Norbye2012-05-221-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds several new templates, to create a new project, a new activity, a new custom view, etc. More importantly, it contains support for these wizards (and the corresponding code generation) to be driven by templates. A wizard contains metadata which provides a name, description and icon for the template, as well as a list of parameters, along with type and constraint metadata for those parameters. When a wizard is created for this template, it automatically adds UI elements to input the parameters and to validate the input. Parameters can also specify their default values as templated expressions using the other variables on the page, so in the New Blank Activity wizard for example, editing the activity name automatically updates the suggested layout name, by repeatedly evaluating a template expression to compute a layout name from an activity name. There's a recipe file for each template which states what actions to take to create the template. In addition to obviously copying resources (such as icons and jar files) and instantiating templates (to rewrite text using variables and FreeMarker logic), it can also merge XML contents (to for example insert activity registration metadata into the manifest file, or add string definitions to the strings.xml file), and it can cause files to be opened when the template is created. Tne new wizards also use JFace's decorator support to provide help and to mark text fields that contain errors, when one or more of the page fields do not validate, as well as to show tip text along the bottom of the page. One example of this is that it explains what a "package name" is when the package field has focus. This changeset also contains a "Template Development Wizard" which lets you point to a local directory containing a template definition, and run a test wizard from there. This is useful for developing, debugging and testing templates. Change-Id: I08e7d2464a1ef00d09517f0154c42681249a7ff6
* Merge "Move XML code to the common library"Tor Norbye2012-05-2111-73/+17
|\
| * Move XML code to the common libraryTor Norbye2012-05-2011-73/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Fix resource validator for style resourcesTor Norbye2012-05-181-1/+5
|/ | | | | | | | | | This fixes issue 31414: Extract style from XML layout doesn't allow . (dot) in the name The root issue is that in value files, you can use "." as part of the resource name; it gets remapped to _ in the R file. Change-Id: I59bf9d7ceb36be832dde64f557d023dd6d1d29e0
* New Configuration ChooserTor Norbye2012-05-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset replaces the configuration chooser with a new UI. First, the two lines of comboboxes have been replaced by a toolbar, which will wrap to two lines if it cannot fit on a single line. However, it tries hard to avoid this scenario by using icons and brief labels. For example, the rendering target is displayed as an Android icon along with just "4.0" instead of "Android 4.0". Similarly, the "Other" locale is just shown as a globe icon, and for example in the Device list "4.65in 720p (Galaxy Nexus)" is display as just "Galaxy Nexus". Second, the "current configuration" label is now a dropdown instead. The text of the label displays the current configuration as before (though using the brief name, e.g. "layout-land" instead of "Landscape Configuration". In addition, it's a dropdown, and opening the menu will display all other available configurations for this file. Thus, if you have a special landscape version and a special tablet version of a particular layout, the menu will contain default, landscape and tablet (where the menu items display the full configuration names such as "Landscape Orientation"). In addition, the configuration menu also contains "Create New...", which is the new location for the Create button which used to be in the toolbar itself. Third, there is a new "Activity" dropdown. This displays the current activity associated with this layout, next to an Eclipse "class" icon. It is initially populated with our best guess of what the activity is. The chosen activity determines which theme is initially assigned to a layout (for example when there is a Manifest registration of a theme to an activity). In the future we will use this facility to drive other features as well, such as preview rendering the action bar (where we need to know the associated activity) or assisting with creating click handlers. The Activity dropdown menu also contains a "Open <Activity class>..." action for jumping to the associated Java code. The chosen activity is persisted as an XML attribute in the layout so it should be preserved across IDE sessions and shared among developers. Fourth, all the dropdown menus are now native SWT menus rather than dropdown menus, which means we can use icons, proper separators, and nesting. The locale menu now shows flag icons next to each region (and when a locale is chosen the corresponding icon is shown in the configuration toolbar). In the Theme menu we no longer need to use "-------" ASCII separators, we can use proper native menu separators instead. And the Theme menu is now nested; rather than a really long list of options, the menu is grouped into related sections: * Currently selected theme * Project Themes > * Manifest Themes > * Holo Themes > * Holo.Light Themes > * DeviceDefault Themes > ... * All > * Open "<current theme>" Declaration... Fifth, the device configuration combobox has been replaced by three inline icon radiobuttons, showing portrait, landscape and (if enabled) square. This makes it easy to switch orientation through a single click. Sixth, the UI mode (Normal/Car/Dock) and Night mode (Day/Night) are no longer directly shown in the configuration chooser since they are not used frequently enough to warrant persistent space in the always visible toolbar. Instead, there is an "Edit Configuration" icon on the left you can click which brings up a full editor dialog where all the previous combo boxes appear, along with the generic configuration qualifier selection dialog. Here you can make more specific edits to the current configuration state. There are various fixes as well. For example the whole toolbar is hidden during platform data loading and made visible at the end. When creating a new configuration file, that new configuration file is opened after creation. We now track whether the current theme (stored in the IDE persistent property) is a project theme or a framework theme. Change-Id: Ic8d9817c7bc4dbcae4535b6b9222393fb49cfde9
* Make XML code completion work for custom views & attributesTor Norbye2012-04-271-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | This changeset improves the custom view handling such that XML code completion offers any custom attributes (along with documentation tooltips and type information). This is done by finding any declare-styleable attributes defined in the project defining the custom view. In particular, this will also work for the GridLayout library project shipped as part of the android.support package. The fix is not tied to completion; it's improving the metadata descriptors computed for custom views, so this fix for example also makes these custom attributes show up in the property sheet in the layout editor. Finally, this changeset fixes a couple of bugs in this area: - One initialization path was not looking up custom views for unknown descriptors, this might be the fix for http://code.google.com/p/android/issues/detail?id=23020 - There was a bug in the code which looks up the namespace prefix to use for a given namespace URI: it would return the default Android prefix for some non-Android URIs. - Small performance tweak to avoid regexp construction in a loop where it's not needed Change-Id: I55dfcea6e6ea9d7c38e18a47b757678176facbd2
* Test fix: The image parameter is mandatoryTor Norbye2012-04-251-6/+0
| | | | Change-Id: I9b8ca8e0384f1cb2343d13e8e43b268c63ed4dcb
* Add support for the WindowBuilder Property SheetTor Norbye2012-04-053-0/+61
| | | | | | This reverts commit 27dac06bfc4297dc9a018edc534f44ecf96cd724. Change-Id: I6708bd4091f0cb677484669479357d479b9db5fa
* Revert "Add support for the WindowBuilder Property Sheet"Tor Norbye2012-04-033-61/+0
| | | | This reverts commit a7621238bf0202419677380ee3a268142358df83.
* Add support for the WindowBuilder Property SheetTor Norbye2012-04-033-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The WindowBuilder propertysheet has been extracted and added as a library in external/eclipse-windowbuilder/. This changeset removes the old propertysheet code (which used the builtin Eclipse property sheet page), and replaces it with the WindowBuilder one, along with new code to aggregate the properties into some categories, as well as tagging some of the properties as advanced. (This was computed by running the same analysis scripts used to produce the most-frequent attributes (sdk/attribute_stats) and instead computing which attributes are used very infrequently or not at all in some representative sample code.) The WindowBuilder propertysheet gives us the following new features: - Highlighting (bold) of important attributes - Masking (and when included, shown in gray italic) of advanced attributes - "Complex" attributes with nesting, used to for example aggregate all the layout parameters into a single node, and the margin layout attributes within those - Tooltips over the attribute names, not values, so they never obscure content In addition, this changeset adds custom implementations of properties, property editors and property dialogs for the core Android property types (XML strings, flags and booleans), which adds the following new features: - Preview rendering of color and image resources inline - Display of -default- attributes (those not specified in XML) using the layoutlib facility getDefaultProperties() to render the implied attributes. For example, if you look at a Button, it will show you that the implied value of "Text Color Link" is "@android:color/holo_blue_light" even though it is not set. NOTE: This only happens for attributes that were actually queried by the widget during rendering. Attributes that are not used by the widget have no (displayed) value. Thus, EditText-specific attributes in a TextView are not shown when a non-EditText TextView is selected. - Evaluation of the attributes. In the above example, in addition to showing @android:color/holo_blue_light, it will chase down the value of this to for example render a blue square next to the value. For drawables it will render a thumbnail, and for String resources it will display the actual value in parentheses. - Field completion in text fields, completing all resource strings (@string, @android:string, etc), as well as flag values. Enum values are chosen in a dropdown. - Checkbox support for boolean values, allowing you to click through the three values true, false and null. - Our custom version of the Property Sheet Page allows you to expand/collapse all properties, and it also has an option letting you switch between Alphabetical Sort (where all attributes are in a flat table, sorted alphabetically by property value), or hierarchical sorted "by category". Currently the categories are simply the defining views, plus 2 more (layout parameters and deprecated attributes). When we get more metadata, it would be nice to switch these to more logical categories, such as "text", "scrolling", "focus", etc. (There is some preliminary support for this in the code, but since the defining-view categories seem to work better those are used instead right now.) Change-Id: Ie4959a3a2c36c083dcc1ba19a70f24b33739fe2f
* Change AttributeInfo.getFormats() to returning an EnumSet<Format>Tor Norbye2012-03-224-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset changes the signature of AttributeInfo.getFormats() from returning a Format[] to returning an EnumSet<Format>. Furthermore, it defines a number of constants for the various common format sets such that they can be reused. Nearly all uses of the getFormats() method was really just trying to see "is format X among the formats", so using enumsets is more natural since it has a contains method. This also lets us replace some attribute init code which was building up a set from the array for this exact same purpose just reuse the format set directly. In the attribute parser, rather than computing the uppercase version of each format string ("dimension"=>"DIMENSION") and then doing a Format.valueOf("DIMENSION"), we now compute a map for all the format constants as lowercase to the corresponding format instance, and use that map when parsing the attrs.xml file. Note that there is a small semantic change from having an array of formats to using an enumset: The format specified an ordering. However, it does not look like any code depended on this, and it's also not clear that the ordering in attrs.xml is intentional. For example, it contains both "color|reference" and "reference|color", and in both cases the intent is that the attribute can specify an actual color or a reference to a color. Now with an enum set, the order used when traversing the formats will always be in their natural order, and for this purpose the REFERENCE type is moved to the end since it's the least specific. Change-Id: I1170cff48086f5cc13e4b70a35deea1f9979c883
* Speed up Android Target Data loadingTor Norbye2012-03-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset optimizes the handling of AttributeDescriptors during the SDK target loading phase. From some simple benchmarks, this speeds up target loading about 40%. (On an low-load machine, loading two targets took on average 9.11s with standard deviation 1.86 for 13 runs; after the fix the same target loading took on average 6.359s with standard deviation 0.944s for 17 runs -- so the speedup is 1.43). The most important fix is to make the computation of the tooltip text and the UI name (which performs various lowercase to uppercase conversions, in some cases involving regular expressions, and many string concatentations) be evaluated lazily. This is a big win since most attributes never have their UI names or tooltips displayed, and when they are, usually just a small number. Since tooltips and UI names are now computed lazily from the AttributeInfo, the constructor for the TextAttributeDescriptor and its subclasses no longer take a UI name or tooltip; instead, there is an explicit setter for the cases where you have a specific tooltip you want to hardcode (as with the builtin descriptors such as the ones for drawables). The actual formatting method for UI names was also optimized a bit, such as avoiding regexp replacements except for cases where they are likely needed, preallocating a larger character buffer, etc. Change-Id: I7004e403fcf696e18bd89a29c6cfd27b61c1e9f8
* Add info about when qualifiers were added to the platform.Xavier Ducrohet2012-03-161-1/+4
| | | | | | | | This is a first step where we setup the info. Next step is to actually use the info when calling ResourceRepository.getConfiguredResources Change-Id: I03c20ad0ec7a53ec8219316cc4af7a59155ef34a
* Add support for suppressing lint via XML attributesTor Norbye2012-02-061-2/+29
| | | | | | | | | | | | | | | | | | | | | | | This changeset adds support for suppressing in XML files: (1) Lint will ignore errors found in attributes and elements if the element (or any surrounding parent elements) specifies a tools:ignore="id-list" attribute where the id-list matches the id of the reported issue (or "all"). The "tools" prefix can be any prefix bound to the namespace "http://schemas.android.com/tools" (2) There's a new quickfix shown for XML lint warnings which offers to add a lint suppress attribute for a given lint warning (setting the id to the id of the warning, and adding the tools namespace binding if necessary). (3) The XML formatter now handles namespaces a bit better: after the preferred attributes (id, name, style, layout params, etc) have been handled, attributes are sorted by namespace prefix before they are sorted by local name -- which effectively will sort any new tools:ignore attributes to the end. Change-Id: Id7474cde5665d9bd29bdd4e0d0cc89ed4d422aea
* Update SDK codebase to JDK 6Tor Norbye2011-12-2112-1/+140
| | | | | | | | | | | | | | | | | | | | | 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
* Don't assign ids to all newly dropped widgetsTor Norbye2011-12-191-0/+15
| | | | | | | | | | | | | | | This changeset makes the layout editor no longer assign default id's to all newly dropped widgets. In particular, it no longer assigns id's to *Layout widgets, such as LinearLayout and RelativeLayout. These id's are typically unused, and in the case where you do want an id to manipulate the widget you probably want to change it to some more logical name than "linearLayout1" anyway. (It also stops assigning id's to <include> tags, <merge> tags and <Space> widgets.) It also changes the label of the "Edit ID..." context menu action to "Assign ID..." for widgets that do not currently have an id. Change-Id: Ibf0ec25a6a687e34d3eebf828251d196cadb9d54
* New lint rule for invalid @+id referencesTor Norbye2011-12-131-12/+0
| | | | | | | | | | | | | | | | | | | | | | This changeset adds a new layout rule which finds cases where you have RelativeLayout attributes pointing to id names that do not exist, such as layout_alignLeft="@+id/navbar" The +id/ syntax here creates the id on the fly, so aapt does not complain, but the new lint rule makes sure that at least one layout actually defines this id as its id. If no match is found, it looks for spelling mistakes and suggests other similar ids in the error message. This condition is flagged as an error. The detector also issues a related warning if it finds an id reference that is not defined in the same layout. This is sometimes okay (where you have deliberately referred to an element which will be included into this layout, or is in a layout including this one), but it's usually an accident. Change-Id: I7f3fa6f4cb5cef6dcd307256050fb9580887addd
* Add package support for Rules API and Detector APITor Norbye2011-11-231-0/+6
| | | | | | | | | | | | | | 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
* Add Lint HTML reporting, and fix position information in parserTor Norbye2011-10-281-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset adds a HTML report option for the lint command line driver, and cleans up the code a bit. It also fixes the feature where the line containing the error is shown along with each error, and turns it on by default. This was previously turned off because the position information for XML nodes was fairly inaccurate (no column information, and the element offset was the end of the opening tag rather than the beginning). With the HTML report, where not just the error line but the window of code around the error is shown, having accurate offset information even in the CLI driver was important. Therefore, this changeset also rewrites the PositionXmlParser. The old approach used XML transformers; now we instead use a SAX parser to incrementally build up the DOM, and marking node offsets as we go along. SAX still only gives element-end offsets, line+column instead of offsets, and no information for individual attributes, so the builder also scans the source in order to build up accurate information. Results are now accumulated during the error reporting phase, then sorted in priority, category and finally file+line number order before being shown as HTML or text. Finally, the code to escape code to attribute values was missing that < is an invalid attribute character, so this CL fixes that issue as well. Also fix some incorrect copyrights. Change-Id: I652a1545b92865a88ecb4e6526616ba4cd75b512
* Misc GridLayout handling fixesTor Norbye2011-10-261-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | This changeset fixes some miscellaneous in the GridLayout support. The gravity handling code (which creates a bitmask for gravity from XML attribute values) was pulled out of the change layout refactoring such that it can also be used by the GridLayout. This is done to figure out where cells are not bound to the top or left corners, in which case they should not be considered when computing a suitable right or bottom edge for splitting a cell. There's also fixes for a problem where certain negative constraints would be offered, there were tooltips when only one of the two dimensions produced suggestions (and you can only drop when both are valid). When removing children back to a blank layout, reset the columCount to 2. And finally there were some problems where the columnCount was larger than the number of actual used columns in the table, where dragging near top/left corner would use some of the later columns rather than the first available one. Change-Id: Ice22754fb14659812b54019452aeca6daaeede10
* Modify validator to reject file resource names starting with _Tor Norbye2011-10-091-0/+9
| | | | Change-Id: I23cea24d7363597968d6602b5a056a59085b9c6c
* XML Comment Formatting FixesTor Norbye2011-10-031-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset fixes issue 20452 related to XML comment handling. There are several changes. First it fixes a truncation bug where the last character in a comment could get erased. Second it makes sure we don't end up with double blank lines, since there were cases where the comment formatter would insert a newline (to preserve newlines after comments in the original document) and a subsequent element or close tag would also insert a newline (which is where the normal blank lines are added). Now the code will peek at the write buffer to make sure we haven't already added a blank line. Third, it attempts to handle multiline comments a bit better such that the code which preserves indentation of the first comment line will dedent down to the minimum indentation level of the block comment. This means that we will format <!-- First Second --> into <!-- First Second --> instead of <!-- First Second --> as the code did up until now. (The current handling was there to make <!-- This is a comment --> format into <!-- This is a comment --> ) Unit tests. Change-Id: Id98faadf3731b82880b37ff852c7c0787bb196f8
* Misc New Project Wizard fixesTor Norbye2011-09-061-0/+7
| | | | | | | | | | | | | | | | | | | This changeset fixes a couple of bugs in the New Project wizard: (1) It escapes strings, such as the application name, in the strings.xml file. http://code.google.com/p/android/issues/detail?id=6725 (2) It fixes package name validation in the activity name http://code.google.com/p/android/issues/detail?id=14811 (3) It selects an SDK target by default http://code.google.com/p/android/issues/detail?id=17505 Finally it also ensures that the suggested activity name is a valid Java class name even where the application name is not. Change-Id: Iba9843dbb2fbb09324122d285e51ad937f6fddfd
* Escape string in "extract string" refactoringMichael Zoech2011-09-021-0/+57
| | | | | | | | | | | | | When executing the "extract string" refactoring only single and double quotes are escaped correctly. This patch for the bug #19612 improves the method by escaping the following characters: * Spaces at beginning or end of string. * @, ? at beginning of string. * ', ", \, <, &, \n, \t anywhere in string. Change-Id: Ia2939213bd5460399dc5e19f5ce413c3f5812ea8
* Add support for remaining asset types in Asset Studio WizardTor Norbye2011-09-012-0/+28
| | | | | | | | | | | | | | | | | | | | 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
* Use GridLayout state to determine exact row and column boundariesTor Norbye2011-08-234-5/+5
| | | | | | | | | | | | | | 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
* Layout editor property menu improvementsTor Norbye2011-08-196-38/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use Eclipse XML parser instead of JDK parser when formattingTor Norbye2011-08-181-476/+0
| | | | | | | | | | | | | | This changeset adds a utility method which parses an XML string using the Eclipse structured model instead of the JDK parser. The resulting document has some extra metadata which the XML formatter can use. In particular, it distinguishes between empty tags and tags without children. Now that this is fixed the formatting on project creation code includes manifest files, which I excluded previously because it made the <uses-sdk> element look ugly. Change-Id: I7069fa43df33d874303435b3625f1c7b20f5b3d3
* Add missing qualifier iconsTor Norbye2011-08-171-1/+1
| | | | | | | | | The Available Width, Available Height and Smallest Width qualifiers were missing icons (which are shown in for exmaple the Create Configuration dialog). This changeset adds icons for these (which also makes ResourceHelper.testGetIcon pass.) Change-Id: I42c4e357245adc0b80320bac5fe1e173d1d0eaf3
* Action API improvementsTor Norbye2011-08-151-26/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a few XML comment formatting corner casesTor Norbye2011-08-111-3/+34
| | | | | | The cases are covered by the new unit tests. Change-Id: I165def59dad59de7e8e1c4e5516c567722aa254e
* Improve partial XML formattingTor Norbye2011-08-101-5/+16
| | | | | | | | | | | | | | | | | | | | | | | This changeset improves the behavior of the formatting when formatting just a part of the document (e.g. the selected region, or more accurately the nodes overlapping the selected region.) First, it looks up the current indentation levels in the document of the start node and its parent and uses that for the indentation, which means that nodes appear to be pretty printed in line instead of jumping to whatever the absolute indentation level would correspond to. Second, the formatter now has a mode where it can format only the opening tag of an element. This is a special case of formatting a node which is particularly useful when you enable automatic formatting by the layout editor, since just setting a property on a root element shouldn't reformat all the element children of the edited node. Third, there are various tweaks to how the whitespace is handled around the inserted node. It also fixes a couple of bugs. Change-Id: If1dd2dc5091a08b770927cd4b9fcafe0c032a216
* Merge "Ability to suppress rendering fidelity warnings"Tor Norbye2011-08-101-2/+28
|\
| * Ability to suppress rendering fidelity warningsTor Norbye2011-08-081-2/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you're working with a custom component that uses unsupported graphics operations, the layout editor will show an error area. This error is always there. That can be annoying since there's nothing you can do about it after reporting a bug. This changeset adds the ability to suppress these errors for the current IDE session. It adds a "Ignore" hyperlink next to each fidelity rendering error message, and when you click it, the specific type of rendering error is suppressed and hidden for the current IDE session. These warnings are only suppressed for a single session and not permanently. This is because you are suppressing an error not for a specific layout but for any occurrence of that error. If these ignore settings were persisted you might open some unrelated layout in the future and be puzzled why it does not look right. Change-Id: I2d20a36aee7767257b16ad805b0e8da36a6eb97e
* | Merge "Fix linear layout and frame layout unit tests"Tor Norbye2011-08-093-13/+12
|\ \
| * | Fix linear layout and frame layout unit testsTor Norbye2011-08-053-13/+12
| |/ | | | | | | | | | | | | | | | | I changed the code which draws drop feedback recently to use a more efficient call (calling drawRect(x1,y1,x2,y2) directly instead of constructing a new Rectangle object and calling drawRect(Rect). Some golden files checking graphics output needs to be updated. Change-Id: I369fed9cb0756ff4f3aa970c1bdd552d0f55faaa
* | Merge "Miscellaneous XML formatting fixes"Tor Norbye2011-08-051-15/+219
|\ \ | |/ |/|
| * Miscellaneous XML formatting fixesTor Norbye2011-08-041-15/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset contains a number of tweaks to the XML formatter: - Handle "end-of-line" comments, such as those seen in some drawable <selector> files: <item android:state_pressed="true" android:color="#ffff0000"/> <!-- pressed --> <item android:state_focused="true" android:color="#ff0000ff"/> <!-- focused --> <item android:color="#ff000000"/> <!-- default --> Here the comments will continue to live on the same line as the end tag. - If the unformatted XML had a blank line between a comment and the next element, then insert a blank line there in the formatted XML as well - Always place the xmlns: attribute on the same line as the opening element tag - In alphabetical attribute sorting, make xmlns: attributes an exception and always sort them to the front just as is the case for logical attribute sorting - Fix some cases where turning on "remove all lines" would still leave some blank lines, such as in front of the root element closing tag and around comments - Fix unit tests such that they run with the default values for the formatter; they were accessing an uninitialized AdtPrefs instance (since they are not running as plugin tests) and were inadvertently just using "false" for all the flags. - Add more unit tests. Change-Id: I537f8afe4ca4d775b5f91574b895ba90a2741f5c
* | Fix some UT.Xavier Ducrohet2011-08-041-0/+18
|/ | | | Change-Id: Ia3ca9ef68d6435a323959913a6bd9298e9bcf0c9
* Use Windows line delimiters on WindowsTor Norbye2011-08-021-2/+20
| | | | Change-Id: I33094888432214fc5c70c4c4392d8afd932a3a7a
* Add a new XML formatter, new options, and format on saveTor Norbye2011-08-012-0/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Sort XML attributes logicallyTor Norbye2011-07-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Grid Layout Support.Tor Norbye2011-07-114-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix locale handling of linear layout weightsTor Norbye2011-07-071-1/+20
| | | | | | | Fix 18298: ADT r12 layout editor uses locale specific decimal separator leading to unparsable XML Change-Id: Ideae319e41f8a7e34075065c63247d50cdf830c5
* Integrate unknown attributes in the normal UiElementNode workflow.Raphael Moll2011-07-061-15/+15
| | | | | | | | | | Somehow this should have been the default. There's a few cases where this will allow us to simplify the code and that will be for another CL. Also fixes http://code.google.com/p/android/issues/detail?id=17762 Change-Id: Ieccd36f5f4042f414311f09339ed18fc73d7b122
* RelativeLayout: Assign ids dynamically, handle multi-drag, bugsTor Norbye2011-06-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Workaround view info cookie bugTor Norbye2011-06-101-0/+28
| | | | | | | | | This changeset works around the case where a ViewInfo cookie is identical to its parent. This is for example the case for a ZoomControls widget, where the child views have MergeCookies whole value points to the parent ZoomControl. Change-Id: Ie0eb62750fba6eeaa7241edce68e05f853e08a75
generated by cgit v1.1 at 2025-08-16 10:19:26 +0000