Quote:
Originally Posted by capink
The "normal" reason for calling that method is that you are doing something on the GUI thread that takes a *long* time, or that your code is on a separate thread without normal event management
|
I am running in the main gui thread because I think I have to, otherwise some actions might fail.
Quote:
Originally Posted by capink
Is the processing really so long?
|
Not always, but it can be. Running long search and replace chain on huge libraries can take hours. I've done this when I was testing the plugin at the beginning.
Quote:
Originally Posted by capink
If it is so long, should we fork a subprocesses or is the "fork a subprocess" cure worse than the disease?
|
I will admit that this is beyond my knowledge. I don't know much about threads and subprocesses and I am not sure I know the difference between them. With how little I know, I am inclined to think this is not possible because the plugin has to run in the main gui thread, as a lot of actions (e.g. search and replace, single field) make certain calls like db.set_field. I am not sure whether this can be done from a separate thread or a subprocess.
Quote:
Originally Posted by capink
If it is so long, is there some way to chain the processing based on events, for example progress timers?
|
This is an interesting idea that I have not thought of. I can try this using QTimers. But it will only alleviate the problem for shorter chains, because with long chains I will still be making the call to processEvents, albeit with much less frequency.
A temporary solution besides the timers, would be to turn this off for chains that are activated by that particular event. I will also test without the call to processEvents and see how much of a difference does it make.