gconf: fix the description of the accounts window

Closes bug #690680.
Updated Polish translation
videooutput: new parameter size_changed() signal

This patch is traversal to all the videooutput subsystem.

It adds a new parameter to the size_changed() signal. This new parameter
indicates the video output mode of the current frame that changed its size.

With this new parameter the UI can know which window resize in case the
output is other window.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
videooutput: add another instance of DisplayInfo

Add another instance of DisplayInfo for the new window which will show the
extended video stream, and its getters and setters in the class hierarchy.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
videooutput: select the display info to use

In the method {x,dx} setup_frame_display() the local display info is
chosen according to the current frame mode, hence the corresponded
display window is configured.

In the common-videooutput, we will get the display info structure
according to the stream type, since they are different widgets.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
common-videooutput: first check new stream, size change later

In GMVideoOutputManager::redraw (), it is more important to know if
there is a new stream in the connection, so that we allocate the
required resources to process it.  Afterwards, we could process the
frame size changes.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
Updated Spanish translation
common-videooutput: fix code style

No functional changes.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
x-videooutput: fix code style

No functional changes.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
x-videooutput: close only current display

Added the close_display () method. It will only close the display associated
with a videooutput mode (remote/local/pip vs remote extended).

This is used when setup_frame_display() we must close only the current
display, avoiding the flickering when displaying both streams simultaneously.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
Updated Brazilian Portuguese Translation
videooutput: add a extended last frame

This allows to demux more easily, keeping separated the extended video
display from the main video display.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
gconf: add ext_zoom

https://bugzilla.gnome.org/show_bug.cgi?id=687775
ext-window: add remote video window

This remote video widget will display the extended remote video stream.

https://bugzilla.gnome.org/show_bug.cgi?id=687775
[windows] Remove unuseful messages
Updated Polish translation
call-window: instantiate the extended video window

When an extended video stream is opened, an extended video widget is
created and displayed. It is shown until the extended stream is closed.

Finally closes bug #687775.  Full support for receiving two streams is
now provided.
ekiga.schemas: fix a possible UDP port collision

The SIP listen port is configured to be 5060, and the default UDP port
range is from 5060 to 5100. This means that the first UDP port used by
Opal is going to be 5060, but it will already be used by the SIP
endpoint, causing an error in the connection. At the next port
binding, the problem will be solved "magically".

This issue has raised in the gatekeeper registration process: after
setting up the SIP and the H323 endpoints, the H323 endpoint starts
the gatekeeper registration. Opal uses the first port in the UDP range
to connect to the configured gatekeeper, i.e. 5060, but the
registration silently fails, because the port is already in use. The
workaround was to unregister and register again.

It remains to do the migration on current ekiga installations.

Closes bug #690621.
Assamese translation updated
Migrate the first port of UDP port ranges from 5060 to 5061

See bug #690621.