[Kde-hardware-devel] Using Solid

David Hubner hubnerd at ntlworld.com
Mon Nov 2 04:30:11 CET 2009


On Sunday 01 Nov 2009 12:40:52 Kevin Ottens wrote:
> On Saturday 31 October 2009 02:12:19 David Hubner wrote:
> > 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.
> 
> I'm not sure what you mean by "hardware profiles per PC" here? Care to 
> enlighten me?
>  

I was thinking of it possibly being used to identify a users PC for configuration possibilities
instead of per user. I admit i thought of this as i was typing the mail so it isn't a well thought
out idea :)

> > >> 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.
> 
> Well, I see that as valuable information to show to the user on the workspace 
> side, still I meant "use case for an application in general" (for instance I 
> doubt a file manager, a picture collection browser, etc. would have any need 
> for such fine grained information).
> 
> That's why we have the solid::control namespace in kdebase, for apps which do 
> some finer grained tasks, like the upcoming replacement for knetworkmanager 
> that Will is working on, etc.
> 

In a general use case i can see why it would not be useful. I admit i am a little in the dark here, 
I cannot find any API docs on Solid::Control or the classes in the source in 4.3,
is it being introduced into 4.4? 

> > 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
> 
> Did you look at KDeviceListModel in kfile btw? Might prove useful, and you 
> could still subclass it or layer a QSortFilterProxyModel on top of it.
>  
> > 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=113
> > 365&PHPSESSID=9c45e78225170ac5e9b5f5ad54af1d79
> > 
> > I am hoping it shall grow as solid grows.
> 
> OK, I've been toying with something similar (albeit not as advanced than your) 
> in my own personal sandbox, you might want to take a look at it in case some 
> stuff could be useful (somehow doubt it but who knows): it is in 
> branches/work/~ervin/solidhardwarebrowser
> 
> I admit that toying with it I'm unsure in which way we should complete the 
> Solid API to enabled such an app without making such API a complete monster 
> containing classes and methods tailored only for this one app. That's still an 
> open point, although solid::control helped a lot in this regard so far.
> 
> Regards.
> 

Thanks i shall have a look at that :) 

-- 
David Hubner
IRC: Kirsan
MSN: hubnerd at hubnerd.org
ICQ: 24308559


More information about the Kde-hardware-devel mailing list