Ddev: Explore GUI options for DDEV-Local

[rfay]

Some people would definitely rather have a GUI to manipulate projects. A GUI can roll tasks into a more familiar and easier-to-remember set of tasks.

Many Go GUI options are listed in awesome-go, these are among them. @andrewfrench had experimented with https://github.com/marcusolsson/tui-go, but it's mostly abandonware now.

A GUI presentation of DDEV-Local has long been a goal, but to date it hasn 't been fully achieved. ddev-ui was built as an Electron app which used ddev list -j to get date. Although it hasn't been maintained for a year and a half, it still seems to mostly work with current ddev v1.13.1. But it has no tests and has nobody to take care of it. It's Electron and mostly React.

I've recently experimented with a couple of GUI options simply to explore maintainable GUI options.

Fyne cross-platform GUI

I experimented with Fyne and ddev in branch and was able to get a table of projects that looks like this:

The key code to get that going is in https://github.com/rfay/ddev/blob/eb69a7e07d9e925d2d73797fabba2a4f69ae277b/cmd/ddev/cmd/gui.go#L19-L99 and it's not tremendously difficult, although it requires jumping through some hoops.

Building with Fyne included

Building on macOS isn't very easy.

1. Obtain "develop" version of "fyne" tool as described in https://github.com/fyne-io/fyne/issues/157#issuecomment-597362440
2. fyne vendor
3. Buld with go install ./pkg/... ./cmd/... instead of make; the current build-tools won't build this successfully

Note that CGO_ENABLED=1 is required

Running the experimental branch

I just kept building and running with go install ./pkg/... ./cmd/... && ~/go/bin/ddev gui

Issues with Fyne

• Outputs complaints at startup on macOS
  When you start a Fyne app there are major deprecation warnings that are output to the screen. Issues suggest that this should be fixed in the next release of Fyne. OTOH the warnings are scary because they imply that Fyne might not work at all in a future version of macOS.

• Cross-compiling is work
  Basically you need fyne-cross for cross-compiling. Full details are on https://fyne.io/develop/cross-compiling.html, but I imagine there's much to learn yet. But the maintainer definitely insists in https://github.com/fyne-io/fyne/issues/741 that it's possible to build for most platforms on macOS or Linux.

• Populating the vendor directory is nonstandard (you need to use fyne vendor as above.)

• Building the application is nonstandard (see above)

• Obviously depending on Fyne would make our GUI completely dependent on the maintenance of that one project. It seems to be very active, but the contribution graph shows that the phenomenally responsive @andydotxyz is the author of nearly everything. Note that @andydotxyz also "wrote the book" on Go GUI development, https://www.packtpub.com/gb/application-development/hands-gui-application-development-go

Path Forward for Fyne

I think we could build a modest GUI using Fyne. It requires some design and significantly more experimentation.

• My next step would have been to add a start/stop button to each row, and I think that would have been easy.
• Adding an "action" pane that would activate when a particular project was selected would be pretty easy, providing buttons for key actions.
• Testing on all platforms Win/Linux/Mac is critical before we get too far.

tview Terminal UI

I experimented with tview in https://github.com/rfay/ddev/tree/20200205_tview_experiments and didn't get a long ways, but it does seem to be an approach with promise, although a text-based gui is certainly not what a lot of GUI lovers will be looking for.

The modest code I experiemented with is in https://github.com/rfay/ddev/blob/a5cab84cb1af95189d1137dcaac2a19d8f9faff5/cmd/ddev/cmd/list.go#L78-L111 and created a ddev list --gui flag.

This version runs with ddev list --gui. You can use the up and down arrows to explore the various projects. I didn't get to where I could add a pane to show details and actions.

tview is a recommended technique referenced by the the sort-of-abandoned https://github.com/marcusolsson/tui-go

Path Forward for Tview

I'd have to understand tview quite a bit better to make any progress with it. But it does have promise.

tview has 24 contributors, but again, mostly @rivo making it work.

[andydotxyz]

I just wanted to add to the Fyne evaluation - the scary deprecation warnings on macOS have been resolved and can be tested on our develop branch. The fixes will roll out in v1.3 expected early May https://fyne.openplan.app/plan/

[rfay]

Thanks @andydotxyz - you're awesome.

[markhalliwell]

I'd be willing to work on https://github.com/drud/ddev-ui

I've been thinking about building an electron app for a while now (although with Vue instead of React).

The more and more I've been working on getting a remote ddev server up and running, the more I realize it would be nice to have a GUI to handle some automation of common tasks.

