[Evolution-hackers] Vacuum folders.db on expunge?

2012-01-18 Thread Matthew Barnes
I still find myself occasionally pointing users to the little shell
script Srini wrote some years ago to vacuum out all your folders.db.
Since moving to XDG base dirs I've kept an updated version of it here:

http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb

Usually after running the script, users report that Evolution feels fast
and responsive again.

Evolution really needs to be doing this on its own periodically, but I
would rather the user not be aware of it.  So no new pop-up dialogs or
info bars or anything like that.

I thought a natural place to tie a database cleansing into would be a
folder expunge (and also File - Empty Trash), something most users do
every now and then already -- or at least something we could instruct
them to do directly within Evolution.

Plus, users are already accustomed to a short delay when emptying trash,
so a little extra delay there should be pretty inconspicuous.

Thoughts?

Matthew Barnes

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


Re: [Evolution-hackers] Vacuum folders.db on expunge?

2012-01-18 Thread Sankar P
 On 1/18/2012 at 09:17 PM, in message
1326901656.25967.14.camel@localhost.localdomain, Matthew Barnes
mbar...@redhat.com wrote: 
 I still find myself occasionally pointing users to the little shell
 script Srini wrote some years ago to vacuum out all your folders.db.
 Since moving to XDG base dirs I've kept an updated version of it here:
 
 http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb 
 
 Usually after running the script, users report that Evolution feels fast
 and responsive again.
 
 Evolution really needs to be doing this on its own periodically, but I
 would rather the user not be aware of it.  So no new pop-up dialogs or
 info bars or anything like that.
 
 I thought a natural place to tie a database cleansing into would be a
 folder expunge (and also File - Empty Trash), something most users do
 every now and then already -- or at least something we could instruct
 them to do directly within Evolution.
 
 Plus, users are already accustomed to a short delay when emptying trash,
 so a little extra delay there should be pretty inconspicuous.
 
 Thoughts?
 

sqlite is used  by not just Evo. But by other applications like Firefox, 
chromium, too.

In openSUSE we found a solution 
http://gitorious.org/opensuse/vacuumizer/blobs/master/vacuumizer to do this via 
a script.

May be the disros can run this script once a month on gdm logging in, so that 
all applications can be benefitted.

Sankar

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


[Evolution-hackers] Nitpick for a mailing list admin

2012-01-18 Thread Matthew Barnes
Akhil, are you still a mailing list administrator?  The subscribe pages
on mail.gnome.org list you and pg...@novell.com but I don't know who
that is.

Anyway, I noticed a typo on the evolution-list description [1]:

General discussion and user queries of the Evolution

We need to remove the word the:

General discussion and user queries of Evolution

But it brings up the larger point of who's managing our mailing lists
these days and can Chen and I get in on that so we have a bus factor 1?

Matt

[1] http://mail.gnome.org/mailman/listinfo/evolution-list

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


Re: [Evolution-hackers] Questions about EDS architecture in http://live.gnome.org/Evolution/EDS_Architecture

2012-01-18 Thread Li, Cici X
Thanks, milan, its very helpful~~

-Original Message-
From: evolution-hackers-boun...@gnome.org 
[mailto:evolution-hackers-boun...@gnome.org] On Behalf Of Milan Crha
Sent: Tuesday, January 17, 2012 3:30 PM
To: evolution-hackers@gnome.org
Subject: Re: [Evolution-hackers] Questions about EDS architecture in 
http://live.gnome.org/Evolution/EDS_Architecture

On Mon, 2012-01-16 at 15:59 +, Li, Cici X wrote:
 1.  evolution-alarm-notify
 
 Is this DBus service to manage calendar(events/task) alarm management?
 Including recur, alarm time reschedule, alarm snooze following?

Hi,
it's not a DBus service, as of today, it's just a process run on Gnome's
session start, which manages alarms (reminders) set on the calendars you
have checked for alarm notifications. It's also not part of EDS, but
evolution itself.

 Is it only relate calendar alarm? or have relation with OS’
 notification component?

Answered above, only calendar notifications, and only those which users
wants to, as set in Edit-Preferences-Calendar and Tasks-Reminders
tab.

 I want to know its detail logic…

Why?

 2.  For below addressbook frame diagram
 
 1)  Did this diagram have some updates?

Unfortunately not.

 The diagrams of addressbook/calendar(in below) are outdated? they
 still refer to EBook, ECal, EBookView, ECalView which are deprecated
 (EBookClient, EBookClientView, ECalCient, ECalClientView are used
 instead). Also, don't know what the listeners correspond to now.

Yes, it's outdated, but the logic is basically the same, the deprecated
objects can be replaced with that currently supported.

 2)  For EBookBackendFile, we use it to save contacts files in
 addressbook.db, this is our common used way, and the way create
 contacts from Evolution UI, right?

Yes.

 3)  “For EBookBackendVCF, This backend gets launched when the
 protocol prefix of the URI is vcf://. As of now there is no way to
 create an address book folder of this type in the Evolution UI.”
 
 When to used this backend? Used to load vcf files from some clients or
 import contacts from file? What is the mainly usage of this backend?

Nice, you cannot create such addressbook, the backend is inaccessible
from evolution's UI right now. I didn't notice it myself. It still can
be created from 3rd party software.

 4)  For EBookBackendLDAP, when to use this backend? What is the
 mainly usage of this backend?
 
 5)  For EBookBackendGroupwise, when to use this backend? What is
 the mainly usage of this backend?

OK, it seems you do not  understand the purpose of EBookBackend.
Basically, EBookBackend (or ECalBackend) descendants provide all the
conversions between structures used by evolution-data-server itself
(EVCard for books and icalcomponent/ECalComponent for calendar) and the
place they read (write) data from (for LDAP it's an LDAP server, for
file backends it's a local file and so on). It is supposed to provide
some necessary functionality to properly work as a backend for
evolution-data-server. The e-addressbook-factory/e-calendar-factory (in
3.3.4 factories prefix is replaced with evolution-..., instead of e-...)
manage these backends and open/close backends on demand. These factories
are DBus services, to which EBookClient/ECalClient-s connect. Before
DBus these two factories were only one binary, named
evolution-data-server-$version.

 3.  For below calendar frame diagram
 
 1)  Any updates of this diagram? Where is ical? 

Similar with addressbook, it's outdated. What do you mean with ical? Do
you mean libical? It's technically not part of eds, it's a library used
to work with iCalendar objects (icalcomponent).

 2)  “Calendar backends deal with the communication between
 evolution-data-server and specific calendar servers/types. Thus, a
 backend must be written for any different calendar source (file
 backend for local files, webcal backend for HTTP, Groupwise, Exchange,
 etc).”
 
 What is the detail difference of backends to handle source file: local
 files, webcal backend for HTTP, Groupwise?

I'm not sure what answer you expect here. If the semi-general paragraph
about backends outlined above didn't help, then probably read the code,
as that is the only detailed difference between them. :)

As I mentioned above, the wiki documentation is slightly out of date,
thus I agree it can be confusing with respect of current sources.
Bye,
Milan

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