Published 2015-05-09 00:00:00

My final words this week on the builder - handling resources, and fake web servers

While I talked in the other posts about how the builder extracts the API for various components from the libvala library and the vapi files, some information that the builder requires has to be manually, created or fetched from other locations.

When the Builder was written in seed, it basically looked at the source code directory, and read files relative to the source code. For the Vala version however, it's not expected to know about the source code directory, so I had to use a different approach.

The Resources

The builder needs various files to run, most of which are in the resources folder in the source tree, this includes
  • Usage files for Roo, and Gtk - these are the files that define that you can add a Gtk.Box to a Gtk.Window, or a to a Roo.grid.Grid and if the child element is a property or just a standard child in the tree.

  • HTML and javascript for rendering the preview. When the Preview of the web applications are rendered, there is a standard set of javascript and HTML that make up the page.

  • An overrides file for the Gtk API, Since we write the source code in vala, It generates constructors for the Gtk Objects instances, the parameters that are needed for the contructor are usually named to match properties, so it can fill in the correct values for the constructors. In some instances this is not correct (a Gtk.ListStore for example as a variadic value for the column data) so the overides file does some mapping here to help out the code writer.

  • The Roo API, when we generate the documentation for roojs and the bootstrap part, we also output a javascript file which contains the API details.

  • Plugin editors - as discussed in the previous post, we use bjs files (the default file standard for the builder) to store the plugin code. 

When fetched these files are now put in the ~/.Builder/resources folder.

Fetching the resources

When I converted the application to use vala, we originally hard coded this to locations on the file system, however that was not really that portable, so I added some code to download the files using libsoup from our git repository. This code would run when the builder started, and could often delay startup times by a half a minute. 

Since these files do not change much, this loading was a bit of an overkill, however since we fetched from the standard git web cgi, there was no simple way to check if the file being downloaded was any different from the file already on the file system. To get around this, we needed to find another way to fetch updated resources.

Our in-house git repo is partially mirrored on github, so after fixing the auto-mirroring hooks, I changed the code in the builder to use the github file API. Along with this I added the ability to 'update' the resources while the application was running (there's a buttons for it now.. although it may move soon to the new Gtk.Headerbar menu button.).

Using the github API we are able to parse the resulting JSON directory listing, find out the git sha1 for the required file, and compare it to the sha1 on the local file system. Meaning we only need to fetch files which differ. Current this is hard coded to our github repo, but It would be trivial to add a setting to pull this from a user-defined github repo, enabling users to add their own Editors, or even start sharing templates for applications or web sites.

A fake web server

The 'Web' application creator part of the builder uses Webkit, historically this has used a mix between the local resources, and also assumes that the roo library is also available via apache on localhost. To try and make it easier to use, I had for quite a while considered serving the javascript and images from the roo library either using a web server built into the application, or by some similar method.

As I investigated this I discovered due to the change in how Webkit2 now seperates the rendering, it is no longer possible to capture requests for network resources and supply a different response. It is however possible to register a special url scheme - in our case we used xhttp://. this can then be handled by the builder, so that it returns a file from the local files system (either a file from the resources downloaded above, or a file from the local file system. At present we are serving the roojs library from the local files system. but the location is hard coded.. (this needs to be fixed).. the code for this is inside our FakeServer.vala 

Anyway that's quite enough about the builder...

Add Your Comment

Follow us on