List of changes that affect user-code (up to 1.52 release)

15 posts / 0 new
Last post
jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
List of changes that affect user-code (up to 1.52 release)

In pursuit of c++ perfection, I'll occasionally refactor or tweak Juce classes in such a way that might require changes to the code that uses them.

The changes involved are usually small, but when you download the latest Juce version and your code fails to compile with it, the error message might not always make it obvious what you need to do.

So this thread is a place where I'll post details of any such changes, which will hopefully make it easier to find an answer if you hit this situation...

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

SparseSet: Many of the methods now take/return Range objects instead of separate start/end values.

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

Line: Refactored the Line class to make it templated, in the same way that Point and Rectangle work. To update existing code, just change "Line" to "Line". You might also need to tweak a couple of its methods, where I've changed the parameters to use Point objects rather than just raw coordinates, but the behaviour should all still be the same. The Line::clipToPath() method has moved to become Path::getClippedLine().

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

LassoSource::findLassoItemsInArea now takes a Rectangle as its parameter.

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

Replaced the old atomic operations with a new templated Atomic class with much more flexibility.

So e.g. instead of having an int and calling static methods to manipulate it atomically, you'd create an Atomic object and use its methods to change it.

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

Removed the VoidArray class - if you've used this, it's very easy to replace, just use Array instead.

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

I'm refactoring the Drawable classes at the moment, as they'll be central to the new jucer's vector editor - I've just changed the way the transforms are structured, and will probably need to change them a few more times before they're stable...

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

I've made an important change to the way that the Image class is used...

(I've been wanting to do this for years, but finally decided it was a good time when I hit a problem that I just couldn't solve cleanly with the current Image class..)

Previously, you'd create an Image object, keep a pointer to it, and delete it when you'd finished. This was fine, but there were all sorts of places in the code where images were shared or passed around, and the responsibility for owning and deleting them was very confusing. This provided lots of opportunities for dangling pointers, leaks, or unnecessary copying of images, as well as making it a PITA to make sure you were using them safely by using ScopedPointers and other tricks.

I've now changed the design, so that an Image is a lightweight object with value semantics, which internally points to a shared, reference-counted object that actually holds the data. That means that instead of keeping a pointer to an image, you just pass them around by value, and when they go out of scope, their image data gets released automatically. Being ref-counted makes it easy to share the same image data between separate tasks.

This has lots of benefits: it makes your code cleaner, safer, less prone to leaks, and it's impossible to get a dangling pointer to an image. The ImageCache class is now much simpler, and you don't have to worry about releasing the objects that it gives you. Likewise when you use the ImageFormat classes to create an image, you don't need to worry about deleting it.

So code like this:

Image* im = ImageCache::getFromFile (f);
g.drawImage (im, x, y)
ImageCache::release (im);

becomes:

g.drawImage (ImageCache::getFromFile (f), x, y);

The changes also mean that you can use images in places that you previously couldn't, e.g. Array.

Since the Image copy constructor now simply creates a reference to a shared image rather than actually duplicating the image, I've added a new method Image::duplicateIfShared(). This will internally duplicate an image if there is are any other references to it, so that if you've been given an image but don't know whether it's in use elsewhere, calling this method will make sure that you're drawing onto your own private copy, and not onto a shared image.

The changes will, of course, break some code. Although most of the Image class member functions are the same, all the Juce functions that used to take or return an Image* now use a const Image& instead... Updating is really straightforward though, and in every place that I've had to change my code for this, the result has been much cleaner and more concise than it was before.

An image can also now be 'null', if you just create it with the default constructor. So where you'd previously have written:

Image* im = ImageFileFormat::loadFrom (f);
if (im != 0)
{
    doSomething (im);
    delete im;
}

You'd now write

Image im = ImageFileFormat::loadFrom (f);
if (im.isValid())
    doSomething (im);

I've updated the (old) Jucer to generate code that's compatible with the new class - let me know if you have any problems with that.

I think the only pitfall that you might need to watch out for would be if you've used the Image copy constructor anywhere to deliberately create a copy, and if it's important to your code that the image actually gets duplicated, then you'd need to make sure you add a call to duplicateIfShared().

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

The ReduceOpacityEffect class has finally been removed, and replaced by Component::setAlpha(), which lets you give any component a settable transparency level.

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

I've removed the Component::getComponentUID() method. I've been trying to slim down and simplify the Component class, and it seemed to be unnecessary baggage - the original reason for having it was for use by the not-very-reliable ComponentDeletionChecker class, which has now been replaced by Component::SafePointer.

If you need to give your component an ID now, you can easily use the getProperties() set to assign whatever kind of value you need to it.

jules
Offline
Last seen: 9 hours 10 min ago
Joined: 29 Apr 2013 - 18:37
Re: List of changes that may impact user-code

The old MAC address stuff in SystemStats has now been replaced by a proper MACAddress class to handle them properly.

Pages