Introjucer feedback

Hello JUCErs!

We're interested in getting your feedback on the Introjucer ... so I've made this as a place for you to voice your opinions. It'd be much appreciated if you could use the following format:


  • ...


  • ...


  • ...

For any dislikes, please try your best to suggest how it might be improved. Please be as specific as you can, as saying "it's rubbish" without any points for improvement isn't very constructive and doesn't help us fix it!

I look forward to hearing your comments, big or small :)


‚ÄĘ If I use a local copy of the JUCE modules, every time I resave my project it overwrites my local copies. I would like an option to retain my local copies.

Thank you! :)


  • integrated jucer (even if jules doesn't use it anymore, this is still¬†fantastic¬†tool for plugin-GUIs)


  • no rename-able exporters
  • no overview table along different exporters/configurations
  • unintended adding of files to¬†resources!!¬†¬†
  • ms visual c++ modifies the project¬†xml-document (adds¬†blanks), this can be problem with source code management tools (there was a thread somewhere)


  • compiling inside introjucer¬†

‚Ä謆(i may update this list in the future)


A few questions / notes:

  • By intergrated jucer, do you mean the GUI editor?
  • Overview table?
  • Why would you want a renamable exporter?
  • I agree with you on the resources thing! ;)

Thank you very much for the feedback! :D


  • One of the best tools in the market to ensure that a project done with JUCE can be compiled without harm on all the platforms, or to create a new JUCE project and to have all the dependencies and project options correctly configured. In my freelance jobs, I have all the time serious problems just to be able to compile a project done by someone else when it is noit done with JUCE. With JUCE only, it is very often without any pain.
  • I use a lot the included tools such as the text translator or the utility to convert ressource files directly inside the Introjucer


  • I have to change the default folder for the VST SDK 2.4 each time I create a new project, it would be logical to save this information once and use it again for new projects, the same way it is already done for the juce modules location
  • It is sometimes painful to update the JUCE SDK in a current project, since saving the project in the Introjucer overwrites all the project options, such as the new files added only in the VS / Xcode project files, the compiler options, some of the extra librairy dependencies etc. But it was more painful a few years ago I have to say.


  • I would love if the Introjucer is able not to replace some information from the project files when a project is saved inside the Introjucer, such as the compiler options
  • I would love if the Introjucer is able to retrieve some information from the project files and update them in the Introjucer files
  • I have never used the GUI editor since I do a lot of custom components, but I might try it again one day

(I might update it later too)

  • Regarding the VST folder issue, we actually have something for this already! Clearly it's not easy enough to find though, so we can improve that. For now, it's under Tools -> Global Preferences.
  • I'm not sure what you mean by your second dislike, could you elaborate for me please? :)
  • As above, for the first "Other"

Thank you very much!



I think I don't have the last version of the Introjucer so, I will check this out ;)

For my second dislike remark , what I meant is that the changes done in the Introjucer are updated to the VS and Xcode project, but that might be useful to do the same thing in the other order, from VS to Introjucer for example, since I don't use the Introjucer often once the project has been created. Moreover, I change a lot of compiler options in VS2013 which are not supported in the Introjucer, and changed into their default values when the introjucer project file is saved.

Ah yes, now I see what you mean.

We'd love to do this, although it's extremely difficult and time consuming, so it'll take a while should we decide to do so; just look at how many different settings there are in Visual Studio! I'll have to give it some thought ...

Out of interest, what sort of compiler options are you changing in Visual Studio?

Thank you again!

Mainly all the flags for the optimization in the code generation category... But for a starter, being able to update the source files included in the project and their hierarchy from VS to the Introjucer would be great !

Ah yes, I've encountered that personally. It's still hard to generalise, but not as hard as getting the whole lot done. Noted!

Thanks again :)


heaps of stuff, but nobody ever really remembers the stuff they like, do they?  

But seriously it's great.  For me, as someone who is learning JUCE and C++ at the same time, it has given me the confidence to dig deeper into coding, and an easy way to actually visualise and interact with the code i create.  If it wasn't for JUCE and the introjucer, i'd still be stuck printing things out in the console.  But instead, i am opening FileChooser dialogs, loading waveforms into buffers,  drawing those on components, and generally seeing that it is possible to get things running.

This forum is super cool, and even though i know close to SFA, everyone has been pretty patient with my questions. 


ok, now this is easier ;)

