Avoiding having to use Introjucer


#1

Has anyone come up with a good workflow to set up Juce-based projects without using the Introjucer? Or has Juce just become too complicated to be used without the Introjucer? :( (I remember the times when things were much simpler, before the Juce modularization happened...)


#2

I've not created a project without the Introjucer for a while but I would imagine it's easier now then ever before? Just:

- Include the module cpp files you need in your project

- Create an AppConfig.h file with any module definitions you need and define JUCE_MODULE_AVAILABLE_juce_module_name to 1 for all the modules you are including

- Optionally create a JuceHeader.h file which includes your AppConfig.h file and all your juce module headers for easy inclusion.

 

If you need events you'll also need to set-up the message system and make sure you dispatch them:

- In your startup code create a ScopedJuceInitialiser_GUI object and then make sure you pump the message loop. (Take a look at JUCEApplicationBase::main() for what generally needs to be done here).

 

Is there any reason for not using the Introjucer though? I've yet to hear a valid reason from anybody against the Introjucer so I'm curious as to what your use case is.


#3

How's JUCE complicated to setup? Is it because you're used to the defunct amalgamation?

And why would you want to avoid Introjucer so badly? Alls you need to do is run Introjucer, make a project, drag your files into it, add the correct exporter, save the project, run your favourite exporter's generated project... and that's pretty much it to get started with the least amount of effort.

I'm with Dave: totally curious to hear what your use case is to avoid it so.


#4

I dislike using Introjucer because it adds hassles to starting a new Juce-based project, making it tedious to do "quickie" projects. Using Introjucer is like having to use a separate IDE...Except that Introjucer isn't really an IDE, just an additional annoyance.

I dislike how Introjucer copies the Juce source code by default into the new project directory. (Yes, I know this can be prevented but it's yet another thing that one might forget to do because of having to use an additional tool like Introjucer. What is the point of copying the Juce source code anyway...? It makes updating the Juce source used by the project more complicated.)

I dislike how Introjucer complains it should be recompiled when I've updated the Juce source code.

I don't use the Introjucer GUI designer and it seems using it wouldn't be useful anyway anymore because it doesn't cover all the GUI components now available in Juce.

Introjucer doesn't really do anything useful for me except stuff that could be handled without having to manipulate a GUI. If only there was some GUIless method to do it...(I guess I have to look into writing some scripts or something myself to do that...)

Sorry if this sounds negative, but I just had to write about this.

 

 

 


#5

...when ever you begin manage big-multiplatform projects (and this is the main reason i use JUCE, cause its multi-platform) (+ different plugin/versions/architectures) with lots of dependencies, introjucer is a big time saver. Without Introjucer i doesn't even know how i would able to manage all my projects, it would be just impossible i think. There are so many possible configurations  and compiler settings and things which can go wrong.

I mainly start introjucer always directly from the IDE, so i the recompile thing doesn't matter for me (its just takes a few seconds anyway)

I agree that the code copy should be by default turned off.

 


#6

I agree that the code copy should be by default turned off.

Agreed - I'm going to change that.


#7

Hi Xenakios, I have to disagree with almost all of that, for me using the the Introjucer is by far the quickest way to create a "quickie project". Even if you take away all the JUCE module stuff the lines of code required to open a window and create a content Component would take you way longer to type than creating a new project with the Introjucer "main window" template.

I do agree that the copy method should be off by default. Sounds like Jules is on that.

I dislike how Introjucer complains it should be recompiled when I've updated the Juce source code.

I think you should heed this, it could avoid some very difficult to track down bugs. Recompiling the Introjucer takes less than a minute, perhaps you could write a script that compiles and copies it to your app dir? The above comment is like saying "I dislike it when my compiler gives me warnings".

I don't use the Introjucer GUI designer and it seems using it wouldn't be useful anyway anymore because it doesn't cover all the GUI components now available in Juce.

Me neither, I think it is just in there for legacy reasons and could be useful for users new to JUCE. I actually find it quicker to code Component positions and graphics these days now we have awsome classes like Rectangle, Point and Line. There's also way less bloat and it's a lot easier to maintain and reason about.

Introjucer doesn't really do anything useful for me except stuff that could be handled without having to manipulate a GUI. If only there was some GUIless method to do it...(I guess I have to look into writing some scripts or something myself to do that...)

You can! Introjucer can be used as as command line app, take a look at "jucer_CommandLine.cpp" for details but to be honest if you've made a change to the project so that it needs resaving you almost always have the gui open anyway. I can't imagine trying to control a project structure from the command line.

 

As chkn says, if you've ever had to manage a project that spans more than one platform the Intojucer really comes into its own. Having a "master" project that you know can re-generate everything else is a great help, especially if you have other contributors.

Sorry if this sounds a bit ranty, it's not meant too, I'm just a big fan of the Introjucer and don't want people to be put off by it when it will likely save them lots of time.


#8

I agree that the code copy should be by default turned off.

well, you mean when the juce code is already in there so that's it's not getting overwritten?

but it should be copied the first time no?


#9

No, that's not what this is talking about. We mean whether the modules should contain locally-copied source code or not.


#10

yes, I was thinking about local-copy too. saying that what annoys me is that the introjucer will update the locally-copied code everytime I resave the project.

 So everybody here generally avoid local copy? how do you manage your projects?

I mean, if you got a super stable version of your soft/plugin that you have released, don't you prefer to have the juce code within your project rather that having your project linked to the tip?

 


#11

I avoid local copies completely.

JUCE is generally stable, so you may as well keep striking while the iron is hot. Also, nothing stops you from waiting to pull on the repository until you're satisfied with whatever JUCE code you're looking at: you can always take a look at the commits on Github to see what Jules is up to.

It's also good to know that all your projects stay on the same page with less hassle, assuming you have multiple on the go.

And I'm not really seeing an advantage of keeping a local copy of JUCE with a project, unless I'm hacking something... but that's really not my thing, seeing that whatever I'm doing could be brought here for either the better of JUCE, or be shown that I may be going about whatever it is the wrong way.


#12

I think you should heed this, it could avoid some very difficult to track down bugs.

+1, I had the weirdest bug where opening a FileChooser crashed the application on OSX and updating the Introjucer magically fixed that, so from now on I listen to this warning more carefully.

And am I the only person that still uses the GUI designer? The standard widgets can be added so easily and for every other component there is the "Add Generic Component" that does the job quite well.

Of course there is stuff which I have to code manually, but I would say that 70% of my interface is based on the Introjucer.

But having something like the Projucer would be great (it got a bit quiet regarding this project, but great to hear it isn't abandoned)