There has been some concerned raised and I want to discuss this on its own thread so no one misses it.
In the upcoming weeks there is going to be a major change in the blackbox internals. Part of this is to remove the home brew linked list code and use the STL. Part of this is to allow for support of the NET WM spec (compliance with KDE and eventually GNOME). Part of the effort is simply refactoring which happens to code every now and then as part of its life cycle. This is one of those times in programming where everything stops because one change breaks everything. The classes in blackbox are tightly interwoven and a seemingly small change causes havoc everywhere. Also some of the actions the net wm spec desires are not easily performed with the current code. An example of this is the _NET_CLIENT_LIST. blackbox is expected to return a list of every open window it manages. The only way to implement this currently is to loop over each workspace requesting its internal window list and make one long list. Then we convert this list to the format the message must be sent back in. Rather than write more list code I would like to use standard C++ style container classes. More C++ people understand them which will allow for more people to hack on blackbox. When we have changed how blackbox talks to external programs we must then rewrite all of the bbtools to support this new mechanism instead of the proprietary protocol we use now. Rather than do this for every bbtool we have decided to create a blackbox foundation class library which contains all of the bits that makes a bbtool look and feel like a part of blackbox. This way people can write blackbox native apps faster as well as keep in sync with bug fixes from the group. Currently each tool has a copied fork of code from the window manager and each one is at a different place in the tree. Some of them have bugs fixed a year ago while others have features not found in the others. Yes, in a small way this duplicates the KDE/GNOME/XFCE/whatever group's work. But that is our choice. The other alternative is to force blackbox and friends to depend on an external toolkit and all of the dependencies that brings with it. This new class lib will *NOT* be a replacement for a full featured system like KDE. It is meant for writing small apps like the pager or bbmail. Basically it will provide easy access to the net wm atoms and to the gradient code which gives blackbox its unique look. It will also provide the i18n class for easy translation into other languages. As you can see there is quite a bit to work on. Let me assure you that once things get into full swing patches and suggestions will be welcomed. But the initial work MUST follow the laid out plan and be executed by those who are familiar with the code base as well as C++. This is not the time for new coders looking to learn their trade. You can do that by helping flesh out the foundation classes, report bugs, add features, etc. when the time is right. To assist those eager to help, during this restructuring I intend to document every class, method, and variable of importance in blackbox. doxygen is a quite nifty tool and blackbox will be structured to support auto documenting of its internals with it. Let me just finish by saying it is wonderful that people want to help. Normally I would welcome the help. My Debian bugs often end with "Patches welcome" and that has been my attitude on this list as well. Once cvs has the new code base in it feel free to start submitting ideas, patches, etc. Thank you for the support.
