Here is a list of things I'd like to see land in 3.26. Start attacking features that you find interesting and can follow through on for 3.26.
- Debugger API and implementation for gdb - Christian will lead this effort and work is starting soon if not already by time you read this.
- Profiler improvements in Sysprof for simple memory profiling and Gjs support.
- Configure program arguments when running application (Builder needs --standalone for example)
- Unit testing integration (possible outreachy/gsoc project)
- Documentation cards (possible outreachy/gsoc project)
- Switch to Meson build system
- Switch templates to be Meson-based
- 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
Time Dependent Projects
- Integrate new shortcuts engine (wip/chergert/shortcuts branch)
- Git integration (using as much of Gitg as possible)
- Other 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.
Add debug easter egg to Builder
Builder has lots of statistics that we track in special counters. It would be nice to have an "easter egg" to display all these internal counters, similar to how Chromium and Firefox have memory debug views. This could use an GAction to activate so it is only activatable via the Builder command-bar.
Improved Word Completion
Currently, Builder relies on “Word Completion” from GtkSourceView. This provides completion of words used within the current, or other open, documents. We would like to see a new Word Completion provider that can take into account the distance of the word from the cursor position so that words near the cursor are in predictable locations.
Ideally, this would look similar to Vim’s implementation of Word Completion. Control+P (in Vim mode) would take us to the closest match above the current word. Control+N would take us to the closest match after the cursor.
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.
Create new IdeBuildTargetType enumeration to libide that contains types such as “program”, “test-suite”, “library”, “resource”, etc.
Add IdeBuildTarget:target-type property
Create a new “test-suite” plugin containing an IdeWorkbenchAddin that can add a new panel to the editor perspective
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.
- Allow viewing the logs for failed unit tests.
- Add a keybinding to execute a “run unit tests” action.
Create a “Code Search Index”
We would like a robust code search for Builder that will require indexing various parts of source code repositories. One way to do this, would be to extract information from the ASTs used by various languages. For example, we can use the Clang AST to extract information for C and C++ projects.
This will necessarily need to create a database that can be searched when performing “Global Search” in the Builder workbench. We should be able to jump to symbols in any file, classes, and other symbols quickly and predictably.
Add Debugger Perspective
Note: Some work is in progress on this item in the wip/chergert/debugger branch.
AlbertoFanjul works on this too.
We need a debugger for Builder. We should add a new “Debugger Perspective” that contains the various debugger panels as well as source views for navigating code during debugging. The views in the debugger perspective will be read-only because they represent the code that is compiled and being executed. Ideally, this plugin will reuse as much code as possible from Nemiver. The Nemiver project is not built to be used as a library, so some amount of embedding will be required. The first step is likely a lot of build system integration. The editor perspective should also be updated to allow toggling breakpoints.
We would like the ability to have “Documentation Cards” that can be displayed in the editor. Think of them as something similar to a twitter or facebook card when you hover over a persons name. They should include some basic information like the name, parameters, documentation, and links to more information. This should fit nicely into a GtkPopover so we can display it as necessary.
This will likely require adding some new interfaces to libide such as an “IdeDocsAddin”. We need a way to allow different documentation backends to provide documentation to Builder. Some might come from *.gir files, readthedocs, devhelp, valadoc, or other external systems.
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.
Builder lacks much formal documentation. This is a travesty. We would like someone to work on a Getting Started Guide for Builder as well as covering the main feature documentation. Long term, we would like this to be a place where users can find tutorials integrated with Builder.
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.
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).
Fullscreen “Distraction-Free” Mode
We would like a fullscreen mode that allows users to focus on code rather than IDE chrome. This would probably look similar to the fullscreen mode in Gedit.
Managing custom shortcuts in a program the size of Builder is a difficult task. Gtk has a few different methods to manage shortcuts and all of them are slightly incomplete in what we need. That means Builder manages shortcuts multiple ways.
Furthermore, we would like shortcuts to be configurable to users with a set of “predefined” starting points. We need a new “IdeShortcutManager” that can manage these all for us and load the right external CSS shortcuts as necessary. Currently, some shortcuts are implemented with CSS, some as application-to-action bindings.
In addition to pre-defined shortcut sets (like Visual Studio, Xamarin, and Eclipse) the user can create their own which might derive from one of these.
Some keybindings will not be configurable, such as the Vim support for IdeSourceView. They will be either “on” or “off” based on the configured shortcuts.
The keyboard preferences panel will need to be updated to support these configurable keybindings. Additionally, plugins need a simple way to register their keybindings so they are loaded/unloaded as necessary.
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:
- Ensure we support the kernel indentation format well (8-space hard tabs, with various indentation rules)
- Add a “kernel module” template that allows building an out-of-tree module.
- Build system hooks that can build against an installed kernel
- Allow choosing which kernel to compile against in the Build Preferences based on available kernel-headers/kernel-devel packages.
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.
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.
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.
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.
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.
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.
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!
Builder does not currently have a way to view the output from running the application. We need an “Output” panel that controls stdin/stdout/stderr of the executed application. This should probably be provided as part of the “terminal” plugin if possible, since it already manages integration with Vte.
The libgspell library supports spellchecking GtkSourceView widgets. It should be fairly simple to wire this up and show spellchecking issues within the editor. There may be some additional work to go through and update misspelled words, but showing them with underline squiggles should be quick. A complete spellchecker sidebar has been done too
Sysprof Profiling of Flatpak Apps
If we are building/running in Flatpak, we would like to be able to profile things. This is going to require one more piece in builder/sysprof to determine the proper binary path. Right now they say things like "/newroot/some/path", and we need to look at pid+filename to translate the path so that sysprof can get the proper inode/.debug file link. Then we can use our symbol dirs to find the linked debug version of the .so.
Flatpack SDK Synchronization
Keeping developers SDK up to date is important so that we can ensure developers are testing their applications against stable code. Additionally, it can provide a way for developers to test against GNOME nightly (or other SDKs) before GNOME releases have shipped.
Other communities also have SDKs, such as Endless and maybe someday automotive Linux. Having a good story for working with and keeping SDKs up to date from Builder will be a nice addition. We have a “Transfers” API in Builder that will provide the ability for the user to track progress.
This project should include new UI somewhere in Builder’s preferences to update an SDK. It should use the “Transfers” API for progress.