Hi HN !

I am Alex, the author of Pyrustic, a collection of lightweight Python projects that share the same policy.

Two functions are enough to know to make a command line application: the function to display text and the function to retrieve the input entered by the user. To make a GUI application, we need to know what widgets to use and the settings to configure them, think about the user experience, create the layout and, most importantly, write well organized code. GUI programming is difficult [1], especially when we do not have a lot of time available and therefore when we have an idea of an application project with GUI, we will tend to postpone [2] the development, sometimes to abandon the project under development because it gets complicated, or instead just create a command line application.

I am not opposing the command line interface to the GUI. There are a few command line programs that I like best in this form. I also like apps that have both a GUI and a command line interface.

I've been working on a framework called TkF for several months now, to make Python GUI applications. The framework uses Tkinter (a thin object-oriented layer on top of Tcl/Tk included in the Python Standard Library) and it just works. But it still takes me long time to create a GUI. So I thought about creating a GUI builder based on TkF. I don't like using a GUI builder but that sounds like a nice challenge: to create a simple to use GUI builder that I will love to use myself !

After several days of thinking, my thoughts drifted away from the Python philosophy: simple is better than complex. I finally gave up on the idea of the GUI builder and decided to create something else that could allow me to create a GUI, as fast as a GUI builder without using the mouse. I made Dresscode, a framework built on TkF.

With Dresscode, the main views of the GUI are Pages and widgets (graphical Components) are positioned on pages with a simple layout mechanism managed with two booleans: new_row and new_col. To increase productivity, I implemented this simple idea: a navigation bar automatically populated with references to the Pages (example: Home, About, et cetera) of the application.

So far, everything was fine until a few weeks ago. I was editing the READMEs of the projects TkF and Dresscode. The README of the TkF project has a nice cover image [3] which is a screenshot of a demo made with TkF. I wanted such a nice image as cover for the Dresscode README. But this demo cannot be done as it with Dresscode without cheating. There are two buttons "Cancel" and "Connect" under a form which cannot be reproduced as it with Dresscode because the layout mechanism has a limited flexibility in order to gain in productivity.

Again a new challenge: I decided to think about how to unlock the potential of the layout mechanism without sacrificing developer productivity. To do this, I introduced the notion of "parent" which allows the developer to freely decide where he wants to place a graphical component on a page. But it's not enough. Some graphical components may need to be enlarged to fit the width of the page or the height or both. For that, I simply borrowed from Tcl/Tk the main parameters of the Pack geometry manager: "anchor", "expand", "fill", and "side".

Thanks to serendipity [4], I had other interesting ideas and I thought that all of this might form a concept that can be implemented in different programming languages. I named the concept GASP: GUI As Stapled Pages. Here, the navigation bar represents the staple. I decided to abandon Dresscode and to create a new project from scratch still in Python: Gaspium [5], the reference framework to build GASP apps.

In short, we define pages to which we add graphical components. With a single line we add a complex graphical component to a page and the flexible layout mechanism is controlled with five parameters ("parent", "side", "anchor", "fill", and "expand") whose defaults are sufficient in most cases. Then we add these pages to an instance of the App class. The first page added is de facto the home page and it will be open when the application is started. Adding a page makes it automatically referenced in the application's navigation bar. Each graphical component can be identified with a unique identifier in order to be able to read its content or update it. Each page has a unique identifier assigned automatically or manually. You can open an arbitrary page directly from the command line and even pass data to it.

As a developer, the GASP concept introduced a new GUI programming metaphor that improved my productivity [6][7]. As an application user familiar with monolithic applications, I see a GASP application as a collection of useful programs, each with a graphical user interface that can be arbitrarily invoked from the command line.

There is the heavily commented source code of a small demo [8] on the Gaspium README. This demo is a GASP application built with Gaspium. You can copy paste and run the demo source code as is (you need to "pip install gaspium" first).

It is a pleasure to share with the HN community this command-line-friendly GUI programming metaphor and its reference implementation. Please post [9] any feedback, ideas, questions or relevant experience, I'd love to hear it !

Thank you for your attention !

[1] https://blog.codinghorror.com/ui-is-hard/

[2] https://news.ycombinator.com/item?id=23537317 (Procrastination is driven by our desire to avoid difficult emotions, says expert)

[3] https://raw.githubusercontent.com/pyrustic/misc/master/asset... (Cover image for the README of the TkF project)

[4] https://news.ycombinator.com/item?id=1826666 (Paul Buchheit: Serendipity finds you)

[5] https://github.com/pyrustic/gaspium

[6] https://blog.codinghorror.com/the-ultimate-dogfooding-story/

[7] https://news.ycombinator.com/item?id=453721 (The ultimate dogfooding story)

[8] https://github.com/pyrustic/gaspium/#demo

[9] http://sl4.org/crocker.html (Crocker's Rules)