Should "Collect Project Items..." be including the entirety of the Plugins folder in the Project?

I just had a surprise when I collected a new Project and discovered that ALL of my plugins were copied from the Xojo folder into the Project folder.

Is this the new normal, or an oops?

Xojo 2022r1.1 on macOS 12.4

It creates a folder called ‘plugins’ in the destination

1 Like

Not trying to poke the bear, but why? It really messes up version control workflows having the full Plugins folder included in every project.

If it’s to allow different versions of plugins for different projects, I can see a use, but at least allow us to decide if it’s needed.

I think a better question is “Why are you using Collect Project for version control?”

Collect Project is for giving your entire project to another user or to Xojo tech support. Having your plugins in there is extremely useful for that.

1 Like

That’s an easy one - Retrieve the same source code layout on all three build platforms without mixed up path elements and keep the platforms in sync during development…

Uh yeah. Don’t do that. Use a real version control system like SVN or Git for that.

Well, gee, I didn’t realize that SVN wasn’t SVN … :stuck_out_tongue:

The problem is that I sometimes add images that are in a location on one platform that doesn’t exist on the others. Collection solves that.

It could be solved with a project option “Don’t Collect Plugins”. Projects with this option set should not create a Plugins folder and gather plugins there.

File a feature request.

1 Like

Yikes. IMHO you should put your images in a location where SVN can reach them on all platforms so you don’t run into version trouble with them.

1 Like

Or, grow to depend on the way that Xojo has worked for years and not expect changes of this magnitude without discussion with users … Oh, I forgot.

Also, the plugins are not my project. Maybe what we need is a different “Collect for Bug Report Submission” option that handles what the Xojo team needs.

For some reason, Xojo changed this feature.

Here is the dialog for Xojo 2021r3.1 and earlier versions (tested 2018r3):

Here is the dialog for Xojo 2022r1.1:

I used the Collect option a couple of times before when I forgot to first copy the image to the project folder and it just created an Images folder (if it was not already there).

I haven’t used this feature with 2022r1.1 but it looks like it is a different option now. Instead of just pulling external files/images to the project directory it is saving the project with everything (even the plugins) in a new location.

Why is it now “for distribution”?
Why not add a new option “Collect Project for Distribution”?


That’s like what I mentioned above -

But, in light of your comment, WHY would I want to distribute my source code and plugins?

My main point is that it was an unexpected change that bloated my SVN automation which is designed to catch new entries in a code tree - now I have 3 projects under version control that contain MBS, EINHUGUR, Bob Delaney, and my own plugins.

In my case, the answer is that it all belongs to a client, and I have a responsibility to ensure that they can continue to maintain the code if I drop dead or get hit by a bus. So including plug-ins is a great feature for me, saving me the trouble of collecting them manually. But I agree with @Rick_A that there’s no reason it can’t be a preference or a checkbox in the dialog itself.


I’m actually happy to see the ominous and completely unnecessary “cannot be undone” warning gone. Of course it can be “undone”, just trash or overwrite the folder containing the collected items. That warning kept me from using the feature for years, lol.

Maybe now, but in past the warning made sense as it processed the current open project modifying it in a way it couldn’t be undone. The current message says it won’t touch the current project but a copy of it in a new location… much better behavior.

An option to collect plugins, right in the interface, seems better than my original idea, like:


1 Like

Really? How was the currently-open project modified?

I agree, but I’d use a checkbox to include plugins rather than another button.

All the links to external content spread to diverse external places were set to the current embedded content. If you changed some external content as you used to, it won’t reflect in your project anymore, if you deleted some gathered content, or folder, it would break you project too.

There really needs to be two options here -

Collect items for Project Cleanup
Collect Items for Ticket Submission

If you use external items, the first should leave them alone, but the second should gather them and make them internal.

For me, the first is mainly to consolidate graphic elements that were added to a project from an external folder.

One more comment - if you use this as it is currently designed, you will not be able to upload a simple project to the ticket system if you have MBS and Einhugur installed - the resulting ZIP is too large to upload. The response I received was to remove the unneeded plugins … kind of defeats to purpose of the current design.

1 Like

You should always do that anyway. Having more than just what is needed complicates the debugging process immensely.

I work on up to 8 active projects at a time and they don’t all use the same plugins - BUT, they all use the same copy of the Xojo IDE where the plugins MUST exist to be used.

How would you recommend that I do that? Shouldn’t that be part of the collection for bug reporting - the collect process only includes the plugins that the specific project requires?