Suggestion for future development direction: CLI/GUI-less/Headless mode

[Lehonti]

Before we start, I know this is a bold, long-term idea and that currently development efforts are limited. However, I want to reassure everyone that this is not about expanding the scope of Pinta, but about making what we already have (the friendly, easy-to-use application) more powerful, and improving the code and its architecture.

It would be great to hear the thoughts of the lead maintainer, @cameronwhite, as well as that of recent contributors, like @Matthieu-LAURENT39, @PabloRufianJimenez, @pedropaulosuzuki, and anyone else.

Background

For a substantial period of time, I opened pull requests often. Many of them were refactorings. I would like to believe that these efforts have improved the codebase. However, most of them were not offering any new features or improving existing ones, but they were focused on "paying off" the technical debt. But then, after integrating the Linux CLI in my daily computing workflow, I got an idea, which I would like to propose, and if it's agreed upon it would inform future development efforts.

Idea: CLI mode

Imagine being able to run and use Pinta without a GUI. I am thinking of something that can read and execute series of commands from STDIN, or even run single commands if only a very specific thing (like applying an adjustment to an image) is desired. My idea is something like Gnuplot or the "headless" mode of LibreOffice.

Architecture

In general, implementing this would involve strictly separating the GUI from the logic. And, more concretely, I propose the MVVM pattern. This is how it would apply to Pinta:

• Model: the "engine" of the application. It is important to emphasize that it doesn't know anything about the GUI. It just manages state and makes sure it is correct and consistent at all times. It would be an abstract representation of the features we know: layers, canvas, history items...
• View (requires GTK): the windows and the controls, which act like a "dumb terminal". It just handles the graphical interactions, but doesn't have a "brain" of its own. It just binds to the properties of the viewmodel.
• Viewmodel (requires GLib): handles communication between model and view. It has GObject properties that can be bound to and read by the view, and reacts to all the events that the view generates.

After the separation is complete, we could create a command-line wrapper for the model

Antecedents

I remember proposing the feature of batch jobs (#1092). At the moment I was trying to think of a good user interface, but every solution I could think of felt too complex. Now I think the easiest and cleanest way to offer this is through the command line. I think that if someone wants to automate tasks, asking them to use the command line is reasonable, and it would also allow them to control the output very precisely.

[badcel]

The idea sounds pretty interesting and could lead to a more capable application. It could have the same attributes you mentioned (friendly, easy to use) available on the CLI.

I'm not into the code architecture very much but when I tried to find a certain place in it, it was pretty straight forward. This is a pretty huge accomplishment for a code base and I can't claim this for GirCore, I think.

From my point of view this is actually a very important feature of an open source project as it allows contributors to help out easily. This should not be lost during restructuring.

In my professional career we are using the MVVM model for developing GUI applications. With this knowledge I would tend to say that you are not well advised to base the CLI View on the GTK ViewModel.
A viewmodel connects a certain View to a model. For example a dialog or a certain user control that is 5 layers deep in the application.
If you want to expose this one feature in the top level of the CLI you would need to access it from some CLI view class and somehow get down the 5 layers to the place you are interested in or create some "DialogViewModel" to set some settings or similar.
It would be like a remote control of the app: The CLI would do the same things on the viewmodel the UI would do. At least from my point of view this would be a bit odd as the CLI interface is than bound to the hierarchical structure of the UI.
Changes to this structure would break the CLI interface.

From my experience the main benefit of view models is that it allows to unit / integration test the application from this layer downward as no GUI needs to run. If then for example the file system would be mocked away one could verify at the end of a test if the expected actions happened on an image and were saved to the virtual file system.

[Lehonti]

Thank you! Just to clarify, I am not proposing to use the viewmodel for the CLI part. What I am proposing is to refactor the graphical app to be MVVM and then use the model (the engine part) in the CLI mode. And if we are going to use the MVVM architecture for the CLI too, I agree that the view and viewmodels have to be structured differently.

[badcel]

Great 👍 than I misunderstood you a little.

[Matthieu-LAURENT39]

I definitely feel this could be very useful (in fact I even toyed around with trying to automate Pinta via CLI in a private branch, but that never really went anywhere).

A full-on CLI interface would probably be the most powerful way to expose automation through Pinta.
I do see a few potential issues with it though:

• I feel this would also mean needing to be far more rigid with changes. We'd be taking on an implicit contract that we're exposing a CLI that won't break (or we could say "the CLI interface may change at any time", but that makes scripts less practical).
• It probably wouldn't be the most ergonomic (when applying effects via CLI, how do you pass arguments to effects? Especially for things like curves).
• The image-editing CLI space already has ImageMagick. It's certainly not as powerful as Pinta, but for most CLI image editing tasks, it's good enough. So is it really worth all the effort?

Another approach I'd like to suggest is to instead expose a D-Bus interface.
This would switch from a fully CLI approach to an approach closer to what you'd get with Selenium, where you can automatically control a browser window through scripts.
A lot of KDE apps do that, exposing most actions through D-Bus, so you can automate most interactions with their GUI software through scripts by simply calling the D-Bus interface.
For Pinta, I feel like this would be better suited, as this can allow you to integrate automation but then continue doing manual edits if you want, allowing for more of a mixed workflow where you can automate tasks you do often but without needing to switch to full CLI.

This would however mean the feature is Linux exclusive, but I feel like most of the interest for controlling Pinta from the CLI would be from Linux users anyways.
And of course it doesn't solve the issues with CLI I mentioned, and it's not a perfect approach either, I'm just mentioning it so we can consider the different ways to do this. I also think a CLI interface would work well too.

[pedropaulosuzuki]

That's very interesting! One thing that comes to mind is: should we have Pinta have the GUI and CLI modes together, or should we abstract the Pinta model into a separate "Pinta Core" library and then create separate frontends to "Pinta Core"? This way, we could have a minimal, scriptable Pinta Terminal Application that can integrate well with many scripts and be lightweight without any GTK overhead in the binary, and a separate Pinta GTK package that is the regular Pinta we already have, with or without the CLI interface. This could also improve end-to-end testing and also allow third-parties to integrate "Pinta Core" into other GUI toolkits, such as Iced or Qt, if desired.

Also, this could help creating node-based Non-Destructive workflows abstracted on top of "Pinta Core", for example, while maintaining "Pinta Core" "as is", by linking the node tree to each Pinta command.

[Matthieu-LAURENT39]

If we're going with a MVVM approach (which is likely be the best way to go about it), having a separate core library with no dependencies on any specific UI framework does make the most sense.
With the way Pinta is designed, I think most non-UI code only relies on Cairo and not GTK, so it's already pretty well separated.

[badcel]

Just as a side note I'm currently considering adding GTK composite template support to GirCore which could come in handy.

Another side note: I tried creating a mvvm demo application for GirCore once and it felt a little off. Perhaps there is work needed beforehand to improve the overall situation for the MVVM scenario with GirCore.

[cameronwhite]

The image-editing CLI space already has ImageMagick. It's certainly not as powerful as Pinta, but for most CLI image editing tasks, it's good enough. So is it really worth all the effort?

I also had similar thoughts - for me a CLI interface to Pinta isn't a super high priority (there are lots of other things to work on already!) but I wouldn't have any objection to contributions for it either.

I'm definitely in support of the refactoring that would allow for this though, and agree moving UI dependencies out of the core Pinta library would be ideal. Even without the CLI this helps make Pinta more testable, and likely also easier to port to new GTK versions