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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
