> It shouldn't have any side-effects. In fact, the code exists to *avoid* > side-effects in the first place. > > Of course, it assumes that there isn't buggy code elsewhere. If there is, > then all bets are lost. I'm not going to document how to bugfix other code, > especially complex code like this. And we've already established that the > SANE backend is buggy.
Sorry, I got that wrong. I thought that always if one subclasses a QProcess, one would have to care about implementing some virtual functions to get it working correctly. If it's only the SANE backend that breaks this, you're of course right. > > If you're really bored some time, maybe you want to file an issue for the > > SANE Pixma backend and tell the devs what exactly is wrong there and/or > > how to fix this? > > I'm not. I'll explain if you file or if you want to actually fix, but I > don't have that much free time available. Within what I could grasp, I filed an issue: https://gitlab.com/sane-project/backends/-/issues/582 I fear fixing this is far beyond my programming skills. I hardly understand what's going on here at all ... > Well, if you use QProcess to call the full SANE backend, that will also > avoid the problem. Yeah, maybe if I would acquire the images not by using libksane, but by calling scanimage via QProcess, I would not have any problem. But apart from losing the functionality I wanted to implement (setting the scanner options in a nice GUI way) that would only work around the real problem, which is a buggy implementation of the plustek backend, wouldn't it? > "If you write buggy code, the application may misbehave" is not > documentation. Let's hope the SANE devs fix it ;-)
