I strongly disagree: I make thorough use of this setup.[/quote]
Hey…don’t quote me out of context! I’m referring only to the case where none of the Juce modules are checked!
I should’ve mentioned that I do exactly as you mentioned; none of the Juce modules are checked in my projects.
But would rather have some reference to the files, so my post still stands accordingly.
I should’ve mentioned that I do exactly as you mentioned; none of the Juce modules are checked in my projects.
But would rather have some reference to the files, so my post still stands accordingly.[/quote]
Yeah but what about when you turn off the option to copy the module sources? Anyway, if IntroJucer is going to add that group it shouldn’t do it in secret, it should make it visible in the IntroJucer tree.
My mistake; I understood “create local copy” of the modules is checked off in the first place… :?
When “Create Local Copy” is turned on, IntroJucer should add a specially marked group for “Juce Library Code”, so that you can see it in the tree. Clicking on this group could add additional options.
No, I wasn’t. I went to Sourceforge, where 1.53 was the latest version at the time. Sorry for the confusion.
I just downloaded juce 2.0, and all the intermediate paths for the compiler and linker are set to the binary directory as expected. It would still be easier if they are not set at all, I did a quick test by commenting out the lines that set these directories in jucer_ProjectExport_MSVC.h and VS2010 will fill in $(IntDir) by default. (I don’t know for the older versions of VS though).
–
Roeland
Could we specify the path of a file, or drag and drop it, instead of a drop-down list, in order to select an Icon under the Introjucer?
Well not really, because the icon needs to be a member of the project before it can be used.
export for codeblocks.
By the way, how come that when I add my png files in a “Binary Data” folder inside the project folder, and inside the different build folders (just like the juce demo does), my “Icon” drop-down list is still empty inside the introjucer?
No idea!
[quote=“StagiaireINA”]
By the way, how come that when I add my png files in a “Binary Data” folder inside the project folder, and inside the different build folders (just like the juce demo does), my “Icon” drop-down list is still empty inside the introjucer?[/quote]
The project overview page needs to update before it recognizes a new image in the project’s binary data. You can do that by clicking on a folder/source file etc. and back to the project.
Chris
I’ve tried this… Also tried to close the introjucer and re-launch it. I don’t understand why I cannot add an Icon to my project.
In fact I don’t really care about the icon, it is just that I am trying to run the Juce HelloWorld example for Android. When I try to build it under eclipse, I get the following error comming from the AndroidManifest.xml:
error: Error: No resource found that matches the given name (at ‘icon’ with value ‘@drawable/icon’)
That’s why I’m trying to set an Icon via the introjucer before rebuilding it.
Hello Jules,
Would that be possible to find a way so we can include files in the “resources” folder that’s in the Xcode project ?
Actually, manual additions are overwrited by IntroJucer…
Thanks,
Salvator
I know you’re probably already on this Jules but there has been quite a bit of discussion around including 3rd party modules in the Introjucer. Personally I have a pretty good setup for my needs but there are instances when symlinks aren’t really an elegant solution. Would it be possible to add additional module search paths? This way the Introjucer can know about modules not directly in the juce directory.
I guess the “Module source folder” option could be replaced by a list of folders but there could be some complications if multiple instances of the same module get included. A simple solution may be just to prefer locations higher up in the list? Having said that the current Introjucer just shows the module twice if there are multiple copies which seems to work fine.
Anyway, thanks for taking a look, I’m sure its already on your radar.
Just to add to this, its important that there is a way to add module search paths, with the settings for those path saved in the .jucer file and not in some machine or user specific registry setting. Otherwise, it is not possible to have a self-contained repository with the module sources.
Would it be possible to add an option for using namespace declarations? At the moment the JuceHeader includes the “using namespace juce” directive but if people are using lots of 3rd party modules it would be nice to be able to specify the namespaces for some or all of them. This could also do away with the DONT_SET_USING_JUCE_NAMESPACE macro and just include the juce namespace as default for Introjucer projects.
Seems like a fairly simple feature to add and would save a lot of hassle when using 3rd party modules. Thanks.
Surely you could just add any “using” declarations in your main header file…? Not sure I see why it’d be better to use a tool to generate them?
I don’t use a common header file for a lot of small projects. I tend to use the Introjucer a lot to quickly generate small test projects when i’m developing a new feature (as I’m sure lots of others do). I thought it would just be quicker and simpler to keep all the using declarations in one place.
I did think about putting them in the USER_CODE_SECTION but obviously the namespaces aren’t defined at that point in AppConfig. How about a similar section in JuceHeader?
I know the Introjucer is becoming rather large but it really needs to be, to be as useful as possible. Perhaps you could have a simple and advanced mode so as not to confuse new users?
-1 to that, a using-directive in the global namespace is discouraged, but a using-declaration is fine.
A third party module that uses JUCE should put the using directive in its own namespace, like this:
namespace non_juce_module_namespace
{
using namespace juce;
// module declarations
}It’s neither practical nor desired for IntroJucer to muck with the global namespace in the manner you suggested, or to automatically generate the using directive above. Portions of third party code may need to prevent the juce namespace from being lifted, to avoid symbol conflicts. Your suggestion would make that complicated.