Jussi Kukkonen wrote: >Chen, Congwu wrote: >> Ohly, Patrick wrote: >>> On Tue, 2010-03-23 at 01:30 +0000, Chen, Congwu wrote: >>>> Ohly, Patrick wrote: >>>>> For example, suppose we have "fingerPrint = Nokia 7120c, Nokia N85". >>>>> I would find it confusing to have a "Nokia N85" and then being told by >>>>> the GUI tells me that "we think you have a Nokia 7120c". >>>> I think the GUI can still tell you "we think you have a Nokia N85, because >it >>>> is a perfect match and we know the device name is Nokia N85, though the >>>> template name is Nokia 7210c. >>> Does the GUI get enough information for this already? If yes, can you >>> describe how Jussi can implement this? If no, what needs to be changed >>> by whom? >> Yes, I think so. The temporary template has 'deviceName' and 'fingerPrint' >property >> for this two. > >Congwu, the problem is this: my phones deviceName is 'jku'. If the UI >does what you suggest we end up with: > > "We think your device is a 'jku'. If this is not correct, please > take a look at the list and select your device if you see it." No, what I suggested is only for a perfect match, as the example above. For your case, the match score will be 0 or a relatively small number, what you might present maybe: "We don't know your device or we think your device looks like.."
I agree if we have can automatically detect 'model name' for a device, we can provide much better matching capability, but this is not supported currently and need more work to do: using default device name, bluetooth profile, SymcML DevInf.... In your case, if we can detect 'jku' has a model name 'Nokia 7210c' and even have the device type 'S40', we can provide a much better matching result. >I don't think that's acceptable. If we support the phone model I have, >it would be nice if the UI told me that, but I won't do it if it lead to >UIs like that. Don't get me wrong, the current info is quite usable: I'm >fine with just showing the template name for now if the model name seems >difficult with the schedule. Yes, detection the model name for a phone would need additional work and I don't think it can get into SyncEvolution 1.0 >That said, here's my thoughts on this -- something I should probably >have written a while ago. I think this would go a long way: All >templates would have: > - template name (always) > - user identifiable device name (always, this is currently > "deviceName") > - score (always, this changes depending on the device this > template is for) > - list of all model names for this template (always) > - current model name (when available, syncevolution sets this when it > has an idea what the model is, either from BT-name or from other > future datasources, like the Bluetooth profile we discussed) I think the only missing part is 'current model name'. Get the information from BT-name seems problematic, how do you know this is a model name not a user defined name? From Bluetooth profile can help detect the model name if the phone supports and from DevInf we may even detect the type of the phone. >What this means is that a Nokia S40 phone would not get templates for >each model (like "Nokia 1234" and "Nokia 5678"), but a single S40 >template with possibly a model name set and all supported models listed. If the S40 phone has a name 'jku', model '7210c' and type 'S40': 0) If we don't know the model name of the phone (which is the current situation), we can only list all supported templates/models. 1) If we already have a template with '7210c' listed as supported models and we can detect the model name for the phone, we can show this template only, and say "we think your device is Nokia 7210c.." 2) If we don't have such thing but have a S40 template and we can further detect that the device type of the phone is S40 series, it can match to a S40 template. >From a UI perspective it's important that all these names are something >that can be shown to a user. Yes, once we really support detection for model name. Best Regards, Congwu _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
