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
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
The newsgroup articles I found with a Google search were generally positive -
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
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
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
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.
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
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
, or share through