Published 2015-03-17 00:00:00
As we are not so crazy busy this month, I finally get time to write about one the key tools that we developed to enhance our development process.
Back in 2010, We built a desktop application called app.Builder.js, written in seed (webkit+gnome). It's main purpose was to enable the rapid development of RooJS applications (a fork of ExtJS). It worked wonders over the years, enabling us to build and prototype applications quickly, and continually improve on them.
While it worked well, due to the nature of Javascript bindings into C, the occasional code problem would cause a complete crash. As most of the code is dependant on the javascript bindings, and gir files that define them. It also became a little troublesome to maintain, extend as it was dependent on the availability of gir bindings for new widgets.
Around mid 2014, It was decided to port the code from Javascript to Vala. Being a relative new-commer to Vala, we first tried porting our Gitlive application, which monitors the filesystem for changes and instantly commit's and pushes all changes. This relatively small project gave us the skills set ready to rebuild application builder in vala.
The first steps on this process was to port the non-User interface components. As Vala is both a compiled and strict type language, we had to be a bit more carefull about the coding, in our original code, there where a number of situation where we took advantage of the 'extendability' of javascript objects. However in Vala we had to be considerably more explicit about what was stored (and why).
However even given these language constraints, the porting to Vala proved to be very simple. While object structures had to be more formally typed, Local variables in Vala, can normally be auto inferred. Frequently code that worked in Javascript, just ported straight to Vala without changes.
var some_instance = new SomeClass();
This was especially true as the javascript API for Gtk and other GObject based libraries is very similar to their Vala equivalent.
After defining our core libraries, to read/write the bjs files, look up the properties of objects etc. we then started to address the User interface. This is where we started taking advantage of the better language bindings to libraries like clutter.
One of the original visions I had for the builder, which allows you to mix code with UI design, was that flipping between coding, and building the UI should be seamless, one minute you are laying out the interface, then you go onto working out what should be occurring when buttons are pressed, menus are selected, grid lines are deleted. In the original builder, our code entry was a dialog that popped up (frequently at some random place on the screen). Using the clutter library, my vision of the WYSIWYG view of the rendered web page in webkit would shrink to one corner while the code was edited, once done, the code editor would hide, and you could test the results of the change.
Again with the original application, the 'new' property or 'add' object list was constantly visible on the screen, even when it was not really being used, in the new User interface, this would expand while being used, and then collapse away when other tasks where being completed.
Selecting files to edit would also be a more seamless interaction, in our old design the file / project chooser took up valuable screen real-estate while not actually being needed. in our new design we can animate (just like good ole SGI) so that the list of files appears on the back side of the webkit preview - one button flips you from edit mode to 'file selection mode'. and we can use a clutter grid to show thumbnails of the actual layouts.
The current code - in it's rough state is currently at
http://git.roojs.org/?p=app.Builder.js;a=summary
Check out and see if you can build it..
git clone http://git.roojs.org/app.Builder.js
have a look at INSTALL.txt - for a rough idea of the packages needed, then just run
./autogen.sh; make install
Watch a short video of the builder in action.
