Re: [MeeGo-dev] QtContacts/KCal-EDS
On Fr, 2011-05-20 at 13:45 +0100, Christophe Dumez wrote: To be honest, I'd rather see the hash support *fixed* rather than removed. Hi, In response to David Woodhouse's feedback, please find attached a patch for QtContacts-EDS that implements thread-safe and collision-safe ID hashing to bring compatibility with unpatched EDS (that uses string ids). I would appreciate if you could review it before I merge the change. These collision-safe hash IDs are not necessarily stable across reopening QtContacts, are they? What I mean is this: 1. Contact A and B have string IDs A and B whose hashes collide. 2. Contact A gets integer ID 1, B gets 2 (after detecting the collision). 3. App stores ID 2 and quits. 4. Contact A gets deleted by someone else (or even the app itself). 5. App restarts. 6. There's no hash collision anymore, so now contact B has integer ID 1 = app gets confused because IDs changed. I believe the only way to solve this is to introduce a permanent storing of the in-memory hash, with all the complications that this introduces (multiple processes need to maintain it collaboratively). I suspect that this can only be done reliably in the EDS server. The other conceptual problem with the patch is the compile time choice between hashing on and off. This needs to be a runtime check, so that depending on whether we use a local file backend or something else the right ID handling will be used. This in turn depends on the IDs are 32 bit capability check that we were discussing with the EDS developers - that still needs to be added to EDS. -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
These collision-safe hash IDs are not necessarily stable across reopening QtContacts, are they? What I mean is this: 1. Contact A and B have string IDs A and B whose hashes collide. 2. Contact A gets integer ID 1, B gets 2 (after detecting the collision). 3. App stores ID 2 and quits. 4. Contact A gets deleted by someone else (or even the app itself). 5. App restarts. 6. There's no hash collision anymore, so now contact B has integer ID 1 = app gets confused because IDs changed. I believe the only way to solve this is to introduce a permanent storing of the in-memory hash, with all the complications that this introduces (multiple processes need to maintain it collaboratively). I suspect that this can only be done reliably in the EDS server. You are right and I knew when implementing that this could be a problem. I chose not to handle it because it requires permanent storing (as you said) and maintaining this mapping can be tricky, especially because the apps are not required to go through QtContacts to interact with EDS. We also need to remember that the problem only occurs if there is a hashing collision and if the apps require the contact local id to me persistent upon restart (meaning that they store the local ids for some reason). Considering there is a very easy and efficient fix for EDS, this seems a bit overkill IMHO. The other conceptual problem with the patch is the compile time choice between hashing on and off. This needs to be a runtime check, so that depending on whether we use a local file backend or something else the right ID handling will be used. This in turn depends on the IDs are 32 bit capability check that we were discussing with the EDS developers - that still needs to be added to EDS. I don't believe this is the right solution. Doing the check at runtime, would of course be more reliable but it would also be less efficient. I believe that a better fix for this would be to edit your 32bits IDs patch for EDS so that it adds -DUSE_32BIT_IDS to libebook-1.2.pc. This way, I could easily detect that at compilation time in QtContacts-EDS. It would be reliable and efficient. What do you think? Kr, Christophe Dumez. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] QtContacts: Switch to evolution-data-server
Hi, Our EDS packages have been in the devel:meego-ux repository for about a week now but we did not get much feedback. QtContacts was still using tracker as backend by default and app developers would need to explicitly force the use of EDS in their code. To avoid this and to help testing the EDS backend for QtContacts, I have just pushed a patched version of qt-mobility to devel:meego-ux repository that uses EDS as default backend. If all goes well, you should not notice any difference with the new backend. Please contact me if you experience any problem with it. Kind regards, Christophe Dumez. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: These collision-safe hash IDs are not necessarily stable across reopening QtContacts, are they? [...] You are right and I knew when implementing that this could be a problem. I chose not to handle it because it requires permanent storing (as you said) and maintaining this mapping can be tricky, especially because the apps are not required to go through QtContacts to interact with EDS. We also need to remember that the problem only occurs if there is a hashing collision and if the apps require the contact local id to me persistent upon restart (meaning that they store the local ids for some reason). I believe that QtContact IDs are meant be stable across restarts. Syncing based on the QtContacts API relies on that, for example (both Buteo and SyncEvolution). We might get away with it with the current set of apps using QtContacts, but there is no guarantee that it will work with all apps. Considering there is a very easy and efficient fix for EDS, this seems a bit overkill IMHO. The goal is to have this working in MeeGo with other EDS backends. David's use case was the Exchange Web Services backend. Whether that'll work in practice depends on other factors, too, like how well these backends support storing arbitrary X- extensions and their filtering support. But without hashing, it won't work at all. The other conceptual problem with the patch is the compile time choice between hashing on and off. This needs to be a runtime check, so that depending on whether we use a local file backend or something else the right ID handling will be used. This in turn depends on the IDs are 32 bit capability check that we were discussing with the EDS developers - that still needs to be added to EDS. I don't believe this is the right solution. Doing the check at runtime, would of course be more reliable but it would also be less efficient. See above. With EDS, we cannot make compile time assumptions about the backend. I believe that a better fix for this would be to edit your 32bits IDs patch for EDS so that it adds -DUSE_32BIT_IDS to libebook-1.2.pc. This way, I could easily detect that at compilation time in QtContacts-EDS. It would be reliable and efficient. What do you think? That would be wrong because libebook might be used to access a non-file backend. -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mon, 06 Jun 2011 10:36:22 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: snip I believe that QtContact IDs are meant be stable across restarts. Syncing based on the QtContacts API relies on that, for example (both Buteo and SyncEvolution). We might get away with it with the current set of apps using QtContacts, but there is no guarantee that it will work with all apps. QContactId is just manager uri + QContactLocalId. QContactLocalId should not be stored by programs, because it can change from one run to another. For synchronization purposes, you might want to consider using QContactGuid. snip Cheers Adrien ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mo, 2011-06-06 at 11:55 +0100, Adrien Bustany wrote: On Mon, 06 Jun 2011 10:36:22 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: snip I believe that QtContact IDs are meant be stable across restarts. Syncing based on the QtContacts API relies on that, for example (both Buteo and SyncEvolution). We might get away with it with the current set of apps using QtContacts, but there is no guarantee that it will work with all apps. QContactId is just manager uri + QContactLocalId. QContactLocalId should not be stored by programs, because it can change from one run to another. For synchronization purposes, you might want to consider using QContactGuid. snip Oh, that's good to know. Thanks for clarifying this. I don't remember where I got the (wrong) idea from. Too much exposure to EDS, I suppose, where the IDs are stable ;-} -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mo, 2011-06-06 at 13:34 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 11:55 +0100, Adrien Bustany wrote: On Mon, 06 Jun 2011 10:36:22 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: snip I believe that QtContact IDs are meant be stable across restarts. Syncing based on the QtContacts API relies on that, for example (both Buteo and SyncEvolution). We might get away with it with the current set of apps using QtContacts, but there is no guarantee that it will work with all apps. QContactId is just manager uri + QContactLocalId. QContactLocalId should not be stored by programs, because it can change from one run to another. For synchronization purposes, you might want to consider using QContactGuid. snip Oh, that's good to know. Thanks for clarifying this. I don't remember where I got the (wrong) idea from. Too much exposure to EDS, I suppose, where the IDs are stable ;-} Hmm, I wonder whether app developers are aware of this. It implies that passing QContactId between processes is not correct, because these IDs are only valid inside the process. Connie, how are contacts references inside the MeeGo UX (for things like show contact XYZ)? QContactId or QContactGuid? -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
Whether that'll work in practice depends on other factors, too, like how
well these backends support storing arbitrary X- extensions and their
filtering support. But without hashing, it won't work at all.
The other conceptual problem with the patch is the compile
time choice
between hashing on and off. This needs to be a runtime
check, so that
depending on whether we use a local file backend or something
else the
right ID handling will be used. This in turn depends on the
IDs are 32
bit capability check that we were discussing with the EDS
developers -
that still needs to be added to EDS.
I don't believe this is the right solution. Doing the check at
runtime, would of course be more reliable but it would also be less
efficient.
See above. With EDS, we cannot make compile time assumptions about the
backend.
I believe that a better fix for this would be to edit your 32bits IDs
patch for EDS so that it adds -DUSE_32BIT_IDS to libebook-1.2.pc.
This way, I could easily detect that at compilation time in
QtContacts-EDS. It would be reliable and efficient. What do you think?
That would be wrong because libebook might be used to access a non-file
backend.
Hi,
Good point, I overlooked this possibility. In that case, I completely agree
that checking the ID format at run-time is the only solution.
I'm attaching a patch for this, I would appreciate if you could review it.
Kr,
--
Dr. Christophe Dumez
Linux Software Engineer
Intel Finland Oy - Open Source Technology Center
From 40a1d868dbc1075c25f00fe3e6411ca785fa7860 Mon Sep 17 00:00:00 2001
From: Christophe Dumez christophe.du...@intel.com
Date: Mon, 6 Jun 2011 14:39:54 +0300
Subject: [PATCH] ID Hashing: Detect EDS contact ID format at run-time
Detect if EDS uses 32 bit integers for contact IDs at run-time and
switch to ID hashing if necessary. With this patch, it is no longer
necessary to indicate which ID format to use at compilation time.
---
engine/engine.pro|5 --
engine/qcontactebook.cpp | 93 --
engine/qcontactebook_p.h | 19 +
3 files changed, 68 insertions(+), 49 deletions(-)
diff --git a/engine/engine.pro b/engine/engine.pro
index 8afa2ce..100d581 100644
--- a/engine/engine.pro
+++ b/engine/engine.pro
@@ -9,11 +9,6 @@ CONFIG += mobility link_pkgconfig
MOBILITY = contacts versit
PKGCONFIG += libebook-1.2
-# ID hashing is required with unpatched EDS
-# because EDS uses string IDS and we need
-# 32 bit integers
-# DEFINES += USE_ID_HASHING
-
# Enable this optimization if this version of EDS
# supports optional/delayed vCard parsing in EBookView
DEFINES += OPTIONAL_VCARD_PARSING
diff --git a/engine/qcontactebook.cpp b/engine/qcontactebook.cpp
index 1448210..f5c5bff 100644
--- a/engine/qcontactebook.cpp
+++ b/engine/qcontactebook.cpp
@@ -51,6 +51,7 @@
#include qcontactdetails.h
#include libebook/e-vcard.h
#include qcontactebook_p.h
+#include qebookidhash.h
#include customproperties.h
/* Error handling Macros */
@@ -74,11 +75,17 @@ static const QString EBookFileIDPrefix = pas-id-;
QString QContactEBook::QContactLocalId2UID(const QContactLocalId contactId) const
{
-#ifdef USE_ID_HASHING
- return m_idHash.value(contactId);
-#else
- return EBookFileIDPrefix + QString(%1).arg(contactId, 4, 16/*base*/, QChar('0')).toUpper();
-#endif
+ switch (m_edsIdFormat) {
+ case EDS::INTEGER:
+return EBookFileIDPrefix + QString(%1).arg(contactId, 4, 16/*base*/, QChar('0')).toUpper();
+ case EDS::STRING:
+Q_ASSERT (m_idHash);
+return m_idHash-value(contactId);
+ default: // Unknown
+qWarning() Warning: QContactLocalId2UID() cannot not be called before any contact is retrieved!;
+qWarning() Warning: Returning an empty UID...;
+return QString();
+ }
}
/**
@@ -87,16 +94,31 @@ QString QContactEBook::QContactLocalId2UID(const QContactLocalId contactId) con
*/
QContactLocalId QContactEBook::UID2QContactLocalId(const QString uid) const
{
-#ifdef USE_ID_HASHING
- return m_idHash.value(uid);
-#else
- // Input validation
static QRegExp pasid_validator(^+EBookFileIDPrefix+[0-9a-f]{4}$, Qt::CaseInsensitive);
- if (!pasid_validator.exactMatch(uid))
-return 0;
- // The following returns 0 if the conversion fails
- return uid.right(4).toUInt(0, 16/*base*/);
-#endif
+
+ switch (m_edsIdFormat) {
+ case EDS::INTEGER:
+// Input validation
+if (pasid_validator.exactMatch(uid)) {
+ // The following returns 0 if the conversion fails
+ return uid.right(4).toUInt(0, 16/*base*/);
+} else {
+ return 0;
+}
+ case EDS::STRING:
+Q_ASSERT (m_idHash);
+return m_idHash-value(uid);
+ default:
+// Unknown format, auto-detect
+if (pasid_validator.exactMatch(uid)) {
+ m_edsIdFormat = EDS::INTEGER;
+} else {
+ m_edsIdFormat = EDS::STRING;
+ // Initialize local id hash
Re: [MeeGo-dev] QtContacts: Switch to evolution-data-server
On Mo, 2011-06-06 at 11:02 +0100, Dumez, Christophe wrote: I understood from Patrick's earlier comments, that the EDS change would just work without the need to patch Qt mobility. Does not seem to case now? Patrick was hoping it would be possible to use EDS by default without patching qt-mobility. I looked into it but it does not seem to be possible (It explicitly uses tracker in the project file and the code would fallback to the memory backend if tracker is not installed). So patching qt-mobility seems to be the way to go (it is just a compile-time DEFINE is a project file). The approach that I suggested after Chris found this snag is the following: * QtMobility will be compiled with QtContacts-EDS as default engine, to ensure that it is used when multiple engines are installed (already done in devel:meego-ux). This is the kind of preferred treatment that Tracker enjoyed so far. * The memory engine will be packaged separately and thus not be installed by default (not done yet). That way it is possible to switch back and forth between EDS and Tracker without recompiling QtMobility or apps: * To use Tracker, ensure that it is the only installed engine. * To use EDS, install QtContacts-EDS. One (unlikely) downside is that the memory backend will not be installed anymore. That might be even be an advantage (smaller images) because I don't think anyone really needs it (more a proof-of-concept than a real engine?!). Explicitly picking a manager of course always works in apps. -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts: Switch to evolution-data-server
On Mo, 2011-06-06 at 13:52 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 11:02 +0100, Dumez, Christophe wrote: I understood from Patrick's earlier comments, that the EDS change would just work without the need to patch Qt mobility. Does not seem to case now? Patrick was hoping it would be possible to use EDS by default without patching qt-mobility. I looked into it but it does not seem to be possible (It explicitly uses tracker in the project file and the code would fallback to the memory backend if tracker is not installed). So patching qt-mobility seems to be the way to go (it is just a compile-time DEFINE is a project file). The approach that I suggested after Chris found this snag is the following: * QtMobility will be compiled with QtContacts-EDS as default engine, to ensure that it is used when multiple engines are installed (already done in devel:meego-ux). This is the kind of preferred treatment that Tracker enjoyed so far. * The memory engine will be packaged separately and thus not be installed by default (not done yet). Chris told me that my cunning plan doesn't work because the memory engine isn't provided as a separate plugin as I thought. So the fallback plan has to be to extend the default order of engines: first EDS (at least on MeeGo, to align with the architecture), then Tracker, then the rest. Chris is working on it. IMHO QtContact should have a configuration mechanism for these priorities instead of hard-coding them. -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts: Switch to evolution-data-server
Hi,
I fixed my patch for the qt-mobility package so that tracker is used as
fallback if the qtcontacts-eds package is not installed (patch attached).
I have just uploaded the fixed package to devel:meego-ux.
Note that qt-mobility has a build dependency on qttracker at the moment for
some reason. I did not remove it.
I did not add qtcontacts-eds as a run-time dependency either because we want
to be able to remove it.
A clean solution for this would be to use package Provides and make
qt-mobility depend on the meta-package provided by qtcontacts-tracker and
qtcontacts-eds (e.g. qtcontacts-backend).
Unfortunately, this would certainly require to update the qtcontacts-tracker
packaging.
Kr,
Chris.
On Mon, Jun 6, 2011 at 3:10 PM, Robin Burchell virot...@viroteck.netwrote:
On 6 June 2011 13:03, Patrick Ohly patrick.o...@intel.com wrote:
IMHO QtContact should have a configuration mechanism for these
priorities instead of hard-coding them.
I'd agree, and it shouldn't be that hard to do, surely. Might be worth
opening a bug for so it doesn't get forgotten?
--
Robin Burchell
http://rburchell.com
--
Dr. Christophe Dumez
Linux Software Engineer
Intel Finland Oy - Open Source Technology Center
From e87aab8ccd9507b0a1456a97c8c0eb33826e89fb Mon Sep 17 00:00:00 2001
From: Christophe Dumez christophe.du...@intel.com
Date: Mon, 6 Jun 2011 15:06:07 +0300
Subject: [PATCH] contacts: Use eds as default engine and tracker and fallback
Use EDS as default backend for contacts if present, fallback
to tracker otherwise.
---
src/contacts/contacts.pro|3 ++-
src/contacts/qcontactmanager.cpp |7 +++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/contacts/contacts.pro b/src/contacts/contacts.pro
index 72bee8e..39e9e17 100644
--- a/src/contacts/contacts.pro
+++ b/src/contacts/contacts.pro
@@ -91,7 +91,8 @@ maemo5 {
}
maemo6|meego {
-isEmpty(CONTACTS_DEFAULT_ENGINE): CONTACTS_DEFAULT_ENGINE=tracker
+isEmpty(CONTACTS_DEFAULT_ENGINE): CONTACTS_DEFAULT_ENGINE=eds
+isEmpty(CONTACTS_FALLBACK_ENGINE): CONTACTS_FALLBACK_ENGINE=tracker
}
diff --git a/src/contacts/qcontactmanager.cpp b/src/contacts/qcontactmanager.cpp
index 2380b22..1ef52a7 100644
--- a/src/contacts/qcontactmanager.cpp
+++ b/src/contacts/qcontactmanager.cpp
@@ -144,6 +144,13 @@ QStringList QContactManager::availableManagers()
QContactManagerData::loadFactories();
ret.append(QContactManagerData::m_engines.keys());
+// Move the fallback engine to second position
+#if defined(Q_CONTACTS_FALLBACK_ENGINE)
+if (ret.removeAll(QLatin1String(makename(Q_CONTACTS_FALLBACK_ENGINE {
+ret.prepend(QLatin1String(makename(Q_CONTACTS_FALBACK_ENGINE)));
+}
+#endif
+
// now swizzle the default engine to pole position
#if defined(Q_CONTACTS_DEFAULT_ENGINE)
if (ret.removeAll(QLatin1String(makename(Q_CONTACTS_DEFAULT_ENGINE {
--
1.7.4.4
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Local 'osc build' do fail at the moment
Hi list, one of the server has some trouble with missing disk space at the moment. This will break your 'osc build' of a MeeGo project on your local machine with strange python messages. Some people do care on this issue at the moment (#meego-arm IRC channel). cheeers Maurice ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mon, 06 Jun 2011 13:38:29 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 13:34 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 11:55 +0100, Adrien Bustany wrote: On Mon, 06 Jun 2011 10:36:22 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: snip I believe that QtContact IDs are meant be stable across restarts. Syncing based on the QtContacts API relies on that, for example (both Buteo and SyncEvolution). We might get away with it with the current set of apps using QtContacts, but there is no guarantee that it will work with all apps. QContactId is just manager uri + QContactLocalId. QContactLocalId should not be stored by programs, because it can change from one run to another. For synchronization purposes, you might want to consider using QContactGuid. snip Oh, that's good to know. Thanks for clarifying this. I don't remember where I got the (wrong) idea from. Too much exposure to EDS, I suppose, where the IDs are stable ;-} Hmm, I wonder whether app developers are aware of this. It implies that passing QContactId between processes is not correct, because these IDs are only valid inside the process. Connie, how are contacts references inside the MeeGo UX (for things like show contact XYZ)? QContactId or QContactGuid? Hmm that would still be correct I guess, but you'd have to check with the mobility developers... I wouldn't expect the DB to change the ids for one same contact from one program to another, but I wouldn't expect the DB to keep local ids valid from one DB session to another (for example with Tracker, we sometimes have to rebuild the DB if the schema changed → IDs can be invalidated). Also, I'm not totally sure if QContactGuid is mandatory, if not it makes things even more tricky :/ Cheers Adrien ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mo, 2011-06-06 at 15:02 +0100, Adrien Bustany wrote: On Mon, 06 Jun 2011 13:38:29 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 13:34 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 11:55 +0100, Adrien Bustany wrote: On Mon, 06 Jun 2011 10:36:22 +0200, Patrick Ohly wrote: On Mo, 2011-06-06 at 08:41 +0100, Dumez, Christophe wrote: snip I believe that QtContact IDs are meant be stable across restarts. Syncing based on the QtContacts API relies on that, for example (both Buteo and SyncEvolution). We might get away with it with the current set of apps using QtContacts, but there is no guarantee that it will work with all apps. QContactId is just manager uri + QContactLocalId. QContactLocalId should not be stored by programs, because it can change from one run to another. For synchronization purposes, you might want to consider using QContactGuid. snip Oh, that's good to know. Thanks for clarifying this. I don't remember where I got the (wrong) idea from. Too much exposure to EDS, I suppose, where the IDs are stable ;-} Hmm, I wonder whether app developers are aware of this. It implies that passing QContactId between processes is not correct, because these IDs are only valid inside the process. Connie, how are contacts references inside the MeeGo UX (for things like show contact XYZ)? QContactId or QContactGuid? Hmm that would still be correct I guess, but you'd have to check with the mobility developers... I wouldn't expect the DB to change the ids for one same contact from one program to another, But that's the same situation as above: if QContactLocalId are only valid during the runtime of a program, or even only while it has the DB open, then there's no guarantee that QContactLocalId 1 in program A refers to the same contact in program B. Michael, can you clarify what the lifetime of QContactLocalId is meant to be? The documentation is silent on that matter, as far as I know. but I wouldn't expect the DB to keep local ids valid from one DB session to another (for example with Tracker, we sometimes have to rebuild the DB if the schema changed → IDs can be invalidated). Also, I'm not totally sure if QContactGuid is mandatory, if not it makes things even more tricky :/ I don't know either. -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Initrd on Kernel to mount root with UUID
On 06/04/2011 03:00 PM, Leonardo Luiz Padovani da Mata wrote: The MeeGo kernel doesn't use an initrd, to make it faster on boot, i guess. The problem i'm facing is that when i install the system on a netbook with a usb disk the order of the disks change and i have problems booting after the installation. This may not be what you want, but in fact there is a maintained initrd implementation for MeeGo on pinetrail. It's used for the isolinux install images. I actually use it, unmodified, routinely when booting from USB (which I often do on devices with an internal drive with an identical image already installed, thus confusing myself and the kernel about which root I'm looking at). It works fine, and interprets a root=UUID=... argument exactly as you would expect. For the common case, it requires no kernel modules and thus works unmodified with recompiled kernels. It's presumably the output of mkinitrd, though honestly I've never had the need to rebuild one so I can't speak to process. Obviously this usage is a development tool, not a production solution. But if you can't find a better workaround it might be adaptable. Andy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] setting TERM in environment
On 6/6/2011 9:20 AM, Robin Burchell wrote: Hi, I've been doing some cursory kicking of the tires of the (very recently released) meego-terminal (https://gitorious.org/meego-terminal/meego-terminal/), and one thing that came up pretty quick when I tried to run top was that TERM wasn't set. Who's responsibility is it to have this set? uxlaunch seems one candidate, but I don't know if that's correct? clearly each terminal has it's own values.. that the terminal program should set! \ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] setting TERM in environment
On Monday, 6 de June de 2011 17:20:57 Robin Burchell wrote:
Hi,
I've been doing some cursory kicking of the tires of the (very recently
released) meego-terminal
(https://gitorious.org/meego-terminal/meego-terminal/), and one thing
that came up pretty quick when I tried to run top was that TERM wasn't set.
Who's responsibility is it to have this set? uxlaunch seems one
candidate, but I don't know if that's correct?
The graphical terminal application itself needs to set it to the value of what
it supports.
Or do you mean in a virtual console? If you mean that, it's the kernel that
sets it:
init/main.c:const char * envp_init[MAX_INIT_ENVS+2] = { HOME=/,
TERM=linux, NULL, };
So the question turns from what failed to set it to what unset it?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] setting TERM in environment
On 06/06/2011 09:32 AM, Thiago Macieira wrote: The graphical terminal application itself needs to set it to the value of what it supports. Or do you mean in a virtual console? If you mean that, it's the kernel that sets it: Don't forget the login applications: ssh will propagate the value of TERM in the source shell for interactive logins, or set it to dumb if it's a batch session. Presumably there are similar tricks in the rlogin and telnet protocols. Andy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] setting TERM in environment
On 6 June 2011 17:28, Arjan van de Ven ar...@linux.intel.com wrote: Who's responsibility is it to have this set? uxlaunch seems one candidate, but I don't know if that's correct? clearly each terminal has it's own values.. that the terminal program should set! \ Right, in retrospect, that was a silly question. Thanks for the quick answer. -- Robin Burchell http://rburchell.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtContacts/KCal-EDS
On Mo, 2011-06-06 at 12:45 +0100, Dumez, Christophe wrote: Good point, I overlooked this possibility. In that case, I completely agree that checking the ID format at run-time is the only solution. I'm attaching a patch for this, I would appreciate if you could review it. If I get this right, the approach is if any UID doesn't contain 32 bit integer ID, start hashing. I haven't checked the details, but I assume you covered the database is empty initially, new contact gets added case as well as database already contains items cases. Now let me really play devil's advocate: what if a hypothetical backend happens to use string IDs but accidentally the first one seen by QtContacts-EDS looks like a 32 bit integer IDs? That would trick the QtContacts-EDS code into entering the INTEGER IdFormat mode incorrectly, wouldn't it? Apart from that I like the approach. I think it'll be easy to persuade me that I worry too much and that it is good enough ;-) -- 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Snowball
Hi everyone, I just received confirmation from ST-Ericsson that hardfp is supported on their Snowball dev board. I've updated the wiki accordingly. http://wiki.meego.com/ARM/Snowball Kind regards, Olivier Nyssen___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QtMobility API to support 9-axis Motion processing
@andy, michael and thiago Thanks for clarification and sorry for late reply due to holiday. As you had pointed out, what my point is exact the position API. Because of the in-accurate position info from only 6-axis (accel+gyro), some vendors had developed arithmetic which fusion the data from 9-axis and do the accurate remedy for 6-axis data, mainly from joystick and game in customer electronic industry. From the original question from Terence, I assume those vendors are meaning they had similar 'motion processing' from not only HW but also SW for accurate position identification. Now, those remedy processing should be non-opensource, so if some libraries can abstract/fusion those processing, that would be great for improving the experience, those kind of abstract can be from other components, (maybe) also can be from QT if possible. -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Andy Ross Sent: Saturday, June 04, 2011 12:22 AM To: meego-dev@meego.com Subject: Re: [MeeGo-dev] QtMobility API to support 9-axis Motion processing On 06/03/2011 05:20 AM, Thiago Macieira wrote: PS: I can't find any relevant documents on fusion arithmetic on the Internet. Can you share some links? This whole 9-axis thing is new to me too. I found a press release that uses the term, along with sensor fusion: http://cdiwebblog.wordpress.com/2011/04/27/invensense%C2%AE-unveils-smartmotion%E2%84%A2-platform-with-9-axis-motionfusion%E2%84%A2-engine/ As everyone has already pointed out: inertial navigation algorithms aren't part of a platform abstraction API. Qt Mobility doesn't provide it for the same reason that you don't find a DCT implementation in OpenGL or 3D vision algorithms in your camera driver. Andy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
