blog dds

I am a big fan of open-source software, and I use many open-source programs on a daily basis. Some of my favourite systems, on which I depend, include the FreeBSD operating system, the apache web server, and the vim editor. I also often use graphviz, CVS, Ghostview, gnuplot, LaTeX, and the GNU C Compiler. I find all of these systems robust, well documented, and, in many cases, superior to their proprietary alternatives.

A few months ago I found myself looking for a GUI development framework. My requirements were:

• Portability across Windows and Unix platforms
• Compatibility with the C/C++ runtime system
• Use of native GUI widgets
• Open-source implementation
• A free license that would allow unrestricted commercial use of the programs that used the system

After some searching I settled on wxWindows. The newsgroup articles I found with a Google search were generally positive - even enthousiastic, so I adopted it and started using it. My first impressions were favourable. Although implementing a GUI application was a bit more difficult than using Microsoft's MFC and the associated Visual Studio wizards and GUI editors, I offset that difficulty against the additional portability, and the warm fuzzy feeling of working on a live open-source platform, instead of proprietary one that was getting deprecated.

Now, as I use wxWindows to develop a real application, I am encountering a number of problems.

• The memory management of the sizer implementation is idiosyncratic and undocumented. The wxSizer::Add documentation does not mention that the sizers added must be heap-allocated objects, and that the sizer implementation will delete them on destruction From a design point of view the current situation is confusing: users allocate and the library deallocates. In addition, the current implementation does not allow users to supply stack or static-allocated sizers. Ideally, the deallocation should be removed from the library, and made a caller responsibility.
• The limits specified in the spin control widgets (wxSpinCtrl) are not enforced for the text portion of the widget.
• There is no mention that the FileHistoryLoad method must be explicitly called by the application. Confusingly, the documentation of the corresponding FileHistorySave method specifically states ``This must be called explicitly by the application.'' In addition, the history load/save functionality is not implemented in the docview sample application, so it was difficult to understand the mechanics of its realization.
• My application exhibited mysterious crashes when I failed to include in the class definitions the IMPLEMENT_CLASS and DECLARE_CLASS macros.
• The methods SetDocumentSaved and GetDocumentSaved are not documented. Fortunatelly I was able to find them by symbolic debugging a problem and grepping a field name at the source.
• Also not documented is the need to call SetDocumentSaved and SetFilename if implementing your own save method. I discovered this fact by examining the source of wxDocument::OnOpenDocument()

I have wasted valuable time trying to track-down those problems; a less persistent or experienced developer might have given up.

This has been a wakeup call for me. My very positive experiences with the other open-source projects I listed in the beginning of this entry had conditioned me to expect open-source systems to be stable, well documented, and generally bug-free. A moment's of rational thought will of course come to the result that this can not possibly be the case. Nevertheless, I regard the experience as one of the reality-checks we all need from time to time.

Read and post comments