PCMan, On Tue, 2011-10-18 at 13:00 +0800, PCMan wrote: > I just passed my license exam yesterday. So that means I will have a > little more free time from now on.
Congratulations! > I'm now thinking about future development. > Since dbus support is now part of glib and nowadays dbus is widely > adopted, > maybe it's time to replace our own hand-made IPC with dbus and make > use of dbus more in LXDE. > It's possible to use dbus inside menu-cache and in the session > manager. > PCManFM might also use it for IPC and to provide some interfaces to > other applications. On the BIND 10 project, we also decided to switch to D-Bus after looking at a few alternatives to replace our own custom communication system. We haven't made the switch yet, so I can't say how much trouble it is. ;) http://bind10.isc.org/wiki/msgqReplacements > The second issue is the use of C++ in LXDE. Currently we mainly use C > and in the future there might be vala. > Doing programming in pure C is quite inefficient and error-prone on > memory management sometimes. > In C++, things can be better encapsulated if it's used carefully. > There also exists some very high quality libraries, such as boost and > some tools provided by google. > Using C++ inside LXDE only introduces one additional runtime lib, > libstdc++6.so. > So actually I'm considering the possibility of using C++ in PCManFM. > Implement some new features with C++ will be much easier than doing it > with pure C. > With C++, the development can be more rapid and we can utilize many > nice existing libs. > Later, I'll try to use C++ inside PCManFM is feasible and will do some > experiments in git branches. > Of course, the program should be kept as fast as old versions and > memory usage cannot significantly increase. > Otherwise, I won't use it. We also chose to use C++ when starting BIND 10, and I've been mostly pleased with the results. Performance is excellent, and the code is generally safer (smart pointers eliminate most memory or other leaks, basic data structures are already present in STL or Boost, exceptions let you handle faults at the appropriate place). The main problem with C++ is that it is very easy to go a bit crazy with all of the language. We crossed the line at one point when we had a bit of template code that only 2 people on the team could understand. So... manage your complexity carefully if you use C++! We use Boost, and have not had any real concerns at all. (We are limited to using the header-only version of Boost, due to licensing issues... our company is strictly BSD License, but we can still use almost all of Boost.) It's high-quality, very portable code. One recommendation is to also compile code with clang. The error messages are much more readable than g++, and you find a different set of problems. (Microsoft Visual Studio and Sunstudio both find different errors, but one runs only on Windows and the other only on Solaris, and neither is free.) One final advice is that we use Google Test along with lcov to do unit tests and also get code coverage reports. Any code without tests is probably wrong (and most of the code with tests too). :) -- Shane _______________________________________________ Mailing list: https://launchpad.net/~lubuntu-desktop Post to : lubuntu-desktop@lists.launchpad.net Unsubscribe : https://launchpad.net/~lubuntu-desktop More help : https://help.launchpad.net/ListHelp