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
Yes
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 ⊠
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â?
2 Likes
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_Araujo that thereâs no reason it canât be a preference or a checkbox in the dialog itself.
3 Likes
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?