Introjucer should use multiple "Module Source Folder"


#1

To support 3rd party moduls it would be great, if you could specify extra “Module Source Folders” instead of only one. Introjucer should automatically warn if there are duplications, and make an overview-tab of the available modules and there versions

[attachment=0]introjucer_add.png[/attachment]


#2

Yes… but doing it like that would lead to a bit of a tricky situation in the exporters. At the moment, each exporter has its own modules path, because obviously each exporter may be running on a completely different machine with a different file-system. So if there are multiple folders, then each exporter would also need multiple local paths, but even if the exporters also had multiple paths, they’d also need to know which module lives in which of those local folders… All a bit messy!

I’ve been mulling over the best way to handle all this, but it’s tricky. Ideas welcome!


#3

Something like a ModuleDirectoryManager - a Local-File-System-Abstraction-Layer which is used by the exporters instead of operating with the local file-system directly …


#4

huh? How would that work?


#5

the exporter uses not the modules path, instead it uses a ModulesManager to iterate trough all available modules.

ModulesManager.getNumAvailableModules()
ModulesManager.getModule(i).getVersionNumber()
ModulesManager.getModule(i).createrLocalFilesystemStructureForModule()

The ModulsManager itself stores links to the localFilesystem / external Links / Git repositores / internet

ModulesManager.addModuleSourceFolder();
ModulesManager.addModuleSourceWebLocation();


#6

no, you’ve totally misunderstood…

It’s trivial to get a list of the modules - the problem is that if you’re running the introjucer in e.g. OSX, and it’s saving a VC project, it’s impossible to know where each module will be on that target Windows machine. But the VC project has to contain these paths.


#7

Yes, they should be on the same relative file path, something the user has to care for. Of cause different drive letters wouldn’t work. Introjucer should warn in this case.
Another possibilty would be, that you can define different source directories for every exporter, like in a matrix.


#8

Yes, unfortunately when you have multiple folders you do need a matrix, which is all a bit of a PITA. It’s already annoying to have to set up each exporter’s modules path, but if each exporter needed to contain a list of folders, plus settings to indicate which module lives in which of those folders, it’d be quite tedious keeping all those settings up to date.


#9

I see the problem, and there is no obvious solution.

Just make sure that when you do figure it out, that it will be possible for each .jucer project to have one or more .jucer-relative paths for modules so that I can make my repositories self contained.

What about making ALL module paths relative?


#10

I could certainly work that way myself, but I bet that people would moan if it was compulsory.


#11

I could certainly work that way myself, but I bet that people would moan if it was compulsory.[/quote]

Okay, how about this. Either all module paths are relative, and you get multiple paths, or you have a single absolute path containing nested subfolders of folders with modules.

What I’m saying is that if you insist on absolute paths, then you have to keep all the modules together in one place so the exporters only deal with one directory.


#12

That’s fair, but quite a complicated policy to explain to users, and to build UI for… Let me ponder on it; I also need to do some work on getting it to find + download 3rd-party modules, now that a few people are starting to create them.


#13

I think that you spread yourself too thin putting the download feature into IntroJucer. Was this necessary? It duplicates a functionality that Git already offers. You’re just one person. My opinion, take the downloading features out completely and let people use Git - leverage the power of all the development and work that goes into Git so you dont have to maintain a redundant feature.


#14

True enough. Though there seems to be no shortage of git-phobic people who use the downloader.

This is all stuff that I need to have a serious think about… It’s also relevant to the new secret stuff I’m working on; more on that soon…


#15

If you want to be the only person contributing to the official JUCE repository then you will have to draw a line at what you will, or will not, work on. Since your output is by definition finite. As a single programmer, I would think that you have to be absolutely ruthless about not reinventing the wheel. Because each hour that you spend replicating existing functionality, is one less hour for new innovating things (like secret sauce).

What did we gain from a code editor in the IntroJucer? No offense, but it can’t compare to existing editors. Not even close. I’m thinking SublimeText and Visual Studio. Those products are dedicated to one thing, and one thing only. So they will always be better. Since there’s no font hinting on Windows (yeah I know its a sore subject) all the text looks horrible. I built the JUCE demo and IntroJucer on Linux and WOW the text looks so much better! And where’s the parameter completion, symbol browser, etc… in IntroJucer? I’m at a loss to figure out what the target audience for editing code within the IntroJucer.

I also have my doubts about this. Without question, JUCE development has been considerably slowed in the last few months. Many items have been marked as “don’t have the time for.” I’m usually a very conservative programmer. I don’t like it when the tools change, and I have to be really sold on something before I accept a change in my workflow. This “secret stuff” seems like it is all tools. Which I will probably not use. I would much rather see energy directed towards fixing bugs and making improvements to the actual library code which ends up on in the final executable.

This all reminds me of the Inner Platform Effect.

On the other hand I certainly understand that after years of development on the same thing it is a welcome change to have something new and exciting.

Since I use git-subtree to bring in the JUCE repository I hope that we dont see the official JUCE repo swell up with a full copy of the LLVM source tree - it would be best in a separate repository. In fact, I wish that the JUCE source tree was its own repo, with the extras in a separate repo but I guess its too late for that now.


#16

Well, keep guessing and maybe you’ll figure it out! I also wish I didn’t have to write a code editor to do it, but it’s unavoidable to make it work. All will be revealed soon enough, and hopefully you’ll like the result.


#17

I figured it out a long time ago, and I’m sure its going to be really cool. I’m just wondering if it’s worth the cost.


#18

I figured it out before you did :mrgreen:

It’s Angry Juce Birds, right?

Bruce