Re: [Evolution-hackers] ANNOUNCE: Evolution 2.10.0, Evolution-Data-Server 1.10.0, GtkHTML 3.14.0 and Evolution Exchange 2.10.0

2007-03-14 Thread Harish Krishnaswamy
On Tue, 2007-03-13 at 23:04 -0400, Claudio Saavedra wrote:
 El Tue, 13-03-2007 a las 13:08 +0530, Harish Krishnaswamy escribió:
  Hi All,
  
  The Evolution Team is pleased to announce the release of
  
  * Evolution 2.10.0
  
  * Evolution-Data-Server 1.10.0
 
 I'm sorry to spoil the fun, but you guys left
 
  g_print (\n\a Header string finally is ** \n%s\n,
header_spec-str);
 
 in e-d-s, camel/providers/imap/camel-imap-folder.c:2367, which is pretty
 annoying, specially because of the '\a' (i.e., a beep every time a new
 mail arrives or a mail is moved to another folder).
 
 This appeared with a patch for this bug[1], I tried to warn but it seems
 it got unnoticed. Hope it's not too late to fix this.
 
 Claudio
 
 [1] http://bugzilla.gnome.org/show_bug.cgi?id=400841
 

You are right - this *is* an annoyance and should have been pruned
before the release,
but it is a tad late - the tarballs are already out.

I also feel that this g_print statement should be conditional on the
debug flags turned on - and should not add noise to normal usage. The
use of \a looks superfluous too.

Varadhan/Sankar : Can you wrap the statement within a suitable DEBUG
level check and get the change committed asap.  TIA.

Thanks,
Harish


-- 
Novell, Inc. 
Software for the Open Enterprise™
http://www.novell.com


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Fix the build with iconv?

2007-03-13 Thread Harish Krishnaswamy
On Tue, 2007-03-13 at 00:50 -0600, Elijah Newren wrote:
 Hi,
 
 I know they aren't the most critical patches in the world, but is
 there anyway I could convince someone to fix the build logic for iconv
 in evolution and evolution-data-server?  The patches already exist at
 http://bugzilla.gnome.org/show_bug.cgi?id=388788 and
 http://bugzilla.gnome.org/show_bug.cgi?id=388789.  It's tiring to have
 to manually patch lots of tarball and svn builds...
 

On a quick evaluation by eye,  the patch looks fine. I will test and
update the bug after running it through my build when back in my office.

(Also, I think the '#include iconv.h'  statement can be safely removed
in evolution:configure.in just like in
evolution-data-server:configure.in.  Perhaps just an oversight).

Thanks,
-Harish

-- 
Novell, Inc. 
Software for the Open Enterprise™
http://www.novell.com


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [UPDATED] Re: Updating our list of GNOME contributors

2007-03-07 Thread Harish Krishnaswamy
Hi,

This is a list (I hope I have not overlooked any)  from the
Evolution/EDS/GtkHTML/Evolution-Exchange modules.

Harish Krishnaswamy
Srinivasa Ragavan
Chenthill Palanisamy
Sankarasivasubramaniam Pasupathilingam
Veerapuram Varadhan
Matthew Barnes
Andre Klapper
Chris Heath
Hiroyuki Ikezoe
Parthasarathi Susarla
Shreyas Srinivasan
Sarfraaz Ahmed
Sushma Rai
Devashish Sharma
Jules Colding
Tor Lillqvist
Rajeev Ramanathan
Simon Zheng
Philip Van Hoof
Mengjie Yu
Wang Xin
Irene Huang
Harry Lu
Vivek Jain
Sivaiah Nallagatla
David Malcolm
James Bowes
Arunprakash
Shakti Sen
Praveen Kumar
Johnny Jacob


Evo Hackers : Friends,  any omission in the above list is inadvertent
- mea culpa. Please let me know, so this can be corrected.


Thanks,
Harish

-- 
Pure in heart, like uncut jade,
he cleared the muddy water
by leaving it alone.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)

2007-02-12 Thread Harish Krishnaswamy
Hi Andre,

 Thank you for your concern - but I believe I *did* give Matthew some
feedback on the patch over IRC (see Chat transcript [1] below) a couple
of weeks ago - about a possible ABI violation and a possible way to
avoid it and he had agreed to rework that bit.  

We do love those who love to hack on Evo :-).

Cheers,
Harish


[1] Log - #evolution - 29 Jan 2007

(20:19:07) xfceslacker: harish is there something wrong with the email I
sent?(http://mail.gnome.org/archives/evolution-hackers/2007-January/msg00053.html)
(20:20:23) harish: xfceslacker: none
(20:21:42) xfceslacker: I waited nearly a month for a response on my
last email.
(http://mail.gnome.org/archives/evolution-hackers/2007-January/msg0.html)
(20:22:05) harish: except that on a very quick glance at the patch - I
feel that inserting a new element into an enum set violates the ABI
(20:22:25) xfceslacker: ok
(20:22:30) xfceslacker: thanks
(20:22:31) xfceslacker: :)
(20:23:16) harish: xfceslacker: I do not primarily hack on the mailer
component - I have poked those who do to have a look at it and provide a
response
snip
(20:23:46) harish: xfceslacker: sorry - the team is swamped by quite a
bit of work..thanks for your patience
(20:23:53) xfceslacker: ok.
(20:24:01) xfceslacker: Anything else you see wrong with the patch?
(20:25:36) xfceslacker: I know my em_utils_load_template function is
ugly.
(20:25:42) harish: xfceslacker: I am not the best person to make the
call - but I'd prefer if you could append the new value so it extends
the current set. 
(20:26:00) xfceslacker: ok
(20:27:06) xfceslacker: You're talking about _mail_component_folder_t
right?
(20:27:35) xfceslacker: or enum {
(20:27:35) xfceslacker:  SEND,
(20:27:35) xfceslacker:  SAVE_DRAFT,
(20:27:35) xfceslacker: + SAVE_TEMPLATE,
(20:27:35) xfceslacker:  LAST_SIGNAL
(20:27:35) xfceslacker:  };
(20:29:04) xfceslacker: or both?
(20:30:19) harish: _e_account_item_t on libedataserver
(20:30:27) xfceslacker: oh
(20:30:29) xfceslacker: sorry
(20:31:14) harish: Evolution is not a devel library...EDS is more
religious about changes 

On Sun, 2007-02-11 at 02:30 +0100, Andre Klapper wrote:
 may a developer answer this, or shall matthew ask for a third time on
 this list, after waiting for six weeks for some feedback?
 
 andre
 


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] ANNOUNCE: Evolution 2.8.3 and Evolution-Data-Server 1.8.3 Release (with GtkHTML 3.12.3 and Evolution-Exchange-2.8.3)

2007-01-29 Thread Harish Krishnaswamy
Hi All,

The Evolution Team is pleased to announce the release of Evolution
2.8.3.

You can download the following :

http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.12/gtkhtml-3.12.3.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.8/evolution-data-server-1.8.3.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.8/evolution-2.8.3.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.8/evolution-exchange-2.8.3.tar.bz2


Upgrade Notes :
Evolution 2.8.3 is a stable release series of 2.8 development.

Release Notes:

Evolution 2.8.3
---

Updated Translations:

Daniel Nylander (sv), Stéphane Raimbault (fr),
Nickolay V. Shmyrev (marking strings as translatable), 
Djihed Afifi (ar), Francisco Javier F. Serrador (es),
Hendrik Richter (de), Jakub Friedl, Priit Laes (et),
Changwoo (ko), Laurent Dhima (sq).

Contributions :
Simon Zheng (352108), Nickolay V. Shmyrev (340165),
Matthew Barnes (357970, 383027, 377511), Chris Halls (372528), 
Wang Xin (389966, 389961, 380064), Raghavendran (343943),
Kjartan Maraas (330969).
Harish Krishnaswamy (208959 - bnc, 377626)   

GtkHTML-3.12.3
--

Updated Translations:
Ilkka Tuohela (fi)

Contributors:
Gilles Dartiguelongue (331813), John N. Laliberte (373092),
Chris Heath (362194, 338884, 360393), Michael Monroe (358641).

Evolution-Data-Server 1.8.3 
--

Updated Translations:

Stéphane Raimbault (fr), [EMAIL PROTECTED] (fr),
Djihed Afifi (ar), Gabor Kelemen (hu), Ilkka Tuohela (fi),
David Lodge (en_GB), Clytie Siddall (vi), Alexander Shopov (bg),
Laurent Dhima (sq), Djihed Afifi (ar), Josep Puigdemont i Casamajó (ca),
Francisco Javier F. Serrador (es), Priit Laes (et), Jovan Naumovski
(mk),
Ankit Patel (gu).

Contributors :
Andreas Henriksson (Fix order of memset arguments in libdb hash)

Evolution Exchange 2.8.3 
-
Updated Translations:
Laurent Dhima (sq), Djihed Afifi (ar).

Contributions:
Matthew Barnes (357660).


Reporting Bugs

If you have problems with 2.8.3, please take the time to submit the bug
using Bug Buddy or at http://bugzilla.gnome.org.  Try to fill in as much
detail as you can regarding the circumstances that lead to the problem.

If you have a feature request, you can also file that at
http://bugzilla.gnome.org/ don't be discouraged if you don't hear from
us right away, we get hundreds of feature requests a year.

You can also check if your bug has been reported before by using the
search functionality of Bugzilla.

More information is available at the project website
http://www.gnome.org/projects/evolution and the project wiki :
http://go-evolution.org/


Known Issues :

GW users need to apply the following patch onto
evolution/plugins/groupwise-features/junk-settings.c to fix a missing
translation header. Non-GW users are not affected by this.

Index: junk-settings.c
===
--- junk-settings.c (revision 33162)
+++ junk-settings.c (working copy)
@@ -23,6 +23,7 @@
 #  include config.h
 #endif
 #include glade/glade.h
+#include glib/gi18n.h
 #include junk-settings.h
 #include glib/gmain.h
 #include gtk/gtktreemodel.h
Index: ChangeLog
===
--- ChangeLog   (revision 33162)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2007-01-29  Harish Krishnaswamy [EMAIL PROTECTED]
+
+   * junk-settings.c: Include glib/gi18n.h.
+
 2007-01-29  Kjartan Maraas  [EMAIL PROTECTED]
 
* send-options.c: (get_cnc): NULL check to avoid a crash


Thanks,

Harish Krishnaswamy

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [Evolution] tips and tricks and questions and answers.

2007-01-08 Thread Harish Krishnaswamy
Andre : Thanks a lot for sharing these invaluable nuggets.  You rock as
always :-).

I have added them to the project wiki at
http://www.go-evolution.org/FAQ. I appeal to all contributors to use
this page for consolidating their FAQ inputs  and help in making this
the de facto reference point for Evolution users regarding such queries.

Thanks,
Harish



