There is a small chance that a device lister is able to discover and add a
previously known device before it is added by the database loader thread.
In this case, copy the data that is user-settable to the existing DeviceInfo
object and destroy the object created from the database query.
This adds and utilizes a new FindEquivalentDevice method that compares the
device unique IDs. This could probably be made more robust as the unique
IDs for some listers may change. However, this is a problem with the database
storage implementation in general.
When DeviceManager initializes, it creates a thread to load device information
from the database. Part of this process includes use of QPixMap for icons which
produced a warning message:
22:32:53.763 WARN unknown QPixmap: It is not safe to use pixmaps outside the GUI thread
In addition, the device is added to the view using beginInsertRows and
endInsertRows. This could contend with a device added by a lister signaling
PhysicalDeviceAdded.
To solve these problems, this change moves the icon loading and insertion to the
main thread. LoadAllDevices reads the data from the database and creates the
DeviceInfo object, then sends a signal to the main thread. In the signal
handler, the icon is loaded and the device is added to the master list and view.
Currently, the failure to connect to an MTP device results in the UI displaying
an open device that appears empty. This change introduces a method
ConnectedDevice::ConnectAsync() that is expected to handle any connecting tasks
that could block asynchronously. Upon completion, this emits a ConnectFinished
signal that indicates success or failure. The row in the UI is only updated
after the successful response is received. Upon failure, DeviceManager will
clean up and the row in UI is left in the pre-connect state.
Currently, only the MtpDevice utilizes this mechanism. All other devices use a
default implementation that immediately reports success.
Jim Broadus
Jonas Kvinge
John Maguire
David Sansome
David Sansome