Would it be possible (and useful) to have some command line options for the Introjucer that would do some stuff without user interaction (some simple getopt would be nice), what i’d like is to have the BinaryData rebuild in case of any of the resources changes, so i could run the Introjucer with a specific update switch on a custom build step in VS. I have some XML files as resources and each time i change the XML i need to rebuild the project in Introjucer, same for images. That would help a lot i think.
It already has some command-line options - if you have a look in jucer_CommandLine.cpp you can see what it can do. Let me know if you think of any other stuff that could be added there!
Well the -resave option looked promising but it’s impossible to have it as a pre-build step, as it modifies the project itself and then all sort of weird stuff happens in VS. If we could only -resave-resources that would be better for this situation only one file would change and VS would not go all weird.
Sounds like a good request, thanks!
How about a Browser Plugin project generator?
Will think about it, but probably not high enough priority for me to do right now.
Simple request (not project related though): a progress bar or any other moving thing when saving a project. Else I never know without looking at the terminal window if it’s done or not, especially useful for projects that copy a bunch of modules around. (first time I tried it on linux yesterday I thought I crashed it).
Hi,
Don’t know if this request fits here…
Anyway it would be nice to improve code editor: font and font size selection, maybe syntax style templates if possible and ability to open file in external editor (or vi like movement)…
Thanks, bye
EDIT: I see that open file in external editor is there, but it opens in default editor - so I change my request to: ability to open file in custom external editor.
Yeah, I’d love to have some time to spend improving the editor! Hopefully one day!
Jules if you try this editor you will be shocked…best editor I have ever seen. This thing blows the doors off any other app. I tried opening a 40 megabyte file and the performance was amazing. It also looks awesome. If you can figure out how to get the TextEditor in Juce to work like this, it’d be really cool.
I’m of course only talking about the actual text editing. The “minimap” (zoomed out preview), gutter area (collapsible text blocks), and side tree navigation are great too but I’m only talking about the editor.
Yeah, I’ve heard a lot of good things about that editor. Unfortunately I’m fairly stuck in Xcode because I use it for debugging 
The output directory for the compiler, linker and the project are set to .\Debug or .\Release. If you create an x64 configuration, it will cause the files for win32 and x64 to be written to the same place.
You can improve this in two ways:
Use (intDir)[/i] and [i](outDir) for the output of the compiler and the linker, so there is only one setting (project / general / intermediate directory) that needs changing.
Use $(Platform)$(Configuration) for the intermediate and output directory of the project. (This will expand to something like win32\Release.)
–
Roeland
[quote=“roeland”]The output directory for the compiler, linker and the project are set to .\Debug or .\Release. If you create an x64 configuration, it will cause the files for win32 and x64 to be written to the same place.
You can improve this in two ways:
Use $(intDir) and $(outDir) for the output of the compiler and the linker, so there is only one setting (project / general / intermediate directory) that needs changing.
Use $(Platform)$(Configuration) for the intermediate and output directory of the project. (This will expand to something like win32\Release.)
–
Roeland[/quote]
Well, there’s a “Binary Location” setting for each config that lets you choose any folder you want for this. I guess I should make it smarter about choosing a default when you leave that field blank though…
…actually, the default folder is already based on the name of the config, so the problem you mention would only happen if you give all your debug configs the same name. And since it automatically gives new configs a unique name, this should never happen by accident (?)
Hi,
Visual Studio has a list of configurations (in my case “Debug” and “Release”) and a list of platforms (“win32” and “x64”). If you build you choose a platform and a configuration, I don’t think a Visual Studio project usually (?) has separate configurations for win32 and x64. The introjucer only adds the win32 platform, so I added the x64 platform in the configuration manager by copying the settings from win32, which includes the intermediate and output paths.
I tried setting a location under Debug/binary location, but in VS the intermediate location for this config is still “.\Debug”.
The other thing is the duplication these path settings. Under C/C++\Output Files, the file locations here should be set to "$(IntDir)" instead of ".\Debug". Similar for the linker settings, the Output File should be something like “.$(OutDir)\program.exe” instead of “.\Debug\program.exe”. This way it is possible to change all these directories in one place, the Output and Intermediate directories under General. ($(OutDir) and $(IntDir) are macros that expand to these directories.)
–
Roeland
Are you definitely using the latest version?
I would like to see the following:
- Ability to use IntroJucer to create a project that doesn’t use Juce at all. There should be no AppConfig, or modules, or any extra junk copied to the output except for the platform-specific projects and the .jucer file.
Okay I’ve been playing with IntroJucer a little bit more. I’m not done yet but what I think I want is that when you uncheck all the Juce modules, saving the project should not create the “JuceLibraryCode” directory in the file system (and everything in it) and also, the resulting Visual Studio project file should not have a “Juce Library Code” group in it.
I’m going to ignore this question for now, while I get a release done, but I want to have a good think about how to get 3rd-party modules nicely integrating in the future, and this will be the kind of thing that’ll involve.
I strongly disagree: I make thorough use of this setup.
Although Jules says he’s going to ignore this for now, perhaps a compromise of leaving it up us coder/users is better (freedom of choice?); a toggle button in the Introjucer allowing the setting such in the project or not.