Site navigation

Load New LookAndFeel as external files? Possible?

General JUCE discussion
#1

I´m wondering how this could be done in an easy way. Any ideas? This would be great to make something even more skinable I guess. (for those with C++ knowledge at least) In any event I could always help graphic-designers with custom files, of course.

I know I could just use the plugin format, lets say, the VST format, and create a dummy VST file, and have the code return a new LookAndFeel pointer via the following call: getPlatformSpecificData()

BUT, I wonder if I could create Juce library modules that are easy to make cross-platform without using the plugin format?

Sorry if this sounds like a NOOB question… :oops:

Best Regards, WilliamK

#2

If that external file is a DLL, then sure :slight_smile:

#3

Sure, as long as it was built with the exact same code, compiler and settings as the app that’s loading it.

Passing virtual C++ classes between DLLs is basically impossible/impractical, unless you’re in complete control of building both the app and all the DLLs. And if that’s the case, then you might as well just statically link it all.

#4

But here´s the hard part, I have no clue on how this will be done, no clue on how to build that, and no clue on how to handle that for other platforms. So, I´m still wondering if using the plugin format wouldn´t be easier. :oops:

I´m an experienced C++ coder, but in terms of projects, libraries and stuff like that, I have no idea… go figure… :roll:

#5

What exactly are you trying to achieve? If you have 3rd party plugins that need to draw a UI why are you taking the responsibility of drawing them but trying to draw them with 3rd party code? Why not just let the plugin do it’s own drawing like any other plugin format?

Using dynamic libraries only really works for existing plugin formats because there is a standard that everybody has to follow. The LookAndFeel class is certainly not like this at all, it can and will change as new classes are added and parameters improved, just look at the TabbedComponent rewrite about a year ago for an example.

I guess the only way to do this would be to define your own intermediate LookAndFeel wrapper that provides some extra information such as the JUCE version so you know what method arguments there will be. You could then query the dll for specific function names and if the dll provides them pass on the calls, if not use the normal vtable in your local wrapper class.

Honestly though there are just so many things that could go wrong here such as the reliance on static or global namespace methods within the LookAndFeel class, exception safety and a ton of other stuff. You would basically have to create your own C API and then struggle to maintain it and keep it in sync with all the different JUCE versions people might be using. Not worth it in my opinion.

#6

Indeed, I see what you are saying, makes sense, thanks bud.

#7

A skinnable LnF based on loading XML, CSS, SVG…etc would be a better idea IMHO.

It’s quite easy to customize colours, fonts and a few static properties using a config file, however doing it seriously is a significant amount of work and would require scripting (Lua, JS,… choose your favorite) to match the level of algorithmic decisisons made into the LnF.

The best example I know about is QT’s stylesheets:
http://qt-project.org/doc/qt-4.8/stylesheet-examples.html

#8

I will do some tests soon, but I´m sure I will find a stupid and ugly method that looks good for users. :mrgreen:

One idea is just to go ahead and do the dumb thing of using a juce plugin do pass a pointer, BUT, also some checks to see what version it is, etc … and in the code I check those things out, not hard. Now, if Juce gets updated with something new, I will have to update the code according to those changes, not a big deal.

Its ugly, but works…

OR, I could just do everything myself on the code.

I will figure something out later this week. Its not really THAT important right now, but I like to think everything ahead of time so I don´t have to overdo anything, or at least as little as possible… :wink: