I had a few questions and bugs I wanted to discuss:
First, if I have released software with any version of JUCE pre V5 that was open-sourced, can I re-release a new version of my application with JUCE 5 personal license and then close the git repo up? Or must I keep the git repo open for the previously released versions of my software?
Issues:
I’m getting a ton of errors trying to run the live build engine. In JUCE 4, I was never able to run the compiler with JUCE, as it crashed every single time I tried to use it. I’m getting similar issues with this version along with errors. I get a JIT engine crash and I get errors:
Had a suggestion that will probably get shot down. Is it possible to only show the splash screen on released products and not products we are running inside our sessions? For instance, I don’t compile with JUCE at all, but only with Xcode, and I recompile the session a few times every minute to check my changes, so that splash screen pops up every time and significantly slows down my workflow. I have no issue with displaying this screen when customers run the app, but it definitely gets in the way when coding (maybe for more added incentive to upgrade?). It would be awesome to be able to disable it for debugging and whatnot.
This was the first thing I was worried about when I heard about the splash screen. Since you aren’t distributing your build, there’s no reason you can’t just flip the splash screen switch to disable it during development, just make sure you flip it back on before distribution (assuming you need to do so in order to comply with your chosen license).
Awesome. I’m a little worried that this may be frowned upon, however, i would not ever release a product against any licensing terms, I would just like to be able to disable it while I’m debugging and testing. The icon covers up part of the functionality of my app and I have to wait for it to “dissolve” every time I compile before I can move on to verify the task at hand.
Then wrap the #define suggested by @jonathonracz within an #ifdef that is only true when debugging.
(Pay attention not to use JUCE_DEBUG though, because I’m not sure that one is already available at the stage where AppConfig.h is preprocessed. You should probably rely on the “native” macro, _DEBUG or NDEBUG, I can’t remember how that is called)
Another bug, but this one is hard to replicate because it doesn’t always happen. When setting the width and height of a GUI component in the class settings, using the tab button advanced the cursor to the next field and other times its glitched out and didn’t advance at all.
I would love to be able to use the live engine or to compile within the Projucer, but those errors continue (and have always been there for me since JUCE 4), any suggestions for this? I suppose I should downgrade to JUCE v4, so I can have code without this nasty memory leak, but the problem is is that JUCE 5 changed some of the properties of my GUIs and I have to manually tweak them to get them all back to looking normal in V5, now if I go back, I have t re-tweak them all again. I’m sort of stuck not knowing which direction to go.
This is fixed on the develop branch on Github and will make it’s way into the Projucer binary in the download from juce.com when we do a point release, which should be very soon.
