This thread is strictly for discussion related to the requirement that IntroJucer is required in order to do any practical development. I’d like to consolidate all of this information in one place for Jules to review. Here are some of the problems that loom on the horizon:
[size=120]extras/static library/ projects will no longer be maintained.[/size]
Jules has expressed a desire to stop providing these projects. Although static linking is discouraged and one can easily put the handful of module .cpp files into their project, an issue comes up with Visual Studio. The full source tree is not available, so browsing or opening individual sources to read the headers or set a breakpoint is not possible. You would have to use Explorer to browse, and external tools to perform a Find in Files.
The official answer is “just use IntroJucer” since it has an option for including the source tree. That would make IntroJucer REQUIRED to do any real development work.
[size=120]Third party modules will require IntroJucer to use.[/size]
If the official position is that IntroJucer is necessary for using JUCE, then by extension and habit third party modules will inherit this dependency. Developers will have no incentive to make modules usable independent of IntroJucer. The target audience for third party modules will shrink.
[size=120]IntroJucer will never fully support all native IDE features.[/size]
Every IDE offers a wealth of specific features, that IntroJucer couldn’t possibly hope to replicate. Pre/Post build steps, property sheets, inherited project settings, and a wealth of other features that do not (and should not) exist in IntroJucer. By making IntroJucer a practical requirement for JUCE development, we exclude all use-cases that contemplate the usage of IDE-specific features. This means that anyone with an existing workflow which uses IDE specific features not supported by IntroJucer will automatically be excluded from eligibility to use JUCE in practical terms.
I made a suggestion that it would be very handy if IntroJucer could import as well as export IDE-specific project files. This would be quite frankly, amazing. Imagine working in Visual Studio with a native project file, making all the changes you want, and then running IntroJucer with a command line switch to create an Xcode project from your existing Visual Studio 2010 project! That would rock! But Jules has stated that this will never happen. This is concrete evidence that IntroJucer will forever offer only a subset of functionality available in native IDEs.
[size=120]Programmers are very picky about their toolchain.[/size]
An average user might grumble about an update to Microsoft Word or new Photoshop features. But programmers can be exceptionally sensitive to changes in their preferred workflow, especially when these changes are forced on them. Just look at the outrage every time Microsoft foists a new API on developers, or screws up Visual Studio.
As programmers, we are creatures of habit. We also tend to stick with something that works, especially when it already has significant inertia. Providing new, additional ways of doing things while preserving existing functionality is cool! But forcing a new way to do something we are already used to doing our own way is a no-no (especially when the new way is incompatible).
[size=120]PRACTICAL development is hindered when IntroJucer is required.[/size]
By “practical” I mean, the ability to easily integrate JUCE into a new or existing project without IntroJucer, and the ability to conveniently apply updates from the JUCE tree into an existing project without IntroJucer. Of course, in theory it is always possible to do so without IntroJucer, but the hassle of needing to manually keep track of what files Jules decides to add, move, or rename and update a project file is needless work (replicated across multiple developers working independently).
I know there are a lot of lurkers in the JUCE forum who would be adversely affected by the requirement that IntroJucer become a part of their toolchain. Now more than ever, we need you to speak up in this thread and explain how this change would adversely affect your development. I don’t mean to disparage IntroJucer - its a GREAT way to get a plugin or application up and running, and it simplifies development for a broad class of JUCE users. But making IntroJucer required for practical development crosses a line that will inevitably harm the JUCE user base.