Explore GUI and TUI options for DDEV

[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 Add table widget fyne-io/fyne#157 (comment)
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 Possible to cross-compile macOS version on Linux?  fyne-io/fyne#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

[marklabrecque]

Have we considered leveraging something like Portainer? We could just add a container to the default stack/recipe to try this out

[rfay]

Well, portainer can certainly show the running containers, but how could it show how a ddev application is working or change its state, etc.?

[marklabrecque]

Fair point! I guess I was thinking it would be similar to Docker Desktop for Windows/Mac, but I see what you mean, the DDEV stack is a bit more specialized and opinionated and we wouldn't be able to interact with the DDEV CLI that way. I see now why this wasn't suggested sooner!

[mandrasch]

Just a side note, I just tried a few Electron tutorials in the past: To my suprise the final step of actually building the cross platform version for all processor types was quite hard, you have to choose between electron-forge, electron-builder, etc. I ended up using a GitHub Action pipeline. Here is a list of alternatives I found: https://github.com/sudhakar3697/electron-alternatives

(Personally I would love Svelte(Kit) for the frontend in the suggestions because of its clean syntax and because I'm a fanboy, but I have no evidence yet that this would allow a better maintenance for a desktop GUI ;-) [Disclaimer: Svelte is stable, SvelteKit not yet])

[rfay]

A simple electron wrapper existed for some time, and may even still work, https://github.com/drud/ddev-ui - I was never satisfied with it because of lack of test coverage (none) and the fact that it had to run ddev list --json --continuous all the time.

[shaal]

I saw a recommendation for https://tauri.studio/ as a performant alternative to Electron.

[iammati]

Hey there, I've took myself the time exploring a few go-native only solutions for ddev-ui and also a web-based solution.

The web-based solution is testable here https://github.com/iammati/ddev-ui
It runs on Vue btw.

I've written down a 5-site long word-document you guys may take a moment to read through it - basically it's about all golang alternatives there are out and what the only major issue is all about: golang's limitation and the UX the end-user has using the UI. Also compares with pro and cons between a web-based solution (still as a executable binary) and a go-native only solution.

Thanks.

ddev-ui options.docx

[rfay]

Hi @iammati - I went to try out your ddev-ui and found it dependent on a custom command that you don't document, ddev pnpm. Can you either provide or describe that please?

Also, would you mind giving the project a different name than "ddev-ui", since I had assumed it was a fork of drud/ddev-ui, so could cause confusion for others as well.

[rfay]

A note on your attached word doc - It's far better to provide (great) information like what you have here in an online format, perhaps as a gist on gist.github.com, or even inline in this issue. It would be far better inline than in a downloadable word doc. You have to remember that people don't even necessarily have the ability to open a word doc (mine is sketchy) and attaching a separate doc makes it hard to comment and easy to skip over. Looks like great work though.

Note that fyne has been actively maintained and the author actually wrote a book about it.

[iammati]

@rfay just renamed to to "ddev-userinterface-vue", hope its kinda more obvious now

The ddev pnpm custom command is also added inside the repository here https://github.com/iammati/ddev-userinterface-vue/blob/main/.ddev/commands/host/pnpm
You may SSH into the web-container and check if pnpm is installed at all (which should also happen automatically by the provided Dockerfile you can check here https://github.com/iammati/ddev-userinterface-vue/blob/main/.ddev/web-build/Dockerfile)

I'll perform a fresh git clone tomorrow and see if I should run into issues.
Also will try to move the word document into a gist. BTW is a PDF actually also fine? Should be quite a standard - at least I hope so - now :)

[rfay]

PDF makes it hard for people to comment and for you to edit, but better than Word. Mostly people work together with markdown and related things unless there is a problem with the formats being too graphic intense or something. In your case, what you have to say would work fine in markdown.

I didn't realize that your project was a complete ddev project, maybe you can add a little more to the readme explaining how to get started.

Thanks!

[iammati]

I hope this is better now: https://gist.github.com/iammati/481c7b38fe474a9af953b141a8e703ec :)

FYI: will edit the README of the custom ddev-userinterface-repo of mine tomorrow and update this as soon as it's done

[rfay]

It's awesome. You can edit it as we go, and people can comment there if necessary.

[iammati]

You may add it into the main post of this issue, would avoid to lose this gist in case people comments in future

[rfay]

@iammati are you a fan of vscode or PhpStorm? One of the important possibilities is to do great plugins for key IDEs, which may be a simpler thing for lots of people than a GUI. This isn't either/or, but it's an important idea.

[iammati]

@rfay i'm a vscode user, never liked PhpStorm at all IMHO..

What do you mean by great plugins for key IDEs specifically? An integrated extension/plugin for IDEs (next to the GUI stuff going on here) which shows like the Docker Container extension for vscode running ddev-projects and perform actions within that etc. ?

[rfay]

I mean that some kind of ddev extension may be the best gui approach for a lot of users. @nico-loeber is working on one for phpstorm. @gilbertsoft has discussed and started one for vscode..

[iammati]

How about users who neither use both? AFAIK the purpose of a GUI for ddev was for those, who are not that much familiar with ddev itself. Not sure how a plugin/extension inside an IDE would solve this specific issue - especially for those, who neither use PhpStorm nor vscode

EDIT: Pretty sure both doing a great job for that and I do not want them to stop at all! I hope we can find a solution which covers all, personally an extension would more or less (depending on its functionality obviously and complexity) cover primarily developers who use ddev on a daily base, I guess...

[rfay]

Like I said, it's not actually either-or, but rather just thinking about the big picture about how to provide a good experience to the most users.

[tyler36]

I think IDE extensions for PHPStorm / VScode would cover more users and should be a priority over a standalone GUI project.
After a project is setup, I find I'm only using ddev start & ddev stop.

@gilbertsoft I'd be interested in testing a VSCode extention, if you need it

[iammati]

Frankly I don't see real usage in that since, IMHO, we really need some sort of polls to know what people actually want — don't get me wrong maybe people would in fact even prefer a plug-in in their IDE way more than a GUI. I can only guess what their real use-case is, at which point a GUI would make sense and when they'd likely use a provided plugin for their IDE...

@rfay how about a poll, as you already mentioned not an either-or decision, but to know what the daily ddev user really needs. :)

[rfay]

People are weird and will always want what they want :) It's more about what the community can support. And if there are maintainers out there who will support things (as they do many places) then it works out OK.