first up....i thought this was a "feature", but recent searches on this forum suggested that perhaps it's a bug:  when setting up a GUI application on my OSX machine, i don't get the GUI editor grid and tools for the mainComponent.  I have to delete the existing mainComponent, and then add a new one with the same name to get it working.


If i had the time and knowledge, these are 2 things i'd try to do to hack the Introjucer to make it better suit me:

I'd love to have the option to deselect the calls to methods which are automatically added by the introjucer.   One example that i recently came across, was that i wanted to code my own resize method, but there was no way to disable intojucer's automated resize call.  It'd be pretty handy if you could turn off the calls to each GUI component through the little menu box that you get for adding the class arguments, etc. 

here's that thread: ( )

super lazy, but i like CTRL+D as a "duplicate" function.  So, if i have a slider i want to duplicate, i don't have to CTRL+C, CTRL+V.  The way i like it is if the duplicated object ends up about 20 pixels down to the right, and then automatically selected, so it can be grabbed and moved easily. 


thanks for all your good work, and for helping me get into coding!


Glad you're having a good time with JUCE and C++!

Regarding the GUI editor thing, it was intentional behaviour, however I've just had a chat with Jules about it and we've agreed to change it to do what you want. I can't say when it'll be done (as we have a lot on our plate at the moment!), but it will indeed be done.‚Äč‚Äč

I've just read that resize thread, and I can't see any harm in adding the option. Will have to discuss this with the others when the time comes though to confirm it.

As for Control + D for duplicate, sure thing! It might not be exactly 20 pixels away, but I'm sure we can work something out that's suitable ;)

Thank you very much!

completely dislike the whole non-library-concept of JUCE. Instead of having to fiddle arround with a GUI I would rather like to have a JUCE project which is completely independent of my own project; that can be hosted on its own SCM and can be updated whenever a new JUCE version is out.

I don't like the idea of defining features in a header file controlling what will be included. I can choose the header files by myself I need, if those are hierarchically including what they need itself.

I also don't like that the introjucer places file copies somewhere, preferable inside my project tree. Why would I ever want to have a separete copy of those files?

Currently its a drag to build a library based on JUCE. The JUCE features needed would be need to known at library build time and therefor defeats the idea of a library.


JUCEs concept here re-invented the wheel but not as round as the currently rolling ones. But one who like to use the round ones needs to install those JUCE wheels as well...

yeah was mainly suggesting that duplicate should have SOME offset.  20 pix was kinda abitrary ;)

also, something else i just thought of that should be super simple, if you want:

i almost ALWAYS go into the main document window patch, and add "setResizable (true, true)" .  Might be easy to have that sort of thing as a clickable option in introducer? 

Fair point about the resize thing, I'll have a think about this.

Thanks again! :)

Could you elaborate a little on the first point? People use JUCE in their own source controlled projects all the time (using things like git submodule). This might also help with your library development problem (although be wary, this is a legal landmine due to the GPL).

Thanks for the feedback! :)

The concept of the introjucer is good and well implemented.



Fast and easy way to maintain cross platform projects.

Organized well.



No method of controlling pre-compiled headers. I have a very large project  (six apps from the same source) and every time I use the Introjucer, I have to reset the pre-compiled headers for each app. Windows only.

Introjucer should provide a browser to point to the paths. Typing in manually is way, way, old school.


Regarding the "browse to" comment - do you mean something like "open in explorer"?

Thank you! :)

How would you reference to an externally hosted JUCE SCM if there is not even a JUCE (library) project to reference to? Yes, there are workarounds, and finally people ending up having copies or generated files out of the JUCE SCM in their projects SCM.

I cleared my "Juce Library Code" folder to only contain JUCE.h and AppConfig.h and reference everything else from my library project and the external SCM. But this is all setup manually and can't be updated by running the introjucer.

The only thing I want in my projects SCM is a reference to the external JUCE SCM (i.e. git submodule or svn:externals) and a link in my project to the JUCE sub project, maybe some JUCE configuration files if really needed - but they shouldn't.

When building a juce based library an AppConfig.h must be given. As the name suggests AppConfig.h is pretty application dependent though.

I am not sure how it is for Applications but JUCE based Audio plugins must directly reference JUCE source files. I understand its not easy to put some of the functions of those files inside a library though, but this additionally makes maintenance harder. (not if you only have a single project...)