Getting ready to ship the first panel plugins

Adobe XD UXP Plugin API
1

This month has seen the public launch of XD panel APIs for developers. We’ve had a lot to communicate leading up to the forthcoming launch of panel plugins in the XD Plugin Manager.

We want to make this next step as easy to follow as possible, so I’m pulling together various topics in this thread that will be important to anyone working on panels this month. We’ll revise and add as needed.

Below, you’ll find critical information on these topics:

  • Test on the release version of XD 21.1
  • Known API bugs to avoid in panels
  • Designing panels for XD’s minimum width
  • Plugin IDs and migrating existing plugins to panels
  • Notes on the review process for panels

Test on the release version of XD 21.1

XD 21.1, a patch update, was just released today. If you are building panel-based plugins, please prioritize testing on this build.

Not recommended for panels testing at this point:

  • Prerelease builds
  • XD 20.0.##

Known API bugs to avoid in panels

application.editDocument() not being enforced yet

The application.editDocument() method must wrap any action that a panel takes to modify the XD document.

There is a bug in XD 21.0.## where this rule is not strictly enforced, thereby letting panels make modifications that should not be allowed. This bug is fixed in today’s XD 21.1.## release. Any plugin not using editDocument() correctly will break.

The good news here is that if you’re already doing the right thing, you’ll be fine. ☆

position: fixed is broken for panels

In your CSS, position: "fixed" should not be used in production panel-based plugins (modals are not affected). There is a known issue where the coordinate system is respective to the entire panel rather than the plugin container. This will be addressed in a future XD release, which will break the layout of any plugins using position: "fixed".

For now, we will not approve any panel plugins found using position: “fixed” until the issue is fixed on our side.

Designing panels for XD’s minimum width

Please design for the minimum width of XD’s UI. Several beta plugins we’ve tested have had UI elements that are lost if the user has their Adobe XD window smaller than the screen size. When the XD window is smaller, the plugin UI real estate can also become smaller.

These are the minimum widths you’ll need to design for:

  • macOS minimum size: 194 px with 12 px margins
  • Windows minimum size: 240 px with 16 px margins

This information and more will be officially documented in the near future.

Plugin IDs and migrating existing plugins to panels

Please see this forum post.

Notes on the review process for panels

We’ll start seeing panel plugins become available in the XD Plugin Manager soon.

If you’re working directly with anyone at Adobe on the timeline for shipping your plugin, please coordinate with them directly about the right time to submit to the review process.

If you’re developing independently and have already submitted to the review process, please note that the publishing timeline will take a bit longer than usual given the excitement around this launch.

Please bear with us; like you, we are super excited to get panel plugins through the process and into the hands of users!

2 Likes
3

Are there any suggested workarounds for the “position: fixed” bug until resolved?

Asking because I’m working on a plugin according these design guidelines where the “Action” button is at the bottom of the panel: https://xd.adobe.com/view/cba2fc00-bdef-467d-6496-433df52016da-bd93/screen/0e23dd4d-048a-4b45-9e13-4e5916c7497c/Sticker-sheet-4/

1 Like
4

I’d just have the button not fixed at the bottom at this moment and have it fixed once the new version is out in the near future

5

Alternatively, you can move the button outside of the container and anchor it with the bottom property.

Something like this:

<div id="myPlugin">
	<div>...</div>
</div>

<button class="myButton">
	
</button>

<style>
	.myButton {
		position:absolute;
		left:10px;
		bottom:10px;
	}
</style>

Or you could keep the button in the container but set the z index to 1 or more and then use the same class above.

<div id="myPluginView">
	<div>...</div>

	<button class="myButton">
	</button>
</div>


<style>
	.myButton {
		position:absolute;
		left:10px;
		bottom:10px;
		z-index:1;
	}
</style>
1 Like
6

Can we post pictures of the panels in our marketing materials?

7

position: absolute works to ensure that your panel can fill the entire container. position: fixed worked during the prerelease, but plugins that want to be sure they can fill the panel should use absolute positioning.

So, if your panel has:

position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;

… you can then use flex layout (or absolute positioning again) to align your controls to the bottom. I thought I had an example in the plugin-samples (e2e-adobe-stock), but I’ll double check.

1 Like
8

You can if you’d like, given that the panel APIs are public. Note that Adobe won’t do any marketing around plugins using panels until XD22 is released (August). (This includes retweets from staff accounts.)

9

I double checked and hadn’t pushed some changes to e2e-adobe stock – those should be live in the plugin samples repo now. That has an example of something pinned to the bottom of the panel using the absolute positioning and flex layout.

1 Like
10

There is one more issue that slipped through:

“Plugin Error: Plugins must add nodes one at a time, not entire subtrees…”

I was just using addChildBefore/After to swap tree position of two groups. It was working just fine until 21.1 patch. This killed one of my primary features :frowning:
Consider this as a feature request :wink: Moving existing groups up/down in the scenegraph tree should be possible.

1 Like
11

I think it’s always behaved this way?

Let’s add an API feature request that would allow moving subtrees around.

12

It was until the last version. Then it worked even with groups. So I thought that this limitation was finally lifted. But in the latest version the limitation is back :frowning:

Feature request would be:

  • Allowing subtrees
  • or at least have something like swapChildren(a, b)
1 Like
13

That particular limit has always been there; the reason it looked lifted is that no validation was occurring (IIRC), so the error wasn’t being caught by XD at all – which could corrupt the document and all sorts of bad things.

Yes, please make a feature request for this.