aboutsummaryrefslogtreecommitdiffstats
path: root/eclipse/plugins/com.android.ide.eclipse.adt/gscripts
Commit message (Collapse)AuthorAgeFilesLines
* Port layout rules to JavaTor Norbye2010-10-2215-2234/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix bug in LinearLayout handling of last linesTor Norbye2010-10-181-1/+1
| | | | | | | | | This fixes a bug where the insert-line for the last position is not always *drawn* (the suggestion was there and the feedback rectangle would snap to it, but the dashed line was not painted because the code to suppress self-dragging was interfering.) Change-Id: I601d2f747357d42b7a797a1ed30b723830d03520
* Merge "Fix various bugs related to linear layout handling"Tor Norbye2010-10-151-35/+54
|\
| * Fix various bugs related to linear layout handlingTor Norbye2010-10-141-35/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset fixes the following issues with LinearLayout: * Correctly position the last insert position in the linear layout when the layout has children. * When you drag a widget which is already in this LinearLayout, don't show insert positions before and after this element, and show a match position exactly where it already is. * Show the best-matching lines not only when you don't have bounds (which it was already doing) but also in conjunction with the bounds outlines. When the dragged bounds are much larger than the widgets around the drop position, it was a bit hard to figure out where exactly the proposed drop position is, and this change makes it a lot clearer. * Fix positioning of the drop rectangle. Before this change we were positioning the drop rectangle using its existing deltaX,deltaY in its old parent; this does not work well both in multi-document cases as well as cases where you are dragging from one layout to another. We are now simply positioning it at delta=0 in the new layout; the next enhancement here would be to consider the layoutGravity. Change-Id: I1c71c3c48a4c104a5cde7382fb1f9a21e57122bc
* | Merge "Prevent layout interaction on certain layouts"Tor Norbye2010-10-157-0/+189
|\ \
| * | Prevent layout interaction on certain layoutsTor Norbye2010-10-157-0/+189
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Some layouts, like ZoomControls, extend another layout class (in this case, LinearLayout), presumably for implementation convenience, but the ZoomControl isn't intended to be used as a generic LinearLayout where you want to drop new widgets in between its existing children, where you want to change the orientation, etc. Therefore, this changeset adds a new layout rule, IgnoredLayoutRule, which various new widget-specific rules inherit from to prevent default layout handling from kicking in. Change-Id: Ia1323866d62859125692207159b9aa855cdf21c1
* | Hide anchor lines and tweak text positioningTor Norbye2010-10-141-2/+4
|/ | | | | | | | | | | | Temporarily hide the anchor lines (the lines from each selected element to its parent's bounds edges) until we can find a way to make it clearer what these mean. Also tweak the pixel positioning of the selection label text to account for the padding around the textbox mask since it was partially overlapping the selection stroke. Change-Id: Iaa4c7139d4d56288b78a104647d5cbb5752f7888
* Fix Orientation context menu for LinearLayout.Tor Norbye2010-10-121-1/+1
| | | | | | | | | If you open a LinearLayout where the orientation has not been specified in XML, then the context menu will say that the orientation is vertical, but visually the layout is actually horizontal. (The default value for LinearLayout is documented to be horizontal.) Change-Id: Id16797d9226b19eb53c2b59249844e2406b049e4
* Fix drag and drop handler to handle reentryTor Norbye2010-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | If you drag from the palette over a linear layout view, you get drop feedback. However, if you drag outside the linear layout and then back in, you often don't get any more feedback. This happens pretty easily with nested layouts. The problem is that the feedback object is initialized and reset in onDropEnter, but the actual guideline computation happens in onDropMove (since only drop move is handed the mouse coordinates). The bug happens because when you leave and return to the drop zone, the feedback object is reset, and then the drop feedback is painted - all before the onDropMove code has been called again. The fix is simple: On drop enter, also call onDropMove immediately such that the layout helpers are given a chance to initialize themselves with the entry mouse position, before they are consulted for drop feedback data. This changeset also contains a fix for LinearLayouts: When there are no children, place the guideline at x=0 or y=0 (depending on whether the layout is horizontal or vertical). Without this fix, the line is placed in the center of the view, which is misleading since that is not where the view will be placed upon drop. Change-Id: Ib5e17a2d9d3818677e4209126233bbde527207c8
* Improve visual feedback for relative layout and frame layout.Tor Norbye2010-10-112-31/+46
| | | | | | | | | | | | | | | | | | Improve the visual feedback for the relative layout and the frame layouts: 1. When there is multiple selection, don't draw adjacent boxes (since that's not how things will look once you drop); instead, draw overlapped boxes, For example if you drag a button and a clock, the button will be placed on top of the clock, not next to it, in both layouts. 2. Replace the center oval+x pattern with the stippled orange line pattern, and make some fixes to relative layout such that (when we have bounds) the preview rectangle is positioned correctly for the parent-relative bounds. Change-Id: Ie4c7b127cb28d9fedf194e9067f2fa9c82ede44e
* Fix bug in constraint display.Tor Norbye2010-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | Need explicit parens to ensure proper Groovy evaluation order. This short script shows the difference between the old and new forms: groovy> def id = "hello" groovy> def it = "world" groovy> def strings = [] groovy> strings << (id ? it + "=" + id : it) groovy> println "strings 1 = $strings" groovy> strings = [] groovy> strings << id ? it + "=" + id : it groovy> println "strings 2 = $strings" strings 1 = [world=hello] strings 2 = [hello] Change-Id: Iab1bc50656b1b975a522e5742240075600bab596
* Remove Groovy Closures from the tool integration API.Tor Norbye2010-10-085-22/+22
| | | | | | | | | | | | Remove Groovy Closures from the tool integration API, and replace with dedicated single-method-interfaces (which can also be invoked as closures from Groovy - but which also would allow non-Groovy implementations to work as View handlers). Also add warning to the javadoc for the interfaces that this is neither a public nor a final API. Change-Id: Ia146e1e150c2d47f95ff5bbb0771efc0e3aaa5ad
* Visual adjustments to the layout feedbackTor Norbye2010-10-065-41/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset makes a number of adjustments to the visual feedback shown during layout dragging & dropping, selection, etc. These are: 1. Render text on top of a translucent mask (white on a transparent gray rectangle). This ensures that the text is readable regardless of what content is under the text. We can't just use the background color for the normal SWT drawString for two reasons: First, we need to control the alpha of the background only (since we want the text to be opaque and the background to be translucent), and second, we often want to draw multiple lines of text, so we need to manually draw a background rectangle which accommodates the maximum width of ALL the lines such taht we don't have a ragged background. 2. Paint the outline mode lines using solid, translucent lines. And adjust the bounding box computation in this case by 1 pixel such that when you have adjacent boxes (such as in LinearLayout), you don't end up with two thin lines next to each other creating a thick line. 3. Change the DrawingStyle internal API from "foreground" and "background" colors to "stroke" (border) and "fill" (interior), with individual alphas. This makes the color definitions simpler (for example we don't need two separate styles, one for the selection border and one for the selection interior). 4. Make the hover more subtle, using no border and just a light translucent gray rectangle to only slightly draw attention to the view under the mouse. 5. Change the appearance of selection to light blue and use a long dashed border around it. The anchor lines are more faint and more translucent to make them stand out less. 6. Change the appearance of the drop-preview to use a dash patterned border identical to the selection border, but colored orange instead. The matching border pattern will hopefully reinforce that the drop-preview line is where the selection (also dashed) will go. 7. Use green to show available drop zones (the grid surrounding a target in RelativeLayout, and the positions between elements in LinearLayout). 8. For invalid drops, use a white X on a red background as the overlay fill. 9. I replaced the oval+X pattern from the LayoutHelpers and replaced them with the orange dashed insert-position lines. I also adjusted the LinearLayout to draw the bounding boxes such that the middle of the bounding box, rather than the top left edge, are aligned with the insert position. Change-Id: I85c77b9fa84b732a78aac635442f96e7ccfc3983
* Add drawing styles to the layout helper APITor Norbye2010-10-043-28/+11
| | | | | | | | | | | | | | | | | | | | | | | | Pull color constants out of the specific layout helper classes (groovy scripts) and the canvas editor and use a generic style enum instead in the interface, and associate the visual attributes (color, line style, thickness, alpha) with a swt-specific enum on the editor side. There is a single new API method which takes an enum parameter, which should let us add drawing styles over time. By having the color definitions on the tool side rather in the specific layout helpers it's not only easier to change the colors but also easier to ensure that the different helper all stay consistent as we change color schemes. In the immediate term (next integration) I'll change some of the colors; after that we should make the colors adapt to the chosen theme, and eventually these should be provided via the SDK from the themes themselves. This changeset doesn't actually change the colors used for the various types of visual feedback (selection, hover, drop-zone, etc) - I'll investigate that next. For that reason I also didn't replace all the various client-side color usage in the RelativeLayout. Change-Id: Iddf4ace9006ec02d9907c3c37d539ab7414f1371
* GLE2: fix RelativeLayout insert bad attributes sometimes.Raphael Moll2010-09-151-1/+4
| | | | | | | | | | | When RelativeLayout drops new elements, it filters the attributes and the filter is supposed to return false to indicate some attribute is not needed. Unfortunately the filtering code was assigning this to a String type and thus the false value was auto-converted to "false", thus failing the test and ending up as-is in the XML. Change-Id: Ife48ad9214a48016b7eb616950660deb3c962f6d
* GLE2: proper feedback on invalid drop targets.Raphael Moll2010-09-111-0/+2
| | | | Change-Id: I412a64fc261314d681009da87ed20fba278afa33
* GLE2: Indicate when drag'n'drop is rejected in RelativeLayout.Raphael Moll2010-09-101-5/+17
| | | | | | | | This is the case where a view from a RelativeLayout is being moved on a dependent view. Now it marks the view with a blue cross to give a clue that it's not a suitable target. Change-Id: I9989427ae9b52e054ff0dcee7cfe860a240ded29
* GLE2: display selection a bit better.Raphael Moll2010-09-091-0/+6
| | | | Change-Id: Ifb1297299697712273694b239a07cf0812e20e7b
* GLE2 context menu: Handle boolean properties as tri-state.Raphael Moll2010-09-011-26/+78
| | | | | | Also offer a clear option for enums and flags. Change-Id: I682ba19d9f5a1c1d5da28909b02a90ec01f4fc62
* GLE2 context menu support.Raphael Moll2010-08-315-9/+235
| | | | | | | | | | | | | Context menu now shows some view properties: - for all views, quick access to layout width/height. - for LinearLayout, quick access to orientation. - for all views, quick access to all boolean, enum or flag attributes. Some follow up will be necessary in another CL, namely: - booleans must be tri-states (true, false, cleared). - need a way to clear enum and flags rather than just change the value. Change-Id: Ie7451c21f0781f0efb0a1bbc676abef80027c4f7
* ADT GLE2: Remove (or disable) debug printfs.Raphael Moll2010-07-271-1/+1
| | | | Change-Id: I3d8a0f6b4731ee78af8da33c1749423ca7b13254
* ADT GLE2: implementation paste operation.Raphael Moll2010-07-223-15/+81
| | | | Change-Id: Ifc7b150eefd810a7c615fd9d3f26904e59c6c4aa
* ADT GLE2: Let groovy rules access a public API of the RulesEngine.Raphael Moll2010-07-211-0/+4
| | | | | | | | | | | This is done by injecting a property in the groovy rule instance with a new interface, the IClientRulesEngine. The client callback currently has 2 useful methods: debugPrintf (which has been moved out of INode) and loadRule(). This last one is the key here, it allows one rule to request another one to be loaded and get its object. Change-Id: I2881854e33cd3b41565dd1e16aaba1484ef765db
* ADT GLE2: drag'n'drop in FrameLayoutRaphael Moll2010-06-222-34/+97
| | | | Change-Id: I397dfbee84928cc336238f3092e86364edeb1f18
* ADT GLE2: render moved items in RelativeLayout.Raphael Moll2010-06-211-15/+34
| | | | Change-Id: I8ac4d8dd7abe43a1e5b32e234a74be80708144ec
* ADT GLE2: cleanup some constants and review feedback.Raphael Moll2010-06-216-67/+36
| | | | Change-Id: Ib9f3473d49bc27dfb87d29855a832a21bdcf3100
* ADT GLE2: drag'n'drop in RelativeLayout.Raphael Moll2010-06-195-68/+243
| | | | | | First pass. There are some details to take care of later. Change-Id: Ic9ac3d34ce4061ed2a8c257ce6bd40ea30497eb8
* ADT GLE2: readme (first quick'n'dirty draft)Raphael Moll2010-06-182-10/+49
| | | | Change-Id: I1e26f9c50d647893d93747ccdbe73e27a5100cef
* ADT GLE2: drag'n'drop for LinearLayoutRaphael Moll2010-06-173-191/+358
| | | | Change-Id: I64959e27f2c08c459e15323d7c8d2cdb041ba9dd
* ADT GLE2: Access AttributeInfo from groovy scripts.Raphael Moll2010-06-081-17/+22
| | | | | | | | | | | | | | | | | | | | | | | This CL extracts IAttributeInfo from DeclareStyleable -- this used to be the metadata extracted from an attribute declared in attrs.xml. The interface that is now available to groovy scripts lets them check whether an attribute is a reference, a string, etc. For an enum or flag that means having access to the defined values too. In the case of the AbsoluteLayout drop, we use this info to check if an attribute is a reference. For example when duplicating a RelativeLayout dropped in an AbsoluteLayout, we need to create new ids and the RelativeLayout is prone to have inner self-references that can be automatically adjusted that way. A large part of the CL is about refactoring the various manually-created attributes in the Descriptors for resources, XML, and such. In this case the IAttributeInfo that is made available via the AttributeDescriptor is not used, but it made sense to keep this consistent in case we want to expose it later and to avoid having to care about special cases. Change-Id: Ic02f69bc16f0e549fcac3956ae93b86651c5be3c
* ADT GLE2: Restore relative position of elements in AbsoluteLayout drop.Raphael Moll2010-06-041-31/+28
| | | | | | | | Change the IDragElement to not carry the original INode, since this is not available when crossing Eclipse instances. Instead encode the info we need in the transfer. Change-Id: I90a1e71171af61e51e8aaded31e05300fa85c014
* ADT GLE2: Generate items on drop in AbsoluteLayout.Raphael Moll2010-06-031-50/+123
| | | | Change-Id: Iaf943b476db553cd39f5c3ee4f9c47ad3cdc6246
* ADT GLE2: Script for AbsoluteLayout for new canvas drag API.Raphael Moll2010-06-012-26/+174
| | | | | | | Most of the changes concern the supporting API (INode and co) to be able to recreate and mofiy the XML elements. Change-Id: I9ab62b3fe125faed1b647f1735f8ff0afd33a5d9
* ADT GLE2: Drag from canvasRaphael2010-05-282-8/+18
| | | | | | | | The groovy scripts need to be changed and will be part of the next CL (only the base view one has been adapted here.) Change-Id: If91602b36a3b147f6a18c9c9538d6d9bec5ecea0
* ADT GLE: pass dragged FQCN to IViewRulesRaphael2010-03-085-20/+20
| | | | Change-Id: Iee6868e65ebdb98a8b62dd07d8490e5363e6f3af
* ADT GLE2: Fix drop coordinates, add FrameLayout.groovyRaphael2010-03-054-19/+95
| | | | | | | | | | | | | | 1- Fix computation of scrolled drop coordinates: margin constant should not be used directly and is now private to the Scaling helper class. The Drop class now defers to the Canvas to convert display coordinates into canvas image coordinates. 2- Fixed a small bug when LinearLayout was computing the insertion point when there were no children. 3- Added a basic FrameLayout for drop support. Change-Id: Iaf1305bd3df16b62fe29568eb811d36704f86482
* ADT GLE2: Snap to RelativeLayout bordersRaphael2010-03-022-35/+111
|
* ADT GLE2: Support for drop on RelativeLayout children.Raphael2010-02-263-30/+66
| | | | Change-Id: I6ed9f1d89f61caf6141f23708854a01247ab5518
* ADT GLE: Experiment with d'n'd in RelativeLayout.Raphael2010-02-223-32/+251
| | | | Change-Id: Ic737d5273b55a4ec78c1d9789616e1e296b77b00
* ADT GLE: experiment with display of Relative layout params.Raphael2010-02-196-7/+97
| | | | Change-Id: Icd8ac13e91b575c7133c5c0256a46e3c16e5fae8
* ADT GLE: new IViewRule interface for Drag'n'drop.Raphael2010-02-183-83/+230
| | | | | | With implementation for AbsoluteLayout and LinearLayout. Change-Id: If8d6301abcc848574b3ab5d8894396a0246b1275
* ADT GRE: Resolve gscripts groovy imports.Raphael2010-02-126-104/+149
| | | | | | | | | | | | | This reconfigures the Groovy engine: - The user projects /gscripts folder is added to the groovy class path (so user can import their own local classes.) - The IViewRule package is added as a default import (using the import .* syntax), which means the scripts don't have the specify every single import anymore. - Our scripts can now extend each others -- as long as the classes are in our package they will be resolved and loaded. Change-Id: I79dabf7d1317a1bf4a0fc04ee8ba0987dca7da15
* ADT GLE2: Implement IViewRule.onChildSelected.Raphael2010-02-091-31/+38
| | | | | | | | Revamp the IViewRule.on[Child]Selected to not return a closure. There is no actual event at selection time. Instead the callback is called directly to paint the canvas. Change-Id: I2b50fbdff734b9c1a2c581ca5958bac43e5f325f
* ADT GLE2: support isMultipleSelection.Raphael2010-02-081-2/+3
| | | | | | | | Problem is easily solved by making this a parameter in the closure, so we don't need to ask rules to give us a different closure, they just need to redraw. Change-Id: I4445c826b03bbb978bf085905ccd67d5e03b0356
* ADT GLE2: Rename IGC to IGraphics.Raphael2010-02-081-2/+2
| | | | | | This is a pure rename refatoring. Change-Id: Iffddb02b4c1efd553a0ba866a58a8059c290a7b7
* GLE2: IViewRule callback for selection.Raphael2010-02-054-11/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: - This moves the selection drawing from the LayoutCanvas to the groovy script. - There's a single IViewRule "onSelected" method. The script which implement it return a closure (aka an anonymous method) that does the actual drawing. - onSelected is called during the actualy selection or when the canvas is refreshed. The rendering closure is actually called later during the canvas onPaint. Here I am mostly testing the logic of having a script callback handle an event (the selection) and returning a closure that does the drawing later (during onpaint). The main rationale for separating them is that the GC needed to draw isn't available during the actual selection event. I plan to reuse this mechanism for drag'n'drop & co. TODO: layout selection is broken and will be fixed in another CL. TODO: onChildSelected will be next. TODO: Originally I had plans for onSelected(isMultipleSelection), which I'm not sure I'll actually add later anyway., I fail to see the point in implementation. Change-Id: Ibc5fecbd107429df1f53b2b8172aba55e6289795
* ADT GRE: create base class for IViewRule.Raphael2010-01-144-291/+15
| | | | | | | | This adds BaseViewRule (better name welcome) that is basically an empty IViewRule so that groovy classes don't have to systematically redefine the same empty boilerplate. Change-Id: Ibf9a03d3aa0ca8a42534f5693792235c31100273
* ADT GRE: Move gscripts package.Raphael2010-01-144-20/+20
| | | | | | | Moving the public API from com.android.ide.eclispse.adt.gscripts to ...adt.editors.layout.gscripts. Change-Id: Idf5b979d47dbbbe2514cce8cc3c688eb273bcce6
* ADT GLE: Support drop in AbsoluteLayout and create XML node.Raphael2010-01-094-22/+267
| | | | | | | | | | | This is a *temporary* CL just to get some things out of the way: - it adds some method to create some XML from groovy - it uses the new dropStart/dropFinish API. However after this is submitted I'll change the IViewRule API as we discussed so all this code will need to change. Again. Change-Id: Ie9c7eebf0f9e1d48e364467fbaac5615b4c42f21
* ADT GRE: move scripts to ADT /gscripts.Raphael2010-01-042-0/+261
So right now we have: - some GRE/GLE code in internal that uses the scripts - the "public" bases client classes in ADT src/gscripts (not internal) - the "client scripts" in ADT /gscripts. - projects use their own /gscripts folder. Change-Id: I899d272233f35f493317a56fde60eb7e4a257c7a
generated by cgit v1.1 at 2025-07-04 23:14:01 +0000