[rfay]

Wow, what an amazing offer, and by an amazing developer.

First, let me try to dangle the idea of working together on a prototype using Fyne in front of you, then I"ll explain the issues with ddev-ui (which still worked the last time I tried it).

Fyne is a golang toolkit, which means that we can feed it data which is known internally to the ddev binary. It seemed to be to be pretty straightforward, I think you'd think of it in GUI terms and be right on your way. I'm very GUI-challenged, and threatened by visual design, so didn't go a tremendous way farther than initial exploration, but I was able to get things working.

There are a number of problems with ddev-ui:

• It relies on just running ddev list -j repeatedly, which is a big performance hit, and also provide it pretty limited information.
• It's written in a different language (obviously) which means the long-term maintenance of it is far less likely to be successful.
• Currently it has no tests at all.

Mostly I'd worry that it would get fixed up, but then nobody would be able to wrap their heads around the maintenance for the long term.

But if we could try out a prototype with the go-based Fyne I suspect there would be a future there. Interested?

[markhalliwell]

Honestly, I'm not very golang savvy. I know it exists, but that's pretty much the extent of my knowledge on it.

Let me counter with the main problems you mentioned:

• It relies on just running ddev list -j repeatedly, which is a big performance hit, and also provide it pretty limited information.

This could easily be optimized by creating a dedicated ddev "API daemon" that listens on a socket/port. Decoupling this data from the main cli command would likely have it's own performance boost as well if it isn't constantly having to initialize said data each cli command boot.

• It's written in a different language (obviously) which means the long-term maintenance of it is far less likely to be successful.

I would argue that more people know JS than golang, which means you'd probably have a better chance of finding more people to help maintain it; just have to ask 😄(that's how I'm here)

Never mind the extensive package library that npm provides, creating web-based GUIs is kind of in the wheelhouse of Node.js.

Electron (et. tools) allows for easier deployment across the three major OS's too . I'm also an apple dev, so code signing isn't really an issue there either.

• Currently it has no tests at all.

That can and should change.

Mostly I'd worry that it would get fixed up, but then nobody would be able to wrap their heads around the maintenance for the long term.

That just boils down to creating and maintaining decent and easy to understand documentation. From quick fixes, heavy feature development to deployment workflows; automating tasks as much as possible along the way as well.

[markhalliwell]

I should also mention that the first point would also tremendously help with building/maintaining remote ddev servers much easier.

[rfay]

I don't dispute that react/electron is a fine place to develop a gui. I'm just wondering how many years you can commit to maintaining it. I don't have any extra bandwidth; I considered learning react to maintain that, but decided my mind would blow up trying to keep too many things sharp.

On the other hand, I'd be happy to work with you to handle the Go problems and get you going in a workable smaller area. It's not that bad if you have an enclosed playground.

If you just look at https://github.com/rfay/ddev/blob/a5cab84cb1af95189d1137dcaac2a19d8f9faff5/cmd/ddev/cmd/list.go#L78-L111 - that's the kind of thing we're talking about. I'm pretty sure that your visual design experience could overcome the lack of go knowledge. And I'm talking collaborative. And the maintainer of Fyne is amazingly helpful.

[markhalliwell]

I'm just wondering how many years you can commit to maintaining it.

Probably for many years to come. This is the first "automated local dev" tool that I have found that actually.... "just works™". I'm very invested in making it better and easier for large scale development (including remote servers). I see myself using this for a very long time.

I considered learning react to maintain that, but decided my mind would blow up trying to keep too many things sharp.

IMO, Vue.js is much easier to learn/maintain. A lot of it is just properly structuring the application.

On the other hand, I'd be happy to work with you to handle the Go problems and get you going in a workable smaller area. It's not that bad if you have an enclosed playground.

Awesome. I'll have to start diggin into it.

I'm pretty sure that your visual design experience could overcome the lack of go knowledge.

Actually, it's kind of a big step for me. It's not a syntax I'm very familiar with. Not saying I can't learn it, but knowing how long it took me to become fairly proficient with PHP because of Drupal... it would be far easier and faster for me to just build something using JS.

[markhalliwell]

I'd also like to say that they're nothing wrong with pursing both. Perhaps the go version can be a little more compact/simplified gui for power users?

[rfay]

I agree that it would be feasible to pursue both. Just scattering the energy is what concerns me.

[andydotxyz]

The fixes will roll out in v1.3 expected early May

It was delayed by a few weeks, but is out now. I hope it helps.

[rfay]

Thanks so much @andydotxyz