630d28af94d1d7f5f791e49d8504a16b7f4559a4 |
|
19-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Improve last editor mode handling We recently added the ability for the IDE to remember whether you last edited an XML file in text mode or in graphical mode (see issue 31340). However, this was tracked with a single boolean flag, which meant that it was an "all or nothing" flag. However, you may want to always edit string resource files with the XML editor, but you want to always use the graphical editor for the manifest file. In this changeset, the state is kept in a bitmask instead, which allows us to track the broad editor types separately. With this, new editors are opened according to the last mode you used for that type of editor. (Note that it tracks "categories" of editors, not individual resource types, so for example the editor for color resources and the editor for state list drawables share the same last mode as the string resource editor. This is because these editors share roughly the same graphical editing capabilities.) (The CL also contains some minor code cleanup.) Change-Id: I4624dffa2349230684c0558a33081adda8d799b2
|
12d4581faa6438941e65a9dc83213be34c6ca970 |
|
13-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Constants refactoring. This changeset moves most constants into the SdkConstants class, and gets rid of AndroidConstants and LintConstants. It also migrates all non-ADT specific constants from AdtConstants into SdkConstants. It furthermore moves various other constants (such as those in XmlUtils and ValuesDescriptors) into the constants class. It also fixes the modifier order to be the canonical modifier order (JLS 8.x). Finally, it removes redundancy and combines various constant aliases such that we don't have both NAME_ATTR and ATTR_NAME pointing to "name", etc. Change-Id: Ifd1755016f62ce2dd80e5c76130d6de4b0e32161
|
81cefe2a26dd6db8a878e30874d12cdcbff0e83b |
|
11-Aug-2012 |
Xavier Ducrohet <xav@android.com> |
More refactoring. Move stuff out of sdklib into common and ide_common. Remove androidprefs and move the one class into common. Change-Id: I71d126a13cf2ba413692e29616f4968a37d7b33a
|
85e4a1a9dd133abb879ec211ce8dd385004edf22 |
|
08-Aug-2012 |
Xavier Ducrohet <xav@android.com> |
Refactor common.jar Move resources and com.android.util.Pair into layoutlib_api where they belong since layoutlib depends on them and we need to control the API. Made a copy of Pair to stay in common.jar but moved it to com.android.utils.Pair (the one in com.android.util.Pair is marked as deprecated to prevent usage where applicable). Also moved XmlUtil and PositionXmlParser to com.android.utils to match Pair. Change-Id: I21d7057d3f2ce604f86a3bb1fa3c130948c93b89
|
2a65086ed8cc1fdace4f98e0931893e5cdce171d |
|
27-Jul-2012 |
Tor Norbye <tnorbye@google.com> |
26501: Handle padding between image and text The visual refactoring for converting a LinearLayout with a <TextView> and an <ImageView> adjacent into a single <TextView> using a compound drawable, needed to properly handle spacing between the two widgets. This changeset updates it to convert margins between the views into a single drawablePadding attribute. Change-Id: Idb077e3324c279d41fdc0baa68008fe862d8181a
|
1d3020c83415d3d60f3f4c024ae2a21e0c8b4a13 |
|
04-Apr-2012 |
Tor Norbye <tnorbye@google.com> |
Add isSame on IDragElement, and sort primary to front Change-Id: I7121b5f0e3714fec705387603f641bc14ed0ab3e
|
7e4b8e9d595e45baa9d87cdb8282f02759e73abc |
|
30-May-2012 |
Tor Norbye <tnorbye@google.com> |
Fix nullness annotations Eclipse 4.2 includes analysis support for @Nullable and @NonNull annotations. However, it requires these annotations to be *repeated* on every single method implementing or overriding a superclass or interface method (!). This changeset basically applies the quickfixes to inline these annotations. It also changes the retention of our nullness annotations from source to class, since without this Eclipse believes that a @NonNull annotation downstream is a redefinition of a @Nullable annotation. Finally, the null analysis revealed a dozen or so places where the nullness annotation was either wrong, or some null checking on parameters or return values needed to be done. Change-Id: I43b4e56e2d025a8a4c92a8873f55c13cdbc4c1cb
|
a881b0b34678ad76c9f5eba62fac7a00a22ac606 |
|
20-May-2012 |
Tor Norbye <tnorbye@google.com> |
Move XML code to the common library The ManifestMerger library needs to look up the prefix to use for the Android namespace, and the Document.lookupPrefix method is not implemented by the Eclipse DOM implementation (which throws an exception). However, we have an implementation of this in the ADT plugin. This changeset creates a new XmlUtils class in the common/ library (which is accessible by both ADT and the manifest merger, and the anttasks where the manifest merger is used), and moves the namespace prefix lookup code in there. It also moves the XML escape methods into that class. It also adds a new method to the ManifestMerger for merging directly from documents (rather than files), and makes sure that all the merging code goes via the prefix utility method rather than calling the document.lookupPrefix method. Finally, it moves the various string constants associated with XML namespaces into the single XmlUtils class, since these were spread across several different classes before (and many of them are needed in the XmlUtils class). The vast majority of the diffs in this changeset are related to simple import statement changes to reflect the new locations of these constants. Change-Id: Ib8f3d0e5c89e47e61ea509a23925af7b6580abee
|
ab36f4e7488358dea4ab6b54ee2b7bef3da0232b |
|
21-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Update SDK codebase to JDK 6 This changeset makes the SDK codebase compile with source=1.6 (which means it also requires JDK 6). This means that methods implementing an interface requires @Override's. It also means we can start using APIs like the ArrayDeque class and methods like String#isEmpty(). This changeset looks big but the change is trivial: it's basically adding @Override in all the places that need it, along with some other automatic Eclipse cleanup in certain files (such as reordering imports where they were incorrectly ordered (because older versions of Eclipse didn't always handle inner classes right)), as well as cleaning up trailing whitespace and removing some $NON-NLS-1$ markers on lines where there aren't any string literals anymore. This changeset also sets the source and target JDK level to 6 in the Eclipse compiler .settings file, and synchronizes this file to all the other Eclipse SDK projects. Change-Id: I6a9585aa44c3dee9a5c00739ab22fbdbcb9f8275
|
bf9db3ba5053c8f22a07ee748b2cb41d374d8642 |
|
24-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Use GridLayout state to determine exact row and column boundaries This changeset updates the GridLayout support to consider the state of a rendered GridLayout when deciding where the rows and columns are. This information is already available in the GridLayout object, so if one is provided use that data rather than inferring it from the bounds of the views in each row and column. This required changing the view rules API a bit to pass the view objects in to the key entry points (drawing selection, drag & drop and resize). Change-Id: If8484f7f7181c65d0a2fdf629ffd515edd05448b
|
e287bc8580e19d72a911615475b353790cf000eb |
|
16-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Layout editor property menu improvements This changeset adds two forms of view attribute metadata: * First, it records the most commonly used attributes for each view. This was determined by gathering statistics on as many layout files as I could find and then picking those that are used 10% or more. * Second, it records in the attribute metadata which View defines a given attribute. The context menu uses the above information to present the available attributes in several ways: * In the top level menu, where we had "Edit ID", and if applicable "Edit Text", it now lists the top attributes instead. For example, for a RatingBar the first handful of menu options are "Edit ID...", "Edit NumStars...", "Edit StepSize...", "Edit Style..." and "IsIndicator" (a boolean pull-right menu). Incidentally this automatically handles some cases which were manually handled before, so the code in LinearLayoutRule to add an "Orientation" menu is no longer needed; it's just one of the two common attributes handled by the new attribute list. * The "Properties" menu is now called "Other Properties", and instead of showing all properties, it has a new level of menus: * "Recent". This is initially empty, but as you edit other attributes, it gets populated (in most recently used order, kept up to date) with recently edited properties. * One submenu for each defining View super class listing exactly the attributes defined by that view. This is useful for browsing and editing related attributes. If you are looking at a textual view like a Button for example, you can look at the "TextView" menu to find all the text related options (TextColor, TextSize, etc). These menus are listed from the nearest to the further superclass, so for example if you right click on a CalendarView you'll see these menus: Recent > ---------------------------- Defined by CalendarView > Inherited from FrameLayout > Inherited from ViewGroup > Inherited from View > ---------------------------- Layout Parameters > ---------------------------- All By Name > * As you can see from the above, there are two more menus below the inherited menu items. "Layout Parameters" lists all the layout parameters available for the selected nodes (which is defined not by the view itself but the view that it is contained within). And finally there is "All By Name", which is a complete menu containing all available attributes for the view (and this is what the Properties menu used to contain). * The code which computes a display name from an attribute was also tweaked to capitalize not just the first letter but any first word letter, so for example when you look at the possible values for Gravity you now see "Clip Vertical" instead of "Clip vertical". * The edit property dialog for the properties menus now uses @string or @style resource choosers for the text, hint and style attributes (used to just be a plain text box.) Change-Id: I3b30d48b85fd13f0190c760756bf383a47b3f4a5
|
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
|
654dc86699080b7c7b9931ad35f823c848eb2e9c |
|
14-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Add new InsertType for widget moves within the same layout For some layouts, such as LinearLayout, when you drag widgets into the layout, we automatically adjust the widths and heights of some widgets, such as text fields (to make them fill the full width in a vertical linear layout, and so on). However, this was also done when dragging a widget from one place to another within that same layout. In that case, we should leave the dimensions and weights alone, since the user may have deliberately changed these. This requires splitting the InsertType.MOVE into two, since we still want to apply default sizing when you move a widget from a different layout into this one. The InsertTypes are now MOVE_INTO and MOVE_WITHIN, and we only apply default size styling if we are not moving within the same layout. Change-Id: I73ace89aff8111417bd6635e13397e7f027bab0a
|
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
|
8f6e2fc89af2a75e05608d9ee1c648171ea47d83 |
|
11-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Add resize feedback tooltip This changeset adds a "tooltip" during resize operations close to the mouse cursor which displays feedback about the current resize dimensions. The feedback window is similar in appearance to a tooltip, but unlike SWT tooltips it moves with the cursor and updates the text dynamically, and appears immediately rather than being tied to mouse motion timeouts. It is also partially translucent and uses a slightly smaller font. Change-Id: I6b663510f078f325d2f7b168c887aeff14de31b8
|
0554235850447278b26b2cc622bd1c59b4e81038 |
|
08-Jul-2011 |
Tor Norbye <tnorbye@google.com> |
Fix locale handling of linear layout weights Fix 18298: ADT r12 layout editor uses locale specific decimal separator leading to unparsable XML Change-Id: Ideae319e41f8a7e34075065c63247d50cdf830c5
|
8fce2f820c15938e973238e553d8ad493eab6d7c |
|
14-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Add two more layout actions for linear layouts Add two more actions: (1) Clear All Weights: This removes all the layout weights in a layout, and converts and 0-sized views to wrap_content. (2) Assign All Weight: This adds all the weight in the layout to the selected view(s) and removes it from the remaining views. Change-Id: Id2a27299d99f77ef4056b7e1745373d52a9331f7
|
fdde9dd8b616e50f2db0fe9ec872718b143339c0 |
|
14-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
When distributing linear layout weights, also set size to 0dp. DO NOT MERGE When you use the layout actions bar "Distribute Weights" in a LinearLayout, in addition to setting all the weights to the same nonzero value, also set the size (the height for a vertical linear layout and the width for a horizontal one) to 0dp, to ensure that the widgets are all given the same total size rather than sharing the remaining space evenly. In addition, when adding new widgets to a LinearLayout, see if all elements in the linear layout already have nonzero and equal weights, and if so duplicate this weight value on the new widget as well, and similarly also duplicate 0dp/0dip/0px if used. Change-Id: I78d1c5af05a8b8b54e4d1eb0d426ce592bc1fc69
|
762c68b0eeb2e58e6d1bf591732479a62d8ac035 |
|
14-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
When distributing linear layout weights, also set size to 0dp When you use the layout actions bar "Distribute Weights" in a LinearLayout, in addition to setting all the weights to the same nonzero value, also set the size (the height for a vertical linear layout and the width for a horizontal one) to 0dp, to ensure that the widgets are all given the same total size rather than sharing the remaining space evenly. In addition, when adding new widgets to a LinearLayout, see if all elements in the linear layout already have nonzero and equal weights, and if so duplicate this weight value on the new widget as well, and similarly also duplicate 0dp/0dip/0px if used. Change-Id: Iac5284a866b19b27e91666dc62278c63b8dde2bb
|
42b2f34604a3f8e8ac191831d8f01a0498760d38 |
|
09-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Fix various warnings I ran the latest version of findbugs on our codebase and fixed some (not all!) of the warnings. I also ran with Eclipse 3.7 RC3 and updated our compiler warning settings for the new warnings that are available. I also fixed some DOS line endings in some files (formatted with CRLF instead of LF). Change-Id: I9a9d34a9b60f2cb609245793815d96a4587007b0
|
628f0f8dcdfaad793a97690a1479ba0f22d8b0ee |
|
06-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Guidelines for match_parent, and linear layout weight fixes First, add guidelines to allow snapping to "match_parent" (or fill_parent, depending on the API level). Second, fix the linear layout resizing scheme to handle corner cases a bit better (corner cases such as resizing to a smaller size than the wrap_content bounds, or resizing inside a layout that is "full"). Also split up the resizing code into a compute-method and an apply-method such that we can display feedback for the current weight during the resizing operation. Change-Id: Idd2917230870d26f94473dabc1a2a6becc3ba738
|
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
|
c6a4984b10644bc0cb3a02bdda423b2a836234f0 |
|
18-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Make edit texts grow in horizontal LinearLayouts using weights If you drop a text field in a vertical linear layout, then the *width* of the text field is automatically set to fill. This uses metadata to check what the fill preference is of each dropped view. This changeset extends this scheme to also grow text fields in a horizontal linear layout. However, instead of using fill_parent on the layout_width, this uses a layout_weight instead. This means that the text field will fill, but it will not push subsequent children out of the way the way a fill_parent would. This changeset also changes the default orientation of a LinearLayout that is created in new XML files. (I looked around and noticed most layouts that have a LinearLayout at the root will use a vertical LinearLayout.) Change-Id: I52eec4841e4bac076da655c603235547cfd46b73
|
523c97de99580f005611d982df0459324267cf1b |
|
08-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Layout Actions bar fixes This changeset fixes a couple of layout actions bar issues: (1) Refresh the actions bar after running one of the layout actions. This for example fixes the issue that if you click to toggle the layout orientation then the baseline button will appear for horizontal layouts. (2) Fix an issue with the lazy-initialization of dropdown menus; they weren't actually initialized lazily because the code to determine whether a choice list should be a dropdown or a radio group would cause initialization. (3) Fix layout gravity on RelativeLayouts; it was reading/writing the attribute "layout_gravity" instead of "gravity". Change-Id: Ic41158257b3938a2e6daa8714dcd15d6bf21fa2f
|
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
|
a5d2bf173d15b74a6bcf57220c4e73b971bd09ab |
|
17-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Rewrite Outline drag & drop handler Rewrite the drag source and drop target listeners for the Outline. The drop target listener now uses the SWT Tree support for drag & drop (such that you for example get drop position feedback lines between siblings). You can now drag items within the outline to do precise reordering, as well as target particular positions during drops, either within the outline or from the canvas or the palette. This changeset also fixes a number of other issues I ran into at the same time: - Fix keyboard shortcuts such that they map to the same context as the canvas (e.g. when you activate the outline it shows the same undo context as if you click in the associated canvas) - Fix a bug with context menu code when none of the options are selected in the XML - Fix selection dispatch. If you had two side by side canvases, selecting items in the Outline would show highlights in both canvases; it now only causes selection syncing with the associated canvas. Change-Id: I00c3c38fabf3711c826a3bc527356cbc77ad4a7e
|
fe3eebe57ba2925642cc1b257cb03ba617d298af |
|
09-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Issue 13051: Use match_parent or fill_parent based on API level Fixes issue 13051: New layout editor always insert "match_parent", even on older platform. View rules can now look up the API level of the current project, and based on that choose to use match_parent or fill_parent when they need to manipulate the layout attributes. Change-Id: I861e1f7f7409c40c05b1472268f120806667025c
|
dc040487da0fed1b5f366c5435bdff3638bc37b6 |
|
30-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Rename some layout editor classes This changeset contains only renaming of some classes (and a couple of >100 column adjustments), no semantic changes. The name changes are: BaseView => BaseViewRule BaseLayout => BaseLayoutRule ScaleInfo => CanvasTransform CanvasSelection => SelectionItem PropertySheetPage2 => PropertySheetPage OutlinePage2 => OutlinePage Change-Id: I14d8c711b12154f4fcb2169129fd553e31fdab84
|
bfcbad18934be1f51ae03d4b6255cfe2d7239aaf |
|
24-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Extract layout constants into a separate constants class Combine the constants in BaseView and a LayoutConstants class over in the internal packages into a new LayoutConstants class, and reference these constants elsewhere (statically imported). This was suggested by in the feedback to review #18971. Change-Id: I40b76f8f6045c34a98f7a2363f96d2942360d1f3
|
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
|
b8235512174daabfc899ff71b5ffd9241556d305 |
|
16-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Improvements to LinearLayout feedback When you have a small and empty linear layout, and you drag something larger (such as a button) into it, the drop feedback is a bit confusing: The drop feedback rectangle is larger than the linear layout, so the bounds are outside the layout. This changeset addresses this by forcing the bounds of the drop preview to be at most the dimensions of the LinearLayout itself. Second, the fix I applied last week to show the last insert position, did not work in all cases - in particular when the drag originates outside the canvas itself. To determine if we are inserting at the last position, look at the number of target node children, rather than the number of potential insert positions, since in some cases the number of insert positions will be smaller than the number of children. Finally, there was a theoretical bug that if one of the dragged elements did not non-zero bounds, then the insert position would be wrong. This is also fixed by this changeset. Change-Id: Ia30e99f7a3aa45b8091855b69aaef86ec3699405
|
48eb12393a8bafb52d314fea053ac0cdfa200946 |
|
12-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
LinearLayout guide fixes When we have bounds for the dragged items, we show a preview rectangle where the item will appear after the drop. We show this rectangle midway between the two siblings that share the insert position. However, when you are inserting *after* the last item in the LinearLayout, there is no reason to show the item midway, since at this point nothing below the insert position needs to be shifted down. This checkin changes this such that for the last insert position, we show the rectangle fully below the insert line (or to the right of it in case of a horizontal layout). This changeset also fixes a bug where the last (available, not active) dropzone would not be shown on a palette drag. Change-Id: If449b43582e072c9e0ad6d7741afbe8e845e8df9
|
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
|
2be70bde5a6dcd6447c32ef55866020be372f96c |
|
18-Oct-2010 |
Tor Norbye <tnorbye@google.com> |
Port layout rules to Java We had a number of layout implementations in the tool written in Groovy; these were hard to deal with because of lack of good tool support (debugging didn't work, refactoring didn't work, code completion didn't (always) work, go to declaration didn't work, semantic checks like unused code didn't work, etc. etc.) Since these layout helpers are only getting larger, replace them by equivalent Java code to make development easier. This checkin also moves the API classes formerly used by Groovy scripts into a new package (next to the Java layout rules) under com.android.ide.common (api and layout) since this code isn't Eclipse specific and could be used by other IDE vendors. These interfaces were left identical (only the package statements and directory location changed), with two exceptions: I added a new method called "in" to IAttributeInfo.java, and I added a parameter to IViewRule's onInitialize method. The Groovy code was kept as close to the original as possible; I copied in the Groovy code, and then replaced the Groovy-specific constructs (closure-iteration on collections, literal map syntax, etc) with equivalent Java code. The only tricky part was ensuring that Groovy's handling of the == and != operators were translated into .equals calls. Change-Id: Idf7660ddea3766eac0a4a65ce6524d3f5119f7b2
|