Skip to content

Releases: elyra-ai/canvas

v13.9.1

27 Aug 21:31
52e740e
Compare
Choose a tag to compare

This is a patch release. No new features. Just one fix.

Issues Resolved

Full Changelog: v13.9.0...v13.9.1

v13.9.0

26 Aug 17:06
62b5521
Compare
Choose a tag to compare

Common Canvas

#2115 Support collapsed super node resizingCollapsed supernodes can now be resized when the config field enableResizableNodes is set to true. This behavior is separate to the resizing behavior when the supernode is expanded to display the sub-flow in-place.

Common Properties

#2108 Need shouldFilterItem support for oneofselect control
The Oneofselect Control now filters items by default based on the input text.
oneofselect

Issues Resolved

Full Changelog: v13.8.0...v13.9.0

v13.8.0

12 Aug 22:03
8483035
Compare
Choose a tag to compare

Common Canvas

Just bug fixes

Common Properties

#2088 Include actions in properties title editor

Parameter definitions now supports a title_info section in the uihints (elyra-ai/pipeline-schemas#148) where a list of actions can be specified to be displayed in the title section. These actionRefs will be mapped to actions defined in the action_info section.
image

Issues Resolved

Full Changelog: v13.7.0...v13.8.0

v13.7.0

06 Aug 23:07
bd46e16
Compare
Choose a tag to compare

Feature Enhancements

Common Canvas

#2090 Add new left side panel to allow toggling between palette and search panel

This requirement has two parts:

  1. The application needs control over what is displayed in the left flyout. Based on the user clicking buttons in the toolbar, sometimes the Palette is displayed and sometimes a Search panel is displayed showing a sophisticated search UI.

  2. The palette (or any replacement search panel) should be displayable underneath the toolbar rather that at the side of the toolbar.

Requirement 1

Common Canvas has default behavior for the palette. This is enabled when the canvas config field enablePaletteLayout is set to “Flyout”. This default behavior involves:

  • automatically displaying a palette icon as the left most button in the toolbar
  • handling clicks on the button to control the opening and closing of the Palette in the left flyout
  • allowing the application to specify whether the “closed” palette is shown as a narrow palette or hidden completely. (This is controlled by the enableNarrowPalette canvas config field).

This default behavior might conflict with any control the application is given over the contents and behavior of the left-flyout. Therefore, to implement this requirement, the default palette behavior and the ability to control the left flyout have been separated as follows.:

  • When the default palette behavior is switched on (enablePaletteLayout === "Flyout") Common Canvas manages everything to do with the left flyout and the left flyout cannot be controlled by the application.
  • When default palette behavior is switched off (enablePaletteLayout === "None") the application must handle all aspects of the left flyout.

Consequently, to implement this requirement with this Elyra Canvas release, the application must do these things:

  • Disable the default Palette behavior by setting enablePaletteLayout to “None”
  • Add whatever buttons are required to the toolbar for opening the palette or search panels
  • Control the display and contents of the left-flyout based on which toolbar buttons are clicked

To allow for the third item two new props have been added to <CommonCanvas> called leftFlyoutContent and showLeftFlyout.

These work in the same way as these currently supported props:

  • rightFlyoutContent and showRightFlyout
  • topPanelContent and showTopPanel
  • bottomPanelContent and showBottomPanel

Notes

  1. To allow the application to provide the Palette as content for the left flyout the Palette object is now exported from Elyra Canvas. To satisfy this requirement the application must import the Palette from Elyra Canvas and then specify it in the leftFlyoutContent prop of <CommonCanvas>

  2. The width of the left flyout will expand to accommodate whatever contents that are specified in the leftFlyoutContent prop of <CommonCanvas>

  3. The Stages sample application in the Test Harness has been updated to implement the steps mentioned above. To see this, open the Test Harness, click the Common Canvas button and then click the 'Stages' sample application.

  4. You can see the code that was added to the Stages sample app, as follow:

    • The default behavior of the Palette has been switched off here
    • The two buttons for the toolbar are specified here
    • The editActionHandler has been updated to handle the click on each of these buttons here
    • The render method has been updated to render the appropriate content into the left flyout here and here
  5. For this work item a number of internal class names have been removed. These were not part of the documented API but are documented here for completeness:
    common-canvas-items-container
    common-canvas-right-side-items
    common-canvas-right-side-items-under-toolbar
    common-canvas-items-container-under-toolbar
    common-canvas-with-top-and-bottom-panel

Requiremnt 2

The left flyout (whether it is displaying the default palette or the left flyout contents provided by the app) can be displayed underneath the toolbar by setting the enableLeftFlyoutUnderToolbar config field to true. (This is the equivalent of the enableRightFlyoutUnderToolbar config field). You can see this behavior if you view the Stages sample app where you will see the Palette/Search panel appearing below the toolbar. You can see it has been switched on in the Stages sample app code here

#2079 Add ability to adjust position of context toolbar for links

Two new Canvas Layout fields have been added called linkContextToolbarPosX and linkContextToolbarPosY. These are used as an offset for the bottom center position of the context toolbar for all links. Positive X is to the right, negative X is to the left, and positive Y is down, negative Y is up.

They can be specified like this:

    const canvasConfig = {
        enableCanvasLayout: {
            linkContextToolbarPosX: 10,
            linkContextToolbarPosY: -10
        }
    };

This behavior has been implemented in the Stages sample app. You can see it in the Test Harness. In the Test Harness click the “Common Canvas“ button and the “Stages” sample app. You can see the code for it here

#2095 Hide link Label with ... and decorations based on link length in Common Canvas

Two more new Canvas Layout fields have been added in this release called:

  • linkDistanceForAltDecorations — A distance in pixels between the start point and end point of the link below which the ‘alternative decorations’ will be displayed. This defaults to 150.

  • linkAltDecorations. — Should be set to an array of alternative decorations for the link. Each element of the array should follow the decoration specification just the same as the regular decorations. The default for this field is null, which means no alternative decorations will be displayed. They can be specified something like this:

    const canvasConfig = {
        enableCanvasLayout: {
            linkDistanceForAltDecorations: 100,
            linkAltDecorations: [
                { id: “alt-123”, label: “XXX” }
            ]
        }
    }

This will display a label “XXX” in the middle of the link when the distance from the start point to the end point of the link is below 100 pixels.

The Stages sample app in the Test Harness has been updated to use this feature. In the Test Harness click the “Common Canvas“ button and the “Stages” sample app. You can see the code here.

Common Properties

Just bug fixes

Issues Resolved

  • #2079 Add ability to adjust position of context toolbar for links by @tomlyn in #2080
  • #2083 With WYSIWYG comments IBM Plex Condensed font display incorrectly by @tomlyn in #2084
  • #2085 Page crashes when mousing over node while submenu toolbaritem i… by @tomlyn in #2086
  • #2093 Text decoration on a Link -- entry area closes when mouse cursor moved out (intermittent). by @srikant-ch5 in #2094
  • #2081 Conditions + small portion of controls by @mikieyx in #2082
  • #2090 Add new left side panel to allow toggling between palette and s… by @tomlyn in #2091
  • #2095 Hide link Label with ... and decorations based on link length i… by @tomlyn in #2096

Full Changelog: v13.6.1...v13.7.0

v13.6.1

30 Jul 02:19
c994e2d
Compare
Choose a tag to compare

This is a patch release. No new features. Just one fix.

Issues Resolved

Full Changelog: v13.6.0...v13.6.1

v13.6.0

30 Jul 01:44
ef37446
Compare
Choose a tag to compare

Feature Enhancements

Common Canvas

#2022 Arrange Horizontal does not work when we have a detached link

The arrange horizontal and arrange vertical feature now handle fully-detached and semi-detached links appropriately. Previously the unattached ends of those types of link were left in their original positions. In this release, the ends of those links are moved to a position they would be in if they were attached to a node.

#2064 Enable new Comment type which supports a WYSIWYG

In this release, Elyra Canvas supports a new kind of comment called a WYSIWYG* comment. Applications can choose to support:

  • the current type of comment (which may optionally include markdown syntax) OR
  • the new WYSIWYG comments OR
  • both.

A new canvas config field called enableWYSIWYGComments has been added. When set to true the default context menu / context toolbar displayed when right-clicking on the canvas, will display a New WYSIWYG Comment option. The default toolbar will not be changed.

The application can programmatically customize the canvas toolbar and context menu / context toolbar to issue the new actions "createWYSIWYGComment" and/or "createAutoWYSIWYGComment" which will do the same for WYSIWYG comments as their counterparts "createComment" or "createAutoComment" do for regular comments.

A sample application called "WYSIWYG Comments" has been added to the Test Harness which allows you to try out this new feature. You can see the code for it here which will show how the toolbar can be customized to add the "createAutoWYSIWYGComment" action.

WYSIWYG comments support the following formatting actions that are applied to the entire text entered for the comment:

  • Font
  • Font Size
  • Bold
  • Italics
  • Underline
  • Strikethrough
  • Text color (choice of 64 colors including transparent)
  • Align horizontally (left, center, right)
  • Align Vertically (top, middle, bottom)
  • Background color (choice of 64 colors including transparent)
  • Outline (No outline, Solid outline)

Internally, a WYSIWYG comment is indicated by the presence of a "contentType" field set to "WYSIWYG" in the comment object in the pipeline flow. The comment can also have an array of format objects which contain elements that describe the formatting applied by the user.

More details are here:
https://github.ibm.com/NGP-TWC/wdp-abstract-canvas/issues/3810#issuecomment-86608709

  • WYSIWYG stands for 'What You See Is What You Get'

#2076 Document that a ibm plex scss should be included when building an applications

The Loading Fonts section of the Initial Setup page in the documentation has been updated to mention that applications should include these lines in their .scss files when building.

$font-prefix: './fonts';
@import 'node_modules/@ibm/plex/scss/ibm-plex.scss';

Please make that addition to your application build process.

Common Properties

#2030 Add readOnly control in Common Properties

A new read_only uihint has been added to Common Properties controls. Applying read_only removes all the interactive functions from the component.

A control can be converted into a read-only control by adding “read_only”: true in the uihints parameter_info in the paramDef as shown below:

  "uihints": {
    "id": "Expressions.test",
    "description": {
      "default": "Test expression controls"
    },
    "parameter_info": [
      {
        "parameter_ref": "expression_readonly",
        "read_only": true
      }
   ]
}

Issues Resolved

New Contributors

Full Changelog: v13.5.0...v13.6.0

v13.5.0

30 Jun 20:03
5359601
Compare
Choose a tag to compare

Feature Enhancements

Common Canvas

#2033 Support new link line types

The link construction and drawing code has been completely overhauled in this release. Previously, Common Canvas supported "Curve" and "Elbow" links which connected ports together, and "Straight" links that were free floating (or 'freeform') which were drawn directly from the source to target node ignoring port positions.

In this new release, these concepts have been split as follows:

  • The existing enableLinkType config field will specify the shape of the links, and can be set to either “Curve”, “Elbow”, “Parallax” or “Straight”. “Parallax” is a new line type which has a small starting and ending line separated by a diagonal line.
  • A new config field called enableLinkMethod, that can be set to "Ports" or “Freeform”, will control how the links are built, where "Ports" will draw the link from a specific port on the source node to a specific port on the target node and "Freeform" will draw the links between nodes with no reference to where ports are positioned. "Ports" is the default.

The application can use any combination of enableLinkType and enableLinkMethod to get the display required.

Please see the documentation here for some examples of this:
https://elyra-ai.github.io/canvas/01.01.02-links/#data-links

and here for how port positions will affect link drawing:
https://elyra-ai.github.io/canvas/03.06.01-node-customization/#overriding-port-positions-and-link-directions

There are three new sample applications in the test harness called “All ports”, "Parallax" and "Network" which shows some of the combinations of these config fields in action.
https://elyra-canvas-test-harness.u20youmx4sm.us-south.codeengine.appdomain.cloud/#/

enableStraightLinksAsFreeform

To avoid 'breaking' the API and to maintain the previous behavior where "Straight" links were always displayed as “Freeform”, a new config field has been introduced called enableStraightLinksAsFreeform that is a boolean that defaults to true. When true, this will force “Straight” links to be displayed with the “Freeform” option regardless of what enableLinkMethod is set to. If this is set to false , the value specified in enableLinkMethod will be used by Common Canvas for "Straight" links.

Warning: enableStraightLinksAsFreeform is deprecated and will be removed in the next major release. Therefore, applications using enableLinkType set to “Straight” should set enableLinkMethod to “Freeform” NOW to prevent problems when upgrading in the future.

Overriding port position and link drawing

The customization of port positions is already supported by Common Canvas but what is new in this release is that, with enableLinkMethod set to "Ports", Common Canvas will decide on a direction for the links to be drawn to/from ports based on their positions on the node. This change means that, for example, output ports can be displayed at different sides of the node and the links will be drawn away from the node. Please see the docs here for details:
https://elyra-ai.github.io/canvas/03.06.01-node-customization/#overriding-port-positions-and-link-directions

Self-referencing links

In this release, nodes can optionally have self-referencing links that loop back to themselves.

If the new enableSelfRefLinks config field is set to true, users will be able to drag a link from an output port on a node and drop it onto an input port, or body, of the same node to create a self-referencing link. Alternatively, the application can programmatically create self-referencing links. These links will be displayed using the combination of settings specified for enableLinkType and enableLinkMethod described above.

See more in the documentation here:
https://elyra-ai.github.io/canvas/01.01.02-links/#self-referencing-links

Common Properties

Just bug fixes.

Issues Resolved

Full Changelog: v13.4.0...v13.5.0

v13.4.0

27 Jun 21:06
3efae17
Compare
Choose a tag to compare

Notes

Because of a build issue all of the items from this release are covered by the release notes for v13.5.0. Please refer there for details:
https://github.com/elyra-ai/canvas/releases/tag/v13.5.0

v13.3.0

19 Jun 00:33
3f43a0f
Compare
Choose a tag to compare

Feature Enhancements

Common Properties

#2012 Add support for helperText in all Common Properties controls. by @srikant-ch5 in #2013

A new helperText uihint is available to all Carbon controls that supports it

Issues Resolved

v13.2.0

07 Jun 05:21
6bdfbda
Compare
Choose a tag to compare

Feature Enhancements

Common Canvas

#1987 Enable options to allow link lines to be drawn over nodes

A new boolean configuration field called enableLinksOverNodes has been that defaults to false. If set to true links are placed above nodes in the canvas.

Issues Resolved