wxFormBuilder v3.5.0b & wxWidgets v3.0.115 July 2014
As is typical for a lot of non-headline Ubuntu LTS packages, wxFormBuilder is busted as it does not generate minsize XRC tags, and quite likely has a load of other problems I did not even check for. As a result I decided to ditch it immediately and instead install the latest release, which was v3.5.0beta. I suspect that this beta requires wxWidgets v3.0, but given that I have had headaches with Ubuntu's wxWidget development libraries in the past, I did not even try to check whether it was an incompatibility or not and simply installed the latest wxWidgets from source.
XRC & wxFormBuilder together are an approximate equivalent of Glade for wxWidgets, so I tried them out with this in mind. Like wxGlade I felt wxFormBuilder was more WSYIWYM than WYSIWYG when compared to GTK's Glade, and hence took a while to get to grips with, but it is definitely a massive improvement over the (now abandoned?) wxGlade. Being a beta version it had a few things that ought not be there, and it was definitely less featureful than Glade particularly in the number of available widgets, but nevertheless I felt it was easily good enough to get things done.
Building wxWidgets 3.0.1I am not actually sure if all the
enableclauses are needed, but mediactrl certainly is.
tar -xjvf ~/Downloads/wxWidgets-3.0.1.tar.bz2 ./configure \ --prefix=/opt/wx-3.0.1 \ --enable-graphics_ctx --enable-unicode --enable-mediactrl make make install
All that's needed to do is then setup the anviornment variables:
export PATH=/opt/wx-3.0.1/bin:$PATH export LD_LIBRARY_PATH=/opt/wx-3.0.1/lib
Building of wxFormBuilder doesn't actually need
LD_LIBRARY_PATH but running it does. Ideally one should hack around with the makefiles to add
-Wl,--rpath so that the library path is compiled in, as
LD_LIBRARY_PATH is evil..
unzip ~/Downloads/wxFormBuilder_v3.5.0-beta-source.zip cd source chmod 755 ./create_build_files4.sh ./create_build_files4.sh cd build/3.0/gmake make build=release cd ../../..
Since this is a beta version I suspect it is meant to only be run in-situ rather than installed, but I decided to install it anyway:
sudo cp -r output /opt/wxFormBuilder
wxPython 3.0.1 & VirtualENVThe wxPython sources come with the corresponding version of wxWidgets, which is built in much the same way as I have done previously. It is assumed that
/optis writeable by the current user, as these days I keep development libraries & kits I expect to update semi-frequently here rather than either
/usr/local. I doubt that all the parameters I've given the configure script are actually required, and by the looks of things stc and gizmos are now part of the standard code-base..
tar -xjvf ~/Downloads/wxPython-src-184.108.40.206.tar.bz2 cd wxPython-src-220.127.116.11 mkdir bld cd bld ../configure --prefix=/opt/wxPython-3.0.1 \ --with-gtk --with-gnomeprint --enable-debug \ --enable-debug_gdb --enable-geometry --enable-graphics_ctx \ --enable-sound --with-sdl --enable-mediactrl \ --enable-display --enable-monolithic --enable-unicode \ --with-libjpeg=builtin --with-libpng=builtin \ --with-libtiff=builtin --with-zlib=builtin make make install cd ../..
Next stage is to setup virtualenv and install the wxPython bindings into it:
export PATH=/opt/wxPython-3.0.1/bin:$PATH virtualenv /opt/wxPython-3.0.1 source /opt/wxPython-3.0.1/bin/activate cd wxPython-src-18.104.22.168/wxPython python ./setup.py build --debug python ./setup.py install
..and finally a quick test:
export LD_LIBRARY_PATH=/opt/wxPython-3.0.1/lib cd demo python demo.py
I tried both building wxWidgets both as as a static library and passing
setup.py in order to avoid using
LD_LIBRARY_PATH, but both were unsuccessful as I suspect it is the python binary itself that searches for the wxWidget shared libraries.
Various gotchasBy the looks of things, the wxFormBuilder build script is not particularly robust, most likely because it assumes a Ubuntu-based system. This got me quite a few times as I was using a RedHat-based system rather than my usual Ubuntu desktop for my first run-through, but i suppose this is to be expected with notionally beta software..
For some reason wxFormBuilder assumes that you have done a standard install rather than a monolithic one, which if you did the latter by using
./configure --enable-monolithic, results in the following build failure:
==== Building additional-components-plugin (debug) ==== Creating obj/Debug/additional-components-plugin additional.cpp Linking additional-components-plugin /usr/bin/ld: cannot find -lwx_gtk2u_richtext-3.0 /usr/bin/ld: cannot find -lwx_gtk2u_propgrid-3.0 /usr/bin/ld: cannot find -lwx_gtk2u_stc-3.0 /usr/bin/ld: cannot find -lwx_gtk2u_ribbon-3.0 /usr/bin/ld: cannot find -lwx_gtk2u_media-3.0 collect2: ld returned 1 exit status make: *** [../../../output/lib/wxformbuilder/libadditional-30.so] Error 1 make: *** [additional-components-plugin] Error 2
In this case the only thing you can really do is go back and rebuild wxWidgets without
--enable-monolithic - this is why I use a separate wxWidgets install rather than the one included with wxPython..
Missing XML files at runtime
Upon running from
/opt rather than in-situ where it was built, you may well get an error dialog with the following messages:
00:53:05: Error loading images: The file does not exist. File: /opt/wxFormBuilder/share/wxformbuilder/xml/icons.xml <stringutils.cpp@221> 00:53:05: Error loading application: The file does not exist. File: /opt/wxFormBuilder/share/wxformbuilder/xml/objtypes.xml <stringutils.cpp@221> wxFormBuilder cannot continue.
This is due to a broken link, which can be fixed by the following:
cd /opt/wxFormBuilder/share sudo rm wxformbuilder sudo ln -s .. wxformbuilder
Missing libraries at runtime If built on 64-bit RedHat-based systems rather than Debian-based ones such as Ubuntu, you may get a dialog with the following:
Could not set current working directory (error 2: No such file or directory) /opt/wxFB/source/output/lib64/wxformbuilder/libcommon.so: cannot open shared object file: No such file or directory Error loading library /opt/wxFB/source/output/lib64/wxformbuilder/libcommon <database.cpp@1426> Could not set current working directory (error 2: No such file or directory) Could not set current working directory (error 2: No such file or directory) /opt/wxFB/source/output/lib64/wxformbuilder/liblayout.so: cannot open shared object file: No such file or directory Error loading library /opt/wxFB/source/output/lib64/wxformbuilder/liblayout <database.cpp@1426> Could not set current working directory (error 2: No such file or directory) /opt/wxFB/source/output/lib64/wxformbuilder/libadditional.so: cannot open shared object file: No such file or directory Error loading library /opt/wxFB/source/output/lib64/wxformbuilder/libadditional <database.cpp@1426> Could not set current working directory (error 2: No such file or directory) Could not set current working directory (error 2: No such file or directory) Could not set current working directory (error 2: No such file or directory) /opt/wxFB/source/output/lib64/wxformbuilder/libcontainers.so: cannot open shared object file: No such file or directory Error loading library /opt/wxFB/source/output/lib64/wxformbuilder/libcontainers <database.cpp@1426> Could not set current working directory (error 2: No such file or directory) /opt/wxFB/source/output/lib64/wxformbuilder/libforms.so: cannot open shared object file: No such file or directory Error loading library /opt/wxFB/source/output/lib64/wxformbuilder/libforms <database.cpp@1426>
On 64-bit Linux distributions there is no real consensus on the use of
lib64, which is complicated by issues such as having both 32-bit and 64-bit libraries installed. The build script and linker obvious have different ideas in this case, and I am inclined to take the easy way out:
cd /opt/wxFormBuilder ln -s lib lib64