Making a GTK application in Haskell, part 1

In this series, we aim to create a todo-list application using Haskell, GTK 4, and the Adwaita library. Adwaita provides numerous useful widgets and styles. Our intended audience consists of intermediate Haskellers with development experience in Haskell. Adwaita is a library of GTK components that represent the GNOME project's design language, encompassing accessibility and style guidelines.

It enables the creation of applications with responsive design and real-time recoloring when the desktop transitions between light and dark themes. Throughout this series, we will utilize the haskell-gi toolkit, which automatically generates Haskell bindings from GTK libraries, allowing us to interface with GTK in a manner that is familiar to the C API.

To maintain readability, the presented code will be incomplete, highlighting the key concepts. The complete project can be found at https://github.com/Floreal-Technologies/adwaita-todo. Initially, we will establish the adwaita Application that manages resources, including Adwaita stylesheets, which are quite useful. Subsequently, we will introduce the empty window displaying "Todos" as its title and dimensions of 480 by 640.

The Elm Architecture (or TEA) serves as a pattern for architecting interactive programs. Central to this approach are three concepts: This methodology has gained popularity through Elm and proves effective in managing the imperative nature of the GTK toolkit. Now, it is time to represent our application state and its actions. In accordance with the Elm Architecture, we model everything as data structures, ensuring clear visibility of triggered actions and their implications.

User interactions with the application are modeled as Messages: a predetermined set of actions for which we have clear modifications to the model. We begin with a few messages that the user may trigger to update the model. While this is a preliminary step, more messages will be added as we progress. To inform our designs, we will outline our expectations before commencing the user interface.

Drawing from experience, it is often not immediately apparent how design emerges from data, so we tend to scrutinize the shape of our data less frequently. For this project, we will employ several widgets, which we encourage you to explore by clicking on their names to view screenshots: With these building blocks, let's define the connection between our widgets: To observe visual feedback, you will need to trust that the resulting design resembles the pencil-and-paper draft from the beginning of this article.

Analogous to the demo at the beginning of this article, the current implementation is where we integrate the Model-View-Update trio. We will define two additional functions: dispatch and step, which work in tandem. dispatch manages message processing, prioritizes GTK execution, and invokes step to execute the model update that triggers the view update. step reads the model, applies the update function (from Model.hs) to generate the new model, writes the new model, and transmits the updated model and dispatch function to the View.

The View responds with the new content as a Gtk widget, which we subsequently set within the window. This concludes the current article. We will delve into additional features for our Todo List application in Part 2.