[Kde-hardware-devel] Using Solid

[Kevin Ottens]

On Wednesday 21 October 2009 22:58:12 David Hubner wrote:
> After programming in Solid for a while, i would just like to add my two
> cents to the API. Solid is great to use but i would like to make a few
> questions, recommendations + wishes :)

Glad you liked it. ;-)
 
> Wishes:
> 
> 1. It would be nice if there was a Solid::Computer class with
> information about the motherboard etc etc. Example the HAL "Computer"
> object.

I've been thinking about that in the past, but the only real use case I came 
up with was "finding the right icon for the computer", so it's just what the 
icon() method do on the root object. Do you have any use case for finer 
grained data as you're proposing?

For random desktop apps I couldn't find any use case where they'd need this 
info, hence why it's not exposed.

> 2. It would be extra nice if there was a used property as well as a size
> property in StorageVolume. I don't know if this is possible as HAL does
> not have this either. Probably out of the scope of a hardware framework.

Yes, used is excluded on purpose as in most case we'd end up polling the 
system to keep this information up to date which I'm definitely not fond of. 
In fact this particular point got raised several times already.

> 3. Would be nice if it was possible to check connected status on each
> NetworkInterface rather than global, or the Solid::Networking:Notifier
> statusChanged function to say which NetworkInterface caused the status
> change.

Again, any use case for that?

> 3. It would nice if fetching devices with the type
> Solid::DeviceInterface::Unknown would not show devices already in other
> categories, or maybe, have a new enum type for that kind of function.

This one is rather a corner case really. :-)
I think it could be changed, would need modifying the HAL backend, could be a 
bit expensive though. Honestly kind of too minor for me to actively spend time 
on it, but I'll definitely review patch and provide guidance if someone is 
interested in it.

> Recommendations:
> 
> 1. Most classes have a slight description in the method name when it
> comes to the method type, for example, fsType in StorageVolume but some
> classes just have this methods listed as type, example, Battery + Button
> classes. Its kind of inconsistent.

In fact not, this one was somehow intended (btw, if it was really an issue 
it's now too late to fix because of binary compatibility concerns). The 
difference in type() for Battery and Button is that it describes really the 
type of the battery|button itself, while fsType() for StorageVolume describes 
the type of the filesystem contained in the volume.

> Questions:
> 
> 1. What is the direction of Solid? Is it aiming to become a complete
> device framework to interact with/show all devices in the users
> computer, or, just devices that show some kind of status. For example
> will it show system devices like PCI-PCI buses or motherboard resources?

I'm planning to broaden the scope of Solid to deal with some more system 
related status, and to also tackle networked devices (if I ever find time for 
it). PCI-PCI buses or motherboard resources OTOH aren't in my plans so far, I 
want libsolid to be helpful for desktop application developers and they 
generally don't need such fine grained information.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20091027/3337a6a0/attachment.sig