eyond the
third stable update (backporting patches, fixing security issues, etc.).
I'm not sure the GNOME release team _prohibits_ making additional stable
updates beyond the third scheduled point release, but it's generally not
done given our limited manpower.
M
erver that actually need it, which
does not include libedataserver.
You make an entirely valid point about at least announcing API/ABI
breaks to the list beforehand. ACAICT there was no announcement or
discussion of the libedataserver breakage on either list. I'll bring
this
On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote:
> IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still
> OpenSUSE ships with in-built libdb. I'm not aware of any other distro.
>
> JPR, who use to maintain Evolution few years back, gave me the notes on
> why it was de
On Tue, 2008-10-07 at 14:22 +0100, Michael Meeks wrote:
> What I'd love to see instead, is a one-shot migration to a simple plain
> text, authoritative file with the contacts and then (perhaps) optionally
> a binary cache I guess. But for the volume of data there, presumably
> slurping it and
lution team is concerned), I
would caution you to consider whether starting such a large project is
worth the effort.
Hope this helps,
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
assume is significantly less than full standards
compliance.
I don't know if your design is modular enough for this to be feasible,
but you might also consider starting a parallel implementation using
WebKit and get as far with it as you can, with the intent of switching
away fr
ssed this with the other Evolution/Camel developers yet,
so there are currently no plans to include it in 2.26. That may change,
but for now it remains purely experimental.
Matthew Barnes
[1]
http://svn.gnome.org/viewvc/evolution-data-server/branches/camel-gobject/
___
On Mon, 2008-11-10 at 15:27 +0530, Srinivasa Ragavan wrote:
> > In time I'd also like to explore taking greater advantage of GObject
> > signals and properties in Camel, and also deprecating CamelArgV and
> > CamelArgGetV.
>
> Also the Camel Events to GObject signals right, or you meant the same?
is is a heads up. Any objections?
Matthew Barnes
[1] http://bugzilla.gnome.org/show_bug.cgi?id=557818
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
x27;ve liked. In the next
posting I'll talk about the new shell design and touch on some of the
things it now handles for you that the current shell does not.
If you have questions, suggestions or concerns, please don't hesitate to
shoot me or the list an email. After all, I'm writing t
On Mon, 2008-11-17 at 13:35 +0530, Srinivasa Ragavan wrote:
> Thanks for the great update on this Matt. Its going to be a tough time
> for many of us for the next couple of months. That's one reason, I asked
> you to look at Camel/Gobject stuff for 2.27.x. May be, we have too many
> things to do, w
Thanks for your interest in the branch and for letting me know about the
build issues. Can you tell me what options you're passing to your
autogen.sh and/or configure command so I can try to reproduce this?
Thanks,
Matthew Barnes
signature.asc
Description: This is a digitally si
oc/gal/index.html
Not sure if there's enough documentation there to be helpful, but that's
all there is.
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
them aware of your
project. They might have code you can reuse.
Contact Marina Zhurakhinskaya or Owen Taylor
.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Sat, 2009-03-21 at 20:42 +0100, Butrus Damaskus wrote:
> It seems Gnome moves to git. I would like to ask whether evolution
> goes also (and will there not be at least some SVN gate)?
Evolution being a core GNOME component, we will also move to git.
Matthew Barnes
signature.asc
Descr
there's a growing pile
of pending changes). However the E-D-S git repo is alive and well.
I'm hoping we'll have this resolved by the end of the week, but it's
largely out of our control. Like you said, sit tight and be patient.
Matthew Barnes
[1]
http://mail.gnome.org/archives/gn
ed on the DOAP files plus any corrections I receive.
Thanks,
Matthew Barnes
[1] http://en.wikipedia.org/wiki/DOAP
[2] http://www.go-evolution.org/EvolutionTeam
signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers ma
27;s been broken for several releases and apparently even Sun no longer
enables it in their Evolution package for Solaris. So presumably no one
cares anymore.
I will proceed with this sometime next week unless I hear objections.
[1] http://bugzilla.gnome.org/show_bug.cgi?id=58
nyway?
If no one objects before next weekend I will remove the option in time
for 2.27.5. Silence is consent.
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.
whether those
person(s) even maintain it anymore. I also have not been able to get a
straight answer out of anyone after asking repeatedly for admin rights.
I presume live.gnome.org is actively maintained with stronger anti-spam
measures, and I think it's a more suitable place for Evolution
On Thu, 2009-07-23 at 14:35 +0530, Sankar P wrote:
> I don't see a high data content. There are Camel docs, plugin docs,
> some design docs about shell and threading, most of which will have to
> change anyway, soon. And most of the other links originating from the
> go-evolution home page points t
ritten there and
the resizing effect no longer occurs.
The branch should land in time for Evolution 2.30.
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
ration scripts out there.
Matthew Barnes
[1] live.gnome.org's markup syntax seems way more expressive and is
actually DOCUMENTED! (http://live.gnome.org/HelpOnEditing) Unlike
our own. (http://www.go-evolution.org/Help:Editing) Not to mention
the style sheets are prettier.
signa
Do you mean Drupal? That would answer my earlier question.
live.gnome.org uses MoinMoin, go-evolution.org uses Drupal?
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Mon, 2009-07-27 at 22:57 +0530, Johnny Jacob wrote:
> http://www.go-evolution.org/Special:Version
>
> Mediawiki :-)
Ah, thanks for that! Now I can actually conduct some experiments.
Matthew Barnes
signature.asc
Description: This is a digitally signed mes
y Google results have yielded mostly conversion
scripts in the opposite direction (MoinMoin-to-MediaWiki), or else
software that requires admin access to the MoinMoin database.
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
f libical, but no longer.
You can find the latest release here:
http://sourceforge.net/projects/freeassociation/
Build instructions are in the README file:
http://freeassociation.svn.sourceforge.net/viewvc/freeassociation/trunk/libical/README?view=markup
Matthew Barnes
signature.asc
Descript
;s thoughts:
http://bugzilla.gnome.org/show_bug.cgi?id=590044
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
#x27;, and then to 'gnome-2-28' (if appropriate). In other words,
commit to the bleeding edge first and then backport.
Thanks,
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Correct, it is a known issue. The proposed solution is to move the
servers/exchange code to evolution-exchange, since that code is only
useful to evolution-exchange anyway.
See: http://bugzilla.gnome.org/show_bug.cgi?id=456240
Matthew Barnes
signature.asc
Description: This
certain if this works at the moment.
Looking at the code that handles the URI, it seems to expect a
contact:// scheme and "source-uid" and "contact-uid" parameters, but I
don't have an example handy. Hopefully the EContact's URI gives you
something close to that form. Y
he take-away here is
IF YOU REQUIRE WORKING BUILDS, USE THE GNOME-2-28 BRANCH.
The sausage making is particularly messy right now, so unless you're
involved in it I'd advise you to steer clear of the "master" branch
until further notice.
Thanks,
Matthew Barnes
age 166). I'm
sure the corrections can be implemented or verified pretty easily. The
burden may fall on the Free Association project as much as if not more
so than on us.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hac
On Thu, 2009-10-22 at 18:29 +, Gary Ilijevich wrote:
> How can I build evolution so that it won't use the keyring manager for
> passwords? I want this in the build so that no-one can enable the
> keyring at runtime.
Evolution-Data-Server deals with the keyring, not Evolution.
On Thu, 2009-10-29 at 13:59 -0400, Reid Thompson wrote:
> got errors trying to build...
Patch looks correct, thanks. That was my fault. Public shame is what I
get for being lazy and not building backported changes.
Matthew Barnes
___
Evolut
window?
If the plugin does not use the configuration tab in the Plugin Manager,
you can tag the plugin as a so-called "system" plugin in its .eplug file
as follows:
The plugin will be loaded and enabled, but not shown in the Plugin
Manager so there will be no way to disab
OME 3.0 if that's
what release team decides on.
That said, historically "rock-solid" and "Evolution" are seldom used in
the same sentence, and I know that we could certainly benefit from an
extra six months to focus on polishing and bug-fixing.
Matthew Barnes
_
network connections).
If that's the case you'd be better off using IMAP directly.
In any case, evolution-l...@gnome.org is a better place for these types
of questions.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
a
bunch of rusty old image handling code from the mailer, particularly in
em-format-html-display.c.
As always you can choose not to link to GtkImageView with a configure
option: --disable-image-inline. But doing this will prevent you from
viewing "image/*" attac
for questions that can be easily answered with a Google search. But if
you present yourself as competent, patient and respectful of others'
time, I think you'll find we're a pretty friendly bunch.
Good luck!
Matthew Barnes
___
Evolution-h
elieve that the overuse of threads carries much of the blame for
Evolution's chronic instability over the years and that reversing that
trend first and foremost requires minimizing our use of threads for I/O
and relying more heavily on GLib's main loop.
Comments and constructive criti
gled with for much of GNOME 2. The
community's patience is wearing thin and so is mine.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
igher priority issues like you mentioned. The GObject transition
will mainly happen in the background, during my off hours.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
On Tue, 2009-11-24 at 12:25 -0500, Paul Smith wrote:
> found it. Please apply this patch to fix the build:
Done, thanks for that.
http://git.gnome.org/cgit/evolution/commit/?id=6d1bb4ffec7dd204a61810d4182510f29ff4dfad
Matthew Barnes
___
Evolut
categories
>
> evolution-shell-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 .../
un --install-schema-file for all 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
ou prefer to see issues here on this list?
You mean bugs or issues in git master?
Use your best judgment. Safe answer is always Bugzilla. But if it's
something that worked yesterday and now suddenly doesn't (build breakage
or some other careless boo-boo), posting to the list will us
re on your system.
Do you know of a good way to make that more detectable for developers,
short of uninstalling Evolution?
We've had several similar "insufficent LIBADD" bugs lately, all of which
slipped in under my radar because I keep
were from
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
ll hopefully have far fewer issues with frozen UIs.
Does that sound like a more down-to-earth approach?
Matthew Barnes
[1] Alex's new GConverter interface also caught my eye as a potential
replacement for CamelMimeFilter sometime in the distant future.
___
ing from a past life, so maybe
I could be of some help here beyond just pitching lofty ideas from the
peanut gallery.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
o expand our S-expression vocabulary to maintain
the distinction:
"Sender" "contains" "foo"
(and (match-all (sender-contains foo)))
"Specific Header" "From" "contains" "foo"
(and (match-all (header-contains "From&q
behind the technology curve.
I think it strikes a good balance, personally.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
lso, we should be careful about using the word "standard" when talking
about mbox and Maildir. Neither of these formats are standardized, and
in fact variations abound among mailer programs. Certainly we should be
able to export messages to these formats, however we decide to sto
ivially by passing the content through
a CamelMimeFilterFrom. Right?
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
DG directories. folders.db then would
live under $XDG_CACHE_HOME and could be safely destroyed, whereas
metadata.db would live under $XDG_DATA_HOME.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org
summary database, or I may
just be propagating false rumors.
I'm mightily tempted to just enable it by default and see what breaks.
Can't be much worse than the issues we're already haunted by.
Matthew Barnes
___
Evolution-hackers
time] Timestamp when the UID was generated
[pid]Evolution's process ID when the UID was generated
[serial] Meaningless number, incremented for each UID generated
[host] Your hostname
See evolution-data-server/libedataserver/e-uid.c for more details.
Matthew Barnes
___
et. Also, gnome-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
ons that link 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-
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
u have virtualization
software, Fedora's devel repository (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
build with by default now.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
GCC docs for details before choosing a particular
> value. 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
urn in external
dependencies without breaking anything, great. But I wouldn't call it a
showstopper.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
e-account-setup'
>
> Any fix would be helpful, thanks!
Committed a fix.
I 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
___
so updated the download 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
ome.org
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
project
of this size 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 b
n for EPluginUI, 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
sponding IFDEF in code.
>
> 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
t; have some heavy-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
but
it sounds like that could 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 GS
with all the knobs and switches you see 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-h
still be archived in git as well as
older release tarballs and branches.
Matthew Barnes
[1] evolution-mapi developers: if you'd like me to set this up for you
too just say so, otherwise I'll keep my mitts off.
___
Evolution-hackers
prefer?
Bear in mind this would supplement the still manually updated NEWS file.
Matthew Barnes
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
n 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
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
pport for the 'givenName' attribute, but since I'm
> new 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
On Mon, 2010-03-15 at 20:06 +0100, Thomas Mittelstaedt wrote:
> In latest git master, I had to update the Makefile.am in
> evolution/capplet/settings to make it build:
Thanks, changes committed.
Matthew Barnes
___
Evolution-hackers mailin
On Mon, 2010-03-15 at 18:25 -0400, Paul Smith wrote:
> Hi Matt; where were they committed? I pulled the latest git HEAD and I
> don't see these changes... see my previous email (sorry I posted without
> reading this but my Evo has been offline so I could rebuild it :-p :-))
>
> Maybe they went on
t; -
> + $(top_builddir)/capplet/settings/libevolution-mail-settings.la \
> + $(top_builddir)/shell/libeshell.la \
> + $(top_builddir)/e-util/libeutil.la
Okay thanks. Committed.
Matthew Barnes
___
Evolution-hackers
I've written a new framework for Evolution 2.31 that allows individual
object and widget classes to be extended through GTypeModule.
Simply stated, it's a new way to write plugins for Evolution which gives
you finer-grained control than EPlugin offers and doesn't involve nearly
as much scaffolding
policy, 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
Date:
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?
>
>
it.gnome.org/browse/evolution/commit/?h=gnome-2-30&id=5d362dba25a974b826a864dbfab5cd3510b77f12
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
tly it was a redundant and misspelled version of the
correct icon name: "mail-mark-not-junk" (extra dash).
All I did was work around it:
http://git.gnome.org/browse/evolution/commit/?h=gnome-2-30&id=e9ea8a567cc85027ef7dcef7ba3ad03044677793
Matthew Barnes
___
And I see you already filed a bug:
https://bugzilla.gnome.org/show_bug.cgi?id=616954
I guess I'll be reverting my work-around commit then. This is quickly
turning into a fiasco.
Matthew Barnes
___
evolution-hackers mailing list
evolutio
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 topi
On Thu, 2010-04-29 at 18:51 -0400, Paul Smith wrote:
> I did, and they were, but I'm not getting any email. I take it your
> response means you are getting bugzilla mail?
Oh, am I ever. In fact, make it stop! :)
___
evolution-hackers mailing list
evo
maybe offer up a few of them to GIO itself.
The short-term goals are a priority for 3.0, the long-term goals are
just stuff I'm planning for some future Evolution 3.x release.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gn
xpress
mode in the coming 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
Hi Christian,
This sounds pretty cool and would be a welcome addition to the Evolution
suite.
On Tue, 2010-05-25 at 19:29 +0200, Christian Hilberg wrote:
> We have searched the web for information on similar projects and so far
> found all of them in some kind of stasis or to be abandoned. In
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 invoke
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 a
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]. I have an initial proposal of what should go where.
Migration should just be a series of straight-forward move commands,
plus a few subtle rename
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
On Wed, 2010-06-09 at 09:18 +0200, Milan Crha wrote:
> Are you going to change ESourceGroup's base_uri to contain only the
> protocol for all the ESourceGroups? If yes, then I think it's not the
> best thing, because for example evolution-mapi uses as base uri
> "mapi://u...@server/", and each acco
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 looke
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 bet
On Wed, 2010-06-09 at 14:49 +0100, Ross Burton wrote:
> local:<>, 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 unsubscribe
301 - 400 of 610 matches
Mail list logo
