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.
Comments
Toot!
Share