You will need to consider: regardless of method, could the operation of your feature be reasonalbly classified as "taking over Skype UI".
I'd say sending a mouseclick to get fullscreen video definitely isn't that. Causing Skype main window to run away from the mouse cursor definitely would be

Hi, I would like to follow up on this. I would like to create a user interface for Skype, that allows it to be controlled via keyboard/remote control ("remoteUI"). For all of the voice functions this is not a problem, the API has sufficient support for all the needs. Video control is the problem... the API does not support positioning and size at all and according to the terms you are not allowed to control the Skype UI.
From a programming standpoint here are the current options for video control as I see it:
1) Maximize Button
The remoteUI is running in full screen and as a topmost window. A video call is started. The full screen button is pressed programatically. After the application checked, that the video window is in full screen, the main window of the remoteUI hides or blends to be transparent for the duration of the call. And it will restore itself, if Skype or the remoteUI loses focus (depends on which app is keeping focus in the first place).
This works with a two way video call, but is difficult, if you are only sending. So if you are only sending, you would be unable to switch to the video. It would be great, if you could maximize the video window, when in a video call even if you are only sending.
2) Maximize with separate window
Very similar to the first approach the remoteUI will work in full screen. When video is started the remoteUI ensures, that the video is either in a separate window or that Skype is running in compact mode. Then the separate video window is maximized even when Skype is only sending. I am unsure yet on how to get Skype into compact mode or enforce a separate video window. It would be great, if there would be an API for that...
The separate window along with programatically positioning it underneath the remoteUI before hiding it or making it transparent gives a little bit more control and could result in a consistent behavior.
3) Total control

Well, this works flawlessly: The remoteUI stays in full screen mode and has two place holder controls for the send and received video - both have their own handle. The application monitors the Skype window and reparents the send and received video window into the place holder controls when found. If the remoteUI looses focus, then the video windows are immediatly reparented to their original parent windows as if it never happened...
Well, while option 3 is from my viewpoint of course the best, being the most reliable and giving the user a seemless experience, but I guess this violates the terms of the API (3.1 (vii) and/or 3.2). Option 1 will most likely work and be compliant with the terms of the API, but has significant drawback for one-way calls. Option 2 might be the compromize, but I think it will be very hard to programmatically ensure that Skype starts the video in a separate window.
Couldn't Skype just add some features to the API like:
VIDEO_CONTROL_MODE - similar to silent mode, but informs Skype, that the application wants control over the video
SET_SEND_VIDEO_WINDOW MAXIMIZE|MINIMIZE|ABSOLUTE x,y,width,height
SET_RECV_VIDEO_WINDOW MAXIMIZE|MINIMIZE|ABSOLUTE x,y,width,height
REHOST_SEND_VIDEO_WINDOW handle - reparents the video into the window identified by the handle
REHOST_RECV_VIDEO_WINDOW handle - reparents the video into the window identified by the handle
If the videos are not active the calls still should work, but show a placeholder image. The rehosting is essentially what I did with option 3, implementing an API call would leave the control over the video windows to Skype and the API call "gives" the controls to the windows identified by the handle - instead of the application "taking" them from Skype.
Well, but that is just a suggestion...
What is your opinion about the outlined approaches to control the video?
Which one _might_ be viable and conform with the API terms - if one of them is it at all?
Thanks,
Alex