In general there isn't actually a problem resulting from having multiple instances of an application open at once. If the issue here is that it's not clear which instance a dialog box comes from, then there is a fairly easy solution to that at least when running in a KDE Plasma environment: use the "Dialog Parent" effect, which is on by default. This darkens the parent window then a child dialog is open. The "Sheet" effect may also be useful, as it connects the dialog to the parent window.

Sadly these are not available when using alternative window managers, such as the Muffin window manager provided by Linux Mint. I recommend using Plasma instead with its KWin window manager (obviously! ;-) ).

If I've misunderstood the problem, please help me understand what the issue is rather than proposing a solution (it's hard to evaluate a solution when the problem itself isn't clear!).

The problem is easier to understand if you would give a little consideration for the life and business interests symbolized by the end users environment your application has been invited to function within.

In short human courtesy is a well practised technique of asking first what action is most appropriate for any given interface or any particular instance... a simple initial system check for a prior instance of your code shows continuity of the integrity of your code with a courteous and logical Y/N offer of choice. You would avoid the imposition of arrogance that your code immediately grabs CPU clock and system resources without any prior knowledge of the impact on the end users business needs "at that time".

Surely a better choice to please the user than to piss them off?

So when a K3b x3 copy run is performed, your running code is obscured by a subsequent instance of the same code preventing the user from remaining in control of the copy process (their process in fact). The behaviour of your code is in conflict with reasonable and proven conventional behaviours of human/machine interface engineering. Workarounds, your descriptive response, can only be tolerated under certain extenuating conditions. For example, in extremis, Apollo 13; by using a team of engineers at JPL, a workaround was discovered using insulation tape, cardboard, polythene sheeting, pvc piping, in combination used to convert the square format carbon dioxide filter from the LEM to fit the round format air filtration housing of the command module in order to save the lives of the crew!

The differing designs were afterwards recognized as problematic. Changes were made, so that future workarounds would be unnecessary and so that either would fit in the command module air filtration unit in all subsequent missions.

Workarounds are not in themselves wrong, but they cannot be tolerated for what they represent in design, risk, or inconvenience to the user!

I sincerely hope the nature of the problem presented by your code in its current form is now clear? Please allow for best practice?

Sincere thanks for appropriate code changes to meet this "multiple copy behaviour - independent of users default settings as an issue of Best Practice".

Do you think you could attach a screen recording that illustrates the problem? I recommend the Peek, Vokoscreen, or SimpleScreenRecorder apps for this purpose.

I apologise, it is clear from your response that you are indeed unable to understand what it means to have a piece of application code misbehave because the author has no awareness of basic ettiquette. Not only does it, your code, fail to follow best practices in checking and negotiating control of multiple instances of its own existence, with the 'very least of iterative code investment', so to maintain code validity at all times. But it fails to prevent serious inconvenience to the end user and their execution space as they attempt to get work done in what is generally termed a 'tight schedule'. This is outrageous, crude coding that breaks trust in Linux applications. Gone are the days where chucking rubbish at users is even close to adequate because there is serious competition in the marketplace.  Have you thought of working for Microsoft? 

In such circumstances your contribution for all its legendary capabilities is not yet house trained. 

A virus in your clear experience is a valid piece of code since it contains no bugs!

Apart from my disbelief, you have clearly done substantial research to get this far. Just think how far you would get if your editor/compiler or IDE simply screwed up your code but provided you with no error narratives? Could you stick with having to hand code every byte without access to any libraries? Should I care about your situation at all? Most programmers work in teams. I think you will find it is because after work everybody gets a kick from sharing a good laugh - because getting to know each others values make life much brighter, from which our collective code is much sharper!

Please only add relevant information and do not change the bug status.

If you'd rather write wall-of-text monologues full of insults and passive aggression, I don't think we can help you. Please see https://community.kde.org/Get_Involved/Bug_Reporting#Bug_tracker_etiquette.

Feel free to attach the requested screen recording that illustrates the problem and I'll re-open the bug.