Feel free to post a poll in Discord!

[rfay]

Back from the road trip, looking forward to giving this some attention. Sorry that the focus on v1.19 may still distract me this week.

[iammati]

@rfay glad you're back! 🙂

How should we continue here? Was about to text you about the poll if you would be able to make one on the Discord server which would look more "official" + you/the admins could also ping @everyone 😅

Not sure how much integration of functionality is required at all in a GUI or what a non-ddev-expert would expect, that's why I'd recommend for some sort of poll so we can see what people really need/wish to see, right?

[rfay]

Well, I want to give your https://github.com/iammati/ddev-userinterface-vue a quick run-through. Other ideas will need to wait until v1.19 is done for further progress.

[iammati]

Ohh crap I completely forgot to update the readme... are you stuck at some specific point? Guess I'll be able to update it over the weekend or maybe before the weekend (around friday noon/eve CET)

[rfay]

No rush, do it when you can, and mention here.

[iammati]

@rfay I've updated the README, repository clone should be quite easily done :)
https://github.com/iammati/ddev-userinterface-vue

[andydotxyz]

In case it helps the following items noted above have been resolved in Fyne:

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

Building the application is nonstandard (see above)

(It was due to an issue of packaging in the GLFW dep and the fixes were accepted upstream)

Also, in case the maintainer status is something that worries you, we now have 8 core maintainers, 100 contributions and a company that exists to secure the future of the Fyne toolkit :) https://fynelabs.com.

[rfay]

Note Bubbletea as well for a TUI, https://github.com/charmbracelet/bubbletea

[rfay]

Inspiring podcast with the folks from charm, makers of bubbletea, https://changelog.com/podcast/481 - loads of potential there for all areas of ddev.

[rfay]

An important note for PhpStorm users: The ddev-intellij-plugin provides lots of help for folks that are used to a more GUI approach.

[rfay]

Wails: https://wails.io/blog/wails-v2-released/

If you are unfamiliar with Wails, it is a project that enables Go programmers to provide rich frontends for their Go programs using familiar web technologies. It's a lightweight, Go alternative to Electron. Much more information can be found on the official site.

[rfay]

Wails: https://wails.io/blog/wails-v2-released/

If you are unfamiliar with Wails, it is a project that enables Go programmers to provide rich frontends for their Go programs using familiar web technologies. It's a lightweight, Go alternative to Electron. Much more information can be found on the official site.

[rfay]

Great interview with the maintainers of wails and fyne in Gotime podcast:

https://changelog.com/gotime/271

[rfay]

Let's do a TUI with Bubbletea. A GUI is too big a reach for our current situation, but lots of Golang apps are very happily using Bubbletea.

Closing in favor of

• Rework DDEV UI as a TUI using Bubbletea #5762

In another world we may well try a GUI, but TUI first.