[Kde-hardware-devel] Meaningful names in Device::description

[Kevin Ottens]

On Wednesday 03 October 2012 13:19:42 Alex Fiestas wrote:
> Last weekend I patched up 3 pieces of software adding the following logic:
> 
> On pluggable/removeable devices, use Device::Product, if not use
> Description.
> 
> The idea is to show the product name for things like cd-drivers or
> pendrives.

Be careful with it though, won't work in all cases. For cd-drivers or 
pendrives you might not get what you expect from the product name.
 
> In reviewboard Kevin pointed out that would be better to add this logic into
> UDev/UDisk backend, he said that HAl had something like that.
> 
> Looking at the code, both backends share pretty much the same code to get
> meaningful content, links:
> 
> http://goo.gl/V403j
> http://goo.gl/NblUl
> 
> And it doesn't seem that neither of them is showing product() for the
> usecase mentioned before.

Right, I confused a bit the discussion the last time. Let's me try again to 
get it properly this time. The point is that we already have complex 
implementations for description(). For instance for the storage cases we look 
at both the drive and the volume to devise a proper string. I see no problem 
in doing that with other devices... for instance climbing up the device tree 
internally to locate the product name if we know that a storage volume is in 
fact something shared by a phone via UMS. It's much more friendly to show "N9 
disk" for instance than the generic stuff we're doing at the moment (we do it 
that way because the product name of a fixed disk is rather uninteresting)... 
we never got to the point of doing it reliably (hence the "generic by 
default").

And that's why I said "be careful" above... Product and vendor names might not 
end up being what you expect. I remember horrible names like "ST825674" in my 
places list in the early days... I don't know if UDisks2 is any better in that 
regard though, that's why I proposed this logic to be per backend.

> We need to find a short-term solution applicable to 4.9.3 and 4.10.
> 
> Personally, I have mixed feelings on patching description, since description
> should be "more than one word" indicating some specifications from the
> device instead of the product name.
> 
> In the future, we can add Device::friendlyName or something like that, but
> that's libsolid2 material.

Urgh, no... That was the intent of description() to be this friendly name 
(maybe the name isn't the best though). It's a way for developers to have 
quickly something to put in front of the user, if they want something finer 
then they can start using other methods, introspecting and so on.

If description() returns something extremely generic while it could return 
something more useful then it should I think.

> So, what do we do? do we patch description or we patch the software using
> us?

Definitely patch description IMO.

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: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20121012/3409cfc0/attachment.sig>