I have been trying to sort out an import issue at the user-list. I
guess the level of inquiry falls within the hacking domain. I have some
CSV and VCF files of my Contacts created with Windows-7 export tool. I
plan to import the contacts into Evolution running on Fedora Linux
(Lovelock). My Evo
==5510== 41 bytes in 1 blocks are possibly lost in loss record 8,473 of 17,762
==5510==at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==5510==by 0x3B6A048B52: g_malloc (gmem.c:164)
==5510==by 0x3B6A06101D: g_strdup (gstrfuncs.c:102)
==5510==by 0x1693D7B1: ews_message_info_clone (cam
On Friday 08 April 2011 Milan Crha wrote:
> [...]
> With respect of "fetch on demand", it'll be tricky to achieve, to make
> this done right on each operation which deals with the calendar
> component in a certain way (operations like copy, move, send and so on).
> But there is some API function,
On Fri, 2011-04-08 at 15:31 +0200, Patrick Ohly wrote:
> On Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote:
> > Once this passes muster, I'll push these patches (probably *without* the
> > NTLM bits, if you're looking closely at what I included) to the
> > gnome-2-32 branches and perhaps star
On Fri, 2011-04-08 at 15:06 +0200, Christian Hilberg wrote:
> There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're
> sitting on presently). That means we cannot maintain a backend-private file
> cache with this version, since we cannot inform Evo about it ... is that
> cor
On Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote:
> Once this passes muster, I'll push these patches (probably *without* the
> NTLM bits, if you're looking closely at what I included) to the
> gnome-2-32 branches and perhaps start doing a 'final call' for 2.32.3
> candidate bugs/patches.
Pl
Hi everyone,
thanks for the input so far.
On Friday 08 April 2011 David Woodhouse wrote:
> On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote:
> > On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote:
> > > We could use Evolution's file-link attachment mechanism by writing into
> > > Evos
Hi there,
I have (perhaps) an unusal setup - I get mail to an IMAP inbox, and
then filter much of it off to local storage, and move the rest manually
as I need to.
I have around 1000 mostly short, text only messages in my IMAP inbox;
and yet:
du -m
/home/michael/.local/share/evo
On Fri, 2011-04-08 at 12:17 +0100, David Woodhouse wrote:
>
> Perhaps the best option is to have a call to EDS which asks it to
> 'resolve' the attachment into a local file URL instead of a remote
> one?
The more I think about this, the more I like it. Add an
X-EVOLUTION-UNRESOLVED-ATTACH: proper
On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote:
> On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote:
> > We could use Evolution's file-link attachment mechanism by writing into
> > Evos
> > file cache from the backend and placing the file paths into the
> > ECalComponent
> > when
On Fri, 2011-04-08 at 10:39 +0200, sean finney wrote:
> On Fri, Apr 08, 2011 at 09:08:28AM +0100, David Woodhouse wrote:
> > You're more than welcome to use git.infradead.org if you want.
>
> Well it would be nice to get them *somewhere*, anyway, since it does feel
> silly that there are a number
On Mon, 2011-04-04 at 08:53 +0200, Milan Crha wrote:
> On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote:
> > That's great; thanks. I'll do a little more testing on the patches
> > I've cherry-picked into my trees, and then unless someone else has
> > objected in the meantime I'll push them.
Hi David,
On Fri, Apr 08, 2011 at 09:08:28AM +0100, David Woodhouse wrote:
> You're more than welcome to use git.infradead.org if you want. But even
> if Milan sees the 2.32 branch as being dead and doesn't want to spend
> any of his own time on it (and nobody can blame him for that), I would
> ho
On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote:
> We could use Evolution's file-link attachment mechanism by writing into Evos
> file cache from the backend and placing the file paths into the ECalComponent
> when reading calendar objects from the Kolab server, and read attachment fil
On Thu, 2011-04-07 at 15:08 +0200, Milan Crha wrote:
> Hmm, I still do not like the idea of adding things to gnome-2-32 branch,
> I thought I saw you telling that if anyone will complain then you'll not
> do that and I thought I complained to it, but I cannot find the email
> right now, so I cannot
On Fri, 2011-04-08 at 09:54 +0200, sean finney wrote:
>
> > Sounds like you would be in a good position to do it though.
>
> Because I'm not a gnome dev, I (a) don't have push access, and (b)
> am a bit hesitant to go against Milan's wishes, since he's the dev
> who is primarily keeping things up
Hi everyone.
While working on the evolution-kolab plugin, we found that there is no direct
support in ECalComponent for attachments inlined into calendar objects. Thus,
so far, we can cope with attachments inlined into Kolab calendar objects by
hiding them in private ical fields. That way, we c
Hi David,
On Thu, Apr 07, 2011 at 01:07:38PM +0100, David Woodhouse wrote:
> Personally, no. I'd rather ignore MAPI completely and get on with the
> implementation of evolution-ews.
Understandable, though as we've discussed on IRC we don't really have
the option of using that here, at least for a
18 matches
Mail list logo
