Hi, I want to traverse the whole document to look for specific nodes such as text to change them to outlines.
But I am failing because I cannot select text that is inside a group that is a part of the Artboard.
Message I am getting tells me I am not in the right Edit context.
Plugin Error: Cannot select node not in the current edit context: [object Object]
The question is… how to get there? I do not want user to be selecting anything since I want to check whole document.
I also do not want to detach nodes from parents since the structure is already established.
Selection doesn’t work and normally I would assume that this would be a way of getting to the right node…
Documentation doesn’t explain how to change scope.
Without using some tricks like degrouping (which – in my opinion – isn’t a very good solution, and you’ve also stated that you don’t want to do that), you can’t. The edit context actually serves as a kind of “control” for the user to grant the plugin editing rights for the selection.
Instead, you should try to adjust the way your plugin works to fit this requirement. For example, you could only manipulate everything that’s selected (which would also be much more user-friendly and a user could still select everthing if they want to) or you could ask the user to select everything if you really have to (although – as I’ve stated, I wouldn’t consider that good UX, which – with the target group in mind – isn’t necessarily the best thing to do ).
All in all, it is more a “how to make the plugin fit the requirements” instead of the “how to avoid the requirements” kind of mentality that you’ll need to get this to work. While it may be (with some tricks) theoretically possible to avoid the edit context, there is a reason why it’s there (and it’s not just to annoy developers ).
Totally agree here - I do not want to change file structure in any way. De-grouping will cause loosing folder properties and sceneflow actions. However, edit-context is not a new thing - it is not the first time where You are allowed to modify just child objects, or where You need to change the scope in order to access the right child node. It is just insanely weird that You cannot “jump” to that node here. You can just read out properties and… yeah… that’s it.
I cannot agree here. Plugins, scripts are usually created to enhance the workflow. To add functionalities that normally are either cumbersome or not existing. To optimize workflow etc.
Unfortunately in my use case it seem not to be possible to write a plugin that serves a requirements.
I want to achieve something similar to Illustrators function:
Select > Same Fill Color (or Same Stroke Color)
It is not doable without possibility of searching through the document structure and modifying it.
It is not only problem for the plugin writing perspective - it is a huge architectural mistake!
It already limits Adobe XD possibilities in terms of flexibility and structure. It seem so that it is better to keep tons of “loose” objects on the Artboard instead of organized structure with named folders which is a bit contra towards the clean workflow state.
It is being very problematic now, when It is possible to auto-animate the scenes and I have tons of Artboards that look similar (but different)… I cannot even select objects manually that are in different groups. That means I cannot do bulks changes and what follows - my workflows are starting to be very painful.
It is yet again kind of contra-productive for a tool that should allow to quickly iterate over many variations of prototypes. We are getting in kind of evil-loop here. Tool itself is limiting some user actions - that causes that people want to write plugins to change it. But it turns out it will not be doable because yeah… because tool doesn’t allow it as well.
And don’t get me wrong Adobe. I really like to work with XD. It is still way faster then doing prototypes in PS, AI or software that is dedicated for that - because I have a direct integration with Creative Cloud.
Also XD got way better over past months. I kind of scratched it off my PC right after release because it was just “not there yet”.
It is in a really nice state now. But it lacks some things…
Thank You for taking up the topic.
However, this is just the first “iteration” of extensibility. I’m sure issues like this will get addressed (and many issues that existed during the Beta are already resolved now). I think that there are – of course – issues that need to get addressed but at the same time, but I wouldn’t say it’s an evil-loop (there are already many great plugins and as the APIs get extended to allow things like what you need, there will be many more great plugins).
Agreed (but I think – looking at the way Adobe develops XD – that this is by design to also be able to include user’s opinions)
Anytime. Also, please note that I’m the kind of person trying to always look on the other side in a discussion, so I might agree with you more than you think – it’s just that I’m trying to “play devil’s advocate” here and there to – eventually – arrive at the (hopefully) best solution…
Chiming in here – we’re aware of the edit context limitations, and have run into them ourselves while building sample plugins. We are thinking about our options to extend how you can edit the document as a whole, but we want to make sure we do it right. That said, the edit context is architecturally fundamental to XD, so changing how it works would affect everything… which means that it will take some time and lots of careful consideration and testing before we release any changes here.
Any and all use cases (like the ones you’ve already mentioned) are great to have on hand as well to help justify the work that will be required to make such changes, so keep those use cases coming.
I’m not sure if you’re still having issues with this but without reading the entire thread I noticed one thing that can cause issues. If you can, avoid using forEach() as it may cause problems with synchronous and asynchronous operations.
The forEach() call is an asynchronous method that accepts a callback function. That means that the anonymous / lambda function is called out of order or out of line of a click event that is necessary for some operations to work.
forEach expects a synchronous function
forEach does not wait for promises. Kindly make sure you are aware of the implications while using promises(or async functions) as forEach callback.
IIRC when you call some XD API’s like setting the selection or calling commands some of those operations may be asynchronous. So XD may start an operation and create a promise that where you need to wait a bit for it to complete but if you are using forEach loop with a callback you may be moving on and selecting the next item(s) while the first aren’t finished yet and causing some errors and out of context problems.
It took me a while and lot of debugging to solve some issues.
Instead use a traditional for loop.
I might not be wording this correct but @kerrishotts might better be able to explain it.