kde plasma workspace structure

[Alex Fiestas]

On Sat, Jun 9, 2012 at 12:37 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> Also from looking at the KWin source base I have to disagree about the
> benefits of keeping code portable. It makes the code ugly, adds additional
> ifdefs. Keeping the source compiled with different compiles is a good thing,
> that's why I compile KWin in my Jenkins with clang and gcc.

KWin is a reaaally different use case, but maybe you can make use of
this feedback.

I have been struggling with all this abstraction thing, I have some
conclusions it may be useful to have in mind for further developments.
Let me explain you (all) two good examples of a successful abstraction
and a not so good abstraction.

LibSolid:
Small library that only does one thing, hardware discovery. It is
abstracted in a way that you can plug backends (build time) and thus
will provide to the exposed interface with information. For example:

Solid::Device::listFromType(Solid::DeviceInterface::StorageAccess):

This will go through all the backens asking "Do you support
StorageAccess? yes? give me yours).

When linux ecosystem changed from HAL to U*stuff it did without a full
replacement for HAL, even if you used all the U* stuff together you
couldn't get the same amount of functionality that we had with HAL.

It took us 3 days for porting all KDE software that used libsolid from
HAL to UDisk,UDev, UPower, Alsa. Before the sprint took place we
already had some code around, but you get the message, in a few days
we ported all KDE software to the new stack.

Now UDisk1 is being deprecated (yaay ! ) and we already have UDisk2
support, so no application will need to be change in order to modify
this.

Now about non linux applications, we had a Windows backend nobody
cared about (not since I'm the maintainer of libsolid) so it was in a
not-really-working state. A few weeks ago a fellow Amarok developer
appeared and started fixing it so now Amarok can do usb-storage on
windows.  How much effort did I had to put into making Windows work?
none.
Did the Windows abstraction improved or tested more libsolid? Yes, we
detected that Windows doesn't have the concept of one of our
interfaces (don't remember which one right now). So we may want to
drop that interface in the future (if it makes sense in all OS).

I call this a great success on abstraction, making our software better
and NOT adding barriers to either libsolid developers or application
developers or windows/osx/other developers.

Solid::Control:
Since libsolid was (and is) mostly about hardware discovery we needed
something to control this hardware. The idea was: You get a list of
network interfaces with libsolid, then you connect to a Wifi using
Solid::Control.

It sounded wonderful, we should be able to have support for multiple
backends, we wanted to be prepare for more NetworkManager API changes,
or Bluez changes etc.

Time passed and at the end we end up with with 4 libraries that were
only used by almost one application, for example:

KBluetooth -- Solid::Control::Bluetooth
Network Management --Solid::Control::Network
KRemote -- Solid::Control::Remote
PowerDevil - Solid::Control::Power

While we were theoretically ready for new backends at the moment of
truth those abstracted libraries were more of a barrier than a help
when any change needed to be done in either application.
Also we realize that backends were really hard to do because the
public interfaces were coupled with some concepts, great example is
Solid::Control::Network and wicd / conman backends.

So at some point, we looked at the big picture and decide that there
was no point for having this libraries abstracted mainly because they
were almost only used by their primary applications and they were too
complex to do a good abstraction (we won't be able to make a good
abstraction out of wicd, conman and NM).

So we drop all of them, and instead we added the needed bits of api to
libsolid, only the things that really were being used by many
applications, like for example:

-Inhibition
-CanIconsumeResources ?
-I'm connected to a network ?

At the end, thanks to this experiment now we to know where to abstract
and how to do it properly.

So to sum it up, abstract and multi platform? yes. But wisely and
where it makes sense.

Last point, same thing is happening with PA, it is too different for
making KMix make full use of it. If we want to have a great sound
support we will have to develop something only for PA.