On Wed, 2007-01-03 at 13:44 +0100, Andre Klapper wrote:
 hi folks,
 
 looks like i'm currently a bit disappointed by the company that still
 provides the software for my open enterprise(tm) (and no, it is not a
 problem of time).
 time to free some of the few written bits of knowledgework that
 would otherwise rot on my harddisk.
 
 attached you will find a file that includes a collection of evo related
 questions that have been asked more often or that have been very
 interesting, and of course their more or less complete answers.
 no guarantee for anything included, but a copy, paste, redistribute,
 change as you like licensee.
 i sometimes used this to answer mailing lists user questions, hope it's
 useful to somebody.
 
 welp, so long crew here,
 andre
 
 plain text document attachment (evolution-FAQE), tips and tricks and
 questions and answers.
 = Mail =
 Questions regarding the mailer and composer, for example junk mail, 
 encryption or spell checking.
 Please note that desktop integration issues (for example setting the 
 preferred browser and launching evolution from a browser) are part of the 
 interoperability section.
 
 == General ==
 === I cannot see some emails, but they must be there. ===
 Some possible reasons:
 * You use filters on incoming (or outgoing) messages that move your messages 
 automatically to another destination. If you have enabled junk filtering, 
 also take a look into the junk folder.
 * Check your search view in the search bar right above the message list, 
 perhaps you have any value in it?
 * Just to be sure: Click Edit | Show Hidden Messages.
 * Take a look into Evolution's Junk folder. Messages that are marked as Junk 
 disappear from the original folder and are only displayed in the Junk folder.
 * Check your default folder under Edit | Preferences | Email Accounts | Edit 
 | Defaults. Perhaps it is set to some other folder then the folder you 
 thought of.
 If this specially refers to an IMAP account and you upgraded Evolution to 
 version 2.4, and you are using a Cyrus IMAP server, then try to change your 
 account settings to Show subscribed mails only. Then use Folder | 
 Subscriptions to subscribe to your Inbox and any other folder. You might 
 need to restart Evolution in between. This bug is fixed was Evolution 2.4.2.1 
 and later.
 
 
 === How i can update/refresh Search folders (formerly called vFolders)? ===
 Refreshing a Search folder by a command is not possible (see 
 http://bugzilla.gnome.org/show_bug.cgi?id=257582). However, you should get an 
 updated view by going to another folder and then going back to your Search 
 folder.
 
 
 === Why do my mail filters not work? ===
 Generally, be aware of the fact that the order of your filters is important. 
 If your very first filter has a Stop processing rule, all the other filters 
 will be ignored by the emails that match to this first filter rule.
 If you want your filters to apply automatically and you are using an IMAP 
 account, make sure you have enabled Apply filters to new messages in INBOX 
 on this server under Edit | Preferences | Email Accounts | Edit | Receiving 
 Options | Options.
 Also, filters depend on the new flag which will be set only when a 
 particular mail is fetched from server for the first time. If any other mail 
 client is used to check mail before Evolution, Evolution's filters may not 
 work.
 
 
 === Why do I get the message No provider available for protocol email.? ===
 This can happen if you have just installed Evolution on a new machine and 
 have copied the file named filters.xml, so your filter rules are suffering 
 from a version mismatch with Evolution. Since the filters refer to accounts 
 directly, and accounts all have a unique ID number, you get the above error 
 if it cannot find the account anymore, so you either have not copied the 
 account settings or they have been changed in the meantime. To fix it, edit 
 your filters and re-select the folder for each Copy/Move filter.
 
 
 === How can I get informed of new mail arriving? ===
 Since Evolution 2.2, a panel notification applet via D-BUS exists.
 Evolution itself is only able to play a sound file or to beep. Go to Edit | 
 Preferences | Mail Preferences | General | New Mail Notification.
 Note that esound must be running to be able to hear your sound file.
 
 
 === Why does new junk mail automatically get marked as read? ===
 Good question - one can easily miss new messages which have been incorrectly 
 marked as junk. Workaround: Both for trash and the junk folder, one can 
 enable displaying the number of ALL messages in the preview pane (in brackets 
 

Re: [Evolution-hackers] evolution-data-server/calendar/libical and SVN

2007-01-02 Thread Harish Krishnaswamy
On Wed, 2007-01-03 at 00:29 +0100, Andre Klapper wrote:
 hejhej,
 
 Am Dienstag, den 02.01.2007, 14:46 + schrieb Ross Burton:
  Those problems might not be a real issue, as nobody really hacks on
  libical.
 
 correct,
Although not as active as the rest of the module,  there have been quite
a few critical bug fixes made on libical every major release. I will
look into the svn-howtos to see if it is possible to get a writable
checkout of libical or at least make it less of a road hump to
developers.

  and this also means that nobody updates the timezone data 
 think there's currently wrong data at least for iran, brazil and
 australia, iirc).

I have opened http://bugzilla.gnome.org/show_bug.cgi?id=392170 to track
and fix the discrepancies in timezone information.


quote who=Mark McLoughlin
 The libical module will be checked out using anonymous SVN, meaning 
 evo hackers wouldn't be able to directly hack on that checkout
 
   - When you branch, the branched evolution-data-server will still 
 refer to libical trunk. You'd need to modify the svn:externals 
 property to refer to the libical branch
 
Mark : Thanks. I am already working on the problem.  I am holding the
option of adding the 'svn:external's until tonight to explore
alternatives (making libical a snapshot copy like libdb as we do not
make separate package releases of libical anyway).

Cheers and a Happy New Year to All,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] RFC: Evolution's library requirements

2006-12-05 Thread Harish Krishnaswamy
Hi fellow hackers,

With reference to Bug 380534 on clarifying Evolution's library
requirements, I am putting down my thoughts and recommendations here and
will be proposing this in the weekly evolution meeting (#evolution-meet
on irc.gimp.org at 1000 UTC 6 Dec 2006) tomorrow. Comments/questions
welcome, as always.

I see two aspects of the problem described in the bug that merit two
separate approaches :

a. Inbound Dependencies - The libraries that Evolution/EDS/Evolution
Exchange depend on.
b. Outbound Dependencies - Dependencies that EDS libraries provides to
other applications that are based on or integrated with Evolution/EDS.

On (a) Inbound Dependencies, 

I suggest that on upstream CVS, Evolution  should depend on the most
recent stable versions of the libraries available in the corresponding
GNOME release (Evolution 2.9.x/2.8.x on GNOME 2.16, 2.6.x on GNOME
2.14). This is similar but not exactly the same as what Matthew has
outlined in Bug 380534. I agree that the configure scripts need to
hard-enforce these dependencies while building the packages.

I feel it is important that we move away from 
i) the use of deprecated APIs from various GNOME libraries to the
improved, maintained versions.
ii) Evolution specific widgets/thread/mutex/data structures
implementation that are now available in generic GNOME libraries. This
is possible now in some cases (EList-GList, EThread-GThread,
EMutex-GMutex?) but not all (ETable, ETree).

This ensures we take advantage of the newer capabilities available and
make it easier for contributors to continue adding value to our project.

However, it is also true that a very large number of our users
(enterprise, organizations, ISVs) still live on older GNOME Desktop
environments (Gtk = 2.6), willing to upgrade specific applications
(Evo) but not their entire Desktop every six months. I think this would
be the case in future too that the 'majority' of the  installed base
stays a step or two behind the Bleeding-Edge/State-Of-The-Art Latest
releases.

If-defs and conditional compilations with significant addition to the
maintenance complexity are a necessity to support such users who need to
move to newer versions without overhauling their desktop. It is fair
IMHO, however, for individual distributions to handle them according to
their needs, rather than the upstream maintaining a super-set of
everybody's constraints. 

I wish to propose an exception to the above if and only if when an
inbound dependency is likely to cause a change to an outbound dependency
as discussed in (b).


On (b) Outbound dependencies, 
 and this is specially relevant to bugs like 373117, where we would like
to preserve the binary compatibility of outbound libraries (libebook and
libecal, in particular, which are the heavily used ones and as well as
various Camel/Calendar/Addressbook providers built on EDS) and take care
that any changes do not trigger massive upgrade overheads for those who
consume our libraries.  Evolution has learnt this the hard way, erred on
some and handled them with additional code overheads in other cases.

Here, I would recommend that we extend the APIs rather than
modify/delete them and mark the deprecated functions (to be discarded
after a specified and sufficient timeline) so that they do not get used
in newer code.  These libraries need to support older environments (and
possibly deprecated library calls) in a broader sense than in case (a). 
In these cases, some conditional compilation and #ifdef hacks will have
to be supported on the upstream as well. I wish I could specify hard
numbers on minimum dependencies for various libraries here. ( Is
'Libraries corresponding to GNOME 2.14' a good one ?) but I do not have
the answers yet. If you have a POV that you feel must be considered,
please do let me know or join us in the meeting tomorrow.
(There has also been a separate discussion on the need to get
Evolution's Camel library versioned and promise a compatible interface
for foreseeable future and Varadhan is already working on this with
other mail hackers).


I also feel the library dependencies are best conveyed by the build
tools and our decisions should be reflected in and enforced by our
pkg-config and configure scripts.  (remember the recurring NSS/NSPR ,
LDAP/NTLM issues ?) 
The Answer : Patch and Testing love [hint...hint ;-)]


Thanks,
Harish




___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [ANNOUNCE} Evolution 2.9.3 and Evolution-Data-Server 1.9.3 released (with GtkHTML 3.12.3 and Evolution-Exchange-2.9.3)

2006-12-04 Thread Harish Krishnaswamy
Hi All,

The Evolution Team is pleased to announce the release of Evolution 2.9.3

You can download the following :

http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.3.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.3.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.3.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.3.tar.bz2

Upgrade Notes :
Evolution 2.9.x is the unstable series of 2.10 development.


What is New ?
=

Evolution :
Updated Translations:
Ivar Smolin (et), Jakub Friedl (cs),
Karsten Bräckelmann (nb), Francisco Javier F. Serrador (es),
Christophe Merlet (fr)

