-ERROR **: No schema for GConf key
'/apps/evolution/shell/file_chooser_folder'
aborting...
Aborted (core dumped)
Run this as yourself (not super user):
gconftool-2 --install-schema-file .../shell/apps_evolution_shell.schemas
Matthew Barnes
the *.schema files in that
directory, just in case, or might that break things?
I think just as needed is fine. I've been careful to only add new
schemas and not change or remove existing ones.
I suspect there's a better way to manage this, but it hasn't occurred to
me yet.
Matthew Barnes
doesn't (build breakage
or some other careless boo-boo), posting to the list will usually get
you a quick response.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Debian people.
I'll play around with that and see if I can work it into my standard
release preparation checklist.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
approach?
Matthew Barnes
[1] Alex's new GConverter interface also caught my eye as a potential
replacement for CamelMimeFilter sometime in the distant future.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman
gallery.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
the content through
a CamelMimeFilterFrom. Right?
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
-infrastruct...@gnome.org
would be a better place to ask.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
to the client-side calendar library (libecal).
Speak up now with any concerns. Sorry for announcing this at the last
minute, but it was overlooked in the original commit and almost slipped
out unnoticed.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution
On Sun, 2010-01-17 at 16:35 -0500, Paul Smith wrote:
I have the latest version of gtkhtml as well but nothing like this
exists there that I can see.
Matt, did you forget to commit your gtkhtml changes?
I did for a short time today, but they're there now.
Matthew Barnes
(aka. Rawhide) has it already.
Matthew Barnes
[1] http://live.gnome.org/Jhbuild
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
. The problem is that these warnings can be false positives,
that's why there are different levels of aggressiveness.
Ah, good, thank you both.
I'll see what the different levels produce and maybe file some cleanup
bugs about it.
Matthew Barnes
it a
showstopper.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
still can't reproduce these build failures myself for some reason, so
if you could verify there are no more linking problems I'd appreciate it
greatly since we have a release tomorrow.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers
page on the website:
http://live.gnome.org/Evolution
http://projects.gnome.org/evolution/download.shtml
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
as soon as possible so we can include them in the upcoming release.
Thanks,
Matthew Barnes
[1] http://live.gnome.org/TwoPointTwentyseven
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
doesn't scale. These days we prefer patches be submitted
to and reviewed in Bugzilla.
Please continue using the evolution-hackers mailing list for things
like design discussions, developer meeting and hackfest announcements,
merge announcements, reporting build breakage, etc.
Thanks,
Matthew
, feel
free to ask me for help if you get stuck.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
.
It would be nice if someone could check whether WIN32 still compiles..
I can't speak for Win32 or even Unices beyond Linux, but the patch looks
okay to me. Being so close to a stable release, however, unless this
fixes a bug I'd suggest holding off until 2.31 development opens up.
Matthew Barnes
-lifting transactional guarentees for an utter
corner-case, for a non-critical file anyway :-)
I would prefer g_file_replace_contents_async() for cases like this.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http
potentially be a good solution for account
settings: centralized access + change notification + a highly readable
and portable storage format.
Once I find time I'll be starting yet another branch to try and flesh
out some of these ideas, and pave the way for GSettings.
Matthew Barnes
[1] http
in
the Account Editor, Calendar Properties, Address Book Properties, etc.
I'll post a more fleshed out proposal to the wiki once I learn more
about the GSettings key file backend.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers
for your particular setup.
You may need to log out and log in again for the new settings to take
effect. (There's probably a way to do it without having to log out, but
I'm not sure how.)
Hope this helps,
Matthew Barnes
___
Evolution-hackers mailing list
to Gnome/Evolution, I don't know which source files to edit. Any
pointers/advices?
For starters, please file a bug about it:
https://bugzilla.gnome.org/enter_bug.cgi?product=Evolution-Data-Server
LDAP code is in the 'ldap' backend in Evolution-Data-Server.
Matthew Barnes
, and perhaps even set a GNOME Goal for it?
From what I've read on d-d-l, GNOME_MAINTAINER_MODE_DEFINES should be
deprecated and replaced with something we can agree on.
Proposed patch attached.
Matt
commit f6a4ce37e5ea1dc0df62ac244fbeb158de3d2cb2
Author: Matthew Barnes mbar...@redhat.com
Date: Tue
On Tue, 2010-03-30 at 15:35 +0200, Vincent Untz wrote:
Le mardi 30 mars 2010, à 09:18 -0400, Matthew Barnes a écrit :
Even better, can we get a macro added to gnome-common that implements
this deprecation flag policy, and perhaps even set a GNOME Goal for it?
Sure, it'd be nice to have
/evolution/commit/?h=gnome-2-30id=5d362dba25a974b826a864dbfab5cd3510b77f12
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
-mark-not-junk (extra dash).
All I did was work around it:
http://git.gnome.org/browse/evolution/commit/?h=gnome-2-30id=e9ea8a567cc85027ef7dcef7ba3ad03044677793
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your
On Thu, 2010-04-29 at 17:07 -0400, Paul Smith wrote:
Hi Matthew; that bug in gnome-icon-theme has been fixed in both the
gnome-2.30 and master branches. Do you want me to file another one
against Evo to get your change reverted?
Nah, not necessary. I'll get it reverted.
On another topic,
days and fire off bug reports if you spot anything.
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 Tue, 2010-05-25 at 15:26 -0400, Reid Thompson wrote:
is there a short explanation of what express is somewhere?
It's an attempt to simplify and rewire Evolution's user interface to be
more suitable for small screen netbooks -- particularly devices running
MeeGo. It's an alternate mode
On Wed, 2010-05-26 at 17:57 +0530, chen wrote:
AFAICS gtk+ minimum version has been bumped and we had some reasons for
that which could not recollect atm. Matt should be able to provide more
information there..
We have a policy of only requiring the latest -stable- platform so that
you can
Is there any reason why we can't just use file:// as the base URI for
the On This Computer source group? No other group uses that scheme,
so it seems we could identify the On This Computer group as file://
as easily as file://home/mbarnes/.evolution/calendar/local. Plus it
would solve a whole
On Wed, 2010-06-09 at 17:50 +0530, chen wrote:
Changing the uri to local:// might break other applications who depend
on the uri to check if its a local calendar source. I could not
understand what kind of problems changing uri solves.. Is it really
necessary to change the uri ? Just looked
On Wed, 2010-06-09 at 08:41 -0400, Matthew Barnes wrote:
So a local source group with a base URI of:
file:///home/mbarnes/.evolution/calendar/local
will become:
file:///home/mbarnes/.local/share/evolution/calendar
Let me rephrase this to try and better clarify:
A local ESource
On Wed, 2010-06-09 at 14:49 +0100, Ross Burton wrote:
local:unique-id, surely. No need for // when you're not putting a
hostname or path.
Good point.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or
On Mon, 2010-06-21 at 18:28 +0200, Christian Hilberg wrote:
Does the front-end process refer to Evolution, i.e. is a Camel.Provider
running inside Evolution instead of EDS? I was hoping that all non-UI-related
stuff could be run inside EDS, so we would facilitate Evo only for account
On Thu, 2010-06-24 at 15:10 +0200, Christian Hilberg wrote:
By the way, are there any known pitfalls using multiple instances of Camel
simultaneously? I think I've read something about Camel not being
multithreading-safe (can't seem to find the link just now), but our backends
will likely
On Wed, 2010-06-30 at 22:20 +0100, Chris Vine wrote:
I have found that evolution-data-server-2.30.1 installs libedataserver
as libtool version 11 (libedataserver-1.2.so.11) whereas
evolution-data-server-2.30.2.1 installs it as libtool version 13
(libedataserver-1.3.so.13).
Rationale for the
On Wed, 2010-06-30 at 22:53 +0100, Chris Vine wrote:
Can you help me on what gnome components compiled for gnome-2.30.0/1
might now be broken and require recompilation (apart from evolution
itself, that is)? It looks from that bug report as if that will
include ekiga, as well as empathy.
On Thu, 2010-07-01 at 13:16 +0200, Christian Hilberg wrote:
I'll propose this as our style guide then. Just like Ross in one posting (I
think back in 2009), I'm interested specially in getting to know about indent
style. patch.shtml talks about 8-space-tabs (and true tabs instead of
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote:
for EBook it is, all the async API there uses 'status' as an indicator
of the operation result in the async callback. I'm changing it to GError
too. I'm still on ECalBackend, but it seems some similar change will be
in ECal too, though I'm
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
___
evolution-hackers
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) - but
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 /
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 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 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
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 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
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 can simply return e_cal_backend_store_get_path
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 user
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 developers
who aren't
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
weekend.
I decided to defer
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 Gnome
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
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 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. You
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 GnuTLS
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
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,
GCancellable *cancellable
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 de...@desrt.ca
To: desktop-devel-l...@gnome.org
Subject:
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
the MIME stream filters alone
until CamelStream is replaced, and then eventually port them all to the
GConverter interface (complete with extensive unit tests). But I don't
see that happening until well into next year.
Matthew Barnes
[1] http://mail.gnome.org/archives/evolution-hackers/2009-November
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.
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
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
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 to
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 you
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 fine.
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't
want Evolution
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
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 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 that
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 branch
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
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:
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).
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
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
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
can come back to it later
/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 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
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
the only ones still
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
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'd need to update GTK+2, not evolution?
Correct
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
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 only
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 Sun, 2010-12-19 at 18:38 +, Rob Bradford wrote:
Signals:void(*load_error) (ESourceRegistry *registry,
GFile *file,
GQuark error_domain,
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 mention which
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
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
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 just to get it out
of the way. I'll take care of updating the Exchange modules as well.
Matthew Barnes
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
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 changes
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 unsubscribe, visit ...
http
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. Delete your local copy
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 source-uid
Attributes: source: source-uid
This would make
On Thu, 2011-01-20 at 18:24 +0100, Milan Crha wrote:
Nope, go for it. It may also fix an issue with BirthdayAnniversaries
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 for
101 - 200 of 465 matches
Mail list logo
