Re: [Evolution] evolutio forgets my passwords every start from Fri, 03 Feb 2012 15:39:53 -0800

2012-02-14 Thread Patrick O'Callaghan
On Mon, 2012-02-13 at 18:47 -0600, Matthew Barnes wrote:
 On Mon, 2012-02-13 at 19:41 -0430, Patrick O'Callaghan wrote:
  As has been commented several times on this list over the years, none of
  KDE knows anything about the Gnome keyring. KDE has its own entirely
  separate keystore, the KDE Wallet.
  
  The existence of two subsystems with essentially the same functionality
  but which don't communicate with each other is a constant irritant.
  Every time I start Evo in a new login session I have to re-type my login
  password *and* my Gnome keyring password (it used to be just one of
  them, now it's both; I guess that's progress ...). There's some talk of
  a new KDE-side package which will address this but I don't know the
  details.
 
 Stef Walter has assured me he's working on a replacement for GNOME
 Keyring called GSecret that uses the same freedesktop.org standard D-Bus
 API as KDE Wallet, so theoretically you can mix-and-match the KDE Wallet
 service with the GSecret client library or vice versa.
 
 http://stef.thewalter.net/2011/09/introspecting-certificates.html?showComment=1317622996198#c5364051270673968069
 
 As soon the GSecret library is available, ditching GNOME Keyring will be
 a top priority for me.  GNOME Keyring is as much of a pain to program to
 as it is to use outside of GNOME.

Sounds good. I was actually thinking of a different package which is
being pushed for KDE 4.8: http://www.ohloh.net/p/ksecretsservice Since
this is also D-Bus based, we can cross our fingers and hope for
compatibility.

poc

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list


[Evolution] differences between search within vfolder and search within underlying lists

2012-02-14 Thread Ross Boylan
I have vfolder that combines two different inboxes.  If I am within the
vfolder and type a selection in the search box (on subject or sender)
the search is very slow (the underlying boxes are large).  If I go to
either of the inboxes and do the same search the results are much
faster.  However, the latter searches miss stuff that the vfolder search
finds.  Both mailboxes are imap (cyrus for the messages not found,
courier for the other).

I'm running evolution 2.22.3.1 on Debian Lenny.

Can anyone explain why the results and speed differ?


One theory has occurred to me: when searching the individual boxes evo
does an IMAP search.  This is fast, but misses stuff if the indices are
corrupt.  I have some reason to think they are for cyrus, since the
indexing job fails often (always?).  The vfolder search does not use
IMAP search, perhaps doing things on the client side, and so does find
everything and does  take longer.

Thanks.
Ross Boylan

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list


Re: [Evolution] differences between search within vfolder and search within underlying lists

2012-02-14 Thread Milan Crha
On Tue, 2012-02-14 at 12:28 -0800, Ross Boylan wrote:
 I have vfolder that combines two different inboxes.  If I am within the
 vfolder and type a selection in the search box (on subject or sender)
 the search is very slow (the underlying boxes are large).  If I go to
 either of the inboxes and do the same search the results are much
 faster.  However, the latter searches miss stuff that the vfolder search
 finds.  Both mailboxes are imap (cyrus for the messages not found,
 courier for the other).
 
 I'm running evolution 2.22.3.1 on Debian Lenny.

 Can anyone explain why the results and speed differ?

Hi,
2.22.3 is rather old, I'm not sure whether this one is related for that
version, but one slowness was caused by including also BCC in Sender or
Recipient search type, which is available only within a message, thus
the filtering code was required to open it, instead of reading only
summary information. This had been fixed later, in [1]. I've no idea
about different results, unless the Bcc headers are taken in effect.
Bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=593020

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list