[Kde-hardware-devel] Using Solid

[David Hubner]

Kevin Ottens wrote:
> 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.
>
>   
I was mainly thinking computer UUID, this is avaliable in HAL but i am 
not sure about other backends.
It would allowed for hardware profiles per PC. I can see reasons for not 
adding it tho. This is a hard one to judge.


>> 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?
>
>   

This is mainly to tell which interface is connected when you have a 
wireless and wired connection. It could be used
to tell when a connection is gone from wired to wireless. It would also 
be useful on servers which have more than one
network card as you probably wish for both to be connected or to state 
which one is not connected.

>> 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.
>
>   

I am intrested in it mainly to show devices in a tree view that are 
unknown to specific types. I am not sure if this should
be done at framework level or app level tho. I shall see what i come up 
with and if i am happy with it i shall submit a patch

>> 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.
>
>   
Ahh that makes sense, thanks.
>> 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.
>
>   

Sounds good to me. Just so you are aware and not thinking i am just 
asking questions for the sake of asking, i am
developing a device viewer completely based on solid. 
http://www.kde-apps.org/content/show.php/Device+Information+KCM?content=113365&PHPSESSID=9c45e78225170ac5e9b5f5ad54af1d79

I am hoping it shall grow as solid grows.

> Regards.
>   
>   

Thanks

> ------------------------------------------------------------------------
>
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>