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?
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:
Also, I just had a very strange issue come up while running JUCE 5:
Is this a memory leak on the Projucer’s end?
I had to force quit out of everything and now JUCE will not reopen, I will restart my computer and report back.
You cannot seem values being input into ProJucer text editors:
A system restart and I can open the Projucer once again.
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).
In your application’s
#define JUCE_DISPLAY_SPLASH_SCREEN 0
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,
NDEBUG, I can’t remember how that is called)
Thanks for the all the help guys. Appreciate it.
Any word on the bugs / issues I reported from the dev team? Seems like this memory leak would be rather important to address.
It’s saturday, and we’re a bit tired after all the release stuff, but of course we’ll look at it asap.
Awesome. I apologize if my eagerness to play with the new features came off as me lacking patience. I do want to play with the live build engine
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.
These issues will be fixed shortly.
Thanks for the update, t0m.
The memory leak issue should now be fixed in the 5.0.1 release.
EDIT: Ignore that, it’s still there. I’ll work on getting a fix out.
Ahhh damn, I just redownloaded it! Haha, all is good. Thank you for your diligence.
OK I think it’s fixed now - see this post.
Curious if there will be a fix for the text editor input being invisible in the Projucer (4th image of original post).
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.
Awesome. I suppose I should get into the habit of pulling the code and compiling myself…