On Tue, 2011-03-01 at 23:02 -0500, Matthew Barnes wrote:
> My next steps are to write the migration code for all the XML blobs in
> our "sources" GConf keys, and then it's on to mail accounts.
I rebased the "account-mgmt" branches [1] again to snapshot my progr
It's getting to be branching time again. I think in the past we've
usually branched when the hard code freeze starts, which would be next
Monday. Shall we go with that again or does anyone have a desire to
branch sooner?
(Speaking for myself, I don't really have anything ready to land yet.)
___
On Sun, 2011-03-13 at 21:32 +, David Woodhouse wrote:
> Ug, and now I've found that that workaround doesn't work either. If we
> try to rename a folder, we end up blocking in the main thread, waiting
> for the soup request that we deliberately put into an idle function so
> that it could run i
On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote:
> do not forget that the DB cache is compiled conditionally, because some
> distros do not ship libdb. Using SQLite for this was mentioned months
> ago, only no-one got time to actually do it, so go for it.
Also, as far as I know there is still
Long ago and cubicle far, far away I wrote this little debugging
enhancement for GObject that collects statistics about instance
creation, destruction, etc. by class type and then prints a nicely
formatted report when piped through a tool named 'gobject-stats'.
My proposal for it got kinda hijacke
On Fri, 2011-03-04 at 12:58 +, David Woodhouse wrote:
> I wasn't planning to do any of the actual crypto code directly in
> Evolution; I was planning to use NSS for that. The additional
> functionality would presumably live inside #ifdef CAMEL_HAVE_NSS, like a
> lot of other code in e-d-s alrea
On Fri, 2011-03-04 at 12:25 +, David Woodhouse wrote:
> On Fri, 2011-03-04 at 07:17 -0500, Matthew Barnes wrote:
> > Perhaps it's a different story for mobile devices?
>
> To a large extent, yes. The 'encrypt it all' solution means that you are
> forced to
On Fri, 2011-03-04 at 11:55 +, David Woodhouse wrote:
> On Fri, 2011-03-04 at 06:50 -0500, Matthew Barnes wrote:
> > Can you go into more detail about why it's needed? Would help me to
> > better understand the use cases.
>
> Mostly corporate paranoia. If your pho
On Fri, 2011-03-04 at 11:40 +, David Woodhouse wrote:
> I'm working on "Enterprise" use of Evolution, and one of the big
> requirements is encryption of data at rest. The answer "just encrypt the
> whole of the user's home directory" only puts them off for so long.
Can you go into more detail
On Wed, 2011-03-02 at 09:36 -0500, Matthew Barnes wrote:
> > You might use something less "aggressive", like iterator or path, for
> > local indexes.
>
> Won't work in the general case. As soon as you insert or delete a row
> prior to the row you're track
On Wed, 2011-03-02 at 15:19 +0100, Milan Crha wrote:
> Not enough, because the above. I'm doing this [1] (2.91.91+). Search for
> e_attachment_store_remove_all() calls (the patch fixes also placing of
> attachments to the correct bar).
That works, I guess. In other places were I build a hash tabl
[[I'm CC'ing the hackers list.]]
On Wed, 2011-03-02 at 14:00 +0100, Milan Crha wrote:
> The GtkTreeRowReference is adding a reference count to the model, so if
> you store this GtkTreeRowReference inside model itself, then the model
> is never freed. This is a case for EAttachmentStore, if it has
On Wed, 2011-03-02 at 12:54 +, David Woodhouse wrote:
> (
> Preface: rather than continuing to use private mail, I'd like to start
> using a proper mailing list for people working on our Exchange Web
> Services plugin. I thought briefly about setting up a new list, but
> decided that the ev
On Tue, 2011-01-18 at 14:32 -0500, Matthew Barnes wrote:
> I think I'm done now with the standalone address book backends and am
> moving on to calendars, so it seemed like a good stopping point for a
> status update.
>
> I pushed snapshot branches named "account-mgm
On Sun, 2011-02-20 at 20:49 +0100, David Klasinc wrote:
> I am working on Gwibber - microblogging client and one of the ideas that
> has come up is using EDS for storing Gwibber contacts. I looked into
> evolution-python bindings and it seems that I can pull this off.
> However, I have two problems
On Thu, 2011-02-17 at 18:37 +, David Woodhouse wrote:
> I assume that your intention is that the Camel async methods would *not*
> be similarly broken, and that you should be able to call them from *any*
> thread and expect them not to break?
>
> If so, we need be *very* careful about calling
o the right a bit
you should be able to spot the "On This Computer" entries. Following
the "name" attribute there should be a "base_uri" attribute with a URI
scheme of either "file:" or "local:". Delete all the "On This Computer"
entr
On Mon, 2011-02-14 at 21:18 +0530, vikas ruhil wrote:
> > can tell in more detail about Meeting ?
> > i want to participate in meeting ?
> > so please tell ?
See: http://projects.gnome.org/evolution/meetings.shtml
We should add some boilerplate text to these meeting announcements that
includes th
On Tue, 2011-02-08 at 14:23 +0100, Onyeibo Oku wrote:
> The Help->About on my Evolution mail menu still reads 'Evolution 2.32.1'
> but I see Development is now at 3.x. Is there anyway I can experience
> the future Evolution Mail Client while you guys do your thing? Is the
> risk of test-running s
On Mon, 2011-02-07 at 09:50 +0100, Milan Crha wrote:
> And that's what is wrong with it. I do not know the polling interval,
> chosen by gio developers, but I prefer to be able to set the polling
> time myself, for fine-tuning. Not talking about unnecessary network
> traffic for those (rather rare?
When creating a new local calendar or memo list or task list there's an
option for choosing your own iCalendar file and among _those_ settings
are choices for how and when to check the file for changes: "On open",
"On file change" and "Periodically".
"On open" is implied with all choices -- obviou
On Thu, 2011-02-03 at 12:43 -0500, Reid Thompson wrote:
> Is there a way to determine where I'm mixing GTK 2 & 3?
I'm not aware of a good way. In the past I've had to pick through
pkgconfig files to figure out what's dragging it in, but it's slow and
painful.
Evolution, Evolution-Data-Server and
2.0. More precisely there is no gtkimageview
release for gtk3 yet. I set the requirement to a bogus value to force
the use of --disable-image-inline when building Evolution against gtk3.
Now that we _require_ gtk3, I need to figure out what to do about this.
For n
On Thu, 2011-01-27 at 08:15 +0100, Patrick Ohly wrote:
> On Mi, 2011-01-26 at 11:34 -0500, Matthew Barnes wrote:
> > Can you elaborate on the creation use case? Sounds like you're creating
> > local data sources on the fly?
>
> Yes. The primary use case is in automated
As of today, we have dropped support for gtk+-2.0. Evolution and all
related modules now require gtk+-3.0.
Until the GTK+ team releases version 3.0, I'm going to keep our gtk+-3.0
requirement set to the latest tarball release -- currently 2.99.2 -- to
ensure we're all keeping up with the latest b
On Wed, 2011-01-26 at 16:23 +0100, Patrick Ohly wrote:
> SyncEvolution uses all of these calls. I don't mind rewriting the code,
> but let's make sure that there is a proper replacement.
>
> What I need to do is:
> - list all address books and calendars
> - open any of the listed databases
> - cre
On Wed, 2011-01-26 at 06:17 +0100, Milan Crha wrote:
> thanks for doing this. I'm only wondering, why not a dot or dash (if
> available for bus names) between the version number and the bus name
> itself? Was there anything preventing it to do it that way? (I'm not
> much familiar with DBus itself,
On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote:
> I kinda wanted to tweak the names anyway, so here's my proposal for the
> new D-Bus interface names:
>
> Old: org.gnome.evolution.dataserver.addressbook.BookFactory
>org.gnome.evolution.dataserver
On Mon, 2011-01-24 at 08:50 +0100, Milan Crha wrote:
> what about wait till Wednesday, after evolution team meeting, and then
> merge gtk3 branches to master branches, and require gtk3 for the Monday
> 2.91.6 release? It saves a bit of work for you, and also forces people
> to fix new issues relate
On Wed, 2011-01-12 at 20:53 -0500, Matthew Barnes wrote:
> The gtk3 branches are rebased now. Delete your local copy.
Would anyone mind if I do another round of gtk3 rebases?
Benjamin Otte fixed most of the gnome-canvas issues, and I've been
rebasing and reorganizing commits on my gtk3
On Thu, 2011-01-20 at 18:55 +0100, Christian Hilberg wrote:
> ++ from the evolution-kolab team. Any idea on how to handle exactly this
> right
> now (we'll be implementing that soon on a totally obsolete Evo version, i.e.
> 2.30 ;-)? Since we did not yet implement this part, we can do so in a wa
On Thu, 2011-01-20 at 18:24 +0100, Milan Crha wrote:
> Nope, go for it. It may also fix an issue with Birthday&Anniversaries
> calendar, when using authenticated addressbook, as right now there is no
> easy way to ask for a stored password for that book. Of course, there
> will be needed new API fo
On Tue, 2010-11-23 at 23:50 -0500, Matthew Barnes wrote:
> Migration issues aside, since that's already a project unto itself, is
> there any reason why our keyring items can't be as simple as:
>
>Description: Evolution data source <>
>Attributes: source: &
On Sun, 2011-01-09 at 15:13 -0500, Matthew Barnes wrote:
> If no one objects I'll plan to do this later this week. So speak up now
> or commit now if you have any pending changes. I'll make sure any last
> minute commits aren't lost.
The gtk3 branches are rebased now.
week. So speak up now
or commit now if you have any pending changes. I'll make sure any last
minute commits aren't lost.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubsc
On Tue, 2011-01-04 at 15:00 -0500, Matthew Barnes wrote:
> The cleanest and most obvious solution is to install the backends into
> separate address book and calendar directories, then have each factory
> process load from the appropriate directory.
>
> This will require a few API
On Wed, 2011-01-05 at 16:21 +0100, Milan Crha wrote:
> Ah, I see, quite complicated. The g_type_module_register_type() says:
>As long as any instances of the type exist, the type plugin
>will not be unloaded.
> Whatever that means. Though if it means what I would expect from it,
> then regi
On Wed, 2011-01-05 at 13:17 +0100, Milan Crha wrote:
> are you sure they are kept in memory? I see the factory calls
Yes, GTypes are registered permanently whether the class is loaded
statically or dynamically. This isn't about class instances.
> Do you mean you are returning from the backend m
ctories yet but it doesn't
really matter much, as long as the "extensiondir" variables correctly
point to them.
If there's no objections I'd like to get this fixed in 2.91 even though
it's not currently causing any problems in 2.91, but
Another status update:
After much consideration I decided to drop GSettings from the equation
and just access key files directly. The key file part of the design is
working out well but I've been fighting with GSettings every step of the
way. It's not that that GSettings is bad, but it's very mu
On Tue, 2010-12-21 at 10:14 +0100, Milan Crha wrote:
> I like your idea. It might work as long as the backend is running,
> otherwise it will not, unless you'll add a listener for this in factory
> and run the backend if needed.
I actually got it working last night for address books, although it
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
> Overall the changes are having a simplifying effect on the code base,
> but it will introduce an API break of some kind to almost every library
> in E-D-S. That's what I wanted to talk about here.
Couple more API breaks to
On Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote:
> > Signals:void(*load_error) (ESourceRegistry *registry,
> > GFile *file,
> > GQuark error_domain,
> >
On Tue, 2010-12-14 at 04:47 -0700, Vibha Yadav wrote:
> Evolution is now compilable against gtk3. Please checkout the gtk3 branch for
> + gtkhtml
> + evolution-data-server
> + evolution
Awesome! Nice work!
Let's hope that's the last of the API breaks.
___
On Fri, 2010-12-10 at 11:54 +0100, Milan Crha wrote:
> It would be good to allow also username changing in EPasswords. It's
> very unusual to allow only password entering when most applications are
> allowing to change both username and password (I'm not aware of any
> other with "enter password on
More brain dumping so this is all out in the open.
Since I've been blathering on about this new ESource API and these
"extension" things but haven't actually posted the API, I thought I
should do so.
Also attached are my notes for the GSettings schemas for these various
ESourceExtension subclasse
Here's a progress update on my account management rewrite.
I've been on travel for the past three weeks and still have another week
to go, so I've only been able to work on this in short spurts -- an hour
here, an hour there. But I've managed to work through all of E-D-S, get
the test-source-comb
On Tue, 2010-12-07 at 22:09 +0100, Stefano Facchini wrote:
> Il giorno mar, 07/12/2010 alle 15.02 -0600, Matthew Barnes ha scritto:
> > > Are you aware of this?
> >
> > Yes, it turned out to be a GTK+ bug. It was fixed last month.
> >
>
> So to fix it I&#
On Tue, 2010-12-07 at 21:50 +0100, Stefano Facchini wrote:
> I didn't mean that I wanted to file bugs about compilation, but about
> the window showing the list of emails. Instead of showing the list, it
> shows whatever occupied that region of the screen before switching to
> Evolution mail: for e
On Tue, 2010-12-07 at 18:37 +0100, Stefano Facchini wrote:
> BTW how can I compile the gtk3 branch? I have already cloned evolution,
> evolution-data-server and gtkhtml git repositories. What I have to do
> now?
$ git branch --track gtk3 origin/gtk3
$ git checkout gtk3
$ ./configure --enable-gtk3
On Tue, 2010-11-23 at 23:50 -0500, Matthew Barnes wrote:
> Also, while we're on the subject of password storage, pretty please can
> we drop support for the old legacy ~/.gnome2_private/Evolution password
> file and make keyring integration mandatory for Evolution 3.0? We are
&
On Thu, 2010-12-02 at 15:25 +0100, Milan Crha wrote:
> I would use the last version in the migration code check, and if any fix
> in the migration routine would be done after another release, then just
> increase the number in the version check. It might work as long as the
> changes will be done n
On Thu, 2010-12-02 at 14:16 +0100, Milan Crha wrote:
> just a question, what about using real versions in GConf key
> /apps/evolution/last_version
> ? There is stored 2.92.0 for the master right now, but the version in
> Help->About is 2.91.4. I believe it would be better to use the real
> version,
nome.org/archives/evolution-hackers/2010-March/msg00023.html
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Mon, 2010-11-22 at 16:17 -0500, Matthew Barnes wrote:
> I'll ponder on this some more. I don't want to get too far off on a
> security tangent right now since this key file proposal is already a
> tangent from migrating to GSettings. But it's good to discuss now so
I finished my first pass at converting all the address book and calendar
backends to the new key file API and am now looking at our GNOME Keyring
integration.
Once again I'm getting bit by the fact that the URIs we've historically
used to identify data sources is just making things needlessly comp
On Mon, 2010-11-22 at 21:47 +0100, Yves-Alexis Perez wrote:
> Simplifying the settings is a good idea, but pretty please, no wizard à
> la thunderbird, it's *horrible*, everytime I need to use it I want to
> die.
Don't worry, I'm not writing any new wizards. This should be as
transparent and unob
On Mon, 2010-11-22 at 19:48 +0100, Yves-Alexis Perez wrote:
> As I understood it, SSL meant a tunneled connection over SSL/TLS, using
> the relevant port (995/pops, 993/imaps, 465/smtps, 636/ldaps). TLS means
> STARTTLS over a normal connection, so usually using the standard port
> (110/143/25/389)
I have a stupid question.
I've been converting the various address book and calendar backends to
my key-file based ESource proposal, and in several configuration dialogs
such as LDAP address books and GroupWise calendars, I see this setting
with choices in a combo box:
Use secure connection: S
Let's talk D-Bus.
I've started integrating the redesigned, key-file based ESource APIs in
a branch of Evolution-Data-Server and so far it's actually simplifying
the affected code. I'm leaving mail aside for now and just focusing on
calendars and address books.
I'm gonna have to remove some funct
On Mon, 2010-11-15 at 08:49 -0500, Reid Thompson wrote:
> my latest build attempt with glib, gtk+, evo-* all at git head appears
> to fail due to some api changes.
>
> Could someone post me the (highest?) tag/branch levels of glib, gtk+
> that will allow me to build evo-* git head?
The master bra
On Thu, 2010-11-11 at 08:55 +0100, Milan Crha wrote:
> Will be there any kind of property inheritance? As in your example
> above, I would like to define the 'color' in the [source]
> key-file-group, thus all extensions will inherit it, but, if user
> changes color for one of them, then it'll creat
On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote:
> Does this mean (for example) that we will be able to have a caldav
> server, with credentials, and then just associate (and maybe
> auto-discover) all of the user's addressbooks, calendars, todo-lists and
> journals which the user has on t
As part of our transition from GConf to GSettings, which Rodrigo Moya
has graciously been helping with, I've put some thought into addressing
the XML string lists which we currently store in GConf under "accounts"
and "sources" keys. We've known for years that this is a really bad
approach, and I
On Tue, 2010-10-26 at 15:43 +0200, Rodrigo Moya wrote:
> I was wondering if someone has started working on the migration to
> GSettings, so that I could lend a hand, so anyone?
Yes, I have. Though so far I've only been nipping around the edges and
making preparations.
This is going to be larger
On Fri, 2010-10-22 at 09:32 -0400, Matthew Barnes wrote:
> Anyway, I already owe other people some code reviews so I'll put away my
> hackers hat for a few days and try to look at this over the weekend. It
> may need to sit on a branch for a little while longer because I don'
On Fri, 2010-10-22 at 15:01 +0200, Benjamin Otte wrote:
> I've pushed a rendering-cleanup branch to git that cleans up evo code
> to compile with GDK_DISABLE_DEPRECTAED again. As I'm fortunately not a
> specialist on Evo code, someone should look it over, but from my
> testing, things still look fi
On Tue, 2010-10-19 at 14:10 -0500, Federico Mena Quintero wrote:
> I'm trying to unwind some code in Camel and in Evolution.
>
> The problem I have is that if you change an email account's extra
> options (e.g. imapx's "apply filters to new messages"), then those
> changes don't take effect until
On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
> The other solution was to maintain all exchange providers in a single
> package, merging evolution-exchange, evolution-ews and evolution-mapi
> into a single package. Other collaboration providers like
> evolution-groupwise and evolution-kolab (yet t
On Sat, 2010-10-16 at 11:49 -0400, Martin Owens wrote:
> > * Cached Camel provider data moves to ~/.cache/evolution/mail. This
> > includes folders.db. Files for local accounts will be divided up:
> > index files for searching would go in ~/.cache, whereas actual mail
> > content (mbox/Mail
On Mon, 2010-10-04 at 17:33 +0200, Javier Jardón wrote:
> The patch attached should fix the problem
Thanks for this. Applied to master branch of evolution-data-server and
evolution. Our other modules are still using GLib's gettext, so I guess
they'll need to be fixed similarly when we switch the
On Wed, 2010-09-29 at 13:13 -0400, Reid Thompson wrote:
> can someone tell me which branch or tag or hash or date of gtk+ I need
> to build to get me a gtk+-2.0.pc file that will satisfy this check.
You want the gtk-2-22 branch.
The git tag for the 2.22.0 release is "2.22.0".
___
after the April release.
Hopefully by then GIO will have TLS support, or else I'll have to figure
out an interim solution.
Looking even further out, I plan to leave the MIME stream filters alone
until CamelStream is replaced, and then eventually port them all to the
GConverter interface (co
On Sat, 2010-09-04 at 09:12 +0200, Thomas Mittelstaedt wrote:
> More errors trying to compile gtkhtml:
Use ./configure --disable-deprecated-warning-flags to work around the
GdkGC errors. GTK+ deprecated GdkGC very late in the GNOME development
cycle and we're not going to deal with it this close
This is just FYI; a mailing list retweet.
This absolutely justifies why we restrict our library dependencies to
stable releases only. Fortunately for us we still use libunique.
Forwarded Message
From: Ryan Lortie
To: desktop-devel-l...@gnome.org
Subject: GApplication is going
On Tue, 2010-08-17 at 10:30 -0400, Matthew Barnes wrote:
> Proposed API uses GIO's async pattern:
>
>void
>e_load_book_source_async (ESource *source,
> GtkWindow *parent,
> GC
e_load_book_source_async() is a mess. It invents its own async pattern,
doesn't allow for cancellation and has no way to report errors.
I would like to fix this before it ships in 2.32. Since it's in
libedataserverui, it shouldn't affect much more than Evolution.
Proposed API uses GIO's async p
On Thu, 2010-08-05 at 09:48 +0200, Joop Beekmans wrote:
> Digging a little deeper, I found this message on an Evo mailinglist
> describing more or less the same issue:
> http://osdir.com/ml/evolution-list/2010-07/msg00337.html
Support for relocatable base directories was -just- introduced in
Evolu
On Thu, 2010-08-05 at 18:30 +0200, Christian Hilberg wrote:
> Result: While libsoup should build against the current GnuTLS lib
> (development
> version, 2.11.0), which has PKCS #11 support since a few weeks now, libsoup
> has no infrastructure for handling client certificates at all [1] and Gnu
On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote:
> Is there any good alternative to using libsoup which makes use of NSS? We're
> pretty much depending on the (mostly) working NSS infrastructure for PKCS #11
> and token handling for certificate based client auth.
That I don't know. Y
On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote:
> Does libsoup make use of NSS (just the newbie's uninitiated question)?
It uses GnuTLS for transport layer security.
http://www.gnu.org/software/gnutls/
> Hey, thanks for that hint! :-) Maybe it would be wise to mark such classes as
On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote:
> Using the Camel.HttpStream should do the trick - is that correct? I've seen
> the Camel.HttpStream being used within Anjal (file em-format-mail.c). Is this
> Camel HTTP part being used somewhere else as well (to be used as another
> r
On Thu, 2010-07-29 at 01:23 -0400, Paul Smith wrote:
> I wonder if Matthew or Milan or anyone have any thoughts on what the
> delay in Gnome 3.0 means for Evolution.
>
> Is the current git master buildable and usable without Gnome 3.0
> components? Do you expect distros to build and ship both Gno
On Sun, 2010-07-25 at 19:23 -0400, Matthew Barnes wrote:
> On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote:
> > I now have all the migration routines written and I'm fairly happy with
> > them. A few more cases to test and I think I may commit this over the
> >
On Tue, 2010-07-27 at 08:24 +0200, Milan Crha wrote:
> does this mean that one would be able to keep .evolution folder as is,
> with some XDG foo? You know, sometimes is useful to run 2.30.x while
> developing 2.31.x on the same machine, where your change makes it
> impossible.
>
> But if it's pos
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote:
> I now have all the migration routines written and I'm fairly happy with
> them. A few more cases to test and I think I may commit this over the
> weekend.
I decided to defer this until at least Tuesday, so that those
On Sat, 2010-07-24 at 07:48 +0200, Yves-Alexis Perez wrote:
> An an evolution user and a packager, is this really a good idea?
> Shouldn't it be safer to keep it “as a backup” but mark it as already
> migrated. This way, another attempt can be tried should the first one
> fail, and we don't touch u
On Sun, 2010-06-06 at 12:34 -0400, Matthew Barnes wrote:
> Once thing I'd like to get done before Evolution 3.0 is dismantling
> ~/.evolution and moving user-specific data to relocatable XDG base
> directories [1].
...
> [1] http://standards.freedesktop.org/basedir-spec/basedir
On Tue, 2010-07-20 at 11:21 +0530, chen wrote:
> On Mon, 2010-07-19 at 17:27 -0400, Matthew Barnes wrote:
> > Backends using these classes can easily construct a suitable cache file
> > or directory name from e_cal_backend_get_cache_dir().
> get_cache_dir
On Tue, 2010-07-20 at 11:21 +0530, chen wrote:
> Is it required ? Having it in ECalBackendStore simplifies the backend
> code to form the path based on the type (calendar,tasks,memos) at a
> single place rather than every backend doing it..
Forming the path at a single place instead of all the bac
On Mon, 2010-07-19 at 09:10 +0200, Milan Crha wrote:
> that's a part which should be changed. The ideal way, as I understand
> it, is to have an ECalBackend function to retrieve a path for
> attachments, and ECal should ask backend for it, instead of duplicating
> the code (it sort of blocks extend
As part of the XDG base directory effort, I've written a couple simple
functions for libebook and libecal:
gchar *
e_book_get_user_cache_dir (const gchar *source_uri);
gchar *
e_cal_get_user_cache_dir (const gchar *source_uri,
On Fri, 2010-07-16 at 15:54 +0200, Christian Hilberg wrote:
> Within our project it has been brought up that POSIX shell scripts might be a
> good choice in order to keep a low profile depencency-wise. Personally, I
> would prefer a higher-level scripting language which will offer more facility
On Wed, 2010-06-09 at 08:56 -0400, Matthew Barnes wrote:
> A local ESource with a URI of:
>
> file:///home/mbarnes/.evolution/calendar/local/<>
>
> will have to be changed as follows when we move to XDG base directories:
>
> file:///home/mbarnes/.loc
On Tue, 2010-07-13 at 18:50 +0200, Christian Hilberg wrote:
> Is there a sensible way how we could deal with CamelException in our
> evolution-kolab plugin, which will be developed against 2.30? This is, can
> CamelException be wrapped in a way which will ease up the transition to
> GError, once
On Sun, 2010-07-11 at 13:08 +0100, David Woodhouse wrote:
> I note that in some places you've elected not to propagate the error
> pointer. For example in imapx_parse_status_info():
>
> -imapx_parse_status_info (struct _CamelIMAPXStream *is, CamelException *ex)
> +imapx_parse_status_info (struct
On Thu, 2010-07-08 at 14:19 +0200, Yves-Alexis Perez wrote:
> I recently enabled large file support in evolution-data-server in
> Debian. It seems that it leaded to the discover of some bugs on i386
> installs (like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580419 /
> https://bugzilla.gnome.
On Fri, 2010-07-09 at 10:29 -0600, Sankar P wrote:
> (oh that out-of-tree Scalix backend is still using
> flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types)
Is evolution-scalix even alive?
It hasn't seen a release in over two years.
Same goes for evolution-jescs.
_
On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote:
> > If Evolution staff will be willing to host our project sources within
> > Evo git repo, we'll happily transfer our stuff there as soon as we
> > have a first preview ready.
>
> Perhaps something to dicuss on #evolution (irc.gimp.net
t's a much more disruptive change and I'm not sure if that will land
in time for 3.0, as I need to turn my attention to other higher priority
projects for awhile.
Matthew Barnes
[1] http://library.gnome.org/devel/gio/stable/gio-GIOError.html
301 - 400 of 610 matches
Mail list logo
