[Builder] Builder BoF Notes from GUADEC



Hi everyone!

I just wanted to sum up some of our discussions from the Builder BoF.
Obviously, with all the major changes we've landed this cycle, there is
plenty of bugs to fix and triage. My fault, of course :)

== Debugger ==

I'm going to get back to the debugger when returning from GUADEC as my
primary focus. That means that I'll be needing others to help triage and
fix papercuts up to our 3.26 release. I need to find my bearings again
based on the current state, but we should get moving quickly. I think
the primary things are:

 * Finish mi2-glib for communication with gdb
 * Implement a number of panels that track state from the debugger
   (stacks, registers, variables, etc)
 * Figure out how many features we want to use from the source editor
   for the read-only debugger view.
 * Write a new GtkSourceGutterRenderer that combines our various gutters
   into something that takes less space.
 * Add a new interface for "Hover Providers" so that we can display
   variable status when you hover in the source view.

I think we can land a majority of this before 3.26, but time will tell.

== Shortcuts ==

The new shortcut engine has landed, but there are a number of things
that need to be done to complete the process and modernize Builder. That
includes:

 * Porting widgets to use the DzlShortcutController (and
   _add_command_action(), etc)
 * Porting the shortcuts window to use DzlShortcutsWindow (which knows
   how to read shortcut themes to display the right shortcut chord
   (Ctrl+x, etc).
 * Add and test the shortcut editor in preferences
 * Stretch goal: allow the user to define new shortcut themes

I think we could live with things how they are for 3.26, but it would be
nice for at least a few things here to land before.


== Project Management Features ==

We very much need to land project management features for our users as
soon as it's feasible. The primary plumbing that needs to be implemented
for this is some sort of project management interface and abstraction
over build system items (library, program, unit test, resources, etc).

Using those abstractions, we need an interface that build systems can
implement to modify their underlying project files.

I think this is something we should push forward for 3.28 in whatever
capacity is reasonable.


== Unit Testing ==

We can probably land basic unit testing in Builder before the full
project management features. To do this we need some of the following:

 * An IdeTestSuiteProvider is probably needed so that we don't have the
   unit tests coupled to the build system directly. Some build systems
   may know about the test runners, others may not. I imagine this
   situation is more common with dynamic languages like Python or JS.
 * An IdeTestSuite, which can provide a list of IdeTestCase and a way to
   run the test.
 * A new TestPanel widget which can be registered in the
   IdeEditorSidebar.
 * Some mechanism to integrate with IdeRunManager/IdeRunHandler so that
   the tests are run in the "runtime" environment choosen for the
   project.


== Templates ==

We need to land the Meson templates for 3.26. This should include our
fixups to use GtkApplication and GtkApplicationWindow subclasses.


== Gitlab Integration ==

I don't think we are fully sure what this means to us yet, but it might
include any of the following:

 * Credentials stored so we can integrate with push/pull/etc in the
   future.
 * Allow listing available projects (both personal and organizations) in
   the greeater.


== Newcomer ==

We simplify the newcomer experience by having a list of common newcomer
projects so the user can simply click on it to clone and then build/run.

 * This needs a mockup, which Bastian has agreed to create for us.
 * Garrett and Bastian to come up with a design for newcomers apps on
   greeter


== Standard Header Plugin ==

We need a "standard header plugin" that allows inserting headers into
new files automatically.

Technically speaking, I don't have a great plan of action for someone to
implement this (because it's tricky with how the buffer manager creates
new files), but we might be able to introduce the feature at a layer
like the "new-document" action provided in the editor perspective.

You might want a header provider plugin, but that is likely overkill
over just hardcoding the headers we know about (along with user
overrides). It should be able to reuse the existing comment support in
GtkSourceView like block-comment-start, line-comment-start, etc.


== Snippets ==

 * We still very much need a snippet editor. It might be simple enough
   to just create a copy of the internal plugins in a text file and
   allow the user to edit that. It would be nice if we could provide the
   user a guide of available variable names in the snippet syntax.

 * We have this super annoying bug when editing snippets that can cause
   the snippet engine to lose it's positioning. It is likely due to how
   we track changes while interactively editing the snippet. This code is
   incredibly complex thanks to GtkTextBuffer.

 * We need some documentation on how to add/edit snippets manually. We
   can place them in ~/.config/gnome-builder/snippets/.


== Completion Result Sorting ==

We would like to improve our sorting for completion results so the user
sees the most valid results first. This takes some tweaking to our
IdeCompletionResults helper based on the result type. Usually it is
doing fuzzy sorting, but we should be able to make it do more.

The main thing we get out of IdeCompletionResults is that it helps us
make using the GList interface provided by GtkSourceCompletion fast. It
also helps us replay previous results as the user continues typing
instead of slamming the compiler backends with more work.


== Integrate Gitg ==

We want to integrate as much of the Gitg interface as we can (within
reason) into Builder. It may be difficult to share code directly due to
the design of both projects, but we should try to abstract things if
possible (and gitg is ammeniable to the changes) and then consume those
bits from Builder.

An easier project that someone can tackle is to add some level of
git-blame support to the gutter when users hover over the line number
(or possibly somewhere else, some design is required here).


== Allow running Builder from Builder ==

We want people developing Builder to be able to hack on Builder from
Builder. Many other projects will need the same features we do for this.
In a nutshell, we just need additional command line arguments or
environment variables to use when running the `gnome-builder` program.
(--standalone in our case).

This type of thing probably belongs in the IdeConfiguration. For
Flatpak, we can stash that information in a private JSON field such as
"x-devel-command" to the project, and then use that instead of
"command".


== Documentation Access ==

If we bundle Builder today via Flatpak (our preferred method)

 * Get documentation information from library.gnome.org
   - We have lots of missing documentation in our Flatpak builds
   - We need to show docs based on the project dependencies
   - Users should be able to browse to find new projects to
     depend on that solve their needs.

== Iconography ==

We need some icons for a few file types. Jakub is going to make some for us.


== Misc Bugs ==

 * There is a double-open buffer when you double-click an item in the
   project-tree. We need to update the buffer manager to prevent this
   race in the file-loading process.
 * Goto declaration is broken. This looks to be fallout from the UI
   revamp. Probably something stupid that I did.
 * Goto line is broken too for gedit mode.
 * GdkPixbuf project isn't working correctly, investigate.
 * Line gutter changes have broken during fallout from the updates.
 * We need gedit-mode shortcuts for goto-end-of-block,
   move-by-paragraph, etc.

== Search ==

 * Keep the previous search result to quickly get back to results when
refocusing
   the search entry. Also requires the clear search icon.

== History ==

We lost history support for forward/backward within the editor. We need
to bring
back jump tracking and back/foward list+controls.

== Meson ==

 * Meson needs hack to find the .c file instead of .h when looking up
   build flags (CFLAGS, etc).
 * Meson should check to see if there is a version mismatch and we
   should clear the old build cache/directory.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]