4 ms·

I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI al

• pcr910303 6y ago
  > I think the problem is that historically when people have done this they've made a total mess of it, and inevitably it doesn't support all options so the GUI always plays catch up (and no one is interested in keeping the GUI up to date). > I think the example for this was the wget gui. Yeah, that's true, but I think it'll be easier than binding GUI to the CLI. The reason CLIs could get this usefulness was because it mixes up user interaction with it's programming interface (which is ironically what people most hate). If you want to make a CLI program, you almost need to spit out useful information to stdout, which means I can extract info from sed. GUIs are much harsher to extracting information and there are some solutions like AppleScript, but it doesn't fly. Which means, exposing the CLI's capabilities to GUIs are much easier than exposing the GUI's capabilities to CLIs. While Fig isn't taking this route, one could write an man-page parser (like how fish does for it's completion) and expose CLI functionality automatically and increase it's usefulness with human annotations. > My take on this is that for beginners this is really useful. It can also help show you new options that you might not have been aware of. (Have you read the full man page?) Yeah, agreed.