fe51dba2aa25e559786e5da315d4db714ffe7559 |
|
12-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Support separate layout editors for a single layout resource This changeset changes the "reuse" behavior of the layout editor to no longer reuse the same layout editor when you are switching between alternate layout files for the same layout resource, such as layout/foo.xml and layout-land/foo.xml. This lets you more quickly switch back and forth and inspect differences between the layouts, etc. There is also an option in the Android > Editors panel to turn on single editor sharing again. The biggest part of the changeset, by far, is a cleanup of the ConfigurationComposite class and associated code. This was necessary not just to support the above feature (where we need to "back out" UI changes when you've made a configuration edit which results in a different file getting opened), but it's also an important preparation for multi configuration editing, where we need to be able to switch configuration settings in and out of a single configuration editor, etc. The configuration data itself is now in a separate Configuration class; the UI is in ConfigurationChooser, and the configuration matching code is in ConfigurationMatcher. There's also a new Locale class to track language/region pairs instead of using 2-element ResourceQualifier arrays. The various menu listeners are also in separate UI classes now. While there are new classes, most of the configuration matching algorithm is unchanged, just moved to a new class and the UI syncing and configuration data lookup replaced. Bitmasks are used to handle configuration changes, such that updating multiple related attributes (e.g. a rendering target change also causes a theme change if say Holo isn't available) can now be processed just once with a single change call. (Various other cleanup too.) Change-Id: I04ac969f46824321be3db0c487ef077c03cc6012
|
bd886a72e724ccf377f499a1c766210a3e19fb9f |
|
25-Aug-2012 |
Tor Norbye <tnorbye@google.com> |
Add lint rule which warns about View.setTag(int, Object) This changeset adds a lint rule which looks for potential leaks when using View#setTag(int, Object) where the Object is likely to contain a strong reference to the context, such as views and view holders. http://code.google.com/p/android/issues/detail?id=26984 Change-Id: Ib606485d2b875d2129c339b9b89be0e444629408
|
feadb6b4daf294c45425eb0300366675a5ce0b89 |
|
27-Aug-2012 |
Tor Norbye <tnorbye@google.com> |
Issue 34322: Fix handling of import statements Fix the commit prefs lint check such that it correctly identifies scenarios where the innerclass "Editor" is referenced without its qualifying top level class, SharedPreferences. Change-Id: I3a22738508b66ce0b3e836feff91f816b2c368e8
|
5890cb76e4ee5407f7a67f8de79d0f3a7ce1e1ab |
|
07-Aug-2012 |
Tor Norbye <tnorbye@google.com> |
Asset studio fixes When generating actionbar icons from clipart, do not strip surrounding space, and do not add extra padding. The clipart images already contain baked in padding suitable for action bar icons. This CL also makes sure the UI disables the corresponding options in this mode. It also renames and moves to the bottom the legacy menu and tab icon generators, and fixes a file resource leak in the image loading code. Change-Id: I8a0dd61c97862206cdc71dc591a207a0b6a050f8
|
2fb2655ff72c6cf7f6cb0ac7e933304a5a1298e0 |
|
02-Aug-2012 |
Tor Norbye <tnorbye@google.com> |
Add support for additional languages in the typo detector This checkin adds typo databases for six additional languages, as well as several fixes to the infrastructure. First, it now supports "globbing", since for example the German typo database contains glob patterns of the form "asymetrisch*->asymmetrisch*". Second, it supports multiword typos (such as "all zu->allzu") which caused some complications (since this means that the typo detector can match beyond the word boundary it was passed in). Third, it adds a bunch of validation code to the type dictionaries, which uncovered a bunch of inconsistencies (duplicate entries, using "-" instead of "->" for some separators, etc). There's now a unit test which produces a cleaned up version of each dictionary file, as well as tests to ensure that the ASCII and the UTF-8 comparison methods are in sync (and this uncovered some bugs which were fixed.) Finally, it fixes the HTML reporter such that it properly handles UTF-8. Change-Id: Ie32cbbe489687a7b50184696a027f87c2e21c409
|
3abd464aaa992994fc17786cdb5b2532ceb84143 |
|
02-Aug-2012 |
Tor Norbye <tnorbye@google.com> |
Allow custom source and class folders Maven places the source files and class files in different locations than our default Eclipse and ant build systems. This changeset adds --sources and --classes arguments to the lint CLI to allow a build script to point to these custom locations. It also also looks in Maven's default location if it doesn't find the normal bin/classes/ folder such that out of the box it might just work even in Maven projects. Change-Id: Ia91b05f0fc9d2c7e504c962d2e794c768085754c
|
74dc3e0d7d584d039689e57a80cf9868267883fd |
|
20-Jul-2012 |
Tor Norbye <tnorbye@google.com> |
Add basic flow analysis support to lint This changeset adds in the ASM analysis library (an optional part of the ASM package lint is already using to process bytecode). It also adds some basic flow analysis to the SecureRandom detector to detect whether a given dispatch to a field of type java.util.Random is actually pointing to a java.security.SecureRandom, in which case it flags calls on it to setSeed() where the argument is a fixed integer. Change-Id: If85ab9f8db0e801a01f1a3ea845865b4f98e259c
|
2c611aed27d75bd816b7887b64f98ff1ed87b097 |
|
20-Jul-2012 |
Tor Norbye <tnorbye@google.com> |
Add lint checks for wakelock and secure random problems This changeset adds new two lint bytecode-based detectors. The WakelockDetector looks for problems with wakelocks: - Calling release() in onDestroy() rather than in onPause() - Calling acquire() but never calling release() anywhere in the app. The SecureRandomDetector looks for problems with the SecureRandom random number generator: - Calling setSeed() with a fixed number, such as a string literal, or something equivalent (such as a static field reference of this or some other class) - Calling setSeed() and passing in System.nanoTime or currentTimeMillis since these are considered predictable seeds. These are both using the new fast-dispatch mechanism for bytecode detectors in lint. In both cases, there are more complex control flow we should be checking using flow analysis; that's for an upcoming CL where we add ASM's analysis library. Change-Id: Iec2a95b042b8a3e4e976923cc62e9dccf2dfeca5
|
eb1fb3f6b660d0acc17c1d9117acbcba809c8041 |
|
20-Jul-2012 |
Tor Norbye <tnorbye@google.com> |
Handle window events across multiple workbench events ADT uses a "window coordinator" which listens for various window related events (such as part activation, editors getting maximized etc) to implement its various layout editor handling (to dock property sheets within the layout editor unless it's shown in the surrounding frame), to activate/deactivate editors for keybinding handling, etc. This did not take into account the possibility of multiple workbench windows getting opened. This CL adds proper support for this. The window coordinator is no longer a singleton; there is one instance per workbench window, and AdtStartup listens for workbench events and creates or disposes these on demand. Change-Id: I298d9d82c7aefd684bcb1ace3bee0267e1f94a60
|
132f83db532360e5bc5c0303e432ec333897fc2e |
|
16-Jul-2012 |
Tor Norbye <tnorbye@google.com> |
Only report field getter issues when targeting pre-Froyo targets Change-Id: Ibc8756c2580a9e263b63b3507224acdf09f264ed
|
c5d16e5c345333414a416a8fb63fc74bd5e8e40a |
|
06-Jun-2012 |
Tor Norbye <tnorbye@google.com> |
Workaround for Eclipse 4.x focus issue In Eclipse 4, the system calls setFocus on the outline view *after* a mouse click inside the outline has been processed. This ends up calling setFocus on the treeviewer. If you clicked in the property sheet to for example start editing a text property, this means the focus loss will cause the property editor to abort editing again. The net result is that you always need to click twice to start editing properties if the Outline view does not already contain focus. This changeset adds a workaround for this. It has two parts. First, simply make the OutlinePage's setFocus() method do nothing if it's called during a mouse click in the property sheet (which we can track with a mouse listener). The second part is trickier. The outline view itself (which is provided by Eclipse and we have no hooks into it) will be called first, and it calls setFocus() on its first child, which is a composite, so it ends up searching down for the first focusable component. The workaround is to add our own widget as the first child, and make it declare that it's focusable but make the setFocus call a no-op. Second, make the widget invisible since we don't want anything but the tree viewer in the outline. Change-Id: Ib89943c410bce599723f59a4f202f339adab6327
|
64bb5c1f6139d05de62c8152f64aad8898df95b2 |
|
26-May-2012 |
Tor Norbye <tnorbye@google.com> |
Code completion in custom views now picks up newly added attrs When ADT encounters a custom view, it creates a view descriptor for that custom view, and in ADT 20 it also finds the associated styles and records these as attributes, which means code completion and the property sheet will show these properties. However, once the descriptor has been lazily created, it never changes. If you go and edit the styles.xml file specifying the attributes for your custom view, you need to restart the IDE before code completion will pick up these changes. This changeset makes this behavior more dynamic: It will now pick up edits to the files specifying styles for a custom view. Change-Id: I365119e18c74378a0a039c1e7a22641c94acf002
|
fd54b68d77bc90d5c607517c27bd7a30a2a8a57a |
|
25-May-2012 |
Tor Norbye <tnorbye@google.com> |
Support selector syntax for thumbnails in templates This changes the thumbnail handling from templates from ad-hoc attributes to a more selector-centric system. The template can specify one or more thumbnails along with parameter values associated with those thumbnails. When the user edits an attribute, the wizard reevaluates the thumbnail and picks the best match (meaning one of the thumbnails that matches all the parameter values, and among those the one that matches the most.) (This changeset also moves the metadata code into a new class.) Change-Id: Ic75d58573df5b2ea200c6b2861bbf36ce17ea1c3
|
7dd444ea0125e50a5e88604afb6de43e80b7c270 |
|
08-May-2012 |
Tor Norbye <tnorbye@google.com> |
New Template Wizard support 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
|
bc5879056fba2eb616dea06e6191bdc218b594c0 |
|
27-Apr-2012 |
Tor Norbye <tnorbye@google.com> |
New Configuration Chooser 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
|
5cae1eabc82d4fcd106897abb9acbd482ad2f849 |
|
16-Apr-2012 |
Tor Norbye <tnorbye@google.com> |
Improved layout window management This changeset improves the way the layout editor handles windows. In particular, it attempts to make the property sheet and the outline more visible. Specifically: * It adds the WindowBuilder docking support, which offers several new features: (1) You can collapse and expand the palette and structure views. If you hover over a collapsed palette (for example) it temporarily opens, and when you drag from it over to the canvas it collapses again. (2) The initial size is pixel based rather than percentage based, so the default palette size is more reasonable on large displays (it used to always take 20%, which was fine on a small screen but a waste on larger screens). (3) You can drag & drop to reconfigure the layout a bit. (This is fairly limited though; in particular, you cannot drag these views out of the editor area and mix them with Eclipse views.) * When the property sheet view is not shown anywhere else, it is shown as part of the outline instead (sharing the vertical space). This works better for the new property sheet implementation since it works better as a vertical window than a horizontal window. * When the outline is not shown anywhere else, it is shown in a new composite window *inside* the editor area. This mode is also entered when you temporarily maximize the layout editor window. * The layout canvas is auto-fit-zoomed when you enter and exit maximized mode, as well as when you open or close docked windows within the editor. The goal is for these changes to offer a good layout editing experience with the outline views and property sheets *without* using a new perspective for layout editing. Note that this is not identical to what WindowBuilder does; they always embed both the palette and the structure views within the editor area, which means the structure view is typically redundant with the outline view on the right unless you maximize the view. With the approach above hopefully we'll avoid that case and you'll always see the views without redundancy (and therefore with more available space for the layouts). Change-Id: I0d338b2781b9732e992f088fcc4e1ba46ff0954f
|
9bd06947302ca6ca3e0b90eef894e553c6c3e067 |
|
05-Apr-2012 |
Tor Norbye <tnorbye@google.com> |
Add support for the WindowBuilder Property Sheet This reverts commit 27dac06bfc4297dc9a018edc534f44ecf96cd724. Change-Id: I6708bd4091f0cb677484669479357d479b9db5fa
|
27dac06bfc4297dc9a018edc534f44ecf96cd724 |
|
03-Apr-2012 |
Tor Norbye <tnorbye@google.com> |
Revert "Add support for the WindowBuilder Property Sheet" This reverts commit a7621238bf0202419677380ee3a268142358df83.
|
a7621238bf0202419677380ee3a268142358df83 |
|
20-Mar-2012 |
Tor Norbye <tnorbye@google.com> |
Add support for the WindowBuilder Property Sheet 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
|
a2c463438d192ba6552b8f01e2c69bd3846e30ef |
|
23-Mar-2012 |
Tor Norbye <tnorbye@google.com> |
Speed up loadPublicResources() 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
|
9bfb05e9d9ea4b2b969e50c3096e2fdb95653648 |
|
06-Mar-2012 |
Tor Norbye <tnorbye@google.com> |
Handle the android support gridlayout library automatically 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
|
b115c0c78a04165fd5a849da0ac73c45bd8ef7b7 |
|
08-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
Make the lint string-format check ignore date strings 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
|
6eb13d0eb131d300de4d18adac9ca2e76769c9f7 |
|
01-Feb-2012 |
Tor Norbye <tnorbye@google.com> |
Lint HTML improvements 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
|
4f12059ac0ec02366992a379ca2044f10abe914e |
|
31-Jan-2012 |
Tor Norbye <tnorbye@google.com> |
Add @SuppressLint support for Java parse tree detectors This changeset adds support for suppressing lint warnings by annotatating variable declarations, fields, methods and classes. Change-Id: If274d65bccdc5c7d6426566c635245d6b3aae147
|
0f9dacc8a0205ce959348fdc9c33246abff7ad31 |
|
31-Jan-2012 |
Tor Norbye <tnorbye@google.com> |
Write lint overview report for multi-report 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
|
37d5a9bbdc2895921cd0f636777efe2d3bad4e5b |
|
09-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Add lint checks: String format, Casts, Security, Imports, /sdcard 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
|
b9eb4030bf5cc2ac91009ac377038f889c18c8a2 |
|
16-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Lint View Improvements 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
|
4c68f3dc9f10b76f1a32ff9c86587adca385a6d7 |
|
14-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Lint Library Support 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
|
581ca2e75fd638f6e95570ac54ff9e6b7b7cde84 |
|
06-Jan-2012 |
Tor Norbye <tnorbye@google.com> |
Extract positional XML parser into common and fix encoding issues 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
|
faab5914e7cc5e7f4676202ba589bf08c5ae0e42 |
|
03-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Add Java Classfile support Change-Id: Ifcc1d88dabb07dc05b2e5c934743ad52f9b6dc1d
|
3ce45b249f898697ae82e8c6dd045966227f3438 |
|
02-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Lint infrastructure improvements 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
|
1b765a82ab15dd2bd3d7bc7e43a7daf37a097e3f |
|
21-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Typography lint checker 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
|
e560cc00de6e514e04fc618981d9f8857692d250 |
|
23-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Automatically fix up editor bindings on project load (once) 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
|
cefde2307aa8737fccc756c3b69c3d7ca3e53e8b |
|
13-Nov-2011 |
Siva Velusamy <vsiva@google.com> |
Add support for NTLM proxy authentication. Change-Id: Ia8375444bf99b33396616a57e781adb22d82175d
|
b4e75e74aef92c6a166f400ca3d542ef7bb952b5 |
|
08-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
Add duplicate icon detector 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
|
38a09054d6e5bb8b9138ae28ebe113130050a066 |
|
07-Nov-2011 |
Tor Norbye <tnorbye@google.com> |
New lint icon detector 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
|
27ed098e750ee9463dfa7a36cef68d219de9eb50 |
|
31-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
Lint infrastructure fixes 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
|
53f27f8adbe5a657e766d81af1d584c2490730b7 |
|
26-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
Two new lint warnings: array-size check, and manifest order 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
|
a85107f7d763276a5a040cf68e2046ac54202015 |
|
06-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
Static analyzer 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
|
e632293a36d9a334d8e87c8baa1f4196f6fb917e |
|
07-Oct-2011 |
Tor Norbye <tnorbye@google.com> |
More GridLayout Fixes 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
|
390b825e915b0c37825d2f3941197bd3abe3394b |
|
30-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
Refactoring quick fix adjustments to caret and selection handling. DO NOT MERGE 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: I1ca305d9c66ae4eb6cd9a4f45f6803bb2444abdb
|
bf09c5651e2ade9738670ff69377824a40d4c79c |
|
30-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
Refactoring quick fix adjustments to caret and selection handling 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
|
8a06163380b3df70071df08a17f2f8c2aa77513c |
|
07-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
Cherrypick 4cd282 from master. do not merge. Grid Layout and Convert to Grid Layout improvements 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: Ifaca43458a4961fa032dfe22dc033b6def3c38d3
|
4cd282c7b21dc06c2d2d02748278f07c94282fc1 |
|
07-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
Grid Layout and Convert to Grid Layout improvements 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
|
d0357c27e602d6bec239897b8375d642bc590a62 |
|
22-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
Welcome Wizard. Do not merge. 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. (cherry picked from commit 292eefb8faa2f75ddbc5d6e20084c9f9a762da29) Change-Id: Idb3f8775ef62a84905cde95b25eeb8691ef0afab
|
292eefb8faa2f75ddbc5d6e20084c9f9a762da29 |
|
22-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
Welcome Wizard 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
|
2e9be3365117d1ece3989cce4bb7ef0421df7343 |
|
08-Sep-2011 |
Tor Norbye <tnorbye@google.com> |
New Project Wizard overhaul 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
|
59bddc5b09c091cfae54577ec36b16925b362b55 |
|
25-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Add support for remaining asset types in Asset Studio Wizard 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
|
5f80e1198ed4dcabfb0cf7669c92adc7dd1a0aeb |
|
24-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Workaround for Linux painting issue 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
|
94986e745141118cace0391da1b4dc8533408751 |
|
10-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Action API improvements This changeset changes the Actions mechanism for view rules to add support for the following: * Delayed computation of submenu contents. Before this, a view rule would have to produce the full tree of actions to be shown in menus and submenus - for example including all the properties, and in turn all the enumerated values for those properties and so on. Now there's a Provider interface which can be used to compute these menu items only when the menu is actually opened. The properties menu now takes advantage of this. This was also necessary to implement the following new feature: * The layout editor context menu now also lists not just the properties for the currently selected views, but also the properties for the parents. For example, if you open the context menu, you'll see the properties for the button you just right clicked on, but there will also be a "frameLayout1" submenu containing the actions for the <FrameLayout> parent of the button, and a "linearLayout1" submenu for the parent linear layout. This is useful when a parent layout doesn't have blank space on its own so it is difficult to target. A future CL will use the lazy initialization to add more options to the properties menu. * Support for arbitrary nesting. Submenus can contain submenus can contain other submenus etc. * Custom ordering. This changeset moves the "sort priority" concept (which was already used for layout actions) up to all actions, which makes it easier for rules to cooperate on ordering because instead of appending or prepending to the superclass' context menu result, actions can now just be initialized with a sorting priority value which makes it trivial to interleave actions regardless of who adds them. This also makes it a lot easier to use custom ordering in choice menus where the ordering used to be alphabetically sorting on keys. * Improved support for multiselection. The callback interface now takes a list of nodes to apply the callback to, and actions can indicate whether they support multiple nodes. This makes it possible for actions to more directly support the case where you apply an action to multiple nodes. As before, the available actions in the context menu is limited such that it only shows the actions common to all. But now those actions can do something specific. For example, if you select "Edit Text..." on many nodes, you will get the input-string dialog once, and then the value is applied to all. Similarly, if you select "Edit Id..." it will ask for a separate id for each value (and you can cancel out of this loop). There are various API changes too. Since the Choices action (which had a map-based set of values) was removed, the OrderedChoices is now renamed Choices. The Actions subclass of MenuAction which all actions also extended has simply been moved up to the top level MenuAction. And MenuAction has been renamed to RuleActions since they are used not just for menus but for toolbars etc and the key thing about this interface is that they are intended for use by rules. Change-Id: If49f75213f2041ebfef7e84254d70d219bb766ab
|
c0cc7c38c016afb66987c2b2340c045f50136f90 |
|
04-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Add tag-handling for Go To Matching in XML documents 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
|
83d04640bf245bb9ce108cef01e188761bc905f8 |
|
02-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Improve smart-indent handling in XML files 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
|
2914952cf3b5bad8292c0ce161a70baccfea9c3a |
|
29-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Add a new XML formatter, new options, and format on save 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
|
401e50139efc9333a689c2306ca66a7b2c840c40 |
|
28-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Add Java Quick Assistant for Extracting Strings 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
|
4eacdfbcc84ad11f599020b12ad76aebed70537f |
|
07-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Grid Layout Support. This changeset adds basic support for grid layouts: - Freeform mode where you can drag & drop anywhere in the layout, and guidelines are offered to align with other left boundaries, right boundaries, baseline vertical alignment and center layout horizontal alingment. In addition, it also offers "preferred spacing" positioning, using the recommended distance between widgets. Also, during a drag a regular 16x16 grid is also (faintly) shown and (when there are no alignment matches as explained above) the position snaps to this grid. We also show the grid-structure (rows and columns, not the regular snapping grid) during drags to make it more obvious that behind the scenes there is a grid (because some other operations might shift rows and columns so it's important to present the right user model.) The freeform grid layout editor will automatically create rows and columns and size them using spacers which are hidden from the user, and on deletion these are automatically cleaned up as well. - Grid mode where you can drag to any given cell, or between any two rows or columns. - Some layout actions for manipulating the grid (add/remove row and column, adjust the gravity, toggle modes.) This CL also contains various diagnostics code for the grid mode, and does not yet correctly support dragging multiple views simultaneously. Change-Id: Ie9ec54805039645e3db78d19095da86b04e44ca0
|
8c3f16ae7d66cedf70c494de3a38a54e90f2a54e |
|
10-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Merge 0b95acc1 from master to r12. do not merge. RelativeLayout: Assign ids dynamically, handle multi-drag, bugs This CL fixes three issues with the new relative layout interaction: (1) Assign ids dynamically. Before this changeset you couldn't attach to a node which does not have an @id attribute, since layout params need to name the constraint by id. This changeset changes this such that you can attach to any arbitrary edge, and when you commit the drag, a unique id is generated on the fly and assigned to the node. (2) Handle dragging multiple nodes at the same time. The new constraints code was unconditionally applying the same constraints to all the dragged nodes, which meant they ended up on top of each other. This fixes things such that the first node is assigned the new constraints, and then all subsequent nodes are attached one next to the other, in a direction depending on which edge you attached to (e.g. attaching on the right will arrange the siblings towards the left out from the edge.) (3) Fix a bug in the code to detect and prevent cycles. Change-Id: I3da16903ffac6c34a0d5efee52a87824fb9e04fb
|
0b95acc1693f67140e988567211c13ca2eb9f926 |
|
10-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
RelativeLayout: Assign ids dynamically, handle multi-drag, bugs This CL fixes three issues with the new relative layout interaction: (1) Assign ids dynamically. Before this changeset you couldn't attach to a node which does not have an @id attribute, since layout params need to name the constraint by id. This changeset changes this such that you can attach to any arbitrary edge, and when you commit the drag, a unique id is generated on the fly and assigned to the node. (2) Handle dragging multiple nodes at the same time. The new constraints code was unconditionally applying the same constraints to all the dragged nodes, which meant they ended up on top of each other. This fixes things such that the first node is assigned the new constraints, and then all subsequent nodes are attached one next to the other, in a direction depending on which edge you attached to (e.g. attaching on the right will arrange the siblings towards the left out from the edge.) (3) Fix a bug in the code to detect and prevent cycles. Change-Id: I157d45e117d3229f285870517b85ed902607b966
|
c99b6718c30d75adb36727d3f9feaa4e89c5d181 |
|
09-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Suggest similar class names or missing pkgs in the error console 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
|
3bfee6e90f8a897ad448e97cf95e4fe954d42925 |
|
08-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Improve error handling for missing and broken custom view classes 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
|
80d9301c2e874b29889c41adb0623666cf534fa0 |
|
10-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Resize & Guideline Support RelativeLayout now has both drop/move and resize guidelines, and existing constraints are visualized for the selection. LinearLayout resizing now uses weights to change the size of nodes rather than setting width/height. All resize operations offer guidelines to snap to their "wrap_content" size. Various bug fixes in related areas as well. Change-Id: I817e34c6e67ce61cfb137eb067076d91f69f99e9
|
429ae88878cf781753d8261d350ad89fe5864169 |
|
07-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Add Resize Support to the Layout Editor This changeset adds "resizing" support to the layout editor. First, the normal selection overlay is replaced with a selection rectangle which also has "selection handles" in the corners and in the middle of each edge. Moving the cursor over one of the selection handle will show a directional resize cursor, and dragging the handle will initiate a new resizing gesture. (This also made it possible to remove the selection fill we've used until now, so the layout editor will "interfere" less with the visual look of the layout.) During the resizing operation, the current size is displayed in the Eclipse status bar. The resizability of widgets is determined by metadata, so for example a ZoomControls widget is not resizable, a rating bar is only horizontally resizable, a TableRow is only vertically resizable, and most widgets are resizable in any direction. The parent layout is involved in the resizing operation. Currently, the resizing gestures will only update the width and height properties (except for absolute layout, which will also set the x and y properties if you are dragging a left or top edge). In a follow up changeset this will be extended to for example make RelativeLayout allow resize dragging to snap to new edges and the resize will be applied as a set of new constraints on the "resized" widget. Thus, you'll be able to drag the right hand side of a widget and drag it over to attach to some other widget or edge, independent of what the left edge or vertical edges are bound to. This changeset also adds the ability for ViewRules to provide a message or error message back to the IDE during a drag or resize operation. For resizing this is used to display the new size. However, it is now also used to display more useful messages in a couple of older scenarios: * Attempting to drag anything into a ListView will display a message that AdapterViews much be configured via Java code * Attempting to drag anything into or within an AbsoluteLayout will warn that AbsoluteLayouts are deprecated. Note that resizing will currently set the size to specific pixel (dip) sizes. In the next changeset I will add guidelines which (in addition to those described for RelativeLayout above) will add guidelines for significant sizes such as the parent size, the preferred (wrap_content) size of the widget, and possibly other hardcoded sizes in the same layout. Change-Id: Ie4f3367e81b24259a106c649c944008f4a3d31ec
|
6baa2f2159c190d8d1c6f883e03862af81b3d829 |
|
24-May-2011 |
Tor Norbye <tnorbye@google.com> |
Don't apply default attributes in a move/copy. DO NOT MERGE There is a method in the layout editor which fills in required default attributes like id, width and height, as well as some optional attributes like a default text attribute. This code was called unconditionally whenever a new child is added to a layout. However, this should only be done when a new widget is created, not during moves or copies from existing elements. Change-Id: I2b437ef609a168f1bb1b7698d3a954a4d2f5faa0
|
01ed60dd2b22c98bf05f52594308c0b7a5a9111a |
|
24-May-2011 |
Tor Norbye <tnorbye@google.com> |
Don't apply default attributes in a move/copy There is a method in the layout editor which fills in required default attributes like id, width and height, as well as some optional attributes like a default text attribute. This code was called unconditionally whenever a new child is added to a layout. However, this should only be done when a new widget is created, not during moves or copies from existing elements. Change-Id: Ic04dec746c70359eca38454bacfdcdb87891719f
|
9718ea331bfc609927b1ec2a2e7453579666fa4d |
|
13-May-2011 |
Tor Norbye <tnorbye@google.com> |
Custom View handling improvements 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 Conflicts: eclipse/plugins/com.android.ide.eclipse.adt/src/com/android/ide/eclipse/adt/internal/editors/layout/descriptors/LayoutDescriptors.java
|
ec22f92d53f4bb74313b91aa491acbfbbb6dc9ce |
|
13-May-2011 |
Tor Norbye <tnorbye@google.com> |
Custom View handling improvements 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
|
3a0de834ccd2b4f89462fcb2d075823597c347ab |
|
22-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Merge "Add code completion support for drawables, animations and colors" 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. (cherry picked from commit aaa917c9c5e6f974ca20b94adfd53d1bf01bb54e) Change-Id: Iddc2405c4802d43126d9b2172f86869de80bef10
|
aaa917c9c5e6f974ca20b94adfd53d1bf01bb54e |
|
22-Apr-2011 |
Tor Norbye <tnorbye@google.com> |
Add code completion support for drawables, animations and colors 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
|
dc8c93e4847780de24531711b7f3f22b2936b491 |
|
24-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Code completion in style definitions & other improvements 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
|
fafa79f3931bb8b396900e3a43ac4294195f83b4 |
|
15-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Add Quickfix and Quick Assistant for creating resources 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
|
bfe50d0630041bbc3e3b2b5182d18e139f2879bf |
|
15-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
XML code completion improvements 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
|
19e438f0504661707fc878a56e1c176b90e1f2f7 |
|
11-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Underline the error range for aapt errors 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
|
0757ce4af2764e4dd564acc0b1a013e910abc8da |
|
18-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
More refactoring work: Convert hierarchy, and change type A lot of work on the "Change Layout" refactoring to improve conversion to a Relative Layout. First, add a "Flatten Hierarchy" option which can take an entire hierarchy of layout widgets and flatten it down to a single top level RelativeLayout where the constraints attempt to reflect the original layout. (This isn't always possible, since some layout managers offer features not possible to express in RelativeLayout, such as a LinearLayout with multiple different weights) but it often works or is at least a good start. (This work is ongoing, but since my changeset is getting large I want to check in this snapshot since the functionality is better than what is in the trunk.) This changeset also adds a new refactoring: Change Widget Type. This can be applied to a selection of elements, and it will convert the widget type to the new target widget type. It will also remove any attributes that are not valid for the new layout. It also improves the wizards which display the possible target types. For Change Widget Type, it will first offer "related" widgets, so for an AnalogClock it will first offer Digital Clock, for a checkbox it will offer a checked text view and a radio button, etc. In addition, it will list Views and Layouts that it finds in any library jars (except for the builtin Android ones), and any custom view classes in the project. There is also now some preliminary support for refactoring unit tests. These tests must be run as Eclipse plugin tests, since they utilize the XML model (and the XML model cannot be mocked). The test infrastructure reads source XML files, applies the refactoring change list to them, and diffs the output with the known expected output (also stored as result XML files in the test project). Finally, there are a number of fixes and improvements to the shared refactoring code. Change-Id: I0974653e530dfb4feb625e0eef8257c29d50614b
|
8dc4366bbaad39d56e1c2ded4046c86a95a17666 |
|
14-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Refactoring: Wrap in Container, Change Layout Type, Extract This changeset adds refactoring support for 3 visual refactoring operations: (1) Wrap in Container. This can be invoked on one or more sibling views (or the root view) to add a new layout container into the hierarchy which "wraps" the views. The refactoring can also update the layout attributes (such as RelativeLayout attachments) such that they refer to the new container instead. If invoked on the root element, the namespace declarations are migrated from the old root to the new root. (2) Change Layout. This can be invoked on a layout view to change the type of layout. In addition to editing the XML type declaration, it also removes layout parameters that no longer apply, and depending on which layout you are converting from and converting to, it may attempt to perform some translation to preserve the layout characteristics. In particular, if you convert from a LinearLayout to a RelativeLayout, then it will use RelativeLayout params to emulate the old LinearLayout by attaching items below (for vertical layouts) or to the right of (for horizontal layout) the previous sibling, and if the baseline property was set on the LinearLayout it will also add baseline constraints on the RelativeLayout. (It also adds default ids on any elements that need it.) There is a LOT more we can do to support layout transformations; this is just a beginning. (3) Extract as Include. We already had this feature, but it performed its own XML document manipulation. This code has been rewritten to use the Eclipse refactoring support (which the other two refactorings are implemented to use as well), which among other things means that you get Preview support - you can press Preview from the refactoring dialog to see the edits before they are made. This rewrite is also necessary to support an upcoming feature: the ability to replace occurrences in other configuration-variations of this layout; for that we need to ability to do multi-file changes which the refactoring support is ideal for. Change-Id: I50b142645f14c29c798fc02df6df69bad5b9426c
|
eb526121bdb1bdda56100a27c05af1033cf4e378 |
|
08-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Make layout editor margins compress when necessary 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
|
1d8e530e396eea23ae63f23838da9b40b4469ec8 |
|
08-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Default the render target to Android 3.0 for newly opened layouts 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
|
a7da09b74d5f41667823ddf36c0cd7f145f54a2d |
|
01-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Add Layout Actions toolbar Add a new toolbar above the layout canvas (and to the right of the palette). This toolbar shows various layout-related actions on its left, and the canvas zoom controls on the right. The zoom controls have been moved from the configuration panel, which has also been reorganized a little with three of the dropdowns moved up to make more horizontal width and take the place of the old zoom controls. The toolbar items vary based on which layout is "active". The active layout is the parent layout of the selection, or the root layout in the canvas if there is no selection. Some examples: - In a LinearLayout, there are radio-button icons for switching between horizontal and vertical orientation, and for toggling baseline alignment - There are toggle buttons for toggling between wrap_content and match_parent (or fill_parent) for the layout_width and layout_height properties - There is a dropdown menu in LinearLayout and RelativeLayout which lets you set the layout_gravity to one of the dozen gravity settings - There is an action button which brings up a margin chooser dialog where you can configure the margin settings for the currently selected elements for layouts that support margins There will be additional actions here in the future. This changeset also adds a few new MenuAction subclasses and factories to make it possible to do ordered lists of choices. It also adds sorting keys to make it easier for parents and children to interleave their actions with simple sorting keys rather than having to append, prepend or merge their respective result lists. In a follow-up changeset I will replace the context menu code to use these, as well as attempt to make all actions stateless such that they can be cached and reapplied for different targets. Some misc cleanup. Change-Id: I6a87144fcfd1d359e5561829bd5d63c852f16970
|
6c9e1ff78b5d7613f4cff379373d69fda19812e6 |
|
29-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Add support for multiple hyperlink targets This changeset makes the Go To Declaration hyperlink resolver produce a list of possible jump targets. Therefore, if you for example point at @android:string/ok, you will get a popup listing all the various string.xml files that define a translation for this string. If there is a current configuration (which would be the case if you are pointing at a resource url from a layout file, but not from a Java file or a manifest file) then the declaration which best matches the configuration is listed first, followed by everything else in alphabetical order by the folder name. This uses the resource maps which the IDE is already maintaining for rendering, so it can compute the set of hyperlinks cheaply. In addition, the hyperlink resolver now goes to the direct declaration of the given resource. This definition can in turn reference another resource url. There is one exception to the instant resolution of files: ids. In layouts it's common to define ids in place (via @+id), and these are not available in the resource map. Therefore, if no id is found defined in a value folder, then the search is deferred until the link is actually clicked. The search will now search not just the base layout folder, but all layout folders, starting with the same folder as the link source, followed by all configuration-compatible folders, followed by all folders. Change-Id: I20fd4f5836e41e5a9839124b7be3a3230f5198f4
|
0ac475d29f793079783f501126239ed6ce8aa31d |
|
21-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Palette with previews, categories and view modes This changeset contains the following improvements to the palette: 1. Display modes. The palette now supports several different view modes, and you can switch these via the context menu. The modes are: a. Previews. This renders previews for all the views using the current SDK platform, theme, screen density, etc. b. Small Previews. This is like (a), but scaled down to 75% size. c. Tiny Previews. Like (a), but scaled down to 50% size. d. Text + Icon. This shows an icon and the name of the view; this is the same as what the palette has looked like before this changeset. e. Icons only. All the modes, except for the Text+Icon mode, will lay out the views in a row (with vertical centering) to fit as much as possible in the available space for that category. The view mode, along with other view flags described below, are preserved across IDE sessions. 2. An accordion view. The palette is now using an Accordion control, which means it by default will keep a single category open, and it will always ensure that ALL the category labels are visible in the current view without scrolling. Via the context menu you can turn off the auto-close of the previous category. The accordion view uses vertical scrollbars within each category content area, if necessary. The accordion view renders the category headers using open/close folder icons, a bold font, and a background gradient which varies between the normal and hovered states. 3. Categories. The category metadata is now used to organize the views into a handful of different categories. The categories can be enabled and disabled via the context menu. When you turn off categories, you get all the views in a single large list. 4. Alphabetical sorting. By default, the views are now sorted "naturally" (e.g. the metadata provided order, where important views are listed first). You can switch it to alphabetical order via the context menu, in which case the items are listed in alphabetical order, either within their individual categories, or if categories are turned off, the global view list. This changeset also adds a new SWT ImageControl. This is necessary to display the preview images, because the CLabel, which is usually used to display images in SWT, is hardcoded to hide the icon if there is not enough horizontal space to display the full label (even when it has no text label), so for wide preview images the images would simply disappear when the palette was resized. Change-Id: I1e1fe051947809206ef9f3a2dfa2fbeae0341107
|
80add2fcf31cf20bca96c6ad87841c6c87f2752b |
|
18-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Configure TabHosts on drop Add a dummy child to the TabHost on drop. Change-Id: I0f00dda449b81025c24933b6e1578b6b1a431272
|
54dbb36a117da8b4279bf64d684122b0afde849a |
|
12-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Warn user about compilation errors causing rendering failures If you have certain types of errors in your project, then rendering will fail with messages that may be confusing. This changeset attempts to identify some of these common scenarios and offer detailed explanations to guide the user in the right direction. Specifically: 1. If the project contains aapt errors (which means aapt did not run successfully), AND the rendering failed with an error related to resource lookup, then begin the render error message with an explanation in bold that this project contains resource errors that could explain the below rendering errors, and to investigate those resource errors first. 2. If the project contains javac errors, AND the rendering failed after the custom project class loader has been consulted, then display a message stating that compilation errors could have caused the failure and to investigate those errors first. 3. If a custom view is loaded, and it does not provide a 2- or 3- argument constructor (which takes an AttributeSet), emit a warning that XML attributes on the view will not work. In addition, this changeset cleans up a few other related things: - Tags are no longer displayed as part of the error message; these are intended for internal checking only (for example to identify resource errors from other errors) - The error display text can now show a vertical scrollbar if the text is longer than the available space. - The code which marks the project class loader as used is marked used as soon as it's asked to resolve a class name, rather than at the completion of a successful load, since we want to know about failing custom classes as well. Change-Id: Ib37a329eed44719ecf741b96ff96747ec4f92ad0
|
9003290cc259ee2a85ef952dcda779d4b500aa59 |
|
10-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Add "Play Animation" menu Adds a new dynamically populated context menu named "Play Animation", which contains 4 sections: - First, the most recently played animation name. This is initially empty, but once you've played an animation, the most recently one is listed there. - "Create...". This is a shortcut which opens the "New Android XML File" wizard, pre-configured to point at the current project and with the Animation category selected. - "Android Builtin >". This is a submenu (also lazily populated) which lists all the builtin Android framework animations alphabetically. - The animations in the current project, if any, listed alphabetically. Selecting any of the project or framework animation names will cause the animation to be played once. During the animation, selection and hover overlays are temporarily hidden. This is just a start; we should play/rewind/stop buttons, maybe a loop toggle button, etc somewhere on the screen when you've selected an aniation. We should also try to filter out animations (especially framework ones) that have no effect on the current selection. Finally, error messages need to be handled better since we are reusing the render session from the editor. Change-Id: If113b02d458972b5cc2cb253dd9e6c312b8302a9
|
db6bf7972148e38434bccc283464de9272a1977e |
|
07-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Replace Sdk.makeRelativeTo() IPath#makeRelativeTo(IPath) was not supported on Eclipse 3.4, so we had a local version of it in our sourcebase, as Sdk#makeRelativeTo(IPath,IPath). However, our version only works correctly for directories, not plain files, but I had been using it for files as well. Now that we no longer need to support Eclipse 3.4, remove our local version and use the builtin path conversion method. (Fixed some invalid javadoc too) Change-Id: I233875e1ecc758eb1ed333686b319b138eb47c4a
|
1f34a9b0c5cdd41dad23719898d5f71f3ee57394 |
|
05-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Improve the Outline contents 1. Make the outline use StyledStrings such that we can use different colors for different elements in the outline. Use the decorations color for the element type that follows the id. 2. For elements that define a "text" property, include the text (or a prefix of it if it is long) in the outline. Thus, for a Button you might see something like "Button01 - "Submit Order"). 3. For elements that define a "src" property, show the source. Therefore, for an ImageView you might see "ImageView - logo". 4. For <include> elements, show the name of the included layout. Change-Id: Ibd4c8339ea0e03c969ccaec1a67bc64436ed67af
|
a18a523fa3e21c78320fadd031716963b3a1c501 |
|
04-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Add "Extract As Include" refactoring Add an "Extract As Include" action to the context menu which lets you extract a set of selected views and move them into a separate layout file of their own, and insert an <include> reference to the new view in place. You can select multiple items as well (provided they are adjacent siblings) and in that case the newly extracted layout will use the <merge> tag as the root element. This changeset also adds a name validator for resource names, used both in the new-name entry field for extracted include layouts, as well as in the New XML File wizard. It enforces that the name (except for the .xml suffix) is a valid Java identifier name (since otherwise the R file will have compilation errors.) This changeset also extracts various inlined String constants like "xmlns", "android" (as used in namespace prefixes), "@id/" etc and replaces them with constants. Change-Id: I3eca8b6afd23f22ca9299ff22c614b4ffd3299bf
|
8386da5e451eec396d0e71576e7366a98017674f |
|
23-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Support for included and merged views We have support in the layout library for handling included views where the include tag is associated with the root elements rendered in that included view. However, there are various scenarios where this is not adequate: 1) including <merge> views (see issue 13288) 2) older layout libraries This changeset fixes the above scenarios, as well as an additional scenario (where rendering included content in an outer layout did not work properly if the included elements were not at the root level). It does this by moving the CanvasViewInfo construction into a set of factory methods which handle various different hierarchy types of ViewInfos. ViewInfos with null keys at the top are handled one way; ViewInfo subtrees that introduce null keys further down are handled another, and it attempts to match up elements in the UiViewElementNode hierarchy with ViewInfo objects. If it cannot match them one to one, it will create a single "bounding box" view containing all unmatched ViewInfos. This will for example produce a single box out of included <merge> views. This changeset also handles multiple includes. The "overlay mask" could earlier only handle a single include whereas the rewritten code can handle multiple "holes" in the mask by computing the set of subrectangles remaining after punching out the include holes. Change-Id: I163413c7fc301f25c4523b0ee03690f983a05322
|
f7eafda210e3eb3fbe8f1cb9c0bd61807f1a05c5 |
|
30-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Replace hand-written mocking classes with EasyMock calls This changeset removes the various hand-written mock implementations of key Eclipse interfaces (IProject, IFile, IFolder, etc) and replaces them with EasyMock proxy objects. This makes our codebase buildable on Eclipse 3.6+. (Also fix a couple of test warnings for abstract testcase classes which were missing tests) Change-Id: I70553ab95dc9386da1c7eed139d3ef587d929478
|
abb73f93a76b5bba7f179e313e6c4a174fdd796c |
|
14-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Remove some actions before milestone The Show Include facility doesn't work properly until we backport layoutlib to all the 2.x SDK layoutlibs. The Play Animation test isn't yet productized. Change-Id: Ib4cd0f0cff029fe23ffaca72a96561a0d748f86f
|
e11d7b12c1d5a34c8977b6330be81c28f65a12e3 |
|
10-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Add Java Hyperlink Support and XML improvements Adds Android-related hyperlinks to Java files. If you for example have this code in your Activity: setContentView(R.layout.main); and you control click on "main", this will now offer (in addition to the normal "Declaration" hyperlink) go to "XML Declaration"), which will then warp to the main.xml file. You can add in the second modifier key to directly jump to the Android resource and bypass the normal Java declaration (which would take you into the R file). The Android Java hyperlink works from R file field declarations too by the way. This now also works for id attributes defined inline, so if you for example jump to R.id.Button01, and this will open the first @+id/Button01 element found in the layout directory. You can also open non-XML references, such as @drawable/icon. This will run the Eclipse open command on the icon. The processing of XML regions is improved, so it will now only highlight say the value part of an XML attribute, or the name part or the element tag name part. Finally, the hyperlink resolvers can now jump into @android resource files (as found in the SDK data directory). Thus, you can warp into (say) @android:drawable/alert_dark_frame. Change-Id: I83fcd1ffb08590f7f587b90f5c64784fe8ce5f67
|
2a58932d3c4e2642cbdbfc161b4f7b884b3d7ea6 |
|
04-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Add a hyperlink resolved for Android XML files This changeset adds basic hyperlink handling to Android XML files (such as AndroidManifest.xml and layout xml files). It registers a hyperlink detector for our XML files, and the hyperlink detector looks up the XML model and finds the node and attributes under the cursor. If found. it then checks these attributes for a set of patterns that it can link to: * If it finds an <activity> element, it looks up the activity name and the package on the root element, and lets you jump to the activity. Ditto for services. * If it finds a @layout attribute value, it attempts to open the corresponding layout file in the res/ folder in the project. Ditto for other per-file resources like @drawable, etc. * If it finds a value resource, like @string, @dimen, etc, it will search through the various XML files in values/ and open up the corresponding XML declaration in the editor with the declaration selected. Note that the resolver does NOT use proper full resource resolution based on the SDK parsing that we have in use within the layout editor etc. That's the natural next step. Change-Id: I5880878fe67f26fb8d3b08b808c02baa1049f2c5
|
4517a1f5f4f9fd21b6a611d8a40ac8b81a7bb9c5 |
|
29-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Include View Support Add improved support for includes. You can now view and edit a layout within another containing layout. On a page with includes, you can double click to warp into the included layout, and it will be shown within the container layout (but with a semi-translucent mask to make it obvious that you are editing only the included content, not the container.) You can also right click on a view and choose "Show Included In", which is a pull-right which lists all the other layouts that are including this view. (If there are no such views, the menu item will be empty). In addition, this changeset adds code to detect if there are cycles in the includes, and if so adds a problem marker in the Problems view listing the offending chain of includes. This is all managed by a new "IncludeFinder" class, which listens for resource file edits (so it only kicks in when you save an XML file, not after each XML edit). It scans layout XML files for includes and maintains a map of file includes. This is done such that it can very quickly provide a list of all files that are including a given target file. This list is also persisted across IDE sessions via a project property. Also fixes outline-expansion to ensure that the outline always shows the top level children. Note: The include-relationships are based on the base layouts (the ones in layouts/, not in customized versions in layout-land, layout-port, etc.) Change-Id: I710560f03f7e214219669af8ffba91874d9881b9
|
6d7a354cc1ad968a2bd17cc4b8db5814490a0f1d |
|
19-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Show images during canvas drags When you drag in the canvas, show a drag image for the view being dragged. The drag image is using 30% translucency such that it does not obscure the drag feedback below it. We're grabbing the image data right out of the rendered scene and just copying out the rectangles for the bounds of each selected item. This has to take the canvas zoom into effect too. While in the zoom code I modified the Zoom In and Zoom Out buttons to only zoom by a factor of 20% rather than 100%. I cleaned up the Pair class slightly; in an earlier version of this fix I was using it to pass back two results from the rectangle painting function; I don't do that anymore but the Pair might as well be cleaned up. (By the way, as suggested in review #19035 I rewrote the FIXME comment related to resource lookup and put it in this CL rather than revising the other one.) Change-Id: Iabe6e29c4073252f5046e3c26b56f4e7674a3f3a
|
ccabacfacfcc90e1725f0342b2e6d273d0bc744e |
|
24-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Unit test fixes First, the AddonsListFetcherTest#testLoadSample_1 was failing on the Mac, because the source code contained non-ASCII unicode characters, and the encoding differs between Windows, Linux and Mac -- and on the Mac the characters were garbage (not the intended Japanese characters). Fixed by using unicode escape sequences to define the expected output instead. Second, rename the AbstractLayoutTest to LayoutTestBase; the test runner (for plugins, not unit tests) was assuming this was a test case (even though it's an abstract class!) so it was emitting a warning about the class containing no test cases. This is simply a base class for all the individual layout tests defining a bunch of useful inherited shared behavior, so rename to avoid the warning. Change-Id: I6e29316c5644db35051218aef8b99ac41ab0cda4
|
99fd7eee15c89fd45b884842c44371326f851930 |
|
22-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Open included layout on double click On double click, if the clicked area originates from an <include>'ed XML file, open the included layout in the editor. Also opens files in the @android: namespace if available, for example if you inculde @android:layout/select_dialog_multichoice. Change-Id: I215c411257717f7b97e7b0ee1d5498c318cdb04d
|
a2d7874ed23bfc2fa7665cc84901e0f4781b4e51 |
|
16-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Add per-view custom initialization logic This changeset adds support for adding custom-logic to initialize views, both to add children and default attributes and to customize layout attributes when added to a new parent. First, there is a new "onCreate" hook which is called to notify a view rule that an instance of its corresponding view has been created. This lets the ViewRule perform custom initialization of the object. The ViewRule is told what type of insertion occurred, such that it can distinguish between a newly created view, a view that is the result of a copy/paste, and a view that is part of a move operation. The changeset adds a number of new ViewRules which take advantage of this: - A TabHost rule creates the various skeleton children that are required, such as a TabWidget child with id @android:id/tabs and a FrameLayout child with id @android:id/tabcontent - A DialerFilter rule creates the mandatory EditText children ("hint" and "primary") - The HorizontalScrollView rule creates a horizontal LinearLayout child - The ImageButton and ImageViewButtons initialize the "src" attribute to a sample image - The MapViewRule initializes the apiKey attribute In addition, views are also notified when a new view is added as a child, such that they can perform additional customizations, in the form of an "onInsert" event. The most important application of this is LinearLayoutRule, which uses this to set reasonable defaults for the layout_width and layout_height parameters. It uses metadata (which is currently built into ADT but would ideally migrate into our XML config files) to determine whether a given child prefers to grow horizontally, grow vertically, both, or neither, depending on the surrounding parent context. For example, an EditText will default to filling the parent width if it is in a vertical LinearLayout, but it will not grow vertically in a horizontal linear layout. And so on. Various other rules also use the onInsert event to tweak children attributes. A ScrollView will for example always initialize its single child to match parent. Views can now also add plain menu items into the context menu, and the TableViewRule adds one such action: "Add Row", which appends a new row into the table. The Palette Preview code also invokes these creation hooks, such that if you for example drag a DialerFilter it can properly render since the mandatory children are created up front. This required various changes to the preview code to be able to handle XML edits by the rules. Finally, this changeset includes various other misc changes that I performed at the same time: - Removed SWT dependency from the ViewRule classes (SWT Rectangle use in Rect) - Fixed AbsoluteLayout unit test (issue 3203560) - Fixed positioning of the preview outline in LinearLayout when only one of the dimensions are clipped due to a smaller target layout Change-Id: I5956fe4e7a31a20b8dd2f9d9b0c1f90e2f75d68a
|
5d08915fe9014124566a2cdd7c1aa4219e01acea |
|
15-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Add drop shadow to dragged items Add in a drop shadow to items dragged from the palette. The primary reason we need this is that some views (in some themes) only render light content on top of a transparent background, which makes them nearly impossible to see on a gray background (e.g. over the palette, when you initiate the drag). The drop shadow helps add contrast. It also makes the drag look better since it helps the drag preview image stand out from the background and visually appear to be lifted on top of it. Since we're doing more image processing now, I moved the existing non-SWT image manipulation methods into a separate ImageUtils class. This changeset also fixes the way we pick the color to crop out when using older layout libraries (without transparency support). We now pick a pixel closer to the bounds of the rendered view such that we for example can handle themes like the dialog theme. Change-Id: Ifcbb840ef715bf26a9609f6996a4f136de5ca754
|
ab784698270a3b49d0f082715c8b4bb9dff04d67 |
|
11-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Preview items on palette drags This checkin renders previews of Android views as you drag them from the palette, using the current theme settings you have for the associated editor. If you are using version 5 or later of the layout library, you get full alpha-blending on the rendered views (so for example in an analog clock you see right through it), and on older version it simply crops out the edge color. The preview image is semi-translucent, and the image is centered under the mouse pointer. The drag feedback operations all relate to the top left corner of the dragged item, so they are passed in the mouse cursor minus the delta to the top left corner of the image. The size of the preview is also used to provide bounds for the drag feedback, such that we can show a preview rectangle rather than just the insert point over layouts that support drop feedback. Some views can't be rendered (e.g. QuickContactBadge), and some views don't have any pixels painted (e.g. all the empty layouts), and in that case we fall back to showing the palette item itself (the icon and label) as you're dragging. There's also a new utility class for SWT common utilities, like image conversion. Change-Id: I315c2dd733317bbada8dae89f57280ced2d7bb51
|
23258d5ae21d164049eef14eebb2ef28a43a7b40 |
|
08-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Add transient visibility mode for empty containers When you add a new container, such as a LinearLayout, it is usually invisible. The reason for this is that an empty layout has 0 width and 0 height. There are two existing features in the layout editor to deal with this: (1) Outline mode, which renders rectangles around all views, and (2) Padding mode, which adds 10 pixels of padding to all views. In combination, these two modes will create a rectangle for empty layouts making them visible and user-manipulatable -- you can for example select or drop into them. This changeset attempts to make dealing with these types of containers easier and more discoverable. It adds a new temporary mode where empty containers (and only empty containers) are automatically padded and have their outlines painted. And more importantly, this is only done in some limited scenarios: When you drag into, or drag within, the layout canvas. As soon as you finish the drag, empty containers disappear again. Unlike padding mode, we don't enlarge the design surface itself, since this mode comes and goes easily and frequently. In addition to this, there is special handling for selection. If you select a zero-sized element (which for example is automatically done when you drop a new layout, and which can also be done by clicking in the outline), then the element is also revealed similar to the show-empty mode, but in this case only the selected item and not any other invisible containers are shown. Change-Id: Ibf3ec6a080a50a8f0f55919c3d3e6c4d2890468d
|
93b86c1f3185c8df21e2a45a31e4cd9ce567cef0 |
|
09-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Fix icon painting transparency for the palette The icons shown in the palette do not have transparency applied to them, which means that you end up with white squares on a white background. This looks okay in the outline view where the icons are shown on a white background, but it does not look good in the palette where they are on a gray background. This changeset fixes the icon generation a bit such that it records a transparent pixel for these icons. It's not an ideal solution since we only have on/off transparency, not an alpha channel, which means that we can't have a smoothly anti-aliased edge of the circles regardless of the background. Luckily, a light color seems to work fine for both cases. While I was at it I also adjusted the font positioning slightly on the Mac platform for some letters that needed it. Change-Id: Idf5a4f6709096935122bfe05cfecffc63e74a863
|
3bd8ee3a9447003224d34bf19328209d6b14d9ad |
|
05-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Add autoformatting of XML, and improved manual formatting This changeset improves the formatting of XML edited by the layout editor in two ways: (1) It improves the way the layout editor handles insertion and deletion into the XML document; it looks up the indentation of the sibling and parent elements and attempts to correctly indent new elements based on the existing surrounding formatting, and it also attempts to clean things up correctly on element deletion. (2) It adds a new user option for turning on automatic XML formatting. When this is on, it will invoke the Eclipse XML formatter on portions of the XML after each edit. This will ensure that the document adheres to the user's preferred formatting settings (maximum line width, tabs versus spaces, line breaks before attributes, etc. Change-Id: I74f9a4240a8c5ca4295c01f3b55751ef10b1c1b0
|
f0fb7ef1ced5a79d02d3044540e4c24063f4699f |
|
05-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Mark internal strings as NON-NLS in rule classes Mark internal strings as NON-NLS in rule classes. This code was initially written in Groovy which is why it didn't have NON-NLS markers. Change-Id: I74517771271e54f165332543092a9d29fc2bc52a
|
83dba505e22985fd2f9414e7c6ef14ce29d31713 |
|
26-Oct-2010 |
Tor Norbye <tnorbye@google.com> |
Add gesture support, marquee selection, and refactoring This checkin adds support for gestures and overlays. Gestures are sessions of mouse/keyboard activity, and this is documented in the javadoc for the new Gesture class. Overlays are units of graphics, and these are documented in the Overlay javadoc. The gesture architecture lets us isolate the logic for each different type of operation (marquee, resize, move, etC), and with associated overlays we don't attempt to for example paint drag feedback during a resize operation, etc. The checkin also adds marquee selection (as a second gesture, in addition to the existing drag & drop based move gesture), along with some associated changes in how the root view is treated. As part of isolating the mouse handling and painting related to gestures, painting etc., I also refactored the code quite a bit. LayoutCanvas which used to be a large class has been split into a number of new classes, one for each area of responsibility: - The mouse listener and drag & drop code has been moved into a GestureManager. (A lot of the drop handling code also came from the CanvasDropListener class.) - Code related to maintaining the set of rendered views, and performing searches in the views, has been moved into a ViewHierarchy class. - Code related to selection has been moved into a SelectionManager. - Various individual painting pieces (outline, hover, etc) have been moved into individual Overlay classes such as OutlineOverlay, HoverOverlay, SelectionOverlay, etc. This also moved associated resource allocation and cleanup into the overlays. - New coordinate classes, ControlPoint and LayoutPoint, are used instead of ints and plain Points to make it really clear which methods require coordinates in the layout (such as the ViewHieararchy search methods) and which ones require coordinates in the canvas control (such as paint methods). There are factory methods to automatically construct the right kind of coordinate from different types of mouse events, as well as methods to convert between the two. I also tweaked the visual appearance of selection a bit more, and some other misc cleanup. Change-Id: I666aabdcd36720bebe406b68237e8966d985fb8f
|
0433222f1351b565d78952e1bb8809528c0e352a |
|
27-Oct-2010 |
Tor Norbye <tnorbye@google.com> |
Add dictionary to codebase Eclipse has the ability to spellcheck comments, and it ships with an English dictionary. However, many valid terms in our codebase is not in this dictionary. This checkin adds a dictionary file which contains many of the valid spelling words used in our codebase. (Unfortunately, Eclipse does not support "project dictionaries" like some other IDEs where individual user dictionaries are merged with shared project dictionaries. However, this new dictionary should be useful for developers who use a dedicated workspace for Android development.) This changeset also fixes some typos. Change-Id: Ied6647f6cb550460c0087498f8c94fa6624e3b4e
|