-
-
Notifications
You must be signed in to change notification settings - Fork 592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore GUI and TUI options for DDEV #2110
Comments
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/ |
Thanks @andydotxyz - you're awesome. |
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. |
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:
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? |
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:
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.
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.
That can and should change.
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. |
I should also mention that the first point would also tremendously help with building/maintaining remote ddev servers much easier. |
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. |
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.
IMO, Vue.js is much easier to learn/maintain. A lot of it is just properly structuring the application.
Awesome. I'll have to start diggin into it.
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. |
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? |
I agree that it would be feasible to pursue both. Just scattering the energy is what concerns me. |
It was delayed by a few weeks, but is out now. I hope it helps. |
Thanks so much @andydotxyz |
Have we considered leveraging something like Portainer? We could just add a container to the default stack/recipe to try this out |
Well, portainer can certainly show the running containers, but how could it show how a ddev application is working or change its state, etc.? |
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! |
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]) |
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 |
I saw a recommendation for https://tauri.studio/ as a performant alternative to Electron. |
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 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. |
Hi @iammati - I went to try out your ddev-ui and found it dependent on a custom command that you don't document, 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. |
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. |
@rfay just renamed to to "ddev-userinterface-vue", hope its kinda more obvious now The I'll perform a fresh git clone tomorrow and see if I should run into issues. |
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! |
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 |
It's awesome. You can edit it as we go, and people can comment there if necessary. |
You may add it into the main post of this issue, would avoid to lose this gist in case people comments in future |
@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. |
@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. ? |
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.. |
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... |
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. |
I think IDE extensions for PHPStorm / VScode would cover more users and should be a priority over a standalone GUI project. @gilbertsoft I'd be interested in testing a VSCode extention, if you need it |
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. :) |
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! |
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. |
@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? |
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. |
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) |
No rush, do it when you can, and mention here. |
@rfay I've updated the README, repository clone should be quite easily done :) |
In case it helps the following items noted above have been resolved in Fyne:
(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. |
Note Bubbletea as well for a TUI, https://github.com/charmbracelet/bubbletea |
Inspiring podcast with the folks from charm, makers of bubbletea, https://changelog.com/podcast/481 - loads of potential there for all areas of ddev. |
An important note for PhpStorm users: The ddev-intellij-plugin provides lots of help for folks that are used to a more GUI approach. |
Wails: https://wails.io/blog/wails-v2-released/
|
1 similar comment
Wails: https://wails.io/blog/wails-v2-released/
|
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 In another world we may well try a GUI, but TUI first. |
For whatever it is worth, I'll probably take a stab at some point to make a webapp UI in Go. It would avoid most of the problems that have been talked about here with regards to desktop apps, electron etc...
Would be far easier to build and maintain than anything with nodejs, react etc... And would have the possibility of being integrated into DDEV at some point, since it would be written in Go. I'll follow up here if I ever do anything with this. It'll definitely be ugly, but functional |
A new option has been announced, Cogentcore, https://www.cogentcore.org/blog/initial-release
|
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.
fyne vendor
go install ./pkg/... ./cmd/...
instead of make; the current build-tools won't build this successfullyNote 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.
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.
The text was updated successfully, but these errors were encountered: