GUI for VVV

[JJJ]

From: https://github.com/Varying-Vagrant-Vagrants/VVV/issues/346#issuecomment-43954276

Only to break up with MAMP

Breaking up is hard to do:

• MAMP is a turn-key sandboxed application for dead-simple local development
• VVV has no UI and requires continual maintenance and dependency juggling.

We all like to make fun, but we should stop marketing VVV as a MAMP replacement until it's equally as easy to use and equally reliable.

As much as we all love a good old fashioned command line interface, an OS X app for VVV similar to https://www.cakebrew.com for Homebrew would go a long way towards introducing VVV to the masses.

[zamoose]

No love for Puphpet?

https://puphpet.com/

On Fri, May 23, 2014 at 12:28 PM, John James Jacoby < [email protected]> wrote:

From: #346 (comment)https://github.com/Varying-Vagrant-Vagrants/VVV/issues/346#issuecomment-43954276

Only to break up with MAMP

Breaking up is hard to do:

• MAMP is a turn-key sandboxed application for dead-simple local development
• VVV has no UI and requires continual maintenance and dependency juggling.

We all like to make fun, but we should stop marketing VVV as MAMP replacement until it's equally as easy to use and equally reliable.

As much as we all love a good old fashioned command line interface, an OS X app for VVV similar to https://www.cakebrew.com for Homebrew would go a long way towards introducing VVV to the masses.

Reply to this email directly or view it on GitHubhttps://github.com/Varying-Vagrant-Vagrants/VVV/issues/369 .

-Doug

[JJJ]

Puphpet is incredibly excellent, but isn't specific to VVV.

[jeremyfelt]

This would be a wonderful improvement.

• What does it take to build a GUI? Is it tough to do cross-platform (Is Adobe Air still a thing) or would it be better to focus on individual OSes?
• Apps can easily be broken into new repositories for maintenance
• What specific parts of VVV would we want to manage beyond vagrants up, halt, suspend, destroy? Virtualbox provides a decent example of what a machine status GUI could start as.
• And/or... what's MVP here?

[vlkz]

WebKit would work fine for cross-platform apps. It pretty much let's you run a webapp locally. I believe it's the same thing HipChat uses.

[jeremyfelt]

http://vagrantmanager.com/ looks like an interesting possibility for at least managing the state of the VM.

[sirjonathan]

+1 for a GUI. I brought over a front-end dev today to work on a WordPress project and while he got through the Terminal steps just fine it was outside of his comfort zone. A GUI could help lower the barrier of entry.

[bosconian-dynamics]

• What specific parts of VVV would we want to manage beyond vagrants up, halt, suspend, destroy?

My thoughts on these matters are somewhat lengthy, lofty, and ambitious, but you may find some use of them yet!

I would like to see a minimal implementation of a system GUI - primarily on the scope of a tray-icon that gives quick access to starting/stopping services/the VM - which would be complemented and expanded upon by a more robust default VVV dashboard. This bipartite approach keeps the host's UI exceptionally lightweight while ensuring maximum compatibility by serving the principal of the UI as a standard web-page, removing the need for packaging a standalone HTML/Javascript engine (and thus also providing nearly the entire functionality of the UI to those who run VVV on headless hosts).

Tray Icon Functionality

• Vagrant up/halt/suspend/destroy/provision
• Xdebug on/off
• Start/stop/restart MySQL, nginx
• Hyperlinks that open a browser window:
  • Dashboard
  • New Site (see Dashboard Functionality section)
  • "Sites" submenu (perhaps only listing a subset of all sites consisting of the most frequently/recently "used" when there are many available)
    • WordPress trunk
      • "View Site" link
      • "Open Local Directory in File Manager" link
      • Other quick-links (see Dashboard Functionality section)
    • WordPress dev
      • "View Site" link
      • "Open Local Directory in File Manager" link
      • Other quick-links (see Dashboard Functionality section)
    • User-created installations, etc.
  • Third-party tool submenu
    • phpMyAdmin
    • WebGrind
    • etc.
  • General log files submenu (opened via hyperlink as they are not directly accessible from host)
    • nginx
    • PHP
    • Xdebug
    • MySQL
    • etc.

Robust Dashboard Functionality The dashboard itself would be capable of most, if not all of the tray icon's functions. Additionally, some kind of (perhaps overly) optimistic features I would like to see it provide are:

