Multithreading in GUI

[Vladimyr0]

Hello Christian, it would be nice to use multithreading in TC more active.
The goal: main GUI should never freeze, when slow drives (or plugins) are not responding.
Some controls can be grayed out or progress bars are displayed instead.
This will make TC more user-friendly and speed up user's work.

P.S.: had some experience in such programming on Delphi...
My program opened and closed trays on optical drives, but
each drive had its own dynamically created thread, plus one more
thread for GUI. Worked like a charm, even while discs were loading.

[ghisler(Author)]

The problem is that many plugins are not thread-safe, therefore it's not possible to do this everywhere.

[fenix_productions]

2ghisler(Author)
Shot in the dark: if some plugins aren't thread-safe wouldn't it be possible to get some details from them using separate (hidden) TC process?

Standard TC instance could run another one with some parameters and communicate using WM messages.

[Vladimyr0]

Let's stay plugins untouched for beginning...
But the main window sometimes is freezing entirely,
when a drive is working slow. Sometimes a small pop-up
is displaying the 'connect' message, but even in this
case user is not able to perform another action.

It's possible to make a progress bar for such situations,
to indicate that the drive is still accessing now. But other
panes and tabs should be active, to give the user ability
to work with other discs and folders (and as an ideal - with
files on the slow disc, which are appeared already on the
disc tab).

Let's consider GUI as the buffer, which is sending commands
to disc operating threads, and collecting response messages
from those ones. GUI can do anything: display some progress
bars, statuses, messages, but should never be inaccessible.
And allow the user to click, drag and edit any object at any time.