Cross Platform limitations?

Are there any limitations to which parts of the API may be used across platforms?


Very few.. A few things are impossible on certain platforms, e.g. Android disallows modal loops, and there are a handful of edge-case bits of functionality which aren't implemented for some platforms, but the vast majority of classes are platform-independent.

I should of been more specific... Reading bytestreams from the mic is universal? How about midi support?


And unrelated, is there some nine-patch support in Juce?

"bytestreams from the mic"? If you mean audio input, then yes, all the audio and midi i/o is completely cross-platform. No raw bytes are involved though, it's all floating point!

Re: the awful "nine-patch" hack... No, that's the antithesis of the kind of vector-based rendering that we should be using for modern multi-DPI displays. I'm pretty sure I've seen forum posts from people who've implemented it (it'd be trivial to do), but isn't something I'd encourage.

I didn't realize vector graphics were supported, that will work fine for me.

What about Layout classes, like HBox, VBox, StackLayout, etc? The samples online seem to specify everything in pixels I'd like to have things stretch and such with differing size displays.


There are a few layout helper classes, though TBH that's not something there's been a lot of requests for. (For a side-project of my own something I need to do is actually to create a flexible layout class that can be loaded from some kind of text file, so there's stuff on the way in that department..)

Using "pixels" isn't a bad thing - you've got to pick some kind of arbitrary unit to draw in, and pixels is IMHO as good as anything. All the drawing is done at floating point-accuracy and components can have arbitrary affine transforms applied, so it doesn't stop you drawing at whatever scale you want. I'm just finalising some new code changes at the moment that let you apply a single overall scaling factor to your entire app too.

[quote]I'm just finalising some new code changes at the moment that let you apply a single overall scaling factor to your entire app too.[/quote]


OMG! Sounds great :D

It's already there: Desktop::setGlobalScaleFactor

Can I set x, y separately? I'd prefer to make both coords 0..1 based. 

As far as pixels being "bad". I think they are problematic across a range of devices. I think 0..1 is preferably for certain apps because of this.

If you are serious about layout, IMHO, JavaFX, Kivy, and AngularJS are "on to something" particularly in regard to "binding" variables. Instead of an observer pattern, they allow you to implicitly define relationships when specifying the formula by which they are calculated. This makes a lot of boilerplate code much simpler and easier to read (and write). Kivy is particularly concise, compared to Java(FX) you have to write a "literate api" to achieve this, but C++ with operator overloading would make this more reasonable.

For example widget1.x = widget2.x + widget2.width  ... would place widget2 to the right of widget1, and keep it there as the .x value of widget1 is "bound" to widget2's x (and width), when they change widget1 automatically changes as well. Very productive and kills bugs at the same time.

No, the global scale doesn't do that, but you can give any subcomponent an arbitrary affine transform.

You can do that in juce - see the Component::setBounds (String) method, and Component::Positioner. But having implemented that, I actually prefer not to use it. I expected it to be amazingly useful, but found that in practice it didn't really make things any simpler, it just moved the logic around and made it harder to debug and to see what's going on.

This is not directly related to JUCE, but I'm curious how one would go about this.

I have a .png file with an example of "tiles" I need to draw (attached). Is there a way to reverse engineer the drawing in JUCE graphics, or is there some support for loading vector formatted files? Unfortunately I don't have a vector file either, just this .png.


Yeesh.. That looks like something from a 1990s myspace background image :)

It's just a rounded rectangle with a few gradients drawn inside it - have a look at the LookAndFeel::drawShinyButtonShape method, which does something vaguely similar for juce buttons.

Or create an SVG and load it with Drawable::createFromSVG