Chen, Congwu wrote: So I'd have a device name when it's known, otherwise I'd use the template name... that would probably work, althpough it does have the same problem I mentioned: People might not know what the categories (such as "Nokia S40") mean. I think your suggestion is still better. Maybe something like this would work "We're not sure of the exact model, but this looks like a "Nokia S40" device. ...". Changes like this are going to affect UI strings so if we want to do this, let's do it ASAP. Now that I've implemented some ui elements on top of this data already, I have some additional wishes: * the names should only include manufacturer/device/platform names to avoid translation problems, so my example of "Nokia S40 phone" should actually be "Nokia S40" * the device type would be nice to have as a separate property (it is not critical though). We discussed this at some point but I don't remember whether it was implemented... Additional question: When there are templates with a score above a limit X, should I hide the lower score templates? As in, if the bluetooth device name has "Nokia" in it, does it make sense to show the "syncevolution client" template? - Jussi

Chen, Congwu wrote: Wait, there is no 'default' already, but it did got a score == 2 because: The LCS of 'SyncEvolutionClient' and 'Nokia' == 'noi', it matched something and thus got a higher score... So setting limit score ==1 does not rule out 'SyncEvolutionClient' as expected and I think we have to eat the bullet here... Best Regards, Congwu

On Mon, 2010-03-22 at 10:20 +0000, Jussi Kukkonen wrote: ... which we don't know at the moment. That's indeed the key point. Suppose we have a config template for device "Foo Bar" (fingerPrint = Foo Bar, with or without underscore - not sure what the current state is). Now we find a device which uses exactly the same config. Should we add it to that config ("extend fingerPrint") or add a second template ("new template")? Advantage of "extend fingerPrint": less templates on disk, less data to transfer via D-Bus, small list of configs to choose from in GUI Disadvantage of "extend fingerPrint": as soon we have more than one model, the first entry can no longer be a simple "Manufacturer Model" string. 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". We could go for "fingerPrint = Nokia, Nokia 7120c, Nokia N85", but that then rules out including compatible phones from other vendors (thus leading to a mixture of "extend fingerPrint" and "new template"). Anything beyond that ("Nokia-compatible") is not suitable because it wouldn't be translated. -- 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.

On Tue, 2010-03-23 at 01:30 +0000, Chen, Congwu wrote: I thought that device name != manufacturer+model? Isn't the device name something chosen by the user? There's no guaruantee that this includes either manufacturer or model. We don't need something for advanced users :-/ We need something that works for all users, as good as possible. 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? -- 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.

Chen, Congwu wrote: 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." 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. 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) 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. that can be shown to a user. UI workflow: if one template has a better score than others { if model name is set { Show "We think this is a '<modelname>'..." } else { Show "We're not sure what this device is exactly, but it looks like a '<templatename>'..." } } else { Show "We're not sure what this device is..." } for each template { if template score > 1 { # there are many possibilities here, see below for each model in templates model-list { Add '<modelname>' into a list where user can select } } } UI possibilities: Showing every model we support might be hard to support longer term (at least I hope the list will grow) and in many ways showing "S40" is relevant info for many people so it may make more sense to show the template names in the list I mention above... But as long as the list of model names the template supports is available, the UI would have the choice. This is doubly important as we get different UIs. Some options: * list every template we support, let user choose * list every model we support, let user choose * have a search interface with autocomplete for model names * combination of the above Jussi

Chen, Congwu wrote: I wasn't talking about the devices we currently support, I'm talking about the general case. There's very little point in coding UIs for just "Nokia 7210c" if it's not usable for all S40 phones we will support. This isn't about matching really (as important as it is). This is about presenting the results when we have a match. A model name would be nice there. Ok. Well, I imagine it would go like this: * Get device specific data that might help: - the BT profile - DevInf - bt name - other? * go through all templates, look for matches between the device specific data and the "supported models" list in the template * if you get a good enough hit return the "supported model" as the model name So user defined name would be used to match but would never be returned as a model name. Jussi