Builder 3.16.2 has arrived!
I released 3.16.0 a couple weeks ago without much fanfare. Despite many months of 16-hour days and weekends, it lacked some of the features I wanted to get into the "initial" release. So I didn't stop. I kept pushing through to make 3.16.2 the best that I could.
Over the next couple of weeks I plan on writing more detailed posts on the technology. I couldn't do that while building it because I lack the ability to multitask on that level. So lets take a visual look through Builder 3.16.2. In future posts we'll dive into the various components that make up LibIDE.
Here we have the new project selector. It is shown when you start Builder. I assume long-term we'll skip this screen and jump you right back into your old project.
This is the new project dialog. Currently you can create a project from an existing one, or checkout from git. I'd like to have a workflow for quickly cloning from git.gnome.org and possibly github.
While Builder is focused on writing GNOME software (and therefore autotools), you can create a project manually by selecting a directory. Unfortunately, you wont get fancy build features in doing so. Builder is abstracted in such a way that we can add additional build systems. If you have a build system you care about, we accept most patches.
With a couple of minor patches to libgit2-glib, we got project cloning working in time. Please file bugs as you find them. We are likely to hit lots of corner cases with authentication.
Here is the editor. It looks incredibly simple, and that took a lot of work. One thing I'm particularly proud of is how it feels like a single widget rather than being composed of lots of little ones. Relentless iteration was key here.
This contains Builder's custom style scheme for GtkSourceView. Also notice the grid background. That work got pushed upstream into GtkSourceView this cycle.
If you take a look at the macros, you'll notice that macro names and expansions are highlighed. Also, type names are highlighted. This all comes from the parsing the file with clang and extracting information from the resulting AST.
You can quickly switch buffers in the view stack.
buffers commands in the command bar will focus this (more on that later).
If you are using autotools with C or C++, we can do a reasonable job of extracting CFLAGS to provide to clang. I went through painstaking effort to make that fast.
We provide you a drop down of symbols that we discovered in the file. Clicking on one will focus it in the editor.
You can switch between header and source quickly with F4.
While we try to do the right thing with syntax formatting, sometimes we get it wrong. You can override the discovered settings with the editor tweak dropdown.
Note that we support editorconfig and modelines today. We also provide some gsettings to set defaults across all your projects on a per-language basis.
Clicking on the document title will give you options related to that document. This includes splits, preview, and save operations. More on preview later.
Splits are pretty universally required out of an editor these days. Builder was designed with that in mind.
Notice the highlighting on enums and function names below. Yeah, we do that too.
I rather like the new designs for creating new files. So I borrowed them for the project tree.
We try to be smart and expand the selected item while you are creating to give you all the context we can.
You can even do a few things with what is in the tree. Clearly this is early on, we have lots more to do. No DnD support yet, sorry!
File rename. I prefer the popover design to editing in place with GtkCellRendererText. I know it's not much context, but it's something.
Honestly, I haven't spent that much time on preferences. But we do have some. I'd love for someone to come own this feature in Builder.
We have a few flavors of keybindings. I prefer Vim.
Late in the cycle, Alexander Larsson had an idea to do keybindings using the new "gtk-key-bindings" CSS property. It was no walk in the park, but it does work. Our Vim is implemented in CSS.
I often get asked why not just use NeoVim for our Vim mode. Someday that might be an option, but not today. I have a few reasons. First, I don't want to maintain multiple editors. Some users will want emacs too. I want all the features we put into a particular mode to improve the other modes equally. It wont ever be perfect, but it's certainly functional.
If you have ideas to merge GtkSourceView<->NeoVim, by all means prototype that and we can look at using it. But wholesale using another widget is out of the question. I don't want to have to absract "IBreakpoint" 4 times for 3 implementations and an interface. That's insane.
Global search is handy for opening files. I certinaly don't use the project tree to open files. This is way faster.
You can also search for documentation.
I do expect this feature to iterate a lot in the future. We have lots of designs to work through.
One thing I never liked about Vim was that Shift+K would take you out of Vim to read the manpage. We can just show you the documentation side-by-side.
I still consider this a crutch though, we should really be providing good documentation at your fingertips when you need it (such as during autocompletion).
We have live preview for markdown.
I think we need a new markdown parser that lets us inject the cursor position. Right now we don't have a way to keep the editor and preview lines matched up vertically.
Works well for small files though.
You have no idea what it took to generate yellow squigly lines with GtkTextView. I had to hide data in the semi-public, albeit out-of-space GtkTextAppearance structure. I ended up stealing a few bytes here and there in the unusable padding between structures.
Errors are easy of course (just set PANGO_UNDERLINE_ERROR). But both that and and setting color is one of those 10+ year bugs. Clearly we should be less crazy in 4.0.
Additions and changes are rendered in the gutter to the left based on colors defined in your style scheme.
We have a dark mode!
You can enable and disable it with
dayhack in the command bar. Let this be an example of how bad I am at naming things.
Also, we have a command bar! You can execute various GActions in the widget hierarchy as well as some vim commands.
For the truely adventurous of you, you can enable the experimental clang autocompletion. It crashes a lot. I don't even run it. You are crazy, don't do it!
Completion of clang proposals builds upon our snippet engine. That means you can tab through the various parameters which contain parameter information to give you some context. Context is paramount.
The snippet engine is pretty powerful. You can have tab-stops, linked edit points, edit points which transform values from other edit points, or none at all.
Also, they come with superfluous animation.
So many of the details in Builder aren't visible. So I'm glossing over half the work that went into this release. I'll be expanding more on that in the future, in posts that are not quite so screenshot heavy.
-- Christian Hergert 2015-04-16
Back to Index