digiKam Developer Documentation: Digikam::WorkerObject Class Reference

| digiKam Developer Documentation Professional Photo Management with the Power of Open Source

Loading...
Searching...
No Matches
Public Types | Public Slots | Signals | Public Member Functions | Static Public Member Functions | Protected Member Functions | Friends | List of all members
Digikam::WorkerObject Class Reference
Inheritance diagram for Digikam::WorkerObject:

## Public Types
enum | DeactivatingMode { FlushSignals , KeepSignals , PhaseOut }
enum | State { Inactive , Scheduled , Running , Deactivating }

## Public Slots
void | deactivate (DeactivatingMode mode=FlushSignals)
| Quits execution of this worker object.
void | schedule ()
| Starts execution of this worker object: The object is moved to a thread and an event loop started, so that queued signals will be received.

## Signals
void | finished ()
void | started ()

## Public Member Functions
| WorkerObject ()
| Deriving from a worker object allows you to execute your slots in a thread.
bool | connectAndSchedule (const QObject *sender, const char *signal, const char *method, Qt::ConnectionType type=Qt::AutoConnection) const
| You must normally call schedule() to ensure that the object is active when you send a signal with work data.
QThread::Priority | priority () const
void | setPriority (QThread::Priority priority)
| Sets the priority for this dynamic thread.
State | state () const
void | wait ()

## Static Public Member Functions
static bool | connectAndSchedule (const QObject *sender, const char *signal, const WorkerObject *receiver, const char *method, Qt::ConnectionType type=Qt::AutoConnection)
static bool | disconnectAndSchedule (const QObject *sender, const char *signal, const WorkerObject *receiver, const char *method)

## Protected Member Functions
virtual void | aboutToDeactivate ()
| Called from deactivate(), typically from a different thread than the worker thread, possibly the UI thread.
virtual void | aboutToQuitLoop ()
| Called from within thread's event loop to quit processing.
void | addRunnable (WorkerObjectRunnable *loop)
bool | event (QEvent *e) override
void | removeRunnable (WorkerObjectRunnable *loop)
void | run ()
void | setEventLoop (QEventLoop *loop)
void | shutDown ()
| If you are deleting data in your destructor which is accessed from the thread, do one of the following from your destructor to guarantee a safe shutdown: 1) Call this method 2) Call stop() and wait(), knowing that nothing will call start() anymore after this 3) Be sure the thread will never be running at destruction.
void | transitionToInactive ()
bool | transitionToRunning ()

## Friends
class | ThreadManager
class | WorkerObjectRunnable

## Member Enumeration Documentation

## ◆ DeactivatingMode

enum Digikam::WorkerObject::DeactivatingMode

Enumerator
FlushSignals | Already sent signals are cleared.
KeepSignals | The thread is stopped, but already sent signals remain in the queue.
PhaseOut | The thread is stopped when all signals emitted until now have been processed.

## Constructor & Destructor Documentation

## ◆ WorkerObject()

Digikam::WorkerObject::WorkerObject | ( |  | ) |
| explicit

Implement any slots and connect signals just as usual. Call schedule() before or when signals are emitted. The object will have moved to a thread when the signals are received by the slots. Call deactivate() to stop computation. Note that without calling schedule(), no signal will ever be processed. You can use the connectAndSchedule convenience connection to avoid having to call schedule() directly. Note that you cannot make this QObject the child of another QObject. Please check if you need to call shutDown from your destructor (see below).

## Member Function Documentation

## ◆ aboutToDeactivate()

void Digikam::WorkerObject::aboutToDeactivate | ( |  | ) |
| protectedvirtual

You can stop any extra controlled threads here. Immediately afterwards, an event will be sent to the working thread which will cause the event loop to quit. (aboutToQuitLoop())

## ◆ aboutToQuitLoop()

void Digikam::WorkerObject::aboutToQuitLoop | ( |  | ) |
| protectedvirtual

Quit any blocking operation. Immediately afterwards, the event loop will be quit.

## ◆ connectAndSchedule()

bool Digikam::WorkerObject::connectAndSchedule | ( | const QObject * | sender,
|  | const char * | signal,
|  | const char * | method,
|  | Qt::ConnectionType | type = `Qt::AutoConnection`
| ) |  | const

Instead, you can use these connect() methods when connecting your signal to this object, the signal that carries work data. Then the object will be scheduled each time you emit the signal.

## ◆ deactivate

void Digikam::WorkerObject::deactivate | ( | DeactivatingMode | mode = `FlushSignals` | ) |
| slot

If mode is FlushSignals, all already emitted signals will be cleared. If mode is KeepSignals, already emitted signals are not cleared and will be kept in the event queue until destruction or schedule() is called. If mode is PhaseOut, already emitted signals will be processed and the thread quit immediately afterwards.

## ◆ setPriority()

void Digikam::WorkerObject::setPriority | ( | QThread::Priority | priority | ) |

Can be set anytime. If the thread is currently not running, the priority will be set when it is run next time. When you set QThread::InheritPriority (default), the priority is not changed but inherited from the thread pool.

## ◆ shutDown()

void Digikam::WorkerObject::shutDown | ( |  | ) |
| protected

Note
  This irrevocably stops this object.
  It is not sufficient that your parent class does this. Calling this method, or providing one of the above mentioned equivalent guarantees, must be done by every single last class in the hierarchy with an implemented destructor deleting data. (the base class destructor is always called after the derived class)