GUI transition [SOLVED]

#1

Hi all,

I am working on a little demo iOS app. Until now, I have just been using a tabbed component to flick between 2 gui components that each take up almost the entire workspace when active. I would like to replace the tabbed component with something a bit more fitting for the platform . . .

In an ideal world:

  • It would be nice to switch between them with a swipe gesture
  • It would be nice to animate the transition

Can anyone suggest where I need to begin looking, or if there is some example juce code about that would allow me to do this.

Thanks!

#2

As a side note, I remember seeing a 3rd party component posted by Haydxn on the forum ages ago. I think it allowed you to graphically navigate a value tree. A demo was posted where you could search your way through an intojucer project or something like that. This had some sliding transitions in it. I made a mental bookmark that it might come in handy later, but for all my searching of the forum, I can no longer find it :frowning: Any help would be great!

#3

Juce doesn’t have any gestures code itself so you would have to roll your own code.

ComponentAnimator class.
The Juce demo has a couple animation demos. There is path/image animation by position, rotation and size in the Graphics demo. There is also a bouncing balls in the Multitheaded demo.

#4

Here’s the Haydxn code you mentioned:

http://rawmaterialsoftware.com/viewtopic.php?f=6&t=6877

It’s using the ComponentAnimator… I’ve been using Haydxn’s code on iOS for transitioning between nested settings screens. If you want to start these transitions when the user swipes, the easiest way to do detect a swipe is to use the following methods in the MouseEvent in mouseDrag():

getDistanceFromDragStartX()
getDistanceFromDragStartY()

#5

Excelent info folks! Thanks.

#6

Ok. Got this working OK. However, I cant get the swipes feeling as responsive as they do in some other APPs when running it on the device. I’m using code like the following at the moment

void cTestBodyComponent::mouseUp (const MouseEvent &e) { if(e.getLengthOfMousePress()<800) { if(e.getDistanceFromDragStartX() > getWidth()/4) //SWITCH LEFT if(e.getDistanceFromDragStartX() < -getWidth()/4) //SWITCH RIGHT } }

It would be nice to use mouseDrag rather than mouseUp to improve responsiveness, but when I do this, subsequent components receive the same drag event and immediately get switched past. Is there some way to reset the event at the point where the component gets switched?

i.e. . . .

if(e.getDistanceFromDragStartX() > getWidth()/4) { e.resetTheEvent() //SWITCH LEFT }

#7

Solved . . . TADA . . .

[code]void cTestBodyComponent::mouseDrag(const MouseEvent &e)
{
const int DRAG_DIST_THRESHOLD = 50; //px
const int DRAG_TIMEOUT = 500; //ms

if (mouseDownInThisComponent && //mouse event must have started here
    (e.getLengthOfMousePress() < DRAG_TIMEOUT) && //swipe must be fast enough
    (abs(e.getDistanceFromDragStartX()) > DRAG_DIST_THRESHOLD) ) //swipe must be long enough
{
    if( e.getDistanceFromDragStartX() > 0) 
        //transition left
    
    if(e.getDistanceFromDragStartX() < 0) 
        //transition right    
    
    mouseDownInThisComponent = false;
}

}

void cTestBodyComponent::mouseDown (const MouseEvent &e)
{
mouseDownInThisComponent = true;
}[/code]

#8

Great!
Are you using the OpenGL renderer or CoreGraphics Renderer?
Wondering if iOS devices have the power to have smooth/responsive animations with just the CPU renderer.

#9

Just using the CoreGraphics renderer. I didn’t even realise the OpenGL renderer was working on iOS (not built the juce demo in many months). Anyway, I have a component that takes up most of the screen with a couple of test buttons, a massive label component containing a digit, and a background image. Now that have cropped and scaled the background image object in the component constructor and just use the drawImageAt (rather than drawImage) method in the draw() function, everything seems to run very smoothly and responsively. I’m very impressed at how simple this was to do in the end! :mrgreen: Juce rocks (but we all knew that anyway).