You can do some pretty evil things with GtkTreeView if you put your mind to it. One of the most common questions over the years has been how to reflow (wrap) text. The short answer is you can’t. The answer for those willing to hack around it is something like:
So the real question is “Why not use GtkListBox?”
GtkListBox is a fantastic widget. But there are some things it does not deal well with today. I presume that once it can deal with only keeping a minimum number of widgets in memory (and the size-request magic that goes with it) it would be a better solution.
Builder keeps a lot of widgets active during the lifetime of the application, and that makes style propagation particularly slow. The fewer widgets we can use, the more responsive we can keep things. (And of course, there are multiple ways to do this).
Features that the UI redesign depends on have landed in libdazzle. This includes animated widget transitions and more.
Builder’s Flatpak of Stable and Nightly channels now bundle OSTree 2017.7 and Flatpak 0.9.6 which should improve situations where we were failing to load summary files from the host.
A painful bug where Builder (Nightly Flatpak channel) would crash when launched from the Activities menu was fixed. This was a race condition that seemed to not happen when run from the command line. After some manual debugging the issue was fixed.
To simplify future debugging, we’ve added a “Bug Buddy” like feature. If you remember bug-buddy, you’re old like me. If Builder receives a SIGSEGV, we try to fork()/exec() an instance of gdb to inspect our process. It will dump a lot of useful information for us like where files are mapped in memory, instruction pointer addresses, and any callstack that can be discovered.
Libdazzle gained some new action muxer helpers to clean up action visibility.
The new editor (perspective, grid, columns, and view) design will help us drastically simplify some of Builder’s code. But this also needs forward-porting a bunch of plugins to the new design.
The new libdazzle based menu joiner landed to help us integrate contextual menus based on file content-type as GMenu does not support “conditionals” when displaying menus.
meson test should work again for running Builder’s unit tests under the Meson build system.
Anoop blogged about his work to add a code indexer to Builder here.
Lucie blogged about her work to make documentation easily accessible while you code here.
Umang blogged about his work to improve our word completion engine here.
You can do some pretty flashy things with Dazzle. Tonight I added the missing pieces to be able to make widgets look like they transition between parents.
The following is a video of moving a GtkTextView from one GtkStack to another and flying between those containers. Compare this to GtkStack transitions that can only transition between their children, not their ancestors. Fun!
There really is a lot of code in libdazzle already. So occasionally it makes sense to spotlight some things you might be interested in using.
Today, while working on various Builder redesigns, I got frustrated with a common downfall of GAction as used in Gtk applications. Say you have a UI split up into two sections: A Header Bar and Content Area. Very typical of a window. But it’s also very typical of an editor where you have the code editor below widgetry describing and performing actions on that view.
The way the GtkActionMuxer works is by following the widget hierarchy to resolve GActions. Since the HeaderBar is a sibling to the content area (and not a direct ancestor) you cannot activate those actions. It would be nice for the muxer to gain more complex support, but until then… Dazzle.
It does what most of us do already, copy the action groups between widgets so they can be activated.
// my_countainer should be either your headerbar or parent of it
// my_view is your view containing the attached action groups
// the mux key is used to remove old action groups
"a mux key");
Exciting, I know.
The number of times I’ve been asked if Gtk has a GtkPaned that can have multiple handles is pretty high. So last year, while working on Builder’s panel engine, I made one. It also gained some new features this week as part of our Builder redesign.
It knows how to handle minimum sizes, natural sizes, expanding, dragging, and lots of other tricky bits. There are lots of really annoying bits about GtkPaned from it’s early days that make it a pain when dealing with window resizes. MultiPaned tries to address many of those and do the right thing by default.
It should be strictly a step up from using GtkPaned of GtkPaned of GtkPaned.
If you find yourself needing to troubleshoot Builder (hopefully just during our development cycles) you can now run the command “counters” from the command bar (Ctrl+Enter). This gives you access to some internal counters.
You can get these out of process too, using dazzle-list-counters PID which cracks open the shared memory page and dumps the counters.
As you might imagine, the counters are in libdazzle now so you can have the same sort of feature in your (C-based) applications quite easily.
The other day, Sri asked me for a quick Gtk example for a talk. Basically he just needed a window with a header bar. So I put together this repo on github with some examples in a variety of languages. After a few contributions from our community, we have even more examples.
I think it would be neat if people submitted pull requests for more languages. Take a peek and see if something you know about is missing. Ideally the example should use GtkApplication, Gtk templates (and resources if possible), and a window with a header bar.
Having these available will make it easier for me to make templates in Builder for more exotic languages.
I spend a lot of time making flashy widgets for Gtk. Mostly because I find it entertaining. You can now benefit from the culmination of many years of my trial and error in a new library I’ve created, libdazzle. The code is currently on github but I suspect I’ll move it to git.gnome.org relatively soon.
Why another library? Because I wanted to. But also, because managing all of this custom widgetry in Builder is starting to get out of hand and I’d really like others to be able to use the code too. Every time I go work on another hobby project I get annoyed that I have to copy and paste a bunch of code over.
This library is truly the culmination of many years of my time writing flashy Gtk+ widgets and the surrounding plumbing. You’ll find everything from an animation framework, menu merging, tree helpers, missing data structures, caching, signal and property management, a panel engine, layered gsettings, theme management, state machines, keyboard shortcuts (including chords) and more.
It comes in at nearly 50,000 lines of C. You can imagine why I’m tired of the copy pasta.
The project builds with Meson, so it should be easy to use as a sub-project if you don’t want to rely on a system installed version. It has support for GObject Introspection and can also generate a .vapi for Vala if that’s your thing.
There is no documentation yet, but I’m slowly getting more and more tests added which can serve as examples in the mean time. Go read some code, it’s good for you.
My approach to development can often differ from my peers. I prefer to spend the early phase of a cycle doing lots of prototypes of various features we plan to implement. That allows me to have the confidence necessary to know early in the cycle what I can finish and where to ask for help.
We have some big stuff coming this cycle.
Panel Engine Revamp
Allan has been working on some major design work in how our panels and documents work. This has been needed for some time and things are looking good. To keep up with this, I’ve been doing some major improvements to panel-gtk, our panel engine. I managed to shake out a few bugs in the process and those fixes have made their way into the gnome-builder-3-24 branch.
The test program is not much to look at, but we have some necessary plumbing in place to do new things.
Shortcut Engine and Key Themes
Furthermore, I’ve been building a new shortcut engine to do the more advanced features we need. Gtk Shortcut Engine (GSE) provides plumbing for applications that need complex features such as multi-key “chords”, keyboard themes, and custom overrides by users. Many of you have asked for this in Builder, and I’m confident in saying it is coming for 3.26. You can find the work in progress in the shortcut-engine repository.
Ultimately I had to import a copy of the upstream’d GtkShortcutsWindow (based on what we wrote for Builder in 3.20) so that we could support chords. So the code-base looks bigger than it really is. The primary design (besides the keyboard themes) is the concept of a GseShortcutController and GseShortcutContext. These two things allow us to do some fun stuff like emacs-style “minor modes” as well as Vim-style modal keybindings.
I expect this to allow us to cleanup our Vim emulation quite a bit. It also solves some of our outstanding problems with keyboard shortcuts and unpredictable GAction activation. It’s really quite fundamental to how you’ll be interacting with Builder from a keyboard going forward.
The big feature for 3.26 is the debugger. I have enough of a working prototype in place to have a reasonably good idea of what the moving parts are. As soon as we land the new shortcut engine and some of the panel updates I’ll be back finishing up that feature.