ericb's place

appleremote02 (part 4)

Removing the F5 key

In appleremote01 cws, the plan was to send keycodes, and the sd had to interpret as commands for the slideshow. It works perfectly, but has the drawback to not respect the portability criteria.

As replacement, I modified the way events are sent to the application

Before, we had :

  [NSApp postEvent: 

    [NSEvent keyEventWithType:NSKeyDown
    location: NSZeroPoint
    modifierFlags : modifierFlags
    timestamp: 0
    windowNumber: [[NSApp keyWindow] windowNumber]
    context: nil
    characters: characters
    charactersIgnoringModifiers: characters
    isARepeat: toBeRepeated
    keyCode: theKeyCode]
    atStart: NO];

Means, for every case, I sent the right keycode, for the right slideshow command ( I passed the theKeycode variable to the postEvent method, using an keyEventWithType:NSKeyDown type) (for further information, see RemoteMainController.m appleremote01 )

The new implementation is different :

1) I created a different event type (otherEventWithType:NSApplicationDefined ) sent to the NSApp

- (void) postTheEvent: (short int)buttonIdentifier modifierFlags:(int)modifierFlags
{
    [NSApp postEvent: 
    [NSEvent    otherEventWithType:NSApplicationDefined
                location:NSZeroPoint
                modifierFlags:modifierFlags
                timestamp: 0
                windowNumber:[[NSApp keyWindow] windowNumber]
                context:nil
                subtype:AppleRemoteControlEvent
                data1: buttonIdentifier 
                data2: 0]
    atStart: NO];
}

(for further information, see RemoteMainController.m appleremote02)

2) in AquaSalInstance::handleAppDefinedEvent(), the NSApp detects the event (in vcl/aqua/app/salinst.cxx ), and turns it into a MEDIA_COMMAND_(some_name) event through the data1 parameter. Then, the sd received the event throught the eventlistener, and does the dispatching to the ::Command and ::Notify implemented methods.

The problem was, it works nicely for all events sent, but only when the slideshow is running.

Means: no way to start the slideshow using the same method as the one used for e.g. gotoNextSlide(), gotoFirstSlide() and so on. My first hack was to continue to create, in salinst.cxx, the NSKeyDown event. The problem is ... it is just a hack.

So I decided to figure out what was happening. And for that, I implemented new methods (uggly buggy hacks, but very usefull to trace everything at runtime), in sd/source/ui/view/viewshel.cxx (see the diff for further information)

What I discovered, is, the events coming from the remote are never seen, when the slideshow is not started !

My first tries where: maybe I do no send the event to the right frame ? So I implemented another hack, when sending the "PLAY" command. The idea was to check for every frame, and see what happens ... More precisely, doing :

switch ([pEvent data1])  
            {
                case kRemoteButtonPlay:
                {
                    nCommand = MEDIA_COMMAND_PLAY;               
                    std::list::iterator it = pSalData->maFrames.begin();
                    while( (*it) && (it != pSalData->maFrames.end()) )
                    {
                        AquaSalFrame* pFrame = (*it);
                        Window * pWindow = pFrame->GetWindow();
                        if( pWindow )
                        {
                            const Point aPoint;
                            CommandEvent aCEvt( aPoint, COMMAND_MEDIA, FALSE, &nCommand );
                            NotifyEvent aNCmdEvt( EVENT_COMMAND, pWindow, &aCEvt );
                            fprintf( stdout, "EVENT_COMMAND Notified from  
                            AquaSalInstance::handleAppDefinedEvent \n");

                            if ( !ImplCallPreNotify( aNCmdEvt ) )
                                pWindow->Command( aCEvt );
                        }
                        it++;
                    }
                }

But nothing ... After tracing a lot, and using the backtraces for working and not working events, Philipp Lohmann suggested me to check the focused window.

So did I, using Window* pWindow = Application::GetFocusWindow(); instead of the list of frames.
And one more time, it was not working :-/

So what is the problem ? After yet another discussion on IRC, Philipp finaly found the reason, following ( if I'm not wrong) Christian Lippka explanations : the draw event listener for the slideshow is not active.

More precisely, the "play" does not work on Windows too. The reason is, as soon as the slideshow exists, it registers as event listener of the application. But that is AFTER the slideshow is started. Said differently, the slideshow doesn't exist at all, before the F5 key is pressed :)

=> So the events go nowhere (what I verified since several days ;) )

The solution (see issue 97195 ) in the air is the sd to register as event handler before. Andre Fischer is the specialist, and will work on that.

So far, once it will work, I'll just fix that in 2 minute, and this is the last change I see before to declare the cws as Ready for QA (and find someone for the QA ...) : everything else works, including a new little feature: play/pause when slideshow started.

Crossing the fingers to see the change occur before the deadline of 3.1 (waiting, I'll have a look at how eventlistener work ... cannot be bad to understand how things work ... ;-) )

.. to be continued ...

Libellés : aqua, Code, development, fun, High-Tech, Mac OS X, OpenOffice

publié par ericb @ samedi, décembre 13, 2008