Contributors :
Francisco Javier F. Serrador (gnome-doc-tools integration, 358249)
Harish Krishnaswamy (evolution.desktop install fixes, GW proxy pruning,
memory leak fixes, 381642 (b.g.0), bug #208959 at bugzilla.novell.com)
Nickolay V. Shmyrev (support for commandline uri in tasks),
Daniel Gryniewicz (349966), Srinivasa Ragavan (Fix DoS by large emails)
Sankar, Chris Halls (372528), Wang Xin (380064), Carlos Garcia (367183),
Chenthill (208318 - b.n.c), Parthasarathi Susarla (348679).
Matthew Barnes (357970).

Evolution-Data-Server:

Updated Translations:
Alexander Shopov (bg), Josep Puigdemont i Casamajó (ca),
Ivar Smolin (et).

Bug fixes : 330157, 350880, 328836, 348123, 365000, 353924. 
174655, 222605, 219729, 208318, 207960. (bugzilla.novell.com)
plus miscellaneous code clean-ups and memory leak fixes.

Contributors :
Harish Krishnaswamy, Sankar, Srinivasa Ragavan, Chenthill, 
Claudio Saavedra, Ross Burton, Matthew Barnes, Andrew Ruthven.

GtkHTML:

Updated Translations : Ivar Smolin (et)
Bug Fixes : Srinivasa Ragavan (#350981)

Evolution-Exchange:

Updated Translations:

Vladimer Sichinava (ka), Ivar Smolin (et),
Rahul Bhalerao (mr), David Lodge (en_GB),
Djihed Afifi (ar), Baris Cicek (tr),
Woodman Tuen (zh_HK), Åsmund Skjæveland (nn)

Reporting Bugs

If you have problems with 2.9.3, please take the time to submit the bug
using Bug Buddy or at http://bugzilla.gnome.org.  Try to fill in as
much detail as you can regarding the circumstances that lead to the
problem.

If you have a feature request, you can also file that at
http://bugzilla.gnome.org/ don't be discouraged if you don't hear from
us right away, we get hundreds of feature requests a year.

You can also check if your bug has been reported before by using the
search functionality of Bugzilla.

More information is available at the project website
http://www.gnome.org/projects/evolution
and the project wiki :
http://go-evolution.org/

Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Groupdav connector for Evolution

2006-11-30 Thread Harish Krishnaswamy
Shreyas,


 The code is here 
 
 http://svn.opengroupware.org/OGoProjects/evolution/trunk/shreyas/
 

Some of the files in the packages miss copyright/license details while
many still retain copyright notices from the original Evolution sources
with dated entries and missing information about the new authors and
modifications. Also, the newly written code needs to confirm better to
the Evolution Code Style guidelines (no // style comments etc.).  Can
you please take care of these details and also let me know if anybody is
volunteering to maintain these modules as well.


Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Copyright assignment

2006-11-15 Thread Harish Krishnaswamy
On Wed, 2006-11-15 at 21:15 +0100, Håvard Wigtil wrote:

 I found
 http://forge.novell.com/modules/xfcontent/private.php/evolution/docs/copyright_form.pdf
  , and after trying to list that directory the more sensible URL 
 http://forgeftp.novell.com/evolution/docs/copyright_form.pdf.
 
 Could someone please update the web pages and / or confirm that the
 fax number and address given in
 http://forge.novell.com/modules/xoopsfaq/?cat_id=30 are still correct?

Havard, 

I am working on getting the url problems straightened out with the site
admins. And yes, the fax number and address given in the aforementioned
page is correct.

Thanks for your patience,
Harish


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution documentation

2006-11-08 Thread Harish Krishnaswamy
Francisco,

Mucho Gracias. 

Srinivasa Ragavan / Radhika are currently handling the documentation
tasks of Evolution. I have requested them to work with you and
co-ordinate the efforts towards the adoption of gnome-doc-utils.

Thanks,
Harish

On Tue, 2006-11-07 at 11:52 +0100, Francisco Javier F. Serrador wrote:
 I'd like to migrate evolution to gnome-doc-utils. Does anybody have any
 problem/issue/question about it?
 
 Cheers!
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [UPDATE] Evolution 2.8.1.1 released

2006-10-19 Thread Harish Krishnaswamy

Hi,

 Evolution 2.8.1.1 has been released as an update to the Evolution 2.8.1
release (GNOME 2.16 stable series) with fixes to a few critical
bugs/regressions [ see details below].

You can download the source tarballs at
http://ftp.gnome.org/pub/GNOME/sources/evolution/2.8/evolution-2.8.1.1.tar.bz2

Reporting Bugs

If you have problems with 2.8.1.1, please take the time to submit the
bug
using Bug Buddy or at http://bugzilla.gnome.org.  Try to fill in as
much detail as you can regarding the circumstances that lead to the
problem.



Thanks,
Harish


Evolution 2.8.1.1 
--

Bugs/Regressions fixed in this release :

#348212, #360815, #333864, #351374, #360815, #334966,
#333224, #359271, #360237, #359236. 

Updated Translations:

Ivar Smolin (et), Josep Puigdemont i Casamajó (ca),
Clytie Siddal (vi), Ankit Patel (gu), Ilkka Tuohela (fi),
Jovan Naumovski (mk), Luca Ferretti (it), Kjartan Maraas (nb),
Zygimantas Beručka (lt), Cyprien Le Pannérer (fr),
Jordi Mas (ca), Tino Meinen (nl), Daniel Nylander (sv),
Francisco Javier F. Serrador (es).



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Building Evolution Exchange from HEAD / with Evolution 2.9.x

2006-10-17 Thread Harish Krishnaswamy
Hi,

 As noted in my previous mail,  there was no new release of the
Evolution Exchange module along with Evolution 2.9.1 and
Evolution-Data-Server 1.9.1. as we had no changes to the
source/translations since the previous release.

However, in case you are building Evolution Exchange from HEAD along
with the latest Evolution/EDS modules (from trunk or 2.9.1/1.9.1
releases respectively) - your evolution-exchange module will fail to
work with the latest Evo/EDS packages.

You need to make the following change in the configure.in (or configure
if you are using  Evolution Exchange 2.8.x tarball)  -

EVOLUTION_API_VERSION=2.10
EDS_API_VERSION=1.2
EDS_BASE_VERSION=1.10

-Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Evolution and friends branched for 2.16

2006-10-16 Thread Harish Krishnaswamy
Hi,

 I branched the following modules

Evolution 
Evolution-Data-Server
GtkHtml [1]
Evolution-Exchange [1]

for the GNOME 2.16 stable series on Saturday. 

Thanks for all those who held their patches for HEAD so we could focus
on the patches for 2.8.x. You may resume the commits to the HEAD now.


Plans/Discussions/Wishlists for the GNOME 2.17 Development series can be
found at
http://www.go-evolution.org/Evo2.10 . You are invited to have a look at
this page and add your own valuable thoughts and feedback.


Thanks,
Harish




[1] on behalf of the maintainers of the module.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [ANNOUNCE} Evolution 2.9.1 and Evolution-Data-Server 1.9.1 released

2006-10-16 Thread Harish Krishnaswamy
Hi All,

The Evolution Team is pleased to announce the release of Evolution
2.9.1. 

What is New ?
=
This release does not have any new major features yet but includes plenty of 
bug fixes since the 2.8.[0 1] releases.

Also, there is no new release on the evolution-exchange module as we have had 
no changes since the 2.8.1 release.

You can download the following :

http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.1.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.1.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.1.tar.bz2


Upgrade Notes :
Evolution 2.9 is the unstable series of 2.10 development.


Reporting Bugs

If you have problems with 2.9.1, please take the time to submit the bug
using Bug Buddy or at http://bugzilla.gnome.org.  Try to fill in as
much detail as you can regarding the circumstances that lead to the
problem.

If you have a feature request, you can also file that at
http://bugzilla.gnome.org/ don't be discouraged if you don't hear from
us right away, we get hundreds of feature requests a year.

You can also check if your bug has been reported before by using the
search functionality of Bugzilla.

More information is available at the project website
http://www.gnome.org/projects/evolution
and the project wiki :
http://go-evolution.org/

Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Sender photo in email display

2006-10-05 Thread Harish Krishnaswamy
Hi Riccardo,

On Tue, 2006-10-03 at 18:46 +0200, Riccardo Lancellotti wrote:
 Hello,
 I have been working on a patch to add the sender photo when the sender
 of the mail is included in the addressbook and (obviously) it has a
 photo.

Great and Thanks. It is always nice to have new contributors :-). 
Welcome to Evolution .

 The code basically works, but requires some love before becoming a patch
 that can make its way into Evolution.
 Before going on with the code polish process I have some doubts that I
 would like to discuss in the mailing list
 
 1)The ui is affected by this patch. It is a trivial addition of a photo
 close to where the rupert monkey appears. Does this addition needs to be
 discussed and approved in some board? Is there any need of some control
 to disable this feaure?

Please go through http://www.gnome.org/projects/evolution/patch.shtml
which describes the patch submission process,  coding style guidelines
and copyright assignment procedures.

 2) a significant portion of the code that retrieves the contact photo is
 similar to the function em_utils_in_addressbook() in em-utils.c (that
 includes also a fancy cache function). Is is a good thing to introduce a
 more general em_utils_addressbook_lookup() that is used both by my
 code and by a wrapper that mimics the original em_utils_in_addressbook()
 function? How can I speed up an addressbook lookup? Which are the most
 computationally expensive functions in the lookup? What benchmark can I
 run?

Please mail your patch to the evolution-patches list or preferrably,
file a bug report in bugzilla [1]  and attach the patch. You may discuss
with the evolution  hackers on the IRC [1] or in this mailing list about
design aspects, performance trade-offs etc.


 3) In the EContactPhoto object the type is not reported. I assume that
 all photos are JPEG, but this looks like a strong assumption. It there
 any better guess I can do?
 
 4) This is my first attempt in working on Evolution. Is it better to
 just post the patch early even if the code is not very efficient or do I
 need to improve performance/and functionalities on my own and then post
 everything at the end?

If your patch adheres to the Patch guidelines and applies cleanly on the
source tree, feel free to post it - so it can be reviewed and tested by
the community.


Regards,
Harish

[1] Refer to http://www.gnome.org/projects/evolution/ for more
information.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] What GLib and GTK+ versions do we support?

2006-09-20 Thread Harish Krishnaswamy
On Thu, 2006-09-14 at 16:26 -0400, Matthew Barnes wrote:
 Stupid question maybe, but configure.in doesn't tell me.
 
 I'm asking because I'd like to use some recently added features like the
 GSlice allocator in some patches I'm working o
 n.  What's the policy on
 this?  Use whatever GNOME 2.16 supports?

'Whatever GNOME 2.16 supports' was my top-of-the-head answer, assuming
few (if any) users might want to update to the latest Evolution
stand-alone keeping their GNOME desktops intact. This was my thinking
when I approved the patches.

On second thoughts, there are users who use Evolution (for
Exchange/GroupWise connectivity) but run on a KDE desktop and it is not
all fun for them to update glib and above.
I feel it is more prudent to make the patch use g_slice features if a
supported version was available but falls back to the old implementation
otherwise.

This adds to the maintenance foo but gets us a few more happy users.

Any thoughts, others ?

-Harish


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Compile problems on darwin

2006-09-14 Thread Harish Krishnaswamy
Looks like 
http://bugzilla.gnome.org/show_bug.cgi?id=339721  to me which has been
resolved fixed.


Does your configure.in file have the PKG_PROG_PKG_CONFIG  macro. Refer
to
http://cvs.gnome.org/viewcvs/evolution-data-server/configure.in?r1=1.167r2=1.168


HTH,
Harish
On Thu, 2006-09-14 at 10:50 -0700, Mikeal Rogers wrote:
 I'm getting this dreaded configure error;
 
  checking for CAMEL_CFLAGS... -I/opt/local/include/evolution-data- 
  server-1.6
  checking for CAMEL_LIBS... -L/opt/local/lib -lcamel-1.2 -lcamel- 
  provider-1.2 -ledataserver-1.2
  checking for CAMEL_GROUPWISE_CFLAGS...
  checking for CAMEL_GROUPWISE_LIBS...
  configure: error: Package requirements (camel-provider-1.2  
  libedataserver-1.2 = 1.7.90 libegroupwise-1.2 = 1.7.90) were not  
  met.
  Consider adjusting the PKG_CONFIG_PATH environment variable if you
  installed software in a non-standard prefix.
 
  Alternatively you may set the CAMEL_GROUPWISE_CFLAGS and  
  CAMEL_GROUPWISE_LIBS environment variables
  to avoid the need to call pkg-config.  See the pkg-config man page for
  more details.
 
 BUT, pkg-config has camel, libedataserver and libegroupwise.
 
  $ pkg-config --list-all | grep libedataserver\|libegroupwise\|camel
  camel-provider-1.2camel-provider - The Evolution mail  
  access library
  libedataserver-1.2libedataserver - Utility library for  
  Evolution Data Server
  libegroupwise-1.2 libegroupwise - Client library for  
  accessing groupwise POA through SOAP interface
  libedataserverui-1.2  libedataserverui - GUI utility library  
  for Evolution Data Server
  camel-1.2 camel - the Evolution MIME message  
  handling library
 
 Any ideas?
 
 -Mikeal
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Code Freeze Break Requests

