QContactDetailFieldDefinition? Can I add custom fields to existing details? how?

[felipecrochik]

QContactDetailFieldDefinition was on the technology preview but I can't find on the 1.0 documentation. Is there a way to add custom details or fields to existing custom details?

The white paper for the qt mobility 1.0 even has a example but it depends on the QContactDetailFieldDefinition.

If it is possible, does the maemo5 backend currently support it?

Thanks,
Felipe

[gnuton]

Hi Felipe,
QContactDetailFieldDefinition is still available in the 1.0.0 docs(http://doc.qt.nokia.com/qtmobility-1...efinition.html)

What are you going to do? The Maemo5 backend doesn't manage yet new Fields added by dvelopers.
Feel free to open a suggestion into JIRA.

Problem is that the M5 contacts engine need to know the VCard where saving the data as well as
the attribute parameters.
Versit modules needs those too in order to export correctly QContacts to a file.

[felipecrochik]

QContactDetailFieldDefinition is still available in the 1.0.0 docs(http://doc.qt.nokia.com/qtmobility-1...efinition.html)

Found the issue: The qt mobility whitepaper example uses "QContactDetailDefinitionField" and not "QContactDetailFieldDefinition". I copied from there and that is why I couldn't find on the api docs.
"
....
QContactDetailDefinitionField newField;
newField.setDataType(QVariant::String);
QMap<QString, QContactDetailDefinitionField> fields = modified.fields();
fields.insert(”Label”, newField);
....
"
(Qt Mobility White Paper page #7)

What are you going to do? The Maemo5 backend doesn't manage yet new Fields added by dvelopers.

My first goal was to implement grouping. I assume I can just add an "extra" notes detail to each contact for now. Do you have any better ideas?

Feel free to open a suggestion into JIRA.

Is the url still the same? I can't access http://bugreports.qt.nokia.com since yesterday.

[gnuton]

Found the issue: The qt mobility whitepaper example uses "QContactDetailDefinitionField" and not "QContactDetailFieldDefinition". I copied from there and that is why I couldn't find on the api docs.
"
....
QContactDetailDefinitionField newField;
newField.setDataType(QVariant::String);
QMap<QString, QContactDetailDefinitionField> fields = modified.fields();
fields.insert(”Label”, newField);
....
"
(Qt Mobility White Paper page #7)



My first goal was to implement grouping. I assume I can just add an "extra" notes detail to each contact for now. Do you have any better ideas?

You can use a QContact has group then create relations between the group contact and other ones.

Is the url still the same? I can't access http://bugreports.qt.nokia.com since yesterday.

It looks down. URL should not be changed.

[felipecrochik]

You can use a QContact has group then create relations between the group contact and other ones.

Am I missing something obvious? The code bellow makes me believe that the backend for maemo5 does not support Groups or Relationships:

    QContactManager manager;
    qDebug() << "Groups: " << manager.hasFeature(QContactManager::Groups);
    qDebug() << "Relationships: " << manager.hasFeature(QContactManager::Relationships);
    foreach (QString type, manager.supportedContactTypes()) qDebug() << type;

[gnuton]

Hops! You are using Maemo5. That backend doesn't support them.
Maybe relationships will be enabled in order to group contacts that comes from the SIM.

Why do you want to group contacts togheter? What are you going to do?

[felipecrochik]

I have created a home applet that will show contacts in different groups (home, family, work, ...) and also was looking to implement a ring by group feature. Is there a plan to have the backend for maemo5 "upgraded" to support more features? what about making the search quicker? Would be possible to use the fetch hints to tell the backend to not worry about anything but contact id and displayLabel? I would assume this would be MUCH quicker than right now.

I would love to poke around the backend code so I can have a better appreciation of what can it do and its constraints... Any hints on where I should look for and how to make my applications use it on an alternative location? I can't figure out how to tell qmake to use an alternative location for the mobility include and libs (I cloned the git repository, compiled it to a different "prefix" and was hoping I could easily compile/control my application to use the alternative version on a different folder)

By the way, in case you haven't seen it, I have already release a first attempt of application using the qt mobility contacts package: http://talk.maemo.org/showthread.php?t=55513

[gnuton]

I think you should be able to do whatever you want with the retrieved contacts. I mean you can retrieve those with the maemo5 engine, you can addrelations to those, but in that case
you cannot save those into the Maemo5 backend anymore. If you try to save them, the engine will complain about the unsupported relationships.
The engines validate the contacts before to save them.

Yes there are plan to improve the Maemo5 backend already. But to be sure things you need are fixed or added , you have to report bugs and or suggestions to JIRA....
Mobility 1.0.1 fixes some things but not yet those things. Online Details works correctly within the latest git snapshot.

Mobility API is changed and it's still evolving... so you have to rebuild your binary to make sure it works correctly.
I think it's a bit difficult to have 2 version of Mobility since you have plugins in the same place.

Explanation:
IIRC applicaitons are linked agaisnt libQtContacts.1 then you can build your app so that it's linked against libQtContacts.experimental.1 but the problem is that
you cannot do so much for the plugins. The Maemo5 backend is a plugins that lives in /usr/bin/qt4/plugins/contacts... so this means that you can have just 1 version
of the Maemo5 backend in your environment. You have to change the path where the engine manager looks for the plugins... if you want to have 2 versions.

Anyway the fastest way is creating a bash script that moves the libs (libQtContacts and the plugin)..

[felipecrochik]

LATE EDIT: I figured out that the best way (if not the only) to have the new "version" coexist with the old one is to just compile the backend with a different manager name and change my application to use this new name. It seems to work w/o problems and will not affect the other applications using the "default" manager I assume.

This was my original message in case you have something to add/comment:

Antonio,
It used configure -prefix to create the packages in a opt sub folder and everything seems that could work just fine. I don't know why but if I remove the libqtm-contact from scratchbox it finds by itself my "alternative" version of the mobility packages on the opt folder and uses it. On the device pretty much works the same way: if I remove the "standard" libqtm-contact package my application find the "alternative" on the opt folder. Of course I don't want to have to uninstall the libqtm-contact package from my phone.

Is there a way to actually tell qmake where to look first for the contact lib? I could change the Makefile but it seems that it must be a smarter way....

I thought the location of the qt libraries was "hardcoded" during the compilation but it does not seem so. If I have my "alternative" libs on the opt sub folder I used during the compilation and the standard mobility libs the application uses the standard. If I remove the standard from the device it finds my alternative one. Is there a way to control this at compilation or runtime? I am not positive but it seems to only happen with the contacts lib (not with the multimedia). My application gets the multimedia from the opt folder even when I have the libqtm-multimedia installed.

I looked into the source code and the program will use QTM_PLUGIN_PATH to control where the application will look for plugins first but it seems that some other process will load the one on usr/lib/qt4/plugin/contacts first and then will not load the other one because it has the same name. I guess the whole thing was not created to support parallel versions unfortunately. Do you have any idea of timeframe for a new release of the mobility packages? weeks, months,... ?

I tried the application with the new libraries and several of the bugs were fixed already. I would like to be able to figure a way to use them in an alternative location until a new official release happens.

By the way: thanks for all the help so far. It seems that no matter what path I take I always end up talking to you and you have the answers

[gnuton]

Hi felipe,
If you change the name of the manager, you have to change the name of the file as well, since you cannot have 2 files with the same dir in (/usr/lib/qt4/plugins/contacts).
All plugins in that directory are loaded.. so that's should be okay.

You have the new mobility libs in /opt.. that's okay. Now what you need is build the binary with those libs and hard-coding the path of those in the app binary.
Yep, you have to override the runtime search path so that when you launch the app it doesn't link against the old libs.
To hard-code the path of the libraries into the executable put LIBS += -R in the .pro file of your application. (-R = RPATH).

Another thing you have to do is link your app to the new libs. Well, your application project file fills the LIBS variable according to the mobility mkspecs (/usr/share/qt4/mkspecs/features/mobility.prf).
You can create a new target in that file.. but the dirty but the faster solution is set the LIBS and the INCLUDE vars in your project file so that you override the default libs and include files.
eg:"LIBS += bla bla" becomes "LIBS = -R -L/path/to/libs -lLibs"

[felipecrochik]

Antonio,
Great! Thank you again.
Am I wrong to assume that the two versions (the official and mine based on the git snapshot) are binary compatible? I imagine not many changes/fixes happened on the libQtContacts file and so far it seems that by just using the "new" manager and compiling againt the official version I will be fine.

Felipe

[gnuton]

Anotonio,
Great! Thank you again.
Am I wrong to assume that the two versions (the official and mine based on the git snapshot) are binary compatible? I imagine not many changes/fixes happened on the libQtContacts file and so far it seems that by just using the "new" manager and compiling againt the official version I will be fine.

Felipe

Actually I faced some problem mixing the lib/application/plugins compiled with different contacts versions.. I suggest you to don't mix them... anyway problems were not related to ABI breaks but there were some strange behaviors when the back-end tried to fetch the contacts..