Thread overview
D support for GNOME Builder
Jan 11
. .
January 11
Something was posted on the forums a few years back about the GNOME Builder IDE (https://wiki.gnome.org/Apps/Builder), and some people were talking about adding D support. Nothing really happened with it, but I am wondering if anyone has thoughts about it?

Seeing D supported in GNOME Builder would be nice, because aside from D, Builder is a great general-purpose IDE for linux, much like XCode is to MacOS.
January 11
On Fri, 2019-01-11 at 03:08 +0000, . . via Digitalmars-d wrote:
> Something was posted on the forums a few years back about the GNOME Builder IDE (https://wiki.gnome.org/Apps/Builder), and some people were talking about adding D support. Nothing really happened with it, but I am wondering if anyone has thoughts about it?
> 
> Seeing D supported in GNOME Builder would be nice, because aside from D, Builder is a great general-purpose IDE for linux, much like XCode is to MacOS.

I have not tried GNOME Builder even though I spend much time writing GKT+ desktop programs. Anjuta was such a disappointment and annoyance that I plumped for CLion and haven't tracked GNOME-oriented IDEs since.

As I understand it from the documentation, GNOME Builder plugins can be written in C, Vala, or Python3. Though I think there might be a way of using Rust via C linkage. This means there would be a possibility of using D to write plugins especially as the critical resource is libpeas and GtkD has a binding.

Clearly having D support in any and all editors and IDEs is a Good Thing™ but I believe getting good D support into CLion will get more traction and benefit for cost for D. Its all about whether CLion (and IntelliJ IDEA) has more users likely to try D than GNOME Builder. C remains the main language around GNOME, though clearly Vala should have the market share. However Rust is on the rise in the GTK and GNOME milieu.

I am going to try and get stuck in to helping Samael et al. make IntelliJ-
DLanguage and IntelliJ-Dub work well with CLion (and IntelliJ IDEA). But if
there is an effort on GNOME Builder to get some D in and it doesn't detract
from the CLion effort, I'm up for it. Especially if the language of
implementation is Python3, Rust, or D.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



January 11
On Fri, 11 Jan 2019 03:08:32 +0000, . . wrote:
> Something was posted on the forums a few years back about the GNOME Builder IDE (https://wiki.gnome.org/Apps/Builder), and some people were talking about adding D support. Nothing really happened with it, but I am wondering if anyone has thoughts about it?
> 
> Seeing D supported in GNOME Builder would be nice, because aside from D, Builder is a great general-purpose IDE for linux, much like XCode is to MacOS.

I was only vaguely aware that GNOME Builder existed and decided to check it out. It's a bit rough around the edges, and it succumbs to the unfortunate modern GNOME habit of having tiny inscrutable icons instead of a menu bar. But I kind of like it, at least in theory, so I decided to have a look.

GNOME Builder supports the Language Server Protocol. Or rather, the nightly builds support it. The nightly builds also depend on bleeding edge GNOME libraries, which means flatpak (kind of bleh). Plugins seem to be written in Python (which is convenient because I'm not particularly able to crack open a flatpak to compile a C or Vala plugin inside).

From that point, it was a matter of copying and modifying the Go LSP plugin.

This leaves a few issues:
* The completion window is five characters wide. Even if DCD integration
were working as expected and DCD were producing the best results ever,
this would be useless.
* Braces and indentation are pretty poorly handled. They're handled right
in C, so it's just a matter of telling GNOME Builder to treat D like C in
this way.
* Either DCD is giving poor results, or GNOME Builder isn't properly
querying it, and I can't tell which.
* It's flatpak, so it doesn't integrate well with the rest of the system.
Most importantly, dcd-server (the version I'm using, at least) doesn't
automatically discover dmd.conf, and it might take some work to find it.
That might not even work if dmd is installed in an unexpected location in
the filesystem.
* The documentation required to get even this far is abysmal, where it
even exists.
January 11
On Friday, 11 January 2019 at 06:08:17 UTC, Neia Neutuladh wrote:
> I was only vaguely aware that GNOME Builder existed and decided to check it out. It's a bit rough around the edges, and it succumbs to the unfortunate modern GNOME habit of having tiny inscrutable icons instead of a menu bar. But I kind of like it, at least in theory, so I decided to have a look.
>
> GNOME Builder supports the Language Server Protocol. Or rather, the nightly builds support it. The nightly builds also depend on bleeding edge GNOME libraries, which means flatpak (kind of bleh). Plugins seem to be written in Python (which is convenient because I'm not particularly able to crack open a flatpak to compile a C or Vala plugin inside).

GNOME Builder's stable version supports the LSP too, not just the nightly builds. I have GNOME 3.30 on Fedora, and Builder supports both Rust and Go using it.

> From that point, it was a matter of copying and modifying the Go LSP plugin.
>
> This leaves a few issues:
> * The completion window is five characters wide. Even if DCD integration
> were working as expected and DCD were producing the best results ever,
> this would be useless.

I don't have this problem, the completion window on my system is as wide as the widest completion available. Sounds like a pretty annoying bug though.

> * Braces and indentation are pretty poorly handled. They're handled right
> in C, so it's just a matter of telling GNOME Builder to treat D like C in
> this way.
> * Either DCD is giving poor results, or GNOME Builder isn't properly
> querying it, and I can't tell which.
> * It's flatpak, so it doesn't integrate well with the rest of the system.
> Most importantly, dcd-server (the version I'm using, at least) doesn't
> automatically discover dmd.conf, and it might take some work to find it.
> That might not even work if dmd is installed in an unexpected location in
> the filesystem.

That should be fixable by having some plugin settings to handle it. If a Builder plugin were to use either DLS or Serve-d, I reckon adding Builder settings corresponding to the language server's settings would be something to do anyway, and both have a setting for this.

> * The documentation required to get even this far is abysmal, where it
> even exists.

Challenge accepted