2006-09-04 Thread Harish Krishnaswamy
Thanks so much for the review and approval love :-).
The changes have been committed and the relevant bugs updated.

Thanks,
Harish


On Fri, 2006-09-01 at 16:03 +0200, Frederic Crozat wrote:
 Le vendredi 01 septembre 2006 à 15:27 +0200, Vincent Untz a écrit :
  Le vendredi 01 septembre 2006, à 18:54, Harish Krishnaswamy a écrit :
   
   Patch #1
   
   
   Bug :   http://bugzilla.gnome.org/show_bug.cgi?id=324118 
   
   Description :   Remove IMAP4rev1 from stable releases
  
  Approval 1/2.
 
 Approval 2/2
 
   
   Patch #2
   
   Bug :   http://bugzilla.gnome.org/show_bug.cgi?id=350250
   
   Description :   Show my message list from the cache first
  
  Quite a big patch. But I trust the evo team on this one. Approval 1/2.
 
 Same comment as vincent.
 
 Approval 2/2.
 
   
   Patch #3
   
   Bug :   http://bugzilla.gnome.org/show_bug.cgi?id=353763
   
   Description :   cannot enter text or edit memo summary field
  
  Approval 1/2.
 
 Approval 2/2
 

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] ANNOUNCE: Evolution 2.8.0, Evolution-Data-Server 1.8.0, GtkHTML 3.12.0 and Evolution Exchange 2.8.0

2006-09-04 Thread Harish Krishnaswamy
 since last unstable release
-

Harish K (#324118)
Sankar P (#350250)
Chenthill (#353763)
Nickolay V. Shmyrev (#334966).


Thanks,
Harish Krishnaswamy.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] ANNOUNCE: Evolution 2.8.0, Evolution-Data-Server 1.8.0, GtkHTML 3.12.0 and Evolution Exchange 2.8.0

2006-09-04 Thread Harish Krishnaswamy
 OK, great. Does one use libsoup-2.2.96 with this?
  Thanks,
 Bill

Evolution 2.8.0 and friends have been tested against libsoup-2.2.96 and
they work well with it. I am not aware if Dan is planning to make a
fresh release of libsoup for GNOME 2.16. but libsoup 2.2.96 should do
just fine.

Thanks,
Harish

 

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Request for patch review and freeze break in evolution

2006-09-03 Thread Harish Krishnaswamy
Hi Nickolay,

 Thanks for the patch. I have reviewed this patch (looks fine) but
following the due process, I prefer to have this reviewed by one of the
mail hackers before the release team is approached and if approved, the
change is absorbed into the release candidate. 


This is my current understanding of the problem :

This bug 

* has been around for quite a while
* 30 duplicates 
* it *is* irritating to have the app crash on exit and
* impacts the user perception of the app's quality adversely.
* has a patch.

Also,

* the impact on the application's feature/functionality is minimal.
* there is no data loss (this is an assumption I need the mailer guys to
validate that the crash does not abort any offline sync activity or the
botch the data)

The risk of absorbing this change needs to weighed against the impact of
the bug.

Let us have this in 2.8.0 if the mailer guys feel 

a) the change is not very risky and/or
b) the user impact is high enough to warrant this risk now.

else I would like to defer it for 2.8.1.


And yes, it would have been nice if this bug had been handled much
earlier before it blew up but then here we are...

Thanks,
Harish


On Sun, 2006-09-03 at 13:15 +0400, Nickolay V. Shmyrev wrote:
 Hi all
 Bug 334966 – Evolution crashes sometimes when closing main window
 http://bugzilla.gnome.org/show_bug.cgi?id=334966
 
 is a critical bug with more than 30 duplicates. It has simple patch
 included that should fix the problem. I think someone should review the
 patch and break code freeze to make users happy.
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e-d-s ABI breakage [ .so bump ] ...

2006-08-16 Thread Harish Krishnaswamy
On Mon, 2006-08-14 at 16:12 +0100, Michael Meeks wrote: 
 So,
 
   I spent a while digging into this and trying to patch it to remove the
 changes and create something that could be back-compat, so we could
 downgrade the .so version again.
 
   Then - I noticed that (apparently) SL 10.1 and SLED10 shipped with the
 new ABI anyway; but (presuambly) we just failed to bump the .so number;
 at least - I'm giving up until Wed. on the grounds of
 incomprehensibility - but it looks like:
 

The ebook ABI change has been committed to the 2.7.x series and not for
2.6.x which ships on SLED10 / SL 10.1.

   * abi breakage occured *
   * SL10.1/code-10 ships *
   * .so versions bumped
   - now -
   * Gnome 2.16 ships *
 
   Which makes it look like code-10 shipped with a libebook that (while
 having a different .so number) is fully compatible with the current ABI,
 (and yet incompatible with the previous version with the same .so
 number).

[Addressbook]
AFAICT, none of the ABI break changes in ebook were pushed into
autobuild and the version on SLED10 is not ABI compatible with the one
shipping with 2.7.90 and onwards. I will poke Varadhan [on CC] who
packages Evolution for SLED10 and get back to you.



   I guess that turns the problem into (mostly) a SUSE issue that we can
 work around by some duplication/linking of the the various libraries
 twice in our packages - [ugh]; and of course - reverting the ABI
 breakage wouldn't help us - it'd prolly just further confuse an already
 messy situation.
 
   Unless I'm confused again ?

[Calendar] Clock Applet (Panel) already uses the changed APIs for
handling recurrence data [1] and no other application in SLED10 is
affected by this - the libecal SONAME has not changed and it is binary
compatible with Evolution 2.7.91.  Technically - this is akin to zero
breakage on SONAMES, rpm deps et all and code-wise, the impact has
already been handled.


[1] JP had put in the fix to the panel.

-Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Evolution Team Meeting Today (16 Aug) stands canceled

2006-08-16 Thread Harish Krishnaswamy
Many of us in the team would be missing the meeting today as it turns
out to be extension of the Indian Independence day and the adjoining
festival.

We would not be meeting at irc today in the regular meeting. If you have
any issues that you wanted to discuss in the meeting, do please post
them on to this list.

Sorry for the late notice !

Regards,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] More e-d-s ABI breakage ?

2006-08-11 Thread Harish Krishnaswamy
On Fri, 2006-08-11 at 10:00 +0100, Michael Meeks wrote:
 So,
 --- source/drivers/evoab2/EApi.cxx
 +++ source/drivers/evoab2/EApi.cxx
 @@ -41,9 +41,10 @@
  #include EApi.h
  #endif
  static char *eBookLibNames[] = {
 - libebook.so.8, // evolution-2.0
 + libebook-1.2.so.9, // ** evolution-2.8 *
 + libebook-1.2.so.5, // evolution-2.4 and 2.6+
   libebook-1.2.so.3, // evolution-2.2
 - libebook-1.2.so.5  // evolution-2.4 and 2.6+
 + libebook.so.8  // evolution-2.0
  };
 
   WTF is going on !? why was this done ? what was the reason for this
 [ FWIW it seems that no other code changes were necessary (so far) ].


We discussed about the calendar changes in IRC but I believe it is
libebook that you really care about.

The changes in question are as follows :
http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.20r2=1.21
http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.21r2=1.22

The bugs that drove this change are :

  * http://bugzilla.gnome.org/show_bug.cgi?id=313533
   [ Allow EContactPhoto to refer to images with URIs]

  * http://bugzilla.gnome.org/show_bug.cgi?id=259536 
   [Missing Gadu-Gadu Messenger in Contact entry]

This was not a trigger-happy change. 

The patch for the first bug was submitted on 15 Aug 2005 (almost a year
ago) and that for the second on 3 Mar 2004 ( more than 2 years ago) and
had been in the back-burner only because we had wanted to preserve the
ABI.


The #313533 patch was vital for Ross Burton's dbus-based EDS and running
EDS on devices (say Nokia 770) would not be possible w/o this change.
The #259536 patch had been blocking a large number of users in Poland
where Gadu Gadu is the defacto IM standard.

In Bugzilla (cf. above links) and elsewhere, there have been vocal
demands for absorbing these patches. See my comment -
http://bugzilla.gnome.org/show_bug.cgi?id=259536#c22 We did aggregate
the changes before the break.

IMO, a single break after two major releases against such gains is
justifiable. These patches were reviewed and approved by the addressbook
hackers before the bump. 

Could these improvements have been absorbed w/o breaking the ABI and
with not too much additional costs in the process?

I do not know - nor did the patch authors or the reviewers. But if you
could show us, I am all willing to learn.

Can you also help me understand the severity of the break in OO.o ?
Why are the library files with SONAMEs hard-coded in a source file ?
Why would you not use (say) pkg-config instead ?


--Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] More e-d-s ABI breakage ?

2006-08-11 Thread Harish Krishnaswamy
On Fri, 2006-08-11 at 21:47 +0530, Harish Krishnaswamy wrote:
 On Fri, 2006-08-11 at 15:54 +0100, Michael Meeks wrote:
  Hi Harish,
  
  First - thanks for digging these changes out for me. But - no, I'm not
  just interested in ebook (though for OO.o that is all), but I'm
  -primarily- interested Evo. itself, in being able to use and test the
  most recent version to help avoid regressions, and indeed ship it for
  older platforms.
  
  So - if you could do the same for the other e-d-s libraries, it'd be
  great to see what changed there too.
  
  On Fri, 2006-08-11 at 20:03 +0530, Harish Krishnaswamy wrote:
   The changes in question are as follows :
   http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.20r2=1.21
  
  So - this changed the EContactPhoto structure - why ? surely that is
  rather pointless. You could easily have added an EContactMimePhoto type
  and added a synthetic back-compat field that would handle the old case
  [ if it was of (whatever) mime type you expected ]. So - I see no
  problem at all doing this compatibly whatsoever. Perhaps a few more
  (~20) lines of code tops.
  
 I had not reviewed the patch or explored the alternatives to avoid
 breakage. I would let the addressbook hackers to comment on that.
 I do think you have a point above, though.
 
 [1] OTH, I did approve the change into the release on the clear basis
 that ferrying Photo images on Contacts was prohibitively hampering the
 performance of the dbus port and the library had all to gain by ferrying
 a url instead.
 
   http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.21r2=1.22
  
  You converted a gpointer value to a 'const gpointer value' - I don't
  see that that is particularly necessary, or likely to break the ABI of
  anything unless it reflects some underlying lifecycle issue. Also the
  enum insertions were (this time) added at the end of the enumeration, so
  why should that break anything ? surely that's a compatible extension.
 
 Point taken - The original patch would have introduced a break - this
 was reworked as an append before it was committed.
 
   
   The #313533 patch was vital for Ross Burton's dbus-based EDS and running
   EDS on devices (say Nokia 770) would not be possible w/o this change.
  
  Nonsense - at least the link above has no API change that is necessary
  for dbus or Nokia 770 support - unless I'm missing something huge; good
  buzz-words though :-) 
  
 
 See http://www.go-evolution.org/DBus_Port_of_EDS .

