PLEASE VOTE! Introjucer REQUIRED for practical development?

General JUCE discussion
1

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).

[size=120]Afterthoughts.[/size]

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.

2

I haven’t looked yet[1] but if the IntroJucer can be modified to output CMake lists, I could probably live with it.

[1] I could plead a long and miserable six months of dedicated PHP/JS coding and SQL tuning keeping me away from fun stuff, or I could just cop to being lazy on my weekends…

3

Interesting results so far, but we need a larger sample set to draw any real conclusions.

4

Agree. The statistics are a bit misleading, though, since the percentages are calculated relative to the total number of ticks and not from total number of people voting. The latter would make more sense, I think.

5

Very interesting thread!

What I’m doing.

As usual, I’m probably the only person doing what I’m doing (I put in a tech support request for my Javascript/Max For Live issue, and they told me, “No one else is doing anything like what you’re doing…”) so I should put it in here.

I have a fairly large number of source files for a one person project - and I also have automatically generated source files. So I have a Python script that takes the existing .jucer file, and replaces all the source files in it with files from my source directory tree - so that if I add a new file anywhere in the tree, it’s automatically added to the .jucer file.

Then I run the Introjucer as a command line tool as part of my “toolchain” - my “make”, in other words. (Thanks to Jules for having the foresight to build it that way! What’s funny is that when it runs, it does start up a GUI app, but never brings up a window, so I can just detect that I’ve reached that part of the build because the focus “flickers”.)

Even though I’m an individual developer, I have a moderately sophisticated toolchain. I use Google protocol buffers as my data interchange language (highly recommended), and they’re compiled into .cpp code which is compiled with my build.

And one of the properties I like to have in a program is “install-free” - you just drag the application to where you want it, the end. In order to do this, I compile in all my icons and similar small assets. Again, I’ve written a little tool to translate these files into C++ files that I compile in. (Yes, there are tools to link your files right into your binary but I couldn’t get them to work cross-platform).

Two Questions About The Introjucer.

First, should the Introjucer be needed at all?

Reasonable minds can differ on this one, absolutely. However, I think that some sort of active component that runs on the developer’s machine is needed - so it might as well be written in Juce, yes, rather than in some other scripting language?

Even Unix open source packages have “configure”, which is written in bash. Every non-trivial package needs to execute code on the target machine…

Tiny tweaks might make for big adoption gains.

The above is almost a non-question, because Jules has actually done the work to make this in Juce/C++, so that’s what exists.

The second question is more practical: how can the Introjucer be made more accessible to the “average developer” - particularly given that we only have a limited resource in a single Jucemeister?

I actually think that pretty tiny changes to the Introjucer would make it much more accessible to a wide range of developers.

I think that the real issue is the barrier to entry, and secondarily the maintenance of Introjucer projects, and both these issues can be neatly solved using a technique similar to what I already have written as Python scripts.

So you’d need a “create” mode for the introjucer with the following command line flags (or of course, GUI setters).

Jucer
  --create    # Main flag to show you're creating or updating a .jucer file
  --output=foo.jucer   # Required flag which shows where your results go.
  --input=foo.jucer    # Optional flag showing a jucer file to use as a template.
  --source_root=/foo/bar   # Where the source code is.
  --include="..."   # Optional flag - we only include files that match one of these patterns.  Default is *.cpp, *.h.
  --exclude="..."  # Optional flag - exclude any files that match one of these patterns.  Default is none.
  --create_main  # Create a main file in the top directory.

This would let you create or freshen a .jucer project automatically from a file tree you had lying around anyway. In other words, if I have an existing project and want to add juce, I can do it automatically in a single step without knowing anything about it.

I have code that more or less does this in Python, it wouldn’t be too hard to just build it into the Introjucer, and the ability for someone to go into their existing source code directory, type a command line, and get a working Jucer project is extremely strong.

6

not again :roll:

7

All I want out of Introjucer is a list of suggested paths for my include trees and a list of required frameworks and Juce modules. I do not want it mucking around in an already-created project file. I’ve got additional build phases, various scripts and necessary third-party tools hooked into the compiler/linker. There’s no way I’d expect Julian to look for every exception and to maintain all the odd conditions of a project. That wouldn’t be fair to him and even a slight problem could send one of us off into the weeds.

For first-timers, I can see Introjucer as a real lifeline. But many of us may be maintaining software for a considerable time. Our special requirements–whether security or something else–mean that our projects get a bit complicated. At that point we’d all appreciate a tool that can give some helpful hints. But that’s all.

8

It looks like the verdict is in, and the results are unsurprising: Many people find IntroJucer quite useful for what it does, but a significant number of developers have their own workflow which is incompatible with it. Therefore, requiring IntroJucer in order to maintain the JUCE source tree in your project is an unrealistic expectation - we still need the static library project.

It seems most would love the ability to take an existing IDE-specific project and export it to another IDE format. So the “killer feature” for IntroJucer is the one where a programmer gets to continue working in their favorite IDE and use their existing workflow, but IntroJucer can step in and produce IDE specific projects for other platforms. This requires reading a project file in addition to writing.

9

As a newbie, the introjucer has helped me in two ways.

  1. It fixed the right parameters, so my application would be detected as a VST-Instrument
  2. It made it possible to convert a (Juce) VS 2010 Project into a VS 2008 Project

But I have to admit, that I find the Introjucer somewhat confusing. Better documentation would come handy.

