Keeping program GUI front-end and CLI functionality separate

Question

In Linux a lot of programs have a CLI version and a GUI front-end. I read somewhere that this follows the linux philosophy and is good practice. Of course it's true from a developers perspective to keep the GUI code separated from the actual program.

Given a program, which can be used happily from the command line, I would want to create a GUI for the command line version. What are my options here?

I can think of only 2 that the GUI developer would use.

• calling the program with the configured paramters like so:

  system("someprogram --paramter1 -p2 -p3")

• having the CLI version be able to run in server mode with sockets (unix, inet, ...) and using those sockets to communicate with the "server"

The cleanest solution would be the second in my opinion, but this is not always possible without altering the CLI version.

The actual question is what is the proper way to have both a cli version and a GUI version built separately?

Answer 1

A different approach is to write your functionality as a library. Then you have a GUI which uses the library; and a CLI which also uses the library. Depending on the complexity of your task that may be the best solution, as both programs could work independently without the need of any kind of inter process communication.

Answer 2

If the execution of the program is relatively stateless, or it's not interactive, or it usually just runs to completion, then the first option is easiest and most appropriate.

If the program is stateful, or long running, then the second option is most appropriate, although more complex.

Think of FTP: using curl or wget to script a download versus using expect to script an interactive ftp session, there might not be a correct answer in every case.

Interesting study cases include:

• nmap can provide all of its complex useful output in XML, with feedback during scanning, once it's started you just have to sit back and wait
• gpg as a CLI has a long history of integration with GUI email clients, it uses file-descriptors for input and output
• xmlclitools has interesting dual mode operation, standalone and client/server

Answer 3

What language are you planning to use for the GUI? Guessing C/C++ based on the system() call. You could also use Python's os.exec*() or os.system() functions or similar functions in a number of other languages including just another shell script that calls Zenity, Yad or GTKDialog for the GUI interactions.

Use of the C/C++ system() function has a number of caveats. Since most other language compilers and interpreters are written in C/C++, their equivalent functions/methods usually have the same issues. Use with caution.

The Puppy Linux community makes extensive use of GTKDialog called from bash shell scripts since it supports most all the usual GTK+ GUI widgets. The XML-like GTKDialog code is embedded in an exported shell script string which is passed in the call to the gtkdialog executable. Thus all the code stays in the same file.

Yad is a fork of Zenity that multiplies Zenity's GTK+ GUI capabilities dramatically and is my current preferred tool.

The general approach of GTKDialog, Zenity and Yad is...

• Write a shell script that interactively collects the arguments with one or more calls to GTKDialog, Zenity or Yad (or, any or all of them for that matter)
• Execute the command line program with the collected arguments

The interactive GUI and functional code could also be in the same script, with a command line option to select GUI, CLI or API (non-interactive) if desired. Even better would be internal detection on startup of the kind of environment with auto-selection of the appropriate interface.