This subject I think needs to be a roadmap item. It’s big and important. We have 4 project types these days: desktop, web, mobile, and console. Xojo’s options for sharing code between those projects really suck, and this has to improve.
Right now, for a version control project, the best I can do is manually copy things from one project to another. This is of course hugely error prone. Saving a project item as XML isn’t really viable because it’s only mildly version-control friendly. Version control projects can’t share nested project items, because project items don’t have their own manifests, as Xojo projects use project-level manifests. This also makes sharing code with git submodules or subversion externals pretty difficult. I’ve made apps in the past to manipulate the project file as necessary to make these work better, but overall, the experience still sucks.
I haven’t opened a feature request yet because I’m asking here if there is one already. But this post is less about the request itself, and more about trying to get Xojo’s attention on the issue. They don’t make the IDE or Feedback for multiple project types, so this issue doesn’t really bite them like it does the community.
I think in magical fairy world, I’d see this problem solved by not solving it. Instead of sharing code between multiple projects, I’d rather Xojo support multiple products in one project. Let me have my mobile and desktop project items in one project with checkboxes in the inspector so I can choose which products each belongs to. Thanks to workers, a little bit of this work has been done already.
More realistically… I don’t know. We probably need a new version control format to make this a reality. I think the IDE would have to communicate changes between project items shared between two projects open at the same time. It might actually be more complicated than supporting multiple products in a project.
But anyway… let’s get some attention on this issue. Let’s get it on the roadmap. This is a problem that’s gone unsolved for far too long.
For example if you make Canvas based control. Then you put that in one repo.
Then you make 2 apps that use the Canvas based control.
Then the git repo for those 2 subscribe to the Canvas based repo.
And its manual opt in regarding versioning with submodules so each of your 2 or more apps can choose when it wants update of your Canbas based control. Which makes it possible to have 2 applications on version 2 of your canvas based control while your 3rd app could be at version 1 if you wanted.
(Xojo project type would of course need to be text based)
Yes, it’s technically possible. Unfortunately this falls apart completely for nested project items, such as classes in a module. Since the manifest is the project file itself, there’s no way to keep that in sync. If I were to add a class to the submodule, the consuming repo wouldn’t see it. The consumer project needs to be manually changed to match. That’s what my app would do for me, essentially blending the manifest of one project with another. The experience is less than ideal.
Edit: Oh an if both your projects are in the same repo, submodules aren’t an option. Symlinks I guess? But that has the same problem as submodules.
I don’t know if this is really “magical fairy world” stuff. I actually hope it’s the eventual goal. You should be able to add new build targets to a project and, when you do so, a section should appear for items specific to that target, with shared code in a Shared section. This would really fulfil Xojo’s ultimate promise, doing what Xojo does best, shielding us from the technicalities underneath, and leaving us with a simple UI that enables us to build for multiple targets.
While I’ve wanted this for a long time, I’m beginning to come around to the fact that this might actually be the most practical option. Make no mistake, this is no small task. There’s some details that I think Xojo would prefer I not go into, so I’ll keep it to myself, but things like the Library showing project-specific controls and the New Project window both come to mind as things that would need to change.
All that said, the IDE is already doing this. I mentioned the Worker class, but that’s exactly what this is. A separate product that contains a subset of the project items. So it’d really be a lot of IDE work, as far as I’m aware. I wish I were able to work on it.
Even beyond the need for multiple target platforms, this could be really beneficial. Imagine having both a full and demo version of the same app in one project, differentiated by what it contains. I personally wouldn’t do this, but it’d be an option. It makes me think we’d probably need an #if ClassExists(ClassName) syntax too. Which honestly also makes my mouth water.
I’ll weigh in here saying that I too think it’s really important that this issue gets some attention.
The biggest pain point I experience daily is the fact that you can’t externalise a module if it contains classes or other modules. If you have a single module or multiple classes and externalise them then it works pretty well.
A good example of this is my MarkdownKit module. This has many classes. A naive programmer would just stuff them all in a single module and copy and paste them into all of their projects. Ideally I want to externalise that module so when I fix a bug in any of the projects using it I will see that reflected in all projects.
What ends up happening is I have to prefix or suffix my classes and stuff them in the global namespace if I want to externalise them. That is just a little gross in my opinion.
I’m a little surprised this hasn’t received more comments than it has. I am finding this is a pain point for myself as well. I am having some difficulty managing external code since classes cannot be contained within an external module.
For me, it would be nice if there were even an external library type project that can be created, allowing me to embed classes and modules, which then can be referenced from a single name space in other projects. I am finding that I am not wanting to add classes (when I should) and instead using dictionaries for things because I am afraid of having just too many external references.
BTW, @GarryPettet thank you for your YT videos showing how you manage external code. It really helped me understand how to make it work - I didn’t know about the option+ cmd drag or see a menu item that does the same (though, it might exist and I haven’t found it yet). I hope you decide to produce some more videos on advanced topics - they are very well done.
I know this is a long running issue, but I hope Xojo sees this and can mark this as a usability issue / feature that should really be part of the platform.
You could drag a folder to the navigator, choose shared, and all resources and modules and classes would be available in a tree (sub-folders included). What it does? Nothing. Just stays there to be used by another feature, referenced content.
Drag a class from a shared folder to a Module for example, it will not copy that class, it will create an reference to that class found in some file.xojo_code found in that shared folder tree. It will look like a copy but only edits in the original file. And such class gets compiled, while the contents of shared folders and subfolders are mere libs there, to link to those referenced contents somewhere in your code.
Problems? Circular reference detection. When A includes B and B includes A at some inner level, like A->B->C->D->E->A
That should work for various kinds of contents and resources, not just classes.
Entire modules, Entire Folders, Images, etc
It would be the Xojo version of “Include” with some atomicity of the content.
I’ve been using XML external objects, and it works “OK” (which is to say, not terrible, not great). My situation is a client/server app where I definitely want 2 separate IDE Project files, but they must share a lot of code. I often have them both open in the IDE and debug / run both of them at once.
I’m a one-person shop, so fortunately I don’t have to worry much about DIFFing the XML format, since XML sucks as a source-code format.
I use SVN via a Cornerstone interface.
+1e6 to this feature request - I think we could, with only a few small tweaks, be able to use the native Text/VCP format for external items instead of XML.
This would not be perfect, but would get me 95% of where I’d want to be with shared code…
(Fun fact) I actually have a project where one tool is built using REALStudio 2011R3, and I’m able to share this source code with my main App built using Xojo 2019 or later.
This works suprisingly well, with two problems:
REALStudio 2011 was a 32 bit app, so I can’t run it on macOS 11 or 12. Solution: I run macOS 10.14 (Mojave) in a VM.
If you edit the source file in a later version of Xojo, it will update the version string, which will prevent REALStudio 2011 from opening it. A quick text edit in BBEdit to revert to the prior version string fixes it.