On Mo, 2011-08-29 at 11:50 +0200, Chris Kühl wrote:
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Mi, 2011-08-24 at 14:46 +0200, Chris Kühl wrote:
>> The bluetooth-device-id-merge-prep is ready to be reviewed now.
> I've merged the D-Bus server reorganization, dbus-test and
> bluetooth-device-id-merge-prep branches. I fixed some minor problems
> found with -Werror -Wall.
> Attached an updated revision of the bluetooth-device-id-inspector.py
> script. Should we maintain it in SyncEvolution?
Makes sense. Should it go in test or should we create a
At some point we should, but then we would also have to move some of the
other scripts. Let's add it to "test" to keep it simple for the time
> Chris, I suspect that I gave you wrong guidance about the use
> deviceName/peerName, or we have to extend the semantic. According to the
> D-Bus API docs:
> * deviceName: device template: the device name that the template
> is for (copied verbatim from that device)
> * templateName: device template: string identifying the class of
> devices the templates works for, like "Nokia S40"; meant to be
> shown to users; optional, fall back to first entry in
> fingerPrint if not set
> Now the syncevo-dbus-server sends deviceName=Nokia, templateName=Nokia
> and peerName=Nokia N97 mini.
> I think it should send:
> * deviceName: the vendor/model information if available, otherwise
> the user-configurable device name (can't be empty, because
> traditionally it wasn't describe as optional)
Right, I can make this change. But when you say "vendor/model is
available" you mean when the product and not *just* the vendor is in
the lookup table, right? That would make sense to me.
IMHO it would make sense also if just the vendor is available. That
information is not provided to the UI otherwise.
But see my later email: after some more thinking I came to the
conclusion that "deviceName" should stay as it is (name chosen by the
user) and the new information should go into "templateName".
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.