On Sat, Jun 9, 2012 at 12:37 PM, Martin Gräßlin <mgraess...@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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
