On Mon, Aug 29, 2011 at 12:25 PM, Patrick Ohly <[email protected]> wrote: > On Mo, 2011-08-29 at 11:50 +0200, Chris Kühl wrote: >> 2011/8/26 Patrick Ohly <[email protected]>: >> > 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. >> >> Great! >> >> > >> > 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 >> tools/utilities directory? > > 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 > being. > >> > Chris, I suspect that I gave you wrong guidance about the use use of >> > 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".
Did you mean peerName instead of templateName? >From the what you are saying here... Patrick Ohly <[email protected]> wrote: >> The UI should be adapted to use peerName instead of deviceName, if >> peerName is available. That way the user would see his chosen name >> instead of the vendor/model name, which will not be unique in the >> (unlikely) case that the user has more than one. Not a big deal. >> >> We might have the inverse situation, too: multiple different devices all >> called "My Phone". I think users should (and can) avoid this, so we >> should continue to display only the chosen name instead of adding the >> vendor/model information - right? > > Given that the UI should only display the chosen name, and expects it in > "deviceName", perhaps we should keep the traditional D-Bus API semantic > unchanged and put the Device ID profile information into the "peerName"? > > That is a bit backwards (peerName is used for user-configurable strings > elsewhere), but has the advantage that no changes will be needed in the > D-Bus clients to get the desired behavior. > ... I understand the following. 1) In the case that we have no PnPInformation info we have... deviceName = User-modifiable name peerName = User-modifiable name 2) In the case that we have PnPInformation info but no product match in the lookup table we have... deviceName = User-modifiable name peerName = Vendor found in Lookup table 3) In the case that we have PnPInformation info and a product match in the lookup table we have... deviceName = User-modifiable name peerName = Vendor + " " + Product found in Lookup table Is this right? Also, the templateName was and is simply the "templateName" field from the template. The code is... string TemplateConfig::getTemplateName() { return m_metaProps["templateName"]; } Should this be different? We could create a different template for each class of phone. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
