3:34 a.m.
Hello,
since SyncEvolution 0.9 ships with the GTK ui, I just tried it out. But
after startup, it tells me that no sync service is configured. When I go
into the configuration dialogue, it lists my account data for
ScheduleWorld, except for the password.
This surely is not top priority, but I think it would be nice if one
could run sync-ui and Genesis next to each other. So services set up in
Genesis should work in sync-ui and the other way around. So could anyone
help me find out why sync-ui doesn’t recognise the services I set up
with Genesis? Then I could adjust Genesis’ configuration mechanisms to
be compatible with sync-ui.
Cheers,
Frederik
7:06 p.m.
On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
since SyncEvolution 0.9 ships with the GTK ui, I just tried it out.
But
after startup, it tells me that no sync service is configured.
The sync-ui remembers the config that the user has selected for use in
sync-ui in a sync-ui specific gconf key. I suspect that "no sync service
configured" really means "no sync service selected" here.
When I go
into the configuration dialogue, it lists my account data for
ScheduleWorld, except for the password.
The sync-ui assumes that the password is stored in the GNOME keyring. It
currently doesn't work well with existing configurations where the
password is in the config.ini itself. I thought we had an open issue for
it (I found the same problem earlier), but I cannot find the issue.
Jussi, did we fix this?
This surely is not top priority, but I think it would be nice if one
could run sync-ui and Genesis next to each other. So services set up in
Genesis should work in sync-ui and the other way around. So could anyone
help me find out why sync-ui doesn’t recognise the services I set up
with Genesis? Then I could adjust Genesis’ configuration mechanisms to
be compatible with sync-ui.
You could use the same gconf key to select the active configuration.
Then sync-ui should work right away. Have a look at
/apps/sync-ui/server in gconf-editor.
--
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.
10:16 p.m.
Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
> since SyncEvolution 0.9 ships with the GTK ui, I just tried it out. But
> after startup, it tells me that no sync service is configured.
The sync-ui remembers the config that the user has selected for use in
sync-ui in a sync-ui specific gconf key. I suspect that "no sync service
configured" really means "no sync service selected" here.
Ok, that makes sense.
> When I go
> into the configuration dialogue, it lists my account data for
> ScheduleWorld, except for the password.
The sync-ui assumes that the password is stored in the GNOME keyring. It
currently doesn't work well with existing configurations where the
password is in the config.ini itself. I thought we had an open issue for
it (I found the same problem earlier), but I cannot find the issue.
Jussi, did we fix this?
This is of course way better in means of security. Maybe I should have a
look if I can implement this for Genesis as well (if gnome-keyring is
present, I’d like not to depend on GNOME too much). But at least for
Genesis some kind of migration would be necessary: If a password is
present in the config file, delete it there and set it in the GNOME
keyring.
I don’t have any experience with gnome-keyring, so I’ll have to see how
much work this would be. Is it even possible to access passwords across
applications (like Genesis and sync-ui)? How does syncevolution know
about the password then? Does it look for it in gnome-keyring for
itself, or do I have to pass it to syncevolution somehow?
> This surely is not top priority, but I think it would be nice if
one
> could run sync-ui and Genesis next to each other. So services set up in
> Genesis should work in sync-ui and the other way around. So could anyone
> help me find out why sync-ui doesn’t recognise the services I set up
> with Genesis? Then I could adjust Genesis’ configuration mechanisms to
> be compatible with sync-ui.
You could use the same gconf key to select the active configuration.
Then sync-ui should work right away. Have a look at
/apps/sync-ui/server in gconf-editor.
Ah, that sounds good! It makes sense to store common configuration
options in a common place.
I just have two questions:
* I think sync-ui uses the template name instead of the server
name in that option. For me, it stores "ScheduleWorld" instead
of "scheduleworld", which I used as the server name. This makes
it difficult to store more than one configuration for one server
(which is necessary, e.g., for syncing more than one calendar
with one service). Is this intended?
* In the future, it might be desirable to sync more than one
service at a time. Would it make sense to make that option a
list instead of a string?
Cheers,
Frederik
6:33 p.m.
On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
> On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
> > since SyncEvolution 0.9 ships with the GTK ui, I just tried it out. But
> > after startup, it tells me that no sync service is configured.
>
> The sync-ui remembers the config that the user has selected for use in
> sync-ui in a sync-ui specific gconf key. I suspect that "no sync service
> configured" really means "no sync service selected" here.
Ok, that makes sense.
Jussi, should we change the string?
> > When I go
> > into the configuration dialogue, it lists my account data for
> > ScheduleWorld, except for the password.
>
> The sync-ui assumes that the password is stored in the GNOME keyring. It
> currently doesn't work well with existing configurations where the
> password is in the config.ini itself. I thought we had an open issue for
> it (I found the same problem earlier), but I cannot find the issue.
> Jussi, did we fix this?
This is of course way better in means of security. Maybe I should have a
look if I can implement this for Genesis as well (if gnome-keyring is
present, I’d like not to depend on GNOME too much). But at least for
Genesis some kind of migration would be necessary: If a password is
present in the config file, delete it there and set it in the GNOME
keyring.
For that the command line needs to support GNOME keyring first, which it
currently doesn't (#3604). So the current status is:
* if the user changes the password on the sync-ui, save in GNOME
keyring with "-" as password in config.in => command line will
ask for password, breaking Genesis
* if the password is stored in config.ini, don't touch it in
sync-ui
I'm not 100% sure, but I think the second point is the fix that I was
looking. Jussi, do you know why the password is not shown in the second
case?
I don’t have any experience with gnome-keyring, so I’ll have to see
how
much work this would be. Is it even possible to access passwords across
applications (like Genesis and sync-ui)? How does syncevolution know
about the password then? Does it look for it in gnome-keyring for
itself, or do I have to pass it to syncevolution somehow?
It is looked up with a set of properties as key:
http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
Any application with access to the keyring can read and write it.
> > This surely is not top priority, but I think it would be
nice if one
> > could run sync-ui and Genesis next to each other. So services set up in
> > Genesis should work in sync-ui and the other way around. So could anyone
> > help me find out why sync-ui doesn’t recognise the services I set up
> > with Genesis? Then I could adjust Genesis’ configuration mechanisms to
> > be compatible with sync-ui.
>
> You could use the same gconf key to select the active configuration.
> Then sync-ui should work right away. Have a look at
> /apps/sync-ui/server in gconf-editor.
Ah, that sounds good! It makes sense to store common configuration
options in a common place.
I just have two questions:
* I think sync-ui uses the template name instead of the server
name in that option. For me, it stores "ScheduleWorld" instead
of "scheduleworld", which I used as the server name. This makes
it difficult to store more than one configuration for one server
(which is necessary, e.g., for syncing more than one calendar
with one service). Is this intended?
This is the configuration name. Configuration names became
case-insensitive at some point.
* In the future, it might be desirable to sync more than one
service at a time. Would it make sense to make that option a
list instead of a string?
We haven't thought about the UI for that yet. Perhaps we'll have a
meta-configuration which lists other configs, in which case a single
string would be 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.
2:35 a.m.
Am Montag, den 17.08.2009, 10:33 +0200 schrieb Patrick Ohly:
On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
> Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
> > On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
> > > since SyncEvolution 0.9 ships with the GTK ui, I just tried it out. But
> > > after startup, it tells me that no sync service is configured.
> >
> > The sync-ui remembers the config that the user has selected for use in
> > sync-ui in a sync-ui specific gconf key. I suspect that "no sync service
> > configured" really means "no sync service selected" here.
>
> Ok, that makes sense.
Jussi, should we change the string?
> > > When I go
> > > into the configuration dialogue, it lists my account data for
> > > ScheduleWorld, except for the password.
> >
> > The sync-ui assumes that the password is stored in the GNOME keyring. It
> > currently doesn't work well with existing configurations where the
> > password is in the config.ini itself. I thought we had an open issue for
> > it (I found the same problem earlier), but I cannot find the issue.
> > Jussi, did we fix this?
>
> This is of course way better in means of security. Maybe I should have a
> look if I can implement this for Genesis as well (if gnome-keyring is
> present, I’d like not to depend on GNOME too much). But at least for
> Genesis some kind of migration would be necessary: If a password is
> present in the config file, delete it there and set it in the GNOME
> keyring.
For that the command line needs to support GNOME keyring first, which it
currently doesn't (#3604). So the current status is:
* if the user changes the password on the sync-ui, save in GNOME
keyring with "-" as password in config.in => command line will
ask for password, breaking Genesis
I saved the password in sync-ui, and now it is present in the config.ini
and in gnome-keyring. So it doesn’t break in this case. But if one sets
up a sync config in sync-ui, it will probably not work in Genesis.
* if the password is stored in config.ini, don't touch it
in
sync-ui
I'm not 100% sure, but I think the second point is the fix that I was
looking. Jussi, do you know why the password is not shown in the second
case?
> I don’t have any experience with gnome-keyring, so I’ll have to see how
> much work this would be. Is it even possible to access passwords across
> applications (like Genesis and sync-ui)? How does syncevolution know
> about the password then? Does it look for it in gnome-keyring for
> itself, or do I have to pass it to syncevolution somehow?
It is looked up with a set of properties as key:
http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
Any application with access to the keyring can read and write it.
That looks nice, I’ll try to implement this in Genesis.
> > > This surely is not top priority, but I think it would
be nice if one
> > > could run sync-ui and Genesis next to each other. So services set up in
> > > Genesis should work in sync-ui and the other way around. So could anyone
> > > help me find out why sync-ui doesn’t recognise the services I set up
> > > with Genesis? Then I could adjust Genesis’ configuration mechanisms to
> > > be compatible with sync-ui.
> >
> > You could use the same gconf key to select the active configuration.
> > Then sync-ui should work right away. Have a look at
> > /apps/sync-ui/server in gconf-editor.
>
> Ah, that sounds good! It makes sense to store common configuration
> options in a common place.
>
> I just have two questions:
>
> * I think sync-ui uses the template name instead of the server
> name in that option. For me, it stores "ScheduleWorld" instead
> of "scheduleworld", which I used as the server name. This makes
> it difficult to store more than one configuration for one server
> (which is necessary, e.g., for syncing more than one calendar
> with one service). Is this intended?
This is the configuration name. Configuration names became
case-insensitive at some point.
Ok, I didn’t realise that.
> * In the future, it might be desirable to sync more than
one
> service at a time. Would it make sense to make that option a
> list instead of a string?
We haven't thought about the UI for that yet. Perhaps we'll have a
meta-configuration which lists other configs, in which case a single
string would be enough.
I’ve had this as a feature request for Genesis, but never actually
implemented it. For the time being, a string is sufficient, but it might
be worth thinking about future requirements. So if a user wants to sync
her private data with Google, and job data with eGroupWare, one would
need more than one active server.
If meta-configurations cover such cases, we probably don’t need to
discuss this here. :-)
Cheers,
Frederik
10:26 p.m.
Hi,
sorry for taking my time... Some answers below, let me know if I missed
any open issues. Frederik, feel free to file bugs in the bugzilla if you
meet interoperability problems with using Genesis and our UI.
Patrick Ohly wrote:
On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
> Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
>> On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
>>> since SyncEvolution 0.9 ships with the GTK ui, I just tried it out. But
>>> after startup, it tells me that no sync service is configured.
>> The sync-ui remembers the config that the user has selected for use in
>> sync-ui in a sync-ui specific gconf key. I suspect that "no sync service
>> configured" really means "no sync service selected" here.
> Ok, that makes sense.
Jussi, should we change the string?
Patrick filed a bug (#5660) and yes, I agree "No sync service selected"
or "No sync service in use" is better.
>>> When I go
>>> into the configuration dialogue, it lists my account data for
>>> ScheduleWorld, except for the password.
>> The sync-ui assumes that the password is stored in the GNOME keyring. It
>> currently doesn't work well with existing configurations where the
>> password is in the config.ini itself. I thought we had an open issue for
>> it (I found the same problem earlier), but I cannot find the issue.
>> Jussi, did we fix this?
Yes, I do believe this was fixed so the ui should be able to sync even
with password in the config file. The password isn't visible in the
dialog though (see below).
> This is of course way better in means of security. Maybe I should
have a
> look if I can implement this for Genesis as well (if gnome-keyring is
> present, I’d like not to depend on GNOME too much). But at least for
> Genesis some kind of migration would be necessary: If a password is
> present in the config file, delete it there and set it in the GNOME
> keyring.
For that the command line needs to support GNOME keyring first, which it
currently doesn't (#3604). So the current status is:
* if the user changes the password on the sync-ui, save in GNOME
keyring with "-" as password in config.in => command line will
ask for password, breaking Genesis
* if the password is stored in config.ini, don't touch it in
sync-ui
I'm not 100% sure, but I think the second point is the fix that I was
looking. Jussi, do you know why the password is not shown in the second
case?
Password is not currently transmitted via D-Bus... It probably should be
at least when we update the config api. Nothing gets broken though: If
you do set a password with the ui, keyring will be used but otherwise
the password won't be touched.
> I don’t have any experience with gnome-keyring, so I’ll have to
see how
> much work this would be. Is it even possible to access passwords across
> applications (like Genesis and sync-ui)? How does syncevolution know
> about the password then? Does it look for it in gnome-keyring for
> itself, or do I have to pass it to syncevolution somehow?
It is looked up with a set of properties as key:
http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
Any application with access to the keyring can read and write it.
The secrets do have individual access permissions. Applications can
grant access rights to the secret: so the UI adds the
syncevo-dbus-server binary into the ACL. If it didn't, there would be a
dialog asking the user to approve the access.
This is a bit problematic as a generic UI can't really tell where the
server binary is... My original instinct was that it's not worth it to
add something like this to the API, but the dbus-glib bindings could
have a helper function for adding the server binary to ACL.
>>> This surely is not top priority, but I think it would be
nice if one
>>> could run sync-ui and Genesis next to each other. So services set up in
>>> Genesis should work in sync-ui and the other way around. So could anyone
>>> help me find out why sync-ui doesn’t recognise the services I set up
>>> with Genesis? Then I could adjust Genesis’ configuration mechanisms to
>>> be compatible with sync-ui.
>> You could use the same gconf key to select the active configuration.
>> Then sync-ui should work right away. Have a look at
>> /apps/sync-ui/server in gconf-editor.
> Ah, that sounds good! It makes sense to store common configuration
> options in a common place.
So... should this actually be part of syncevolution config?
- Jussi
12:35 a.m.
On Thu, 2009-08-27 at 13:26 +0100, Jussi Kukkonen wrote:
Patrick Ohly wrote:
> On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
>> Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
>>> On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
>> This is of course way better in means of security. Maybe I should have a
>> look if I can implement this for Genesis as well (if gnome-keyring is
>> present, I’d like not to depend on GNOME too much). But at least for
>> Genesis some kind of migration would be necessary: If a password is
>> present in the config file, delete it there and set it in the GNOME
>> keyring.
>
> For that the command line needs to support GNOME keyring first, which it
> currently doesn't (#3604). So the current status is:
> * if the user changes the password on the sync-ui, save in GNOME
> keyring with "-" as password in config.in => command line will
> ask for password, breaking Genesis
> * if the password is stored in config.ini, don't touch it in
> sync-ui
>
> I'm not 100% sure, but I think the second point is the fix that I was
> looking. Jussi, do you know why the password is not shown in the second
> case?
Password is not currently transmitted via D-Bus... It probably should be
at least when we update the config api. Nothing gets broken though: If
you do set a password with the ui, keyring will be used but otherwise
the password won't be touched.
I agree, we should transmit the password as part of the revised D-Bus
API. Then we can show that a password is set, which would avoid the
issue that Frederik saw (password seems to be empty). Also, clients with
no support for the keyring can set the password in the config.ini.
>> I don’t have any experience with gnome-keyring, so I’ll have
to see how
>> much work this would be. Is it even possible to access passwords across
>> applications (like Genesis and sync-ui)? How does syncevolution know
>> about the password then? Does it look for it in gnome-keyring for
>> itself, or do I have to pass it to syncevolution somehow?
>
> It is looked up with a set of properties as key:
> http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
>
> Any application with access to the keyring can read and write it.
The secrets do have individual access permissions. Applications can
grant access rights to the secret: so the UI adds the
syncevo-dbus-server binary into the ACL. If it didn't, there would be a
dialog asking the user to approve the access.
This syncevo-dbus-server => GNOME keyring dependency is problematic for
another reason. Suppose that SyncEvolution is used with a KDE GUI and
Akonadi backends. The GNOME keyring shouldn't be used in such a setup.
I don't know what the KDE equivalent of the GNOME keyring is, and we
shouldn't have to know. This implies that password storage should be
entirely handled by clients, with plain passwords in the config.ini as
fallback.
The drawback is that we have to transmit plain passwords over D-Bus,
something that we wanted to avoid originally.
This is a bit problematic as a generic UI can't really tell where
the
server binary is... My original instinct was that it's not worth it to
add something like this to the API, but the dbus-glib bindings could
have a helper function for adding the server binary to ACL.
Not having the syncevo-dbus-server access the GNOME keyring would avoid
this problem. It would still be a problem if Genesis and sync-ui want to
share access to GNOME keyring, but this could be handled via the access
dialog.
>>>> This surely is not top priority, but I think it
would be nice if one
>>>> could run sync-ui and Genesis next to each other. So services set up in
>>>> Genesis should work in sync-ui and the other way around. So could
anyone
>>>> help me find out why sync-ui doesn’t recognise the services I set up
>>>> with Genesis? Then I could adjust Genesis’ configuration mechanisms to
>>>> be compatible with sync-ui.
>>> You could use the same gconf key to select the active configuration.
>>> Then sync-ui should work right away. Have a look at
>>> /apps/sync-ui/server in gconf-editor.
>> Ah, that sounds good! It makes sense to store common configuration
>> options in a common place.
So... should this actually be part of syncevolution config?
Yes. We currently don't have any server-independent config, but adding
some key/value pairs which are stored in
~/.config/syncevolution/config.ini wouldn't be hard.
--
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.
10:51 a.m.
> For that the command line needs to support GNOME keyring first,
which it
> currently doesn't (#3604). So the current status is:
> * if the user changes the password on the sync-ui, save in GNOME
> keyring with "-" as password in config.in => command line
will
> ask for password, breaking Genesis
> * if the password is stored in config.ini, don't touch it in
> sync-ui
>
> I'm not 100% sure, but I think the second point is the fix that I was
> looking. Jussi, do you know why the password is not shown in the second
> case?
I'm working on bug#3604. I think it will be ready in the next few days.
Cheers,
Yongsheng
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
Sent: Thursday, August 27, 2009 10:36 PM
To: Jussi Kukkonen
Cc: syncevolution(a)syncevolution.org
Subject: Re: [SyncEvolution] sync-ui and Genesis compatibility
On Thu, 2009-08-27 at 13:26 +0100, Jussi Kukkonen wrote:
> Patrick Ohly wrote:
> > On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
> >> Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
> >>> On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
> >> This is of course way better in means of security. Maybe I should have a
> >> look if I can implement this for Genesis as well (if gnome-keyring is
> >> present, I’d like not to depend on GNOME too much). But at least for
> >> Genesis some kind of migration would be necessary: If a password is
> >> present in the config file, delete it there and set it in the GNOME
> >> keyring.
> >
> For that the command line needs to support GNOME keyring first,
which it
> currently doesn't (#3604). So the current status is:
> * if the user changes the password on the sync-ui, save in GNOME
> keyring with "-" as password in config.in => command line
will
> ask for password, breaking Genesis
> * if the password is stored in config.ini, don't touch it in
> sync-ui
>
> I'm not 100% sure, but I think the second point is the fix that I was
> looking. Jussi, do you know why the password is not shown in the second
> case?
>
> Password is not currently transmitted via D-Bus... It probably should be
> at least when we update the config api. Nothing gets broken though: If
> you do set a password with the ui, keyring will be used but otherwise
> the password won't be touched.
I agree, we should transmit the password as part of the revised D-Bus
API. Then we can show that a password is set, which would avoid the
issue that Frederik saw (password seems to be empty). Also, clients with
no support for the keyring can set the password in the config.ini.
>> I don’t have any experience with gnome-keyring, so I’ll have
to see how
>> much work this would be. Is it even possible to access passwords across
>> applications (like Genesis and sync-ui)? How does syncevolution know
>> about the password then? Does it look for it in gnome-keyring for
>> itself, or do I have to pass it to syncevolution somehow?
>
> It is looked up with a set of properties as key:
> http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
>
> Any application with access to the keyring can read and write it.
The secrets do have individual access permissions. Applications can
grant access rights to the secret: so the UI adds the
syncevo-dbus-server binary into the ACL. If it didn't, there would be a
dialog asking the user to approve the access.
This syncevo-dbus-server => GNOME keyring dependency is problematic for
another reason. Suppose that SyncEvolution is used with a KDE GUI and
Akonadi backends. The GNOME keyring shouldn't be used in such a setup.
I don't know what the KDE equivalent of the GNOME keyring is, and we
shouldn't have to know. This implies that password storage should be
entirely handled by clients, with plain passwords in the config.ini as
fallback.
The drawback is that we have to transmit plain passwords over D-Bus,
something that we wanted to avoid originally.
This is a bit problematic as a generic UI can't really tell where
the
server binary is... My original instinct was that it's not worth it to
add something like this to the API, but the dbus-glib bindings could
have a helper function for adding the server binary to ACL.
Not having the syncevo-dbus-server access the GNOME keyring would avoid
this problem. It would still be a problem if Genesis and sync-ui want to
share access to GNOME keyring, but this could be handled via the access
dialog.
>>>> This surely is not top priority, but I think it
would be nice if one
>>>> could run sync-ui and Genesis next to each other. So services set up
in
>>>> Genesis should work in sync-ui and the other way around. So could
anyone
>>>> help me find out why sync-ui doesn’t recognise the services I set up
>>>> with Genesis? Then I could adjust Genesis’ configuration mechanisms to
>>>> be compatible with sync-ui.
>>> You could use the same gconf key to select the active configuration.
>>> Then sync-ui should work right away. Have a look at
>>> /apps/sync-ui/server in gconf-editor.
>> Ah, that sounds good! It makes sense to store common configuration
>> options in a common place.
So... should this actually be part of syncevolution config?
Yes. We currently don't have any server-independent config, but adding
some key/value pairs which are stored in
~/.config/syncevolution/config.ini wouldn't be hard.
--
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.
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
4769
days inactive
4782
days old
syncevolution@synevolution.org
7 comments
4 participants
participants (4)
-
Frederik Elwert -
Jussi Kukkonen -
Patrick Ohly -
Zhu, Yongsheng