The charts on the link seems to be broken ATM..I will post the
performance charts to the thread.

BTW, An interesting link I came across...
http://applications.linux.com/article.pl?sid=06/08/04/2158214from=rss

--Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] More e-d-s ABI breakage ?

2006-08-11 Thread Harish Krishnaswamy
On Fri, 2006-08-11 at 15:54 +0100, Michael Meeks wrote:
 Hi Harish,
 
   First - thanks for digging these changes out for me. But - no, I'm not
 just interested in ebook (though for OO.o that is all), but I'm
 -primarily- interested Evo. itself, in being able to use and test the
 most recent version to help avoid regressions, and indeed ship it for
 older platforms.
 
   So - if you could do the same for the other e-d-s libraries, it'd be
 great to see what changed there too.
 
 On Fri, 2006-08-11 at 20:03 +0530, Harish Krishnaswamy wrote:
  The changes in question are as follows :
  http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.20r2=1.21
 
   So - this changed the EContactPhoto structure - why ? surely that is
 rather pointless. You could easily have added an EContactMimePhoto type
 and added a synthetic back-compat field that would handle the old case
 [ if it was of (whatever) mime type you expected ]. So - I see no
 problem at all doing this compatibly whatsoever. Perhaps a few more
 (~20) lines of code tops.
 
I had not reviewed the patch or explored the alternatives to avoid
breakage. I would let the addressbook hackers to comment on that.
I do think you have a point above, though.

[1] OTH, I did approve the change into the release on the clear basis
that ferrying Photo images on Contacts was prohibitively hampering the
performance of the dbus port and the library had all to gain by ferrying
a url instead.

  http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.21r2=1.22
 
   You converted a gpointer value to a 'const gpointer value' - I don't
 see that that is particularly necessary, or likely to break the ABI of
 anything unless it reflects some underlying lifecycle issue. Also the
 enum insertions were (this time) added at the end of the enumeration, so
 why should that break anything ? surely that's a compatible extension.

Point taken - The original patch would have introduced a break - this
was reworked as an append before it was committed.

  
  The #313533 patch was vital for Ross Burton's dbus-based EDS and running
  EDS on devices (say Nokia 770) would not be possible w/o this change.
 
   Nonsense - at least the link above has no API change that is necessary
 for dbus or Nokia 770 support - unless I'm missing something huge; good
 buzz-words though :-) 
 

I feel sorry to know you would think I would stoop to get around the
issue with buzzwords. 

http://www.burtonini.com/blog//2006/Jul/22

The performance tests showed this was prohibitive for EDS on DBUS.  

quoting Devashish
 I didn't explored the problem any deeper but appears that there is
 some problem with e_book_get_contacts code.
 
 For detailed timing reports on this test download the following files
 and open them with sysprof.

See http://www.go-evolution.org/DBus_Port_of_EDS .

--Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] libecal and libedata-cal versions

2006-08-02 Thread Harish Krishnaswamy
On Mon, 2006-07-31 at 17:05 +0200, Øystein Gisnås wrote:
 When the version bump was commited to 2.6.x, it was not commited to
 the 2.7.x tree. Why was that? Because you only bump versions just
 before releases? I hope so. I noticed that libedata-cal versions were
 synced with 2.6.x in
 http://cvs.gnome.org/viewcvs/evolution-data-server/configure.in?r1=1.184r2=1.185.
 libecal was also bumped there, but AGE was not reset.
 
 Is the plan to reset AGE just before the final 2.8.0 release, or was
 it a mistake not to reset it before. The last thing we want is to
 release 2.8.0 with a lower SONAME version than 2.6.x..

Hi Øystein,

The recent libtool number bumps on libecal and libedata-cal do not map
to the corrective bump on 2.6.x (related to the recurrence changes).

slight digression

The changes pertain to the following (yet another ?) break on
libedata-cal

http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend-cache.h?r1=1.16r2=1.17

that splits the calendar cache based on the component types. This change
was introduced to address a host of serious performance woes wrt to
remote servers that manipulate events, tasks and journals together.
You can find the details in my ChangeLog at

http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend-cache.h


This also involved adding an introspective function to e-cal.h
http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libecal/e-cal.h?r1=1.30r2=1.31.


/slight digression

You are correct in pointing out that if this is left unchanged would
lead to a dubious condition where the later release ends up with a
SONAME version lesser than the previous stable branch.

I intend to set it right during the final release (both ecal and
edata-cal libraries need a correction) along with the camel lib bits.

Hope you can help me with some review on these proposed changes as well.

Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync

2006-07-31 Thread Harish Krishnaswamy
On Mon, 2006-07-31 at 03:08 -0400, Peter Colijn wrote:
 Suppose I am writing a new calendar backend. Which of these two
 interfaces is preferred? 

The requirements of your application and the characteristics of your
backend should guide the choice.

 If I implement ECalBackendSync, will
 operations on the calendar cause the UI to block?
 
Not necessarily. Separate the threads that do backend operations and
those that repaint UI.

HTH,
Harish



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Persisting ESource

2006-07-25 Thread Harish Krishnaswamy
On Mon, 2006-07-24 at 14:36 -0700, Scott Herscher wrote:
 Hey all.  I'm trying to add a property to an ESource instance after it
 has been created.  This change doesn't seem to persist at all.  In my
 ECalBackend class, I call e_source_set_property(...).  Looking at the
 code, e_source_set_property() just add the key /val to it's hashtable.
 Where and when does it get written out to disk?  How do I ensure this
 happens?
 
What is the property you wish to persist ?
Generic properties that need persistence should go into GConf (you can
refer to the schema that defines what are saved).ECalBackend objects
signals the change in property values to ECal objects and changes
to/from GConf are synchronized.

ESource properties specific to remote servers (such as GW) are usually
saved to the server and retrieved every session. 

HTH,
Harish
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] pvl_list structure in libical

2006-07-22 Thread Harish Krishnaswamy
Hi Mathew,


On Fri, 2006-07-14 at 17:06 -0400, Matthew Barnes wrote:
 Hi all, I've recently started maintaining Evolution for Red Hat.
 
snip
 The source code is dated November 1995 and looks to be isolated to
 libical.  It's basically a linked-list of void pointers, and I don't see
 anything useful here that GList doesn't already provide.  Plus, the
 utilization of GSlice for node allocations -- rather than raw
 malloc()/free() calls as pvl_list uses -- might yield a small
 performance improvement.
 
 I'm tempted to purge it from libical and replace it with a GList
 structure, but first I wanted to check with the upstream maintainers to
 see if they'd accept such a patch.  Are there other issues here that I'm
 not considering, such as API stability?


The libical module inside EDS is a source snapshot obtained from the
upstream few years ago and has remained as such ever since, save a few
functionality fixes and added functions.

Much of e-d-s clients (incl. Evolution) use the ECal APIs that wrap
around libical functionality though there are many places in Evolution
that still invoke libical functions directly.

It has been our direction to code the new functionality in ECal and
slowly ease out libical calls from Evolution in favor of ECal.

Yes. We would be interested in moving towards GSlice based memory
handling replacing icalmemory and use of G(S)List. It has been the
direction we have wanted to move for sometime but has been in the
back-burner in favor of stability fixes and feature additions.

I would be happy to work with you on this .


-Harish
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] no-inst headers camel-private.h?

2006-07-19 Thread Harish Krishnaswamy
On Wed, 2006-07-19 at 14:36 +0200, Smartuser wrote:
 Hi,
 
 I've some question about the camel-private.h
 Why is it a no-inst header according to the Makefile.am?
 As far as i know almost every provider depends on it.
 Is there a reason or is it just a mistake?
 
 Serjan Pruis

As the name suggests, I am led to believe that it is a private header
and intentionally not installable.
The mistake could actually be that the providers include this directly.

Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Compilation Linking flags

2006-07-18 Thread Harish Krishnaswamy
On Tue, 2006-07-18 at 17:02 -0400, Teresa Thomas wrote:
 How can I obtain the compilation and linking flags necessary for
 libical and libecal (EDS)? Pkg-config doesn't seem to be supported.
 
 Thanks. 

They are.

[EMAIL PROTECTED]:~ pkg-config --cflags libecal-1.2
-DORBIT2=1 -pthread
-I/home/kharish/opt/gnome/include/evolution-data-server-1.8
-I/home/kharish/opt/gnome/include/libgnome-2.0
-I/home/kharish/opt/gnome/include/libbonobo-2.0
-I/home/kharish/opt/gnome/include/glib-2.0
-I/home/kharish/opt/gnome/lib/glib-2.0/include
-I/home/kharish/opt/gnome/include/orbit-2.0
-I/home/kharish/opt/gnome/include/gconf/2
-I/home/kharish/opt/gnome/include/gnome-vfs-2.0
-I/home/kharish/opt/gnome/lib/gnome-vfs-2.0/include
-I/home/kharish/opt/gnome/include/bonobo-activation-2.0
-I/usr/include/libxml2


Cheers,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-13 Thread Harish Krishnaswamy
On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:

 At this moment, all those fall under the name of evolution comma data
 comma server. Some of these libraries (like Camel) don't necessarily
 have anything to do with the Evolution data that is being managed by
 the data server of Evolution.
 
 The E-mails and, folder-summaries, state data and summaries of Camel are
 *not at all* being managed by Evolutions data server. It's simply
 totally unrelated to the Evolutions data server. It looks like even some
 Novell employees don't know that, probably cause it's being marketed as
 one package.

Which Novell employees ? 

 It simply looks like Evolution developers didn't know where to stack all
 these Evolution libraries. And thought .. oh, we already had this
 Evolution data server thing .. lets simply put it there.

 It's not good a solution, imo. A library is a library. We have package
 systems (like yum and apt) to solve the dependency problem for users.

Evolution-Data-Server handles PIM data - (mail / calendaring / contacts
information, journals) packaging them together *does* make lot of sense.

I do not think you are suggesting that every library should be packaged
separately, are you ?


snip
 Conclusion .. all this coupling with Evolution and Evolution Data Server
 is making it harder for application developers to actually *use* the
 provided functionality.

The current packaging *is* good for users and packaging systems.
As for the application developers, you are certainly not the first one
to tread this path.

Ask Gaim. Clock applet. Contact applet. Open Office. Planner. Beagle.



Philip - Nobody is any better with these long winding arguments back and
forth. Can we get to the business at hand ?

Let us spend our energies together on the camel-mmap patch instead.


--Harish
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] strtok camel : Core dump [Was : strtok camel from evolution-data-server]