10

My objection is that, aside from the problem of an incompatible workflow, the use of IntroJucer knocks me out of “the zone.”

Having to switch to another app to make changes to my project, especially when that app does not behave like a native app (where’s the menu accelerators?), is a pain. Not to mention, I’m already used to 15+ years of a specific IDE and now I have to do something different? I’d rather pay the price all at once for making a new Mac OS / iOS / Android / Linux project slash Makefile if it lets me use my regular IDE throughout.

11

Having to switch to another app to make changes to my project, especially when that app does not behave like a native app (where’s the menu accelerators?), is a pain.

It’s not just a pain, it’s a pretty serious time-suck in rapid development. I often do “sprints” on software where I try to get a piece of functionality done in a first pass as fast as possible. This often means, for example, that I’ll just charge ahead with names that I know are suboptimal and files that are too large, and then fix this in progressive refinements - because it takes a few seconds to make these changes.

I used to spend a long time thinking out my names before I started - only to see that as the code developed, they’d get split up and the original name would vanish.

If I were to use the Jucer, even just to rename a few files, it’s several minutes’ work for me - and it’s mousing-heavy, something I like to avoid because mousing is what really hurts your hands. And you can make errors. I think it’s XCode where if you rename the source file, but forget to change it in the project, and the object file is not there, you don’t get an error…

And then I have automatically generated files, which I simply forget to include sometimes.

That’s why I have a script to do all of that now. As I said, I haven’t opened up the GUI version of the Introjucer in 2012 but I’ve made hundreds of changes to names of project files in that time.

As I said before, I think tiny changes to the Jucer to allow it to automatically construct or freshen a project, not even from project files in Visual Studio or XCode (which is a lot of work), but simply from file globs, would make Juce far more accessible.

12

[quote=“TomSwirly”]I’ll just charge ahead with names that I know are suboptimal and files that are too large, and then fix this in progressive refinements - because it takes a few seconds to make these changes…I used to spend a long time thinking out my names before I started - only to see that as the code developed, they’d get split up and the original name would vanish.

If I were to use the Jucer, …it’s mousing-heavy, something I like to avoid because mousing is what really hurts your hands. And you can make errors. [/quote]

Wow, everything you described is identical to my situation. If there’s one thing I hate its picking up the mouse during development.

13

I wouldn’t say I “hate” the mouse. I would say that I make heavy use of my hands, and if I use the mouse a lot, I feel it at the end of the day. This is well-known!

I’m also an emacs user so I can fairly fly when I’m editing - then I drop to a crawl when I’m mousing - and I make mistakes, something I almost never do when typing and can fix in a flash if I do.

This attitude we share is rare amongst civilians but extremely common amongst developers.

14

I am new to Juce, so maybe I haven’t got into the Juce mindset yet. It looks like Juce has some great stuff in it that will be really useful to me, but at the moment I want to use Juce as a library. That is to say, I don’t view my project as a “Juce project”. I view it as my own project with its own way of working, which links in Juce as well as a number of other libraries. Much as Juce looks to be really useful, I don’t want it to take over my project, or the main loop (I’ll post another question about this).

I just want to use Juce as a library, so I just want to link it in normally. Maybe this is just a newbie reaction, but I don’t want a separate app like the Introjucer changing my project files.

15

I’ve said this before in another thread, but I’m going to say it again. I wish the Introjucer could generate static library projects. That way I could just pull the latest changes to Juce, update the Juce static library project, and keep working.

I personally don’t mind using the Introjucer; in fact I think it’s really cool. But when I’m working on projects with dependencies on other projects, it’s impossible to use, and sooner or later, every project ends up having dependencies on other projects.

16

+1

17

I am fine with Introjucer, because I use it to create new projects only. From then on, I develop with XCode for both Windows and Mac (so no browsing problems here) and use VS 2010 solely for fixing Windows-specific issues (which are few).

Therefore I can’t confirm that Introjucer would even be a requirement. I use it once only per project, then (almost) never again. ButI don’t want to miss it! Without Introjucer, starting a new project from scratch would be a lot of hard work.

18

[quote=“Richard Shepherd”]I am new to Juce, so maybe I haven’t got into the Juce mindset yet. It looks like Juce has some great stuff in it that will be really useful to me, but at the moment I want to use Juce as a library. That is to say, I don’t view my project as a “Juce project”. I view it as my own project with its own way of working, which links in Juce as well as a number of other libraries. Much as Juce looks to be really useful, I don’t want it to take over my project, or the main loop (I’ll post another question about this).

I just want to use Juce as a library, so I just want to link it in normally. Maybe this is just a newbie reaction, but I don’t want a separate app like the Introjucer changing my project files.[/quote]

I’m exactly like that. Especially since compile the same projects on a variety of architectures, I have to make sure the linux build is made in separate places so I can continue having incremental builds on arm(soft and hard float)/x86/x86_64

I think the problem could be solved by having the Introducer generate an “intermediate” file with a known way of describing the JUCE bits it want to generate, so we could write a tool to export that into whatever format we want… it could still generate ‘full fat’ app project of course, it’s just the “modules” bits that could be exported in an easy JSON structured file for example…

19

Well, that’s exactly what the .jucer file is - it’s just an XML description of your project, containing enough details to be able to regenerate any of the files you need.

And sorry, but I’m sick of seeing this thread now, and it’s veered way OT, so I’m locking it - feel free to carry on discussing in other threads.