Yes of course you were being sarcastic, but you were also answering a legitimate question and I chose to assume that there was some truth behind your joke. Meaning that one person should insist upon the changes.
lol clearly Soul is the priority right now.
Iām hoping the team is big enough to cope with writing rendering AND audio code. 
I donāt have time to do this but Iād love to see a module that adds support for Googles Skia (https://skia.org/). Could result in a nice LowLevelGraphicsContext and for sure has some nice SVG tricks up its sleeve, since its the engine used for SVG drawing in Chrome, Firefox, Android, etc. Also supports other backends like OpenGL and Vulkan. I know this is probably nothing anybody from the Juce team will be doing. But maybe somebody has the time for. It doesnāt look to hard, to implement your own LowLevelGraphics context.
Tom investigated Skia recently but apparently the build process for it is completely crazy and would be impossible to build into a juce moduleā¦
As a temporal solution, I think it would be interesting to clear that uncertainty (program used by the designer) and understand where the problems are. Iāve had problems with Adobeās Illustrator for example but the designer eventually found a way to export everything correctly by deleting for instance the hidden components and rendering everything as paths. When I read this thread got tachycardia, rushed to compile for Mac, and I was hugely relieved when I saw that everything was showing as expected!
It might be possible to have a Skia module that contained prebuilt binaries for each platform, but this module would need to be distributed separately to the rest of JUCE. We donāt want binary components in the core.
I dunnoā¦ it just feels like this will over complicate my life if I have to get into the weeds of these issues. Easier to just ask for a PNG
Sounds interesting. But you would need to create a good tutorial on how to put it together. I struggle with things like this. For example, I recently gave up on JUCE_ASIO because I donāt know where to put the SDK files.
Kind of off-topic in this thread but for me it has worked by just putting them in :
JUCE\modules\asio.hAlong with asiodrvr.h, asiosys.h, iasiodrv.h. Maybe thereās some cleaner way to do it but once I got it working that way, I just forgot about trying anything else.
1 Like
Well, there is some truth behind my sarcastic statement. Let me explain: by my observation, focus has been mainly on smoothing creases with JUCE right now (eg: dealing with the politics behind VST2, and many bug fixes), with limited feature development.
I donāt need to know the reasons, it doesnāt matter - but it does lead me to an opinion: that conglomerating on a forum isnāt sufficient enough cause to shift towards supporting such massive features - it has to be justifiable value added for Roli at this point in time. Roliās priorities extend beyond an all-encompassing SVG support - a feature that probably wonāt attract enough JUCE users to justify the implementation and long term support costs. (And my assessment can be totally off-base, which is totally cool. 100% willing to change my opinion here.)
Your conclusion is probably correct but your logic in getting there doesnāt seem right to me. The whole point of having multiple people put in a request is so that ROLI can see how many people are interested and then use that information to make a decision that works best for them.
2 minutes of my time to respond isnāt nearly enough to properly explain. I do have work to do.