Tim,
k3bhalconnection.cpp:845:70: error: no matching function for call to 'TDEStorageDevice::mountDevice(const TQString&, TQString&)'
Proposed patch, based upon today's tdebase patch:
diff -urN k3b/libk3bdevice/k3bhalconnection.cpp k3b.new/libk3bdevice/k3bhalconnection.cpp --- k3b/libk3bdevice/k3bhalconnection.cpp 2013-04-05 22:32:35.000000000 -0500 +++ k3b.new/libk3bdevice/k3bhalconnection.cpp 2013-08-09 21:35:42.121489109 -0500 @@ -840,9 +840,9 @@ TDEStorageDevice* sdevice = static_cast<TDEStorageDevice*>(hwdevice);
// FIXME - // Options from 'options' are not currently loaded into 'optionString' - TQString optionString; - TQString mountedPath = sdevice->mountDevice(mountPoint, optionString); + // Options from 'options' are not currently loaded into 'mountOptions' + TDEStorageMountOptions mountOptions; + TQString mountedPath = sdevice->mountDevice(mountPoint, mountOptions); if (mountedPath.isNull()) { return org_freedesktop_Hal_CommunicationError; } @@ -869,8 +869,8 @@ TDEStorageDevice* sdevice = static_cast<TDEStorageDevice*>(hwdevice);
// FIXME - // Options from 'options' are not currently loaded into 'optionString' - TQString optionString; + // Options from 'options' are not currently loaded into 'mountOptions' + TQString mountOptions;
if (!sdevice->unmountDevice(NULL)) { // Unmount failed!
The patch allowed be to build k3b, although you know more than me what is happening.
Darrell
Tim,
k3bhalconnection.cpp:845:70: error: no matching function for call to 'TDEStorageDevice::mountDevice(const TQString&, TQString&)'
Proposed patch, based upon today's tdebase patch:
diff -urN k3b/libk3bdevice/k3bhalconnection.cpp k3b.new/libk3bdevice/k3bhalconnection.cpp --- k3b/libk3bdevice/k3bhalconnection.cpp 2013-04-05 22:32:35.000000000 -0500 +++ k3b.new/libk3bdevice/k3bhalconnection.cpp 2013-08-09 21:35:42.121489109 -0500 @@ -840,9 +840,9 @@ TDEStorageDevice* sdevice = static_cast<TDEStorageDevice*>(hwdevice);
// FIXME
- // Options from 'options' are not currently loaded into
'optionString'
- TQString optionString;
- TQString mountedPath = sdevice->mountDevice(mountPoint,
optionString);
- // Options from 'options' are not currently loaded into
'mountOptions'
- TDEStorageMountOptions mountOptions;
- TQString mountedPath = sdevice->mountDevice(mountPoint,
mountOptions); if (mountedPath.isNull()) { return org_freedesktop_Hal_CommunicationError; } @@ -869,8 +869,8 @@ TDEStorageDevice* sdevice = static_cast<TDEStorageDevice*>(hwdevice);
// FIXME
- // Options from 'options' are not currently loaded into
'optionString'
- TQString optionString;
- // Options from 'options' are not currently loaded into
'mountOptions'
TQString mountOptions;
if (!sdevice->unmountDevice(NULL)) { // Unmount failed!
The patch allowed be to build k3b, although you know more than me what is happening.
Darrell
Looks good, go ahead and push. What is happening is that it was brought to my attention that the TDE HW library API inadvertently assumed the usage of pmount in all cases. Therefore, I updated the API to use a more generic method of specifying mount options; apparently I missed a few users of the TDE HW library such as k3b.
Tim
2013/8/11 Timothy Pearson kb9vqf@pearsoncomputing.net
Looks good, go ahead and push. What is happening is that it was brought to my attention that the TDE HW library API inadvertently assumed the usage of pmount in all cases. Therefore, I updated the API to use a more generic method of specifying mount options; apparently I missed a few users of the TDE HW library such as k3b.
Tim
It's steel not perfect: - mediaName parameter is useless for most of other possible backends, so it would be nice to pass it as a part of mountOptions map. - the retcode is assumed to be the pmount's returned code it's better to return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with KDE_DEPRECATED rather than just replace it. or at least please make some announce at list before performing such changes...
2013/8/11 Timothy Pearson kb9vqf@pearsoncomputing.net
Looks good, go ahead and push. What is happening is that it was brought to my attention that the TDE HW library API inadvertently assumed the usage of pmount in all cases. Therefore, I updated the API to use a more generic method of specifying mount options; apparently I missed a few users of the TDE HW library such as k3b.
Tim
It's steel not perfect:
- mediaName parameter is useless for most of other possible backends, so
it would be nice to pass it as a part of mountOptions map.
- the retcode is assumed to be the pmount's returned code it's better to
return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with KDE_DEPRECATED rather than just replace it. or at least please make some announce at list before performing such changes...
R14 is still in development, so I don't need to use KDE_DEPRECATED. After release then yes, I would need to do that, hence the urgency of the API change. :-)
mediaName will stay as I consider it a defect (albiet one out of our control) if a backend is not able to use a user-defined mount label.
retcode can be changed to an enum without any ABI problems, so this is not too high on my list of priorities.
Tim
2013/8/11 Timothy Pearson kb9vqf@pearsoncomputing.net
2013/8/11 Timothy Pearson <kb9vqf@pearsoncomputing.net It's steel not perfect:
- mediaName parameter is useless for most of other possible backends, so
it would be nice to pass it as a part of mountOptions map.
- the retcode is assumed to be the pmount's returned code it's better to
return a constant from some enum set.
PS when you introduce the new API, you supposed to mark the old one with KDE_DEPRECATED rather than just replace it. or at least please make some announce at list before performing such changes...
R14 is still in development, so I don't need to use KDE_DEPRECATED. After release then yes, I would need to do that, hence the urgency of the API change. :-)
You have announced the hard freeze some time ago, doesn't that mean, that we don't want such changes?
mediaName will stay as I consider it a defect (albiet one out of our
control) if a backend is not able to use a user-defined mount label.
UDisks 2 nor 1, which IMO are the most wanted backends, are unable to do that. Anyway, IMHO it would be better to supply it as a part of the map, because in that case you'll got one less parameter...
retcode can be changed to an enum without any ABI problems, so this is not too high on my list of priorities.
Strictly speaking, this would break the API/ABI unless you'll set some enumes to specific values. But that not a problem.
-
Darrell Anderson -
Fat-Zer -
Timothy Pearson