https://bugs.kde.org/show_bug.cgi?id=404313
arcli...@gmail.com <arcli...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Resolution|NOT A BUG |--- Status|RESOLVED |REOPENED --- Comment #2 from arcli...@gmail.com <arcli...@gmail.com> --- 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". -- You are receiving this mail because: You are watching all bug changes.