Juce 1.35

[jules]

Ok, got a new release out. Some big, if not obvious, changes to the Mac code in this one. Also a new JuceAudioPlugin version to go with it.

The precompiled mac demo and jucer executables should now be universal binaries, though I’ve not got an Intel Mac to try them on, so if anyone has, let me know if it works!

Here’s the changelist:

* added a simple SVG parser to the Drawable class - this can parse SVG into a graph of Drawable objects that you can then render. The parser's pretty basic, and doesn't support much of the (very large) SVG spec, but I'll keep adding features to it as they're needed
* fixed the updating of ToggleButtons that are connected to app commands so that they correctly reflect the command's 'ticked' state.
* fixed the XML parser's handling of non-text element entities
* added a few handy static methods to AffineTransform
* gradient fills can now have a transform matrix specified, to deform their shape
* new class: RectanglePlacement, which is a bit like Justification, but specifically for fitting rectangular graphics within a viewport with various positioning options. This will break a few places where you call methods like drawImageWithin(), but is easy to update and the result is more readable code.
* new method Colours::findColourForName() for looking up colour names from a string
* added a flag to ApplicationCommandInfo to stop menus and buttons getting flashed when particular commands are invoked
* new class: CharacterFunctions, which contains a set of static functions for manipulating ascii and unicode characters and null-terminated strings. This is intended to replace any use of functions like strlen, etc, with a set of safe, platform-independent ones.
* some fixes and optimisations to the file chooser components
* altered the Graphics and LowLevelGraphicsContext classes to use a stack for pushing and popping the clip regions, instead of setting these explicitly with a RectangleList. (This change is needed for future support of OS contexts that can't retrieve the clip path as a set of rectangles)
* removed the Graphics class's copy constructor (use the saveState/restoreState methods instead of a temporary copy)
* added method String::indexOfWholeWord()
* tidied up some of the header files, moving all inline functions (like jlimit, jmax, etc) into the juce namespace
* Mac: complete rewite of the windowing code. Components are now placed in HIViews, rather than directly in Windows. As well as being more futureproof, this is vital for support of AudioUnits and VSTs on Intel Macs.
* Mac: tidied up the build environment. It now compiles a universal binary which is compatible with any system from 10.2 onwards, including intel on 10.4
* Windows: new ActiveXControlComponent class, which lets you embed an ActiveX control in a Juce window. I wrote this to get the new Quicktime control working, but made it generic so you could use it for other things like embedding a web browser, etc.
* Windows: completely rewritten Quicktime support. This now requires QT7 (on windows, not Mac), but it now uses the new ActiveX QT control, which is much better than the archaic way it used to be done. Would like to update the Mac version too, but that'd only work on 10.4, so will wait until older OS versions are less common.
* Windows: fixes for non-western keyboard input sometimes not working in textboxes
* Linux: added a MIDI input device, using ALSA
* Linux: made launching of URLs in the default browser work properly
* Jucer: added an option to view a semi-transparent overlay of the components while editing the background graphics
* Jucer: better positioning of new objects when zoomed-in
* Jucer: added a "common background" graphics layer to buttons, which is drawn behind all the other button states
* Jucer: added key shortcuts for nudging component's position and size around
* JuceAudioPlugin: rewrote the mac VST and AU wrappers to embed a HIView rather than the old window hackery it was using.

[jules]

Oh - and an FYI about graphics on the Mac…

You know I’ve been saying for ages that the Mac graphics were a bit slow, and I’d eventually write a Quartz-based context to speed it up? Well I had a go at this. And it was pathetic! Running the juce demo using Quartz, most normal drawing was many times slower than the old cpu-based drawing, so I put it back the way it was!

In particular, quartz was dreadful at rendering gradients, and just couldn’t do some of the graphics operations that the library needs, so these would have to be faked in an off-screen bitmap and copied back, and it’s all just a mess.

For the future, I think the best plan might be for me to investigate renderers like cairo and glitz, and see if that works out better. Just having an SSE-optimised CPU rendering engine will definitely be at least as fast as Quartz (which isn’t hardware accelerated anyway).

[haydxn]

quite a chunky update there, cap’n storer! thanks as usual

[G-Mon]

There is some sort of unicode/ascii bug on windows. The app name in the title bar is just “J” instead of “JUCE Demo App”

Same thing happens to my app.

[jules]

sigh… win32 is a heap of crap, isn’t it. Ok, here’s a fix, in juce_win32_Windowing.cpp:

[code]UNICODE_FUNCTION (SetWindowTextW, BOOL, (HWND, LPCWSTR))
UNICODE_FUNCTION (DragQueryFileW, UINT, (HDROP, UINT, LPWSTR, UINT))
UNICODE_FUNCTION (MapVirtualKeyW, UINT, (UINT, UINT))
UNICODE_FUNCTION (RegisterClassExW, ATOM, (CONST WNDCLASSEXW*))
UNICODE_FUNCTION (CreateWindowExW, HWND, (DWORD, LPCWSTR, LPCWSTR, DWORD, int, int, int, int, HWND, HMENU, HINSTANCE, LPVOID))
UNICODE_FUNCTION (DefWindowProcW, LRESULT, (HWND, UINT, WPARAM, LPARAM))

void juce_initialiseUnicodeWindowFunctions()
{
static bool initialised = false;

if (! initialised)
{
    initialised = true;

    HMODULE h = LoadLibraryA ("user32.dll");
    UNICODE_FUNCTION_LOAD (SetWindowTextW)
    UNICODE_FUNCTION_LOAD (MapVirtualKeyW)
    UNICODE_FUNCTION_LOAD (RegisterClassExW)
    UNICODE_FUNCTION_LOAD (CreateWindowExW)
    UNICODE_FUNCTION_LOAD (DefWindowProcW)

    if (wDefWindowProcW == 0)
        wDefWindowProcW = & DefWindowProcA;

    h = LoadLibraryA ("shell32.dll");
    UNICODE_FUNCTION_LOAD (DragQueryFileW)
}

}

#undef DefWindowProc
#define DefWindowProc wDefWindowProcW

[/code]

[jules]

(iI’ve patched the current zip file with that change now, too)

[Dub]

When I try and build juce 1.35 the build stops immediately because the SDK path requested is wrong (10.2.8!) - Now, my machine’s never been near 10.2.8, and so I’m wondering if something’s luking unchanged in some config file - (Before anyone asks, I’ve tried the obvious, and checked the Build->SDK path selected is /Developer/SDKs/MacOSX10.4u.sdk) set by using “Cross develop using SDK Mac OS X 10.4 (universal)” - and I can’t find any reference to SDK 10.2.8 mentioned in the error.

Anyone any ideas?

[Dub]

Hang on! I found it… I don’t understand it, but I think it’s right at the bottom of the Build settings (2 which referenced 10.2.8) - D’oh!

OTHER_LD_FLAGS was set to /Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/gcc/darwin/3.3/libstdc++.a

Also, in the Audio VST plug in example MACOSX_DEPLOYMENT_TARGET_ppc
is set to 10.2

Do these matter?

[jules]

[quote=“Dub”]Hang on! I found it… I don’t understand it, but I think it’s right at the bottom of the Build settings (2 which referenced 10.2.8) - D’oh!

OTHER_LD_FLAGS was set to /Developer/SDKs/MacOSX10.2.8.sdk/usr/lib/gcc/darwin/3.3/libstdc++.a

Also, in the Audio VST plug in example MACOSX_DEPLOYMENT_TARGET_ppc
is set to 10.2

Do these matter?[/quote]

This is all defined in the juce.xcconfig file, and if you’ve got all the backwards-compatibility SDKs installed, it means that the build now produces a universal binary that runs on any Mac from 10.2 to 10.4 on intel. This is what you need to do if you’re actually releasing software, as a lot of users still seem to be stuck on 10.2 for various reasons.

If you don’t care about backwards compatibility, just comment-out the lines in juce.xcconfig that you don’t need (or remove the file from the build). The same juce.xcconfig file is also referenced in the juce demo and jucer projects, which makes it easy to apply the same settings to the library and application builds.

[Dub]

[quote=“jules”]
This is all defined in the juce.xcconfig file, and if you’ve got all the backwards-compatibility SDKs installed, it means that the build now produces a universal binary that runs on any Mac from 10.2 to 10.4 on intel. This is what you need to do if you’re actually releasing software, as a lot of users still seem to be stuck on 10.2 for various reasons.[/quote]

Ah! Thanks

I presume I can just install that 10.2 (library?) can just be downloaded from the Apple Developer’s area (I’ll leave it for a while, till I can actually get something tangible going)

… Any ideas about why the vst’s window’s blank>

[G-Mon]

There is a bug in File::hasFileExtension()

It should be:

if (possibleSuffix.isEmpty())
    return fullPath.lastIndexOfChar (T('.')) <= fullPath.lastIndexOfChar 

Or it fails on files that have a dot in their directory name and have a file extension when you call hasFileExtension(String::empty).

eg:

c:\foo.bar\foo.bat

[jules]

[quote=“G-Mon”]There is a bug in File::hasFileExtension()

It should be:

if (possibleSuffix.isEmpty())
    return fullPath.lastIndexOfChar (T('.')) <= fullPath.lastIndexOfChar 

Or it fails on files that have a dot in their directory name.

eg:

c:\foo.bar\foo.bat[/quote]

Ah! Yes, well spotted. Thanks for that one!

[OvermindDL1]

What if a filename does not have a dot at all, perhaps search to see if the dot occurs after the last slash as well?

[jules]