2006-07-07 Thread Harish Krishnaswamy
Hi Philip,


 Most Evolution people already know this. This is just the E-mail you 
  guys have been asking about (well, actually most of you guys asked me to
  make a bug in bugzilla).

Yes.  The Evolution Team has been in conversation with you by mail/irc
and in person (at GUADEC). 


  So or camel is going to be split from evolution-data-server, or I will
  fork camel.

This is not the language of a 'dialogue' -  this reads more like an
ultimatum.


 The one laptop per child project, Nokia (maemo) and maybe sooner or
 later other vendors like PalmSource are getting more and more interested
 in tinymail.


 Situation:
 --
 
 Tinymail depends on Camel. Camel gets shipped with e-d-s. Tinymail
 doesn't use *any* of the other e-d-s softwares, libraries nor its data.
 
 
 Observation:
 
 
 From reading code I *know* camel doesn't have to depend on e-d-s at all.
 It can very easily be cut-off from it. I could probably do this in a few
 hours work.

I disagree. As I am replying, I see Ross has already answered this
point. So, I will skip.


 THIS is ALL I need. Please DO understand this Evolution people.

Try reasons ending with 'This is what Evolution/GNOME needs'. We will
grok it better.


 
 Hacks like packaging tricks:
 
 
 I AM NOT going to require packaging tricks. Packaging tricks are hacks.
 I don't do hacks. Hacks are ugly. Hacks are win32. I didn't come to the
 opensource community to get myself stuck in hacks.
 
 I strongly disagree with hacks. I don't support hacks. I will not use
 hacks. I will fork if I'm forced to use hacks.
 
 

Packaging is NOT a hack. It is a win/win approach for the project and
its consumers.

Ross has already shown the BETTER WAY in ebook. And, the addressbook
component and the Evolution community have gained from his efforts.
So have Ross and Opened Hand.

I do not see what you want to achieve by a fork. But if you must, dear
friend, what can I say :

Camel is Open Source and licensed under the terms of LGPL. 


Your surprised pal,
--Harish


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] po/LINGUAS disaster, going on

2006-06-20 Thread Harish Krishnaswamy
My comments updated on 
http://bugzilla.gnome.org/show_bug.cgi?id=337996

-Harish

On Wed, 2006-06-14 at 09:03 -0400, Matthias Clasen wrote:
 evolution-exchange-2.7.3 is translation-less
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-19 Thread Harish Krishnaswamy
Tor,

 Please commit the patch to HEAD as well as the stable branch. The
change looks fine to me. I will also get the  unregister action tested
in the regular builds on the branches and perhaps in MacOS (I do not
know if it matters, but anyway!) as a routine but I do not expect any
surprises.


Thanks,
Harish



On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
 lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
 
  If my analysis is correct, this means that attempting to do a CORBA
  object unregistration in the GObject finalize method is too late, isn't
  it?
 
 I tested by applying this simple patch to e-shell.c, moving the
 bonobo_activation_active_server_unregister() call from impl_finalize()
 to notify_no_windows_left_idle_cb():
 
 Index: shell/e-shell.c
 ===
 RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
 retrieving revision 1.272
 diff -p -u -r1.272 e-shell.c
 --- shell/e-shell.c   30 Jan 2006 11:49:53 -  1.272
 +++ shell/e-shell.c   16 Jun 2006 23:17:50 -
 @@ -360,13 +360,18 @@ static gboolean
  notify_no_windows_left_idle_cb (void *data)
  {
   EShell *shell;
 + EShellPrivate *priv;
  
   shell = E_SHELL (data);
 + priv = shell-priv;
  
   set_interactive (shell, FALSE);
  
   g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
  
 + if (priv-iid != NULL)
 + bonobo_activation_active_server_unregister (priv-iid,
 + 
 bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
   bonobo_object_unref (BONOBO_OBJECT (shell));
  
   return FALSE;
 @@ -467,10 +472,6 @@ impl_finalize (GObject *object)
  
   shell = E_SHELL (object);
   priv = shell-priv;
 -
 - if (priv-iid != NULL)
 - bonobo_activation_active_server_unregister (priv-iid,
 - 
 bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
  
   e_free_string_list (priv-crash_type_names);
  
 And lo and behold, it works! Now the ESHell gets unregistered, and when
 starting Evolution again it manages to register its EShell and contact
 the already running e-d-s etc.
 
 OK to apply this patch to HEAD and stable? ChangeLog entry:
 
 2006-06-17  Tor Lillqvist  [EMAIL PROTECTED]
 
   * e-shell.c (impl_finalize): Don't call
   bonobo_activation_active_server_unregister() here, it's too late,
   the EShell Bonobo object has already been deactivated and its
   associated CORBA object is NULL.
   (notify_no_windows_left_idle_cb): Instead, call
   bonobo_activation_active_server_unregister() here, when the EShell
   Bonobo object is still fully active.
 
 
 I should still of course also investigate why the other (unknown)
 mechanism which causes unregistration to happen anyway on Unix doesn't
 work on Windows...
 
 --tml
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] How would this work?

2006-06-11 Thread Harish Krishnaswamy
Yes. It is indeed possible for you to use the IMAP camel provider to
talk to your custom server. Just have a look at how the GroupWise
provider is implemented.

See camel_provider_module_init () in
http://cvs.gnome.org/viewcvs/evolution-data-server/camel/providers/groupwise/camel-groupwise-provider.c?rev=1.33view=markup

which (when use_imap is TRUE) sets the groupwise camel provider store to
that of imap.

The groupwise-account-setup plugin is also a good working model for you
to base the zimbra account creation on. This has some limitations
currently which will be addressed in near future (and hence likely to
change).


--Harish

On Sat, 2006-06-10 at 15:55 -0700, Scott Herscher wrote:
 Hey all. I'm wondering if it's possible to write a custom backend for
 evolution and evolution-data-server that re-uses the IMAP camel
 provider?
 
 I've written a custom e-book library that kinda works, and I'm getting
 started on writing a custom e-cal backend that will do calendaring.
 In the interest of time, and since the server I'm working with
 supports the IMAP protocol, I was hoping I could do something simple
 like reuse the IMAP camel-provider and use my custom addressbook and
 calendar plugins in setting the account up.  Is this possible?  If so,
 how would I do something like that?
 
 Scott
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Fix for #331743 - crash on first start

2006-06-07 Thread Harish Krishnaswamy
Yes. I have approved the patch in bugzilla.

Thanks,
Harish
On Wed, 2006-06-07 at 10:22 -0500, Federico Mena Quintero wrote:
 Hi,
 
 Please look at http://bugzilla.gnome.org/show_bug.cgi?id=331743
 
 Evolution 2.7 crashes on startup if you run it within a clean user
 account.  This happens because EMap (the map widget for the timezone
 configuration dialog) uses an incorrect signal marshaller.
 
 The attached patch fixes this.  Is it OK to commit?
 
   Federico
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Bogofilter plugin 0.2.0

2006-05-31 Thread Harish Krishnaswamy
Hi,

 P.S. I'm still willing and able to adapt the source for inclusion in the
 Evolution source tree, with the developers' consent. However,
 introducing choice between the two available junk plugins may render the
 user's configuration non-obvious, so I understand if you wish to keep
 only one bundled with Evolution.
We are open to exploring and assessing alternatives with respect to
handling spam in Evolution. Taking this up for discussion in the
Evolution meeting later today.


Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Your system configuration does not matches evolution configuration

2006-05-18 Thread Harish Krishnaswamy
On Tue, 2006-05-16 at 21:35 +0100, Keith Sharp wrote:

 Is there a bug open for this?  I can pretty reliably recreate this on my
 laptop by running Evolution, stopping Evolution cleanly, hibernating my
 laptop, resuming and trying to start Evolution.
 
 Keith.

The message means what it says - The configuration is not what it should
be for the application to run well.

The work-arounds suggested all refer to environments where multiple
versions of evolution/eds co-exist - and tell you how to recover from a
bad combination.

The action required towards a full solution is to get the environment to
a valid state - remove conflicting versions or isolating matched
versions in your shell environment through proper settings to
BONOBO_ACTIVATION_PATH, LD_LIBRARY_PATH etc.

So this is not a 'bug' that can be fixed by modifying the code. What may
be a bug indeed is documentation (or a lack of it) on the prevention and
recovery of such errors.

Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] A bug for todo conduit.

2006-05-13 Thread Harish Krishnaswamy
You are right. I am moving the timezone check ahead of init-ing the
calendar server.

Thanks,
Harish

On Sat, 2006-05-13 at 11:25 +0800, Yu-Hui Liu wrote:
 Just take a look at evolution/calendar/conduits/todo/todo-conduit.c,
 found a bug.
 http://cvs.gnome.org/viewcvs/evolution/calendar/conduits/todo/todo-conduit.c?rev=1.97view=markup
 The code below:
   if (start_calendar_server (ctxt) != 0) {
   WARN(_(Could not start evolution-data-server));
   gnome_pilot_conduit_error (conduit, _(Could not start 
 evolution-data-server));
   return -1;
   }
 
   /* Get the timezone */
   ctxt-timezone = get_default_timezone ();
   if (ctxt-timezone == NULL)
   return -1;
   LOG (g_message (   Using timezone: %s, icaltimezone_get_tzid 
 (ctxt-timezone) ));
 should be:
   /* Get the timezone */
   ctxt-timezone = get_default_timezone ();
   if (ctxt-timezone == NULL)
   return -1;
   LOG (g_message (   Using timezone: %s, icaltimezone_get_tzid 
 (ctxt-timezone) ));
   if (start_calendar_server (ctxt) != 0) {
   WARN(_(Could not start evolution-data-server));
   gnome_pilot_conduit_error (conduit, _(Could not start 
 evolution-data-server));
   return -1;
   }
 
 Otherwise, the ctxt-timezone will be an empty pointer.
 
 Well, there's some other bugs so the todo conduits doesn't work now. Other 
 conduits work well. May someone take a look at this?
 
 Thanks.
 Calvin
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [ANNOUNCE] Unstable - Evolution 2.7.1, Evolution-Data-Server 1.7.1, Evolution-Exchange 2.7.1 and GtkHTML 3.11.1

2006-04-25 Thread Harish Krishnaswamy
Hi,

One of my sanity tests on the tarballs failed while testing a GW account
operation. I am still investigating the problem and not entirely sure if
it was a libsoup integration issue.
   It did work against the older version of the library and hence I had
referred to the latter, intentionally, so I could roll out the tarballs
in time.

The 2.2.6.1 version should work fine for other providers and most
scenarios in GW too, though.

Harish





On Tue, 2006-04-25 at 17:54 +0200, Andre Klapper wrote:
 Am Montag, den 24.04.2006, 22:50 +0530 schrieb Harish Krishnaswamy: 
  You can download the following :
  [...]
  http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.6.1.tar.bz2
 
 guess this should better be
 http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.92.tar.bz2  
 :-)
 
 cheers,
 andre
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Request for adding version information to libcamel soname

2006-04-24 Thread Harish Krishnaswamy
Hi Øystein and Heikki,

 My hearty wishes to both of you, the new Debian Evolution package
maintainers :-). Looking forward to work with you towards a better
'Evolution' for the world at large.

 On the bigger point, I am in favor of your suggestion on the versioning
