Builder

GUADEC 2018 BoF Ideas

• Keyboard shortcuts overhaul
  • Can we do some design on this so we have a cohesive keybinding set
  • Include panel movements w/ keyboard
  • Can someone make a shortcut cheat-sheet graphic
• What should our git workflow look like?
  • Do we want to use git worktrees?
  • How about staging and viewing commits?
  • What about review with gitlab?
  • Who wants to go design this whole thing?

Builder 3.28 Ideas

• Profiler improvements in Sysprof for simple memory profiling and Gjs support.
• Configure program arguments when running application (Builder needs --standalone for example)
  • We got basic support in 3.26, we need something more advanced now with UI support.
• Unit testing integration (possible outreachy/gsoc project)
• Move clang and vala out of process (and implemented as language servers)
  • This one is slightly tricky deployment-wise as we will need to get those into the flatpak-sdk
• Git integration (using as much of Gitg as possible)
• Improved documentation
• Debugger variable and visualizer support
• Debugger command line/prompt interface
• Improved auto-completion window
• Code folding
• Other ideas?

Project Ideas

If any of the projects below are interesting to you, please join us on irc.gimp.net in the #gnome-builder channel to coordinate. We can help you get started and familiar with the Builder code-base.

Test Suite Runner

We would like the ability for users to run the tests for their project in an automated fashion without resulting to the command line. This project has two steps. The first step is to teach the build system abstraction about “Test Suites” and “Test Cases” (a test suite is just a collection of test cases). With this knowledge, a new panel can be added to Builder which shows the status of the tests with a simple icon to indicate whether the test has passed or not. We should also add a new keybinding to quickly run unit tests and see the result panel.

1. Create new IdeBuildTargetType enumeration to libide that contains types such as “program”, “test-suite”, “library”, “resource”, etc.

2. Add IdeBuildTarget:target-type property

3. Create a new “test-suite” plugin containing an IdeWorkbenchAddin that can add a new panel to the editor perspective

4. Use an IdeTree, IdeTreeBuilder, and IdeTreeNodes to create a list of test suites and their results. We might need to add an IdeTestRunner abstraction that can run the tests, so that various build systems can implement this. For example, the autotools backend might want to use tap-driver to extract information about the results. Meson might have its own test-suite helpers.

5. Allow viewing the logs for failed unit tests.
6. Add a keybinding to execute a “run unit tests” action.

Branch Tools

While Builder will watch your local git working directory for switching branches, it will now provide UI to help you switch branches. We need the ability to switch branches from the Builder UI. My best guess is that we will want this somewhere in the “OmniBar” project popover which can be found in the center of the header bar. When switching branches, we probably want to allow the user to save all their work and either apply it to the new branch, or commit it to the previous branch.

Staging and Committing

We would like users to be able to commit their changes to the underlying Version Control System (IdeVcs) without resorting to the command line. We’d also like to reuse as much as we can from the Gitg project including UI and libgit2-glib. We probably want to add a new “Versioning” perspective where users can manage this step of the software lifecycle.

We will probably need to git-submodule gitg, or portions there-of, to reuse as much as we can. Coordinating with Nacho and Jessevdk will help you find the right solution.

"Reinteract" style worksheets

Years ago, Owen made this really cool interactive Python workspace called "Reinteract". You could edit snippets of python and interact with the results. There were renders for plots and other fancy output.

If we had a basic implementation of something similar to this, we could perhaps even build tutorials inside of Builder using such technology.

External Device Support

Builder supports the concept of “Devices” in libide. The goal is to allow users to push their code to a particular device such as a tablet or phone that supports GNOME. Possibly even a remote GNU/Linux computer such as a server or IoT device.

Some integration with other unfinished components will be required, so that we can setup a remote debugger, profiler, and binary deployment to the device.

Some work has been undergone to add flatpak support to adb, the Android Debug Bridge. This allows us to push a flatpak to a device with a patched adb.

FlatHub

A new project is getting started to allow building flatpaks in an automated fashion. It would be nice if Builder could allow pushing builds to FlatHub and allow the user to get a response about the success of the builds. This might be useful for cross-compiling as well since it is likely that FlatHub will support compiling on i686, x86_64, and various ARM hardware.

Floating, Draggable Panels

The panel system in Builder is fairly static today. We would like to allow some level of user configuration to panels. This will require completing the DnD capabilities in panel-gtk (which can be found in contrib/pnl).

Kernel Module Template

Various programmers who work on the Linux kernel have expressed interest in being able to use Builder. This will require us to support a few things better than we do today. Notably:

1. Ensure we support the kernel indentation format well (8-space hard tabs, with various indentation rules)
2. Add a “kernel module” template that allows building an out-of-tree module.
3. Build system hooks that can build against an installed kernel
4. Allow choosing which kernel to compile against in the Build Preferences based on available kernel-headers/kernel-devel packages.

Indentation Engine

The indentation engine in Builder is very rudimentary. We have some prototypes for a new design that would be nice if someone could run with. It is based on a “tree of interesting points” design and a set of selectors to determine what to do.

However, if someone wants to run with this, you’d have freedom to experiment with whatever design you’d like. The main thing we’d like to gain is to simplify the process for adding a new indenter and allow users to be able to tweak the indentation rules based on their projects coding sytle.

Refactory Engine

Some work has started in wip/chergert/refactory

Builder needs a refactory engine that can be used by refactoring plugins. This should provide the mechanics for applying changes across the entire project and some basic undo support. Plugins may want to add a specific refactory command and this infrastructure should make that as simple as possible.

