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

[Lukáš Tinkl]

Dne 12.10.2012 19:01, Kevin Ottens napsal(a):
> 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.
>

Yup, after thinking (finally ;) about it, I tend to fix description as well. And udisks2 
isn't any better in this regard, quite the opposite :/


-- 
Lukáš Tinkl
KDE developer <lukas at kde.org>