scheme for Camel. On finer thoughts, I would like to evaluate the likely
impact of this change with the mail hackers, keeping in mind any likely
changes to the API during the current development cycle as well as the
compatibility constraints on existing deployments.

I will get back to you in a couple of days.

Thanks,
Harish

On Sun, 2006-04-23 at 23:43 +0200, Øystein Gisnås wrote:
 The Debian Evolution Maintainer Team is planning the upload of Evolution
 2.6 to unstable to happen very soon. Before the upload, we'd like
 feedback from Evolution developers on the biggest change we make to the
 upstream release. In specific, Harish confirmed bug #321372, which is
 what this is about, and also Parthasarathi probably have valuable
 comments on this topic.
 
 The first part of the change was described in the previous mail in this
 thread. In addition to using version numbers to libcamel (contrast to
 today's 0:0:0), we plan on moving the private libcamel provider
 libraries to an install location that is version specific. The current
 location is /usr/lib/evolution-data-server-1.2/camel-providers/, which
 includes the API version, but not libcamel version. As far as I know, it
 has already been discussed to name the e-d-s directory differently. Do
 you have an update on if/when that will happen? What we will do on the
 debian side is to move the contents of camel-providers to
 camel-providers/8, or alternatively name it camel-providers-8 or
 similar.
 
 We highly value having the same names and versions in our releases as in
 upstream. If you could give some indications on what changes will be
 made upstream, and what names and versions will be used for this, we
 could use that name/version scheme already and avoid future conflicts.
 
 Our release will not be delayed indefinitely, but we'll put effort into
 avoiding a diversion from upstream directions. Therefore a quick answer
 will be greatly appreciated.
 
 Thanks,
 

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] a security issue with Evolution

2006-04-22 Thread Harish Krishnaswamy
Which version of Evolution are you referring to ?
Evolution 2.6 does not let you send mails through accounts that have not
been enabled. This issue has been fixed already.

That also leads me to kindly remind you - Upgrade, Upgrade :-)

Thanks,
Harish

On Sat, 2006-04-22 at 02:12 -0300, Jose Tavares wrote:
 Today I was at FISL (Forum Internacional Software Livre) accessing the
 net through the wifi network they were offering. It was an open wifi
 network with no crypto at all..
 
 So, using Evolution I needed do disable the access of my email accounts
 whose pop/smtp does not offer a secure connection. Yes, there's a big
 provider here in Brazil that does not offer secure connection to its
 pop/smtp.
 
 The problem is that I left enable just an account at gmail that is
 configured to make secure connections..
 
 After that, I took an old email in my outbox that had been sent with the
 account from the unsecured provider and selected Edit as new message.
 Then, I thought the From: field would have been changed automatically to
 my new configured default connection.
 
 Guess what happened? I sent the email with the From: field from the
 unsecure provider and Evolution did established an unsecure conection to
 the unsecure provider and sent my plain password through the network
 even with the unsecure account marked as disabled in Evolution!!
 
 []
 JA Tavares
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Google Calendar sync

2006-04-22 Thread Harish Krishnaswamy

Hi Peter,

  Thanks for your interest. I am not aware of anyone working on Google
Calendar ATM. You have the head start :). The way to approach this would
be to write a new Calendar backend in Evolution-Data-Server (in C,
yes). 

To start, 

  *  Let everybody know you are working on it and pen your thoughts
on go-evolution.org.  You might attract a few helping hands.  
  *  The GW calendar backend (which uses GroupWise SOAP APIs) or the
http backend would be nice references to model your design on. 
  * Let me know how much time/effort you plan to put into this and
if you would like it to be added to the 2.8 roadmap.

Feel free to ping the Evolution Team for any further information.

Harish


On Fri, 2006-04-21 at 13:27 -0400, Peter Colijn wrote:
 Hi,
 
 Is anyone working on a way to do 2-way sync with Google Calendar
 (using the XML-based API)? If not, I'd be interested in doing this. I
 worked on the Google Calendar team and am quite familiar with the
 product. I've also done some Evolution work in the past, but it was
 the 1.4.x days so I imagine things are quite different now. Is this
 something that could be done in an EPlugin? Or would I need to write a
 new calendar backend in C?
 
 Any pointers or tips as to the best way to do this would be appreciated.
 
 Thanks!
 
 Peter
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] unprofessional or what

2006-04-17 Thread Harish Krishnaswamy
Hi Ralf,

On Mon, 2006-04-17 at 17:09 +0200, Ralf Engels wrote:
snip

 Bugs at bugzilla.gnome.org don't get re-viewed. 
 So no checking, no assigning and even my patched bugs just lay around.
 Since a month. 
 Even Microsoft is faster!

I am sorry your patch did not receive more love than it so rightly
deserved. We do encounter a huge amount of traffic in terms of patches
and bugs - more than we manage to handle as we would like to.

You may perhaps appreciate that Evolution has consistently topped the
weekly bug activity in terms of bug reports and triaging for several
months running.
http://bugzilla.gnome.org/reports/weekly-bug-summary.html

Thanks to lots of community love  (andre, guenther) - you just need to
look at the bugzilla scores of some of these hackers (who work almost
exclusively on Evolution) to get a grasp of what is being done here.

 Patches at the patches mailing list don't get re-viewed. 
 Ok, maybe that's not needed.

Lately, much of this is moving into Bugzilla and hence some of them do
not get replied. A glance at the commit traffic (thanks to the core
Evolution team and our friends from Sun, China) might give you a better
picture.

 And then we have the evolution homepage where it claims that the last
 IRC team meeting was six months ago.
 Ok, maybe Evolution is stable enough that we don't need such a thing any
 more.

We have had consistent problems in managing this site remotely and
keeping this updated. My bad in having let this slip down my to-dos. 
I will treat this as a wake-up call and get this fixed.

Much of the activity has in fact moved to go-evolution.org - we should
be making it THE official project base as soon as we can get the issues
resolved.
 
Our weekly IRC meetings do happen on Wednesdays at 1000 IST. (You are
welcome, as is every Evo-lover) - We can starting posting the minutes
regularly once we get rid of the site woes mentioned above.

I take it that your mail reflects your love and concern for the project.
We do our best and keep trying to get better - but we are humans too :-)

Thanks for this opportunity to let me acknowledge the work of my
wonderful colleagues and community volunteers. 

And yes, I will follow-up your bug reports and patches - by the end of
the day.


 be professional. Update the homepage, go through bugzilla and write some
 comments to patches on the patches mailing list.
 Or rot...
 
 BR,
 Ralf

I prefer Option A. Thank you.

- Harish


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] IRC meeting cancelled

2006-04-13 Thread Harish Krishnaswamy
Hi all,

  The weekly IRC meeting scheduled for 1000 UTC today stands cancelled
as it is a day
off in Bangalore and the team is not in office.

Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Announce : Evolution 2.6.0, EDS 1.6.0, Evolution-exchange 2.6.0 and Gtkhtml 3.10.0 releases

2006-03-14 Thread Harish Krishnaswamy
Hi All,

The Evolution Team is pleased to announce the release of Evolution
2.6.0.


   What is new in 2.6 ?


# Memo Component
# New Look for the Event/Task/Meeting Editor
# Calendar Publishing support
# CalDAV support
# Network Manager support
# HULA connectivity support
# Improved GroupWise support
# Improved Event Recurrence support
# Calendar Tooltips
# CSV/tab importers for Mozilla, Outlook and Evolution formats
# Contact list support for LDAP addressbooks
# Support for saving Advanced Searches for Address books
# Support for Prioritizing messages in the composer
# Lots of bug fixes and lots of other User Interface Improvements


   Where can you get this ?


You can find the tarballs here :

http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.6/evolution-2.6.0.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.6/evolution-data-server-1.6.0.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.6/evolution-exchange-2.6.0.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.10/gtkhtml-3.10.0.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.91.tar.bz2

Reporting Bugs

If you have problems with 2.6.0, please take the time to submit the bug
using Bug Buddy or at http://bugzilla.gnome.org.  Try to fill in as
much detail as you can regarding the circumstances that lead to the
problem.


Kindly check if your bug has been reported before by using the
search functionality of Bugzilla.

More information is available at the project website
http://www.gnome.org/projects/evolution
and the project wiki :
http://go-evolution.org/

Thanks,
Harish




___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Re: Gender ...

2006-02-16 Thread Harish Krishnaswamy

On Wed, 2006-02-15 at 12:11 +, michael meeks wrote:
 So,
 
   At the risk of offending the gender-confused; it would be -extremely-
 useful to have a Gender boolean in the evolution addresbook [ of course,
 perhaps there is  I'm just missing it but I dug into the code ].

No. There isn't.

   The reason is OO.o will vary it's salutation on gender; ie.
 
   Dear Mrs. Foo
   Dear Mr. Foo
 
   etc. - now one can argue whether this is broken etc. but there it
 is ;-) the current ergonomics are rather built around this - and, you
 can see that such a boolean internationalizes rather nicely.

Why not use 'Title' which is more generic and appropriate - there are
any number of use-cases where a boolean gender would not fit. Addressing
a Doctor / the Queen ;-) for eg.

   So - the question is: can we have it ? currently the OO.o mail merge is
 rather feeble without it.

Certainly not on Evo 2.6 at this point, you perhaps already knew that.
Any reason why 'Title' cannot fit your needs ?

Regards,
Harish
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Re: evolution and pango in 2.13.90 don't play nice

2006-02-02 Thread Harish Krishnaswamy

 At gentoo, we patched the gtkhtml-2.13.90 tarball.  A new one would be
 nice, but is not necessary.
 

fwiw, I rolled out Gtkhtml-2.13.90.1 tarballs yesterday that have
Matthias' fix for the pango issue. 

Regards,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] String/UI change notifications for commits done on UI Hackfest

2006-01-12 Thread Harish Krishnaswamy
hi All,

  We are in String/UI Change announcement period and I notice the due
notifications to gnome-doc lists have not been sent for patches related
to the UI Hackfest. So I will be sending a consolidated notification
citing all the changes done as part of the UI Hackfest with a cut-off on
Jan 13 3:00 pm IST.  Please ensure any further commits with UI/String
changes beyond this time are duly notified to the lists.

See
http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00092.html

for further information.

Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Remove duplicate e-util-marshal.list in evolution/widgets/misc

2006-01-10 Thread Harish Krishnaswamy
This change looks fine to me. Actually, it must have been just oversight
not having removed e-util-marshal.list from evolution/widgets/misc.
 
