* were removed and replaced by a single "RunMainLoop" option. The same option has
been added to Mac OS X platform transport.
* The default value (if option is not specified) is True which means that the
transport will run an events loop on a separate thread to be able to receive
and process messages from Skype (which result in Skype4Py event handlers being
fired up).
* This option has to be set to False if the events loop is going to be run somewhere
else - the primary example are GUI applications which use the events loop to
process messages from the user interfaces.
* Trying to run two loops (one by the GUI framework and another one by Skype4Py)
causes a lot of problems and unexpected behavior. When set to False, this option
will tell Skype4Py to reuse the already running loop.
* Note that if no other loop is running and this option is False, Skype4Py will
remain to function (commands may be send to Skype and replies are returned)
but it won't receive notifications from the client and their corresponding
events will never be fired up.
* unittests for the common parts
Unittests were written for parts of Skype4Py code shared by all platforms and
transports. This is roughly 80% of the codebase and include all classes and the
code translating object methods/properties calls to Skype API commands.
* Call and Voicemail device methods support simultaneous devices correctly
The CaptureMicDevice(), InputDevice() and OutputDevice() methods trio of
Call and Voicemail objects support enabling of multiple devices at the
same time. Previously, enabling one device disabled all the other.
* Collections
Almost all collection types used by Skype4COM are now supported by Skype4Py too.
Collection types were initially skipped as Python provides a comprehensive set
of its own container types. However, since most objects are represented by Handles
or Ids, it makes a lot of sense to create a custom container type holding the
handles only and creating the objects on-the-fly as they are accessed. This
is the main reason for introduction of collection types. They also support
methods provided by their counterparts in Skype4COM world.
* Code cleanup and naming conventions
The whole codebase has been reviewed and cleaned up. The naming convention for
all objects (modules, classes, etc.) has been defined and implemented. It still
is a mixed convention (uses two different conventions applied to different
objects) but at least there is a standard now.
* String type policy
Skype4Py now returns unicode only when it is needed. For example, Skypenames
are plain strings now while chat messages (their bodies) remain in unicode.
Also, if Skype4Py expects a unicode string from the user and a plain string
is passed instead, it tries to decode it using the UTF-8 codec (as opposed
to ASCII codec which was used previously).