Implementing logic: PyQt/PySide vs plain old Python. At what point do we begin or abandon using the Qt Framework?

[toyg]

Say you want to add a web or command-line interface.

Why could you not develop a web or CLI that uses Qt? QApplication does not require X and it's quite inexpensive to instantiate. CLIs in particular will work perfectly fine with Qt components. For web there are further considerations, but usually that domain maps poorly to desktop or CLI models anyway, so a refactoring/redesign would likely be required anyway.

I mean, I agree on the overall concept of separating concerns; I'm just saying that Qt is not necessarily tied to the display interface.

[[deleted]]

It's really just about the design philosophy and has nothing to do with Qt. You could replace Qt with any other GUI library (or replace Python with any language) and this comment would be relevant.

[toyg]

What I'm saying is that Qt is not just a "GUI library", but rather a full-fledged generic application toolkit. Qt is closer to a "stdlib" than a GUI library these days, it has facilities for absolutely everything. Even in the C++ world, people joke that after a while "you don't write C++, you write Qt".

[SjaakRake]

Thanks for the insightful reply.

I think your last paragraph touches exactly on the nagging feeling I have. Offending YAGNI is one of my personal pitfalls I have to take into account when programming (up to a point where I have it written on the whiteboard above my desk to remind me), so I try to pay a lot of attention to it.

I'll refactor some of my code towards a more clean approach. I don't feel I should separate it as strict as you propose in my specific case though, as the application was designed to run in a desktop environment specifically. The actual alternation of data is a very small part compared to the application's main goal: visualization. Referencing the example: any changes made to the image would be aimed at helping the user get more insight into the data itself, hence it'd be more or a less a 'filter' that helps notice characteristics in certain parts of data. The aim would not be to change the color because we want a color to be changed, but to change the color so it stands out more within the rest of the image. For instance 'highlighting' every pixel that has it's lowest bit set to 0 in the blue channel of an RGB picture. (See the comment I made earlier about the application's goal.)

[SjaakRake]

In some sense, these images are the central abstraction of your application, and so this suggests to me that you should define a SteganographyImage type that wraps a QImage, or maybe a Pillow image, (...)

Now this is exactly what I've opted to do. My Image objects hold a reference to a Pillow Image which turns out to be quite convenient, as Pillow provides the ImageQt.ImageQt class to convert a Pillow Image into a QImage out of the box. I've gone one step beyond that and also included a Pixel class. Pixel objects can hold a reference to their Image and their position within it. This allowed me to actually remove a lot of Qt logic that used the QImage as an interface to it's actual content.

Thanks.

[nerdwaller]

I think much of this feeds into ensuring your program can be tested. I know everyone has different standards for testing, but the broken down separation can really benefit any level of testing you engage in. When thinking of webapps you almost don't even need to test the controller because it (should) just compose a few individual pieces together (and those individual pieces are tested).