Srini has been working on widgets/* more than any of us lately, though.
Thoughts, Srini ?

Thanks,
Harish
On Tue, 2006-01-10 at 18:47 +0800, simon.zheng wrote:
 Hi all,
 
 Here is bug information.
 http://bugzilla.gnome.org/show_bug.cgi?id=323529
 
 We found another duplicate file e-util-marshal.list. There's two
 copies of e-util-marshal.list in and evo/e-util and
 evo/widgets/misc. They're 100% identical. What's more, we noticed the
 other modules in evo/widgets, such as evo/widgets/table and
 evo/widgets/text, use the copy in evo/e-util rather than their own
 built-in copies. We think the one in evo/widgets/misc might be dropped.
 
 Attached the patch, pls review and comment.
 
 Thanks,
 -Simon
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Spam attack on go-evolution.org

2005-12-19 Thread Harish Krishnaswamy
I am away from office - on leave and would be back only on Jan.

Srini/Varadhan, can you please look into the same ?

Thanks,
Harish

On Mon, 2005-12-19 at 10:28 -0500, JP Rosevear wrote:
 On Mon, 2005-12-19 at 14:58 +, Tor Lillqvist wrote:
  Check out the Recent Changes page... Lots of pages have been filled with
  spam. Apparently only pages that were empty until now, though?
 
 Same thing happened to the beagle wiki last week. Joe added Captcha
 (http://en.wikipedia.org/wiki/Captcha) support there to prevent further
 issues.
 
 -JP

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Future of Evolution Spellchecking?

2005-12-15 Thread Harish Krishnaswamy
Andre,

  
On Tue, 2005-12-13 at 14:21 +0100, Andre Klapper wrote:

 so would that patch be accepted? any comments or thoughts on this? and
 by whom would it be accepted, because who maintains gnome-spell anymore?
 i know that radek was the last person working on gnome-spell (and harish
 as evolution maintainer told me to mail him directly), but i have not
 received an answer yet (it has been three days), and the string
 announcement period is getting closer (yes, the names of the languages
 have to be translated).

 so can someone assure me that there will be a gnome-spell release for
 2.14 including this patch if i would provide it?
 otherwise it's just worthless and people keep waiting for spellchecking
 support for their language.
 
 keep in mind that it's ridiculous to have the entire gnome-desktop
 translated to xhosa, but not being able to have xhosa spellchecking in
 gnome-desktop's mailer[7], to name one example.
 keep in mind that we are excluding many, many potential customers out
 there (...this one goes out to novell ;-).
This is more about gnome-spell and I am not qualified to answer that.
But I agree it has a huge impact on Evolution users. I'll do a follow-up
on this. 


 in a long run (gnome 2.16?), gnome-spell should switch to use enchant
 instead of aspell. enchant is capable of having multiple  backends loaded
 at once (see backends section at [8]), including aspell.
 but would anyone work on that port?
 
It is on the table - anyone ? :-)

Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Sending mails using disabled accounts

2005-11-29 Thread Harish Krishnaswamy
On Wed, 2005-11-30 at 00:38 +0100, Philip Van Hoof wrote:
 It looks like current CVS does not allow sending E-mails uing disabled
 accounts.
 
 I very often disable E-mail accounts to make it possible to choose
 between multiple of my E-mail addresses. 

you mean - not having them shown up in the mail folders tree ?
How does disabling help you in choosing more easily ?
 Why is this possibility blocked?

It boils down to what one defines 'disabling' an account as. 
I guess you mean it as 'I do not want to see the mails in the account
till I enable it again but it is available right _there_ for all other
purposes - Sending mails, Draft/Sent Item settings..etc..' - (more in
the narrower sense of 'visibility'). 

A lot of new users suggested they interpret 'disabling' as
'I do not want anything to do with that account till I enable it
again'.
What has been done now is to align the behavior to what it suggests (at
least to the many). 

Partha/Shreyas, would you like to shed more light here ?

Harish


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Re: About evolution-data-server/libedataser and evolution/e-utils

2005-11-24 Thread Harish Krishnaswamy
On Thu, 2005-11-24 at 16:33 +0800, Irene wrote:
 Hi, Harish 
 
 I built evolution 2.6 on my Solaris X86 the other day. The build process
 was successful, however, as soon as I started evolution-2.6, it crashed.
 We investigated this problem and arrived at the following conclusions:
 
 camel_vee_folder_hash_folder in
 evolution-data-server/camle/camel-vee-folder.c invokes functions
 including md5_init, md5_update and md5_final. The fact is, two copies of
 md5_utils.[c|h] with exactly same functions defined, exist in the
 evolution system, one in evolution-data-server/libedataser and the other
 in evolution/e-utils. 
Right. This is the result of an incomplete migration of the files and
the existence of duplicates is a known structural issue - though we have
not seen bugs/functional breakage yet. This just explains why the
problem has existed w/o crying for attention for this long- we do need
to fix it.


 Camel-vee-folder.c includes
 evolution-data-server/libedataserver/md5-utils.h, but when evolution
 runs, the md5_* functions in evolution/e-utils/md5-utils.c instead of
 those in evolution-data-server/libedataserver/md5-utils.c are invoked,
 which we think should not be the case. 
 
Building with an eye for this detail (building against the right
function) solves this problem. This is why it works on Linux, i guess. I
need to see how Solaris x86 handles this.

 When we went further into this issue, we saw that there's a huge lot of
 duplication in evolution-data-server/libedataser and evolution/e-utils.
 With such duplications, similar problems may surface in the future when
 one copy of the code is modified while the other remains unchanged. 
 
 We think that something should be done to solve this problem. 
yes. let us get this discussed on the meeting next week. I would love if
someone can volunteer to do a detailed audit on this duplication and
chalk out how we can get rid of the cruft. (In some cases, I suspect
they may not be exact duplicates and both may be required in that form
by different pieces). 

Takers, you can count on me to chip in to lend a hand :-)

Cheers,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

2005-11-24 Thread Harish Krishnaswamy
On Thu, 2005-11-24 at 09:27 +, Ross Burton wrote:
 On Thu, 2005-11-24 at 09:19 +, Ross Burton wrote:
  On Thu, 2005-11-24 at 16:33 +0800, Irene wrote:
   Currently, the MD5Context structures in
   evolution-data-server/libedataserver/md5-utils.h and
   evolution/e-utils/md5-utils.h are different with the first one not
   having a doByteReverse member. 
  
  Hm, that would be my fault: I've been working with e-d-s and cleaned up
  the libedataserver/md5-utils to remove the doByteReverse member.  The
  obvious solution is to remove md5-utils from e-utils.
 
 It looks as if the md5-utils in e-util isn't used at all in Evolution,
 OK to remove it from evolution HEAD?

I agree. Mailer guys, anyone think otherwise ?

 Ross

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

2005-11-24 Thread Harish Krishnaswamy
  Md5-utils.ch are not the only files that are duplicated. Most of the
  files in evolution/e-util have similar copies in
  evolution-data-server/libedataserver.

Yes. To be more precise, evolution-exchange in addition to e-util and
libedataserver :-). 

 I've created a wiki page http://live.gnome.org/EvolutionEUtilDieDieDie
 listing the files which are identical, which are different, etc, to
 track this.
 
 Ross

Thanks Ross :-). That really gets us moving to the next step.

Shreyas had taken the cause up [http://go-evolution.org/Evo2.6#Misc]
early during the cycle and IIRC, had started doing something on it too. 
Shreyas ?


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Formated Printing

2005-11-15 Thread Harish Krishnaswamy
Hi Greg,

   Thanks for your interest.
On Sat, 2005-11-12 at 13:15 -0600, Gregory P. Ennis wrote:
snip
 Can you point me in the right direction, or how can I help to work on
 the solution.
 
Drop in at irc.gimp.org at #evolution (or better still, on
go-evolution.org) we can kick-start a discussion on this.
(The planning page lacks sufficient details concerning this area.
guenther - hint...hint ;-))
Dave Malcolm has worked a bit on the printing stuff and
the mailer guys would be useful contact points.
I can pitch in to help too (with slight delays on find-greps ) :-)

thanks,
harish

 
 Thanks,
 
 Greg Ennis
 
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] e-util compiling errors evo-2.2.1.1

2005-11-01 Thread Harish Krishnaswamy
your prefix looks suspicious. Just do a make clean to get rid of the
generated files
and regenerate your Makefile just to be sure..

On Tue, 2005-11-01 at 08:07 -0500, AG wrote:
 I believe I've got a simple compile error, but I've not found very many
 answers via the ubiquitous google search..
 
 Any ideas??
 Thx in advance for any suggestions.
 
 make[3]: Leaving directory `/tmp/evolution-2.2.1.1/data'
 make[2]: Leaving directory `/tmp/evolution-2.2.1.1/data'
 Making all in e-util
 make[2]: Entering directory `/tmp/evolution-2.2.1.1/e-util'
 (  --prefix=e_util_marshal ./e-util-marshal.list --header 
 e-util-marshal.h.tmp \
  mv e-util-marshal.h.tmp e-util-marshal.h ) || ( rm -f
 e-util-marshal.h.tmp  exit 1 )
 /bin/sh: --prefix=e_util_marshal: command not found
 make[2]: *** [e-util-marshal.h] Error 1
 make[2]: Leaving directory `/tmp/evolution-2.2.1.1/e-util'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/tmp/evolution-2.2.1.1'
 make: *** [all] Error 2
 
 

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Feature Requests

2005-09-16 Thread Harish Krishnaswamy
Please file a bug (enhancement) against Evolution in bugzilla.gnome.org.
Kicking off a discussion in the Evolution wiki
(http://go-evolution.org/Evo2.6) can help get more immediate attention.

--Harish


On Thu, 2005-09-15 at 22:40 -0600, Alejandro Bonilla Beeche wrote:
 Hi,
 
   I have a couple of feature requests for Evolution, where can I send
 these to?
 
 i.e. Be able to do ctrl+z in case that you deleted one extra email and
 want it back into the Inbox.
 
 .Alejandro
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] ANNOUNCE : Evolution 2.4.0 and Evolution-Data-Server 1.4.0 Release

2005-09-05 Thread Harish Krishnaswamy
Hi All, 

The Evolution Team is pleased to announce the release of Evolution
2.4.0 and Evolution-Data-Server 1.4.0. 

What is new since Evolution 2.2 ?
-

- A new menu layout (More HIG compliant)
- Inline PGP Signature/Encryption support.
- Performance enhancements on Camel/GroupWise Backends.
- Auto-fit Image Attachments
- Support for GroupWise proxy accounts
- Extended EPlugin support, importers as an EPlugin.
- Thunderbird-compatible storage of labels on IMAP.
- Support for delegation of meetings (Calendar)
- Marcus Baines Line (calendar) 
- Removal of Exchange button and seamless access to Exchange 
  through Evolution Mail/Calendar/Task components.


And, Evolution-Data-Server is now available in LGPL.



You can download the following :

http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.4/evolution-2.4.0.tar.gz
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.4/evolution-data-server-1.4.0.tar.gz
http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.4/evolution-exchange-2.4.0.tar.gz
http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.8/gtkhtml-3.8.0.tar.gz
http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.6.tar.gz

Reporting Bugs

If you have problems with 2.4.0, please take the time to submit the bug
using Bug Buddy or at http://bugzilla.gnome.org.  Try to fill in as
much detail as you can regarding the circumstances that lead to the
problem.

If you have a feature request, you can also file that at
http://bugzilla.gnome.org/ don't be discouraged if you don't hear from
us right away, we get hundreds of feature requests a year.

You can also check if your bug has been reported before by using the
search functionality of Bugzilla.

More information is available at the project website
http://www.gnome.org/projects/evolution
and the project wiki :
http://go-evolution.org/

Thanks,
Harish




___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers