[Ayatana-dev] Head's up: Some important changes in Unity's source

[Neil Jagdish Patel <neil.patel@xxxxxxxxxxxxx>]

Hey all,

I wanted to give a head's up to two of the larger changes going on in
Unity source at the moment:

Better C++ & Hiding of C-isms
=============================

Unity's foundations are in GNOME, all of which is written GObject C.
However, Compiz is C++ and Unity is a plugin of Compiz. This means that
most of Unity is written in C++, but with lots of hooks into C code
sprinkled across the C++ sources.

While this is great as it means we can keep up-to-date with the latest
GLib/GIO/BAMF/Dee APIs without needing to wait for the *mm bindings (or
create full bindings ourselves), it introduces a headache in two cases:

* Reading the code is more difficult as we can switch between C++ and C
multiple 
  times in a function.

* Managing memory is very difficult as we are dealing with many
different memory 
  management conventions (new/delete, malloc/free, ref/unref,
smart-pointers, etc 
  etc).

So, we are going to try and embrace the world of C++ with a much more
loving arms instead of treating it like the pet we're embarrassed of :)

Over the coming weeks (and already some of this has started in trunk),
you'll start seeing the code transform as it uses a few more features of
C++, namely trying make good use of the nicer way to deal with memory
management and trying to hide a lot of the leaked C/GLib types in the
API with the equivalent C++ types.

In addition to this, you'll start seeing thin wrappers (only covering
methods we care about) around some of the more important GObjects that
we use (from GLib/GIO/Dee/BAMF) which will encapsulate the C code in a
reusable object. It means that we'll be able to confine much of the C
code in a few classes where we can easily test for memory leaks and also
be able to make implementation changes much more easily in the future.

We're hoping to make Unity's codebase much more readable, much better
commented and much easier to get started with if you are hoping to
contribute. We now optionally build Doxygen documentation from trunk and
we hope to make it even more useful as we retrospectively add more API
documentation to the most important objects.

Shared Library
==============

Historically, we've designed Unity's "foundation" services to be
accessible over D-Bus so Unity-2D could work with the same models that
Unity does. However, with the move to C++ and the work described above
to adhere to C++ standards more closely, we are hoping to share a lot
more code this cycle.

To this end, Unity's trunk now produces a libunity-shared library. This
library is useless at the moment, but we will start moving the non-UI
code from Unity's source (the interface with unity-panel-service, the
implementation of the Dash specification) into this library, so Unity-2D
can be built on the same foundations as Unity.

This obviously has the benefit of reducing the amount of code we need to
maintain between the two implementations, but it also means that the
code will get much better testing and be much more stable. We also hope
to share more settings between the two implementations.

..

That's it for now, I'll be sure to keep everyone updated about the
progress!

-- 
Neil Jagdish Patel | Technical Lead
Desktop Experience Team
Canonical
27 Floor, Millbank Tower
London SW1P 4QP
Ubuntu - Linux for Human Beings
www.canonical.com