Reusing the JUCE Splash Screen in my About dialog


#1

I’d like to integrate the logo created by the JUCE Splash Screen into my About dialog, giving credit where it is due. But, adding one to my dialog doesn’t cause it to display, due to the ‘splashDisplayTime’ variable. I locally hacked the JUCESplashScreen class to reset splashDisplayTime to 0 in the constructor, verifying it can work, but this doesn’t feel like the correct solution. In my requirement I’d also like to display the logo until the dialog is closed, instead of having a timer clear it. Are you guys willing to update the class so it is usable for my case? Maybe just an optional construction parameter that turns the timer off? Or a time out paramater, that does nothing if set to 0? Another less ideal solution would be to make the SVG data within the splash screen available, and I could simply draw it myself.


#2

I’m not sure we want to add any complexity to the JUCESplashScreen class. Even if we did modify it as you suggest then it would still be displayed in the bottom right corner, with a shadow, and we’re free to change how it looks or its size at any time, which potentially breaks your dialog. I would just copy the SVG data from the class and use it yourself.


#3

Fair enough. I just wanted to leverage the latest logo being used in JUCESplashScreen, without having to make sure to copy that data with every pull. I personally think this would be a good thing for ROLI/JUCE, to have the actual logo displayed in an apps About dialog. In reflection, I think any changes to the behavior of that class would be too specialized, but making the data statically available from the class would make this simple. I’ll just at some plain text for now.


#4

OK, I’ve added a static Drawable* JUCESplashScreen::getSplashScreenLogo() method to JUCESplashScreen. It’ll be available on the develop branch shortly.


#5

Tom,

Can you change juce_gui_basics.cpp so that

#include "misc/juce_JUCESplashScreen.cpp" 

is excluded when the JUCE_DISPLAY_SPLASH_SCREEN (etc) flag(s) aren’t set?

Thanks,

Rail


#6

Not without introducing more precompiler instructions into the rest of the JUCE codebase. If the flags are set to zero then the corresponding functionality inside the .cpp file is excluded from the final build by the precompiler anyway, so it’s not included in your application.


#7

Awesome! Thanks. :slight_smile: