Forthcoming changes for libsolid

Kevin Ottens ervin at
Sat May 26 22:44:19 BST 2007

Hi list,

I've been away for two weeks partly due to some commitment regarding my 
researchs. Now I'm back but that means that I had to delay even more some 
important, and less important, changes I planned for libsolid in kdelibs.

So I'm requesting the right to work on the following changes for the coming 
monday (sorry for the late notice) and the next one.

1) solid_isDeviceInterface.patch (monday 28th may)
It simply renames Solid::Device::queryDeviceInterface to 
Solid::Device::isDeviceInterface. This method is not widely used outside of 
libsolid, the template convenience is more commonly used. This is a small 
cleanup, but necessary IMO to improve the discoverability of this API, this 
way the class fully follow the is/as metaphor.

2) (kdelibs|kdebase)_no_Solid_DeviceList.path (monday 28th may)
Get ride of the useless DeviceList typedef. It's really unnecessary IMO, I 
prefer avoid having useless type definitions around. I admit I could live 
without those patches applied, but for completeness I'd feel better with 
it. :-)

3) I'd need to strip out a few features from StorageVolume (monday 4th june). 
In fact, the mount/unmount/eject features should be in a separate interface, 
since it could be applied on other type of devices (at least StorageDrive in 
case of floppy drives). Also, it would make the whole more portable since 
mount/unmount is a very unixy concept that might not exist on other platforms 
and should then be made more generic.
My current plan is to move the eject() method to the OpticalDrive interface, 
where it actually makes sense (for instance this interface already have an 
ejectPressed() signal). And the mount/unmount state management in a separate 
interface. This interface and the methods it'll contains are yet to be 
named... Actually that's my only trouble with them, from a technical 
standpoint it should be an easy change, giving them the right names requires 
some brainstorming. :-)

4) I'd need to rework a bit a few classes, mainly AudioHw, Camera and 
PortableMediaPlayer (monday 4th june). They need to be consistent in the way 
we expose drivers/protocols information. Currently they aren't and they're 
enum based which might quickly prove to be a mistake for future 
extensibility, I'd like to switch them to a string based scheme. I still have 
to work out the details though. But for sure that'll be an API incompatible 
change. Luckily those classes are not widely used yet.

(3) and (4) are not ready yet, and are probably the most important. Without 
those changes the aforementioned device interfaces would probably become 
almost useless even before 4.0 is out, and would for sure become a problem 
for future expansion. In particular, the upgrade path for supporting more 
protocols would be tied to kdelibs release cycle which is not acceptable to 
application not tied to KDE release cycle (think third parties and 


If no one object I'll apply the patches for (1) and (2) on monday 28th may 
evenning and start working on (3) and (4) to be able to commit them on monday 
4th june.

Kévin 'ervin' Ottens,
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdebase_no_Solid_DeviceList.patch
Type: text/x-diff
Size: 2388 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs_no_Solid_DeviceList.patch
Type: text/x-diff
Size: 2226 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: solid_isDeviceInterface.patch
Type: text/x-diff
Size: 5168 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list