Three refactory commands that should be implemented to validate the design would be a cross-project rename (basically a sed/awk command across the project), renaming of a local, and renaming of a header. I’d also like to see function renames and eventually extract method operations. We should also have a specialized operation to rename a GObject which deals with function renames, class renames, includes, etc.

UI Designer

We have been hesitant to work on a UI designer for Builder until we get to the point where GSK and constraints have landed in upstream Gtk+ 4.x. The UI designer we want to have in Builder will heavily rely on these core features in Gtk+.

We would also like storyboarding to be part of this design.

The design is very much in the early stages, so if this is something you’d like to work on, we have a lot of planning before any lines of code should be written.

CMake Support

Basic cmake support has landed, but we still need someone to implement $CFLAGS, $CXXFLAGS, and $VALAFLAGS extraction. This involves figuring out how to extract the various GCC/G++/Vala commands that are executed by the ninja backend so that we can use them to prime Clang and libvala for semantic information.

Snippets Editor

Currently Builder does not have UI for editing snippets. We need to add a snippet editor to preferences so that users can view the built in snippets and modify them or add their own. It should be separated by languages. You will probably need to use “subpages” in Builders preferences engine to perform this. You can see an example of how to do that in the “language preferences” in “libide/preferences/ide-preferences-builtin.c”.

Move Clang out of Process

Builder currently uses libclang in process. This means that our memory footprint can get pretty large. Additionally, it subjects us to a lot of memory fragmentation. We need to move libclang out of process using the IdeWorker plugin interface. A new Dbus service will need to be added to IPC from the UI plugin portions (such as clang autocompletion) to the worker process. IdeWorker provides the hooks necessary to create this plumbing. By returning a large GVariant for completion results from the clang worker to the UI process, we can reduce memory fragmentation. This is because we can have a large contiguous buffer for all the completion items.

Improved Auto Completion

We need to either improve GtkSourceView or implement an autocompletion engine in Builder directly. Primarily, we need support for additional columns in the result set. Beyond that, it would be nice if we had an alternate interface to provide completion results. The API for providing results is not ideal for lazily building result objects.

Move Vala out of Process

Much like the clang work item, we need to move Vala out of process. It has some leaks and can crash at inopportune moments. This has had the unfortunate side-effect of taking Builder down with it. See the clang work item for details on what is required.

Add Desktop Simulator

We would like to provide a way for applications to be run within a simulator. We can possibly re-use components from GNOME Continuous to build an operating system image suitable for KVM or Qemu. Owen Taylor has been working on a tool called “gdev” that could be of use here.

We need plumbing to install the application within the simulator and keep it updated. Additionally, we will want a channel to be able to connect a debugger or profiler. It might be possible to reuse the “adb” patches that Bastien put together.

Warning emblem on Project Tree files

If a file within the “Project Tree” is known to have compiler warnings (which we can discover from the IdeBufferManager) then we should overlay the “dialog-warning-symbolic” icon into the IdeTreeNode. This can be done with the “Project Tree” IdeTreeBuilder implementation to call “ide_tree_node_add_emblem()” when appropriate. Some monitoring of changes to IdeBuffer will be required to toggle the emblem visibility.

Add More Visualizers to Sysprof

This requires adding new data sources for network and memory to Sysprof along with a simple line visualizer for them (See the CPU visualizer for examples). Adding a visualizer for Gtk+ frame clock information would be very useful.

Git Perspective

A “perspective” in Builder is like a workspace. It is everything below the header bar, and we have a couple of them today. They include the editor, preferences, build preferences, and profiler. We would like an additional “Git” perspective that can be used to manage various source control aspects. You might use this to stage files for commit. You might use it to browse your projects history including searching for a previous commit to inspect it.

We want this project to reuse as much as possible from the Gitg project including the use of libgit2-glib and UI components from Gitg. The code belongs in the “plugins/git/” directory.

You’ll need to create an “IdeWorkbenchAddin” plugin to register your new perspective, which should be a “GtkWidget” that implements “IdePerspective”. We can help you get the mechanics of this started so that you can focus on the git work.

Bugzilla Integration

Many GNOME projects use Bugzilla. We have so much history there that moving away from Bugzilla does not seem like it’s in our near future. So we should make the process of working with Bugzilla as easy as we can for GNOME contributors.

We would like a “Bugs” perspective in Builder that integrates with Bugzilla and can provide fast access to bugs for a project. It should be possible to reply to a bug, mark it complete, and change various statuses of a bug (such as component, milestone, etc).

We might want to also implement an “alarm clock” with the Bugzilla integration. This would allow a developer to have an alert to remind them to come back and check-in on a particular bug.

It would also be nice if this perspective could have a button to “implement a fix” for a bug which would create a new branch and leave the programmer at the editor. We might also want integration to be able to do things like take the changes in the editor and push them to the bug (after performing a commit on the branch). Perhaps it even makes sense allow uploading a stack trace from a crash once we have landed the debugger. The possibilities are endless!

Modernize Auto-Completion Window

Currently the completion window only supports a single column of text. This is unsatisfactory for the way we'd like to present data. We want the "typed text" column of all results to match up (and be directly under the typed text in the editor). We also want to avoid scanning the data sizing text because that is 1) slow and 2) unnecessary. We can just resize the window from our anchor position in both directions as new items come into view that are larger/shorter.

We also want to avoid the GList API as we currently go through great pains to make that API fast.

We probably want to use GListModel so that we can create the object instances on demand as they are paged into view.