• Streamlined WP Installation Management: vvv-site-wizard and vv are both exceptional tools in their own right, and very nearly essential to those first starting out with VVV. However, both are bash-dependent requiring users of Windows and some flavours of *nix to install a new shell or emulator - many of which requiring confusing installations and complicated usage (i.e. MinGW, Cygwin, Git for Windows bash emulation). Integrating these scripts' abilities to list/add/remove WordPress installations and nginx host entries to the dashboard itself would essentially eliminate the barriers to creating new sites by hand - allowing even those who have never touched a CLI to spin up and destroy installations with a few clicks.
• WP Installation Quick-Links: additional quick links provided for each site entry (these could be added to the tray icon, but I fear over-cluttering the thing):
  • "Administer database" (open installation's DB in phpMyAdmin if the database can be discerned from wp-config)
  • "Visit site"
  • "Site dashboard"
  • "Manage site hosts"
  • "View debug log" (if /wp-content/debug.log is available, or a log file can be discerned from wp-config)
• High-level tools management: this may merit another discussion altogether, but it would be nice to provide an interface for high-level third-party tool management. For instance, I currently provision a modified installation of Interconnect It's serialization-aware Database Search and Replace tool into my default web-root. Others may prefer alternatives to pre-installed tools (i.e. Adminer or SQL Buddy in place of phpMyAdmin). Not terribly necessary, but it would be a neat feature down the road, and would support the standardization of tool installations - something I think the VVV community could really benefit from.

One possible issue with the "robust dashboard" approach is that it would likely provide interfaces for altering the Vagrant's settings and scripts on the host - is it a reasonable thing to do, to alter VVV's provisioning and configuration files from the live VM? There are vagrant extensions that allow executing commands on the host from the VM that would provide some small abstraction to directly altering these files, but still it feels somewhat dirty to me...

• And/or... what's MVP here?

In my envisioned bipartite GUI, I feel the tray icon takes priority. It provides fairly easy to implement functionality (not regarding the actual tray-icon implementation itself - no clue what that requires) that has an immediate and large return in streamlining productivity; it also functions well enough without the dashboard component.

In general, I feel a good guiding notion for the GUI is to abstract away many of the tasks that currently require an SSH session to accomplish.

[grappler]

There are two tools which cover both aspects for tray icon and dashboard.

http://wptavern.com/vvv-dashboard-provides-an-interface-for-managing-varying-vagrant-vagrants-installations http://wptavern.com/vagrant-manager-for-os-x-manage-all-your-vagrant-machines-from-one-place - There is also a Windows version now.

[bosconian-dynamics]

There are two tools which cover both aspects for tray icon and dashboard.

Aye, both are good projects - the question is if and how to integrate their functionality (or some sub/super set) into a VVV-centric tool...

That dashboard definitely has many of the foundations of what I had in mind. It could even be a base for the VVV dash/prototypes, but the project's licensed under GPLv2, and so the I believe the derived dash would have to be as well, which may be undesirable(?).

Vagrant Manager shares the MIT license - Jeremy mentioned it earlier as a possibility for managing VM state. As there are OSX and Windows code-bases available, it could be used to derive UI functionality, as well - however *nix support would have to be implemented separately.

What does it take to build a GUI? Is it tough to do cross-platform (Is Adobe Air still a thing) or would it be better to focus on individual OSes?

I'm no authority on this subject by any means, but after some brief research, my vote is to write a platform-independent implementation and leverage cross-platform libraries to compile platform-dependent binaries (which would ideally leverage native platform controls/widgets). Though likely somewhat more complex than AIR/Java, this removes the need for additional binary dependencies (i.e. AIR/Java runtimes). My vote goes to cross-platform primarily for the sake of maintainability - a single implementation with one UI lib sounds very appealing; meanwhile platform-dependent binaries offer next-to-native performance. My digging turned up a few cross-platform, FOSS UI libraries that appear ideal for the task:

• Qt - widely popular commercial framework with free, open-source licensing available
• wxWidgets - leverages native platform controls
• FLTK - leverages native platform controls
• GTK+

I lean away from proprietary options, and the scope of my research reflects as much (though the likes of AIR as well as Java are certainly still options).

[strider72]

I wonder if it would make more sense to contribute code to Vagrant Manager. Perhaps if that app had a plugin architecture it could be adapted to specific Vagrants such as VVV. It just strikes me that if somebody has already done much of the work, it's smart to build on that rather than re-inventing.

(I'm far from a Vagrant expert, so just tossing ideas here.)

[tomjn]

I started work on something that auto-installs VVV, in a react electron shell, that could be turned into this at https://github.com/tomjn/vvv-cd-installer

[evertiro]

I'm going to revitalize this a tiny bit by suggesting that if we want it to be fully cross-platform, electron may be the answer.

[tomjn]

@evertiro that's the plan, turn the dashboard into a proper UI, then hoist it into electron, I'm not sure where the ticket for that is though

[evertiro]

I'll find it at some point... I'm now determined to get the open issues cleaned up at least a little.