FBP has been around for quite a while, having been invented by J. Paul Morrison in the 60s, but is now becoming more and more relevant thanks to the need for talking to multiple asynchronous APIs and different devices. While NoFlo has been stable enough for production use for about two years now, we ran a successful Kickstarter earlier this fall to push the development tools to a new level.
I attended the FSCONS conference last weekend, and gave a NoFlo talk. Since quite a few GNOME regulars were there as well, we ended up chatting about how NoFlo and FBP could be utilized in the desktop environment. I’m writing this to Planet GNOME to introduce some of those ideas.
NoFlo on gjs
This is of course only the first steps, but shows a little bit of the potential. While NoFlo’s low overhead could mean making actual GNOME applications with it, the initial sweet spot for the integration would be:
- Having a fast UI prototyping tool in GNOME, a bit like how Quartz Composer is used on the Apple platforms
- Allowing users to automate parts of their desktop workflow through simple FBP programs
Vinod Khosla summarized the significance of this quite well:
An author can write a book, a musician a song, a painter a painting. Most UI designers cannot realize their creation
Bringing the GNOME platform to NoFlo
The big part of enabling flow-based GNOME development would be to provide NoFlo components for the various APIs in the GNOME ecosystem. This could be done manually, but quite possibly we could automate at least parts of the process by some smart GObject Introspection hacking.
As I’m currently quite busy on the NoFlo Development Environment, I won’t be able to do this personally. But this sort of work would be the perfect fit for something like OPW or GSoC. I’d be happy to mentor that effort.
The NoFlo Development Environment
We’re building a quite nice graphical editor and debugger for flow-based programs. You can see the current state in a UI walkthrough I posted last month.
The NoFlo UI is a web application that could be brought to the desktop by running it inside a webview. To control the NoFlo runtime inside gjs we would also need a GNOME library for dealing with WebSockets, as that is the way we talk with non-browser runtimes like Node.js or the microflo environment for Arduino programming.
By supporting the NoFlo network protocol on gjs we could easily start, stop, modify, and monitor FBP programs running inside GNOME.
In the long run it would also be possible to build a native flow-based editor as well. After all, since the data model and runtime interactions are standardized, there is no reason why multiple different tools couldn’t interact with the same NoFlo graphs.
While I’m currently working outside of the desktop context, having been around GNOME since early 2000s I’m still following the project with interest. Having NoFlo there would be a great way to revitalize this connection.