4 ms·

I'm considering taking a tool I have which has a pretty nicely fleshed-out CLI interface and wrapping a GUI around it, so people who don't run desktop Linux can

I'm considering taking a tool I have which has a pretty nicely fleshed-out CLI interface and wrapping a GUI around it, so people who don't run desktop Linux can use it too. This seems like it might be perfect for my needs. https://github.com/hiAndrewQuinn/finstem https://github.com/hiAndrewQuinn/finstem Mostly I'm wondering whether anyone else has ever done what I'm trying to do here. My tool has well defined CSV, TSV and JSON flags -- has anyone else ever tried to use an actual full CLI tool unchanged to build a GUI around? What challenges should I be ready to face?

speps 3y ago
Look at Handbrake, which is a glorified UI for ffmpeg for example.
- ElongatedMusket 3y ago
  I use both handbrake GUI and yt-dlp GUI. Here's something they both do horribly and I would suggest for any CLI tool with a GUI wrapper: have a persistent textarea at the bottom of the GUI that shows the equivalent CLI call to the settings I select in real time. This will teach the user how your tool works and also give GUI-only users a taste of the power they could have if they used the command line. So basically, treat the GUI as a stepping stone to helping the user build scripts/workflows around your CLI. That way you are only developing the CLI, and the GUI is just a helper app. The second you start adding features to the GUI that can't be done in the CLI, you are now maintaining two separate apps.
  - speps 3y ago
    A hybrid would be great indeed, Bret Victor style with interactive widgets for each CLI argument. Might be a fun side project one day.
  - hiAndrewQuinn 3y ago
    This is a really good idea, and I can't believe it didn't occur to me with my PowerShell tooling background, since a lot of them have been doing this for a long time.
  - Izkata 3y ago
    Another example: gvim Check out the shortcuts in its dropdown menus.
halfcat 3y ago
Chess engines are a good reference for this. The decision-making part is a CLI that plugs into a GUI like WinBoard[0] or Arena[1]. There’s a protocol the engine and GUI follow, such as the WinBoard or UCI[2] protocols, which just exchange text commands via STDIN/STDOUT. The main challenges are the same problems you’d run into with multithreading, like deadlock where the GUI and CLI are both waiting on the other. So both sides typically need to be running their I/O in a separate thread from the “business logic”, so both sides remain responsive. A second common issue is idiosyncrasies around each OS’s handling of pipes, things like making sure you flush the buffer, or just the different OS-level API calls that differ between Linux, Mac, and Windows. [0] http://hgm.nubati.net/ http://hgm.nubati.net/ [1] http://www.playwitharena.de/ http://www.playwitharena.de/ [2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165bf https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
- hiAndrewQuinn 3y ago
  Much obliged! Chess GUIs are a very natural extension of a CLI, thank you!

speps 3y ago

Look at Handbrake, which is a glorified UI for ffmpeg for example.

ElongatedMusket 3y ago
I use both handbrake GUI and yt-dlp GUI. Here's something they both do horribly and I would suggest for any CLI tool with a GUI wrapper: have a persistent textarea at the bottom of the GUI that shows the equivalent CLI call to the settings I select in real time. This will teach the user how your tool works and also give GUI-only users a taste of the power they could have if they used the command line. So basically, treat the GUI as a stepping stone to helping the user build scripts/workflows around your CLI. That way you are only developing the CLI, and the GUI is just a helper app. The second you start adding features to the GUI that can't be done in the CLI, you are now maintaining two separate apps.
- speps 3y ago
  A hybrid would be great indeed, Bret Victor style with interactive widgets for each CLI argument. Might be a fun side project one day.
- hiAndrewQuinn 3y ago
  This is a really good idea, and I can't believe it didn't occur to me with my PowerShell tooling background, since a lot of them have been doing this for a long time.
- Izkata 3y ago
  Another example: gvim Check out the shortcuts in its dropdown menus.

halfcat 3y ago

Chess engines are a good reference for this. The decision-making part is a CLI that plugs into a GUI like WinBoard[0] or Arena[1]. There’s a protocol the engine and GUI follow, such as the WinBoard or UCI[2] protocols, which just exchange text commands via STDIN/STDOUT. The main challenges are the same problems you’d run into with multithreading, like deadlock where the GUI and CLI are both waiting on the other. So both sides typically need to be running their I/O in a separate thread from the “business logic”, so both sides remain responsive. A second common issue is idiosyncrasies around each OS’s handling of pipes, things like making sure you flush the buffer, or just the different OS-level API calls that differ between Linux, Mac, and Windows. [0] http://hgm.nubati.net/ http://hgm.nubati.net/ [1] http://www.playwitharena.de/ http://www.playwitharena.de/ [2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165bf https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...

hiAndrewQuinn 3y ago
Much obliged! Chess GUIs are a very natural extension of a CLI, thank you!