On Tue, 2011-11-08 at 15:44 +0100, Christian Hilberg wrote:
> With this release, active development has been moved away from SourceForge and
> under the hood of the GNOME project. Thanks to everyone helping with the
> migration and thanks for the warm welcome at gnome.org.
Welcome aboard!
__
On Mon, 2011-11-07 at 16:21 -0500, Matthew Barnes wrote:
> Would anyone object to me removing the migration code from the old mail
> summary files to SQLite? Believe it or not it's been three years since
> we started using SQLite back in Evolution 2.24.
It's done.
http://g
you find a need for libedataserver to link to
Camel in 3.3, feel free.
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, 2011-11-14 at 23:33 -0500, Matthew Barnes wrote:
> There is no longer any _technical_ reason why Camel needs to be bundled
> in the evolution-data-server module. I DO intend to split Camel off at
> some point, but not yet. Parts of its API are still a complete mess and
>
The "wip/gsettings" branch has been merged to master for Evolution
3.3.3. This branch migrates most of our simple GConf keys (strings /
integers / booleans) to GSettings. Huge thanks to Rodrigo Moya for his
work on this!
After installing the updated code (which includes a .convert file), I
belie
On Wed, 2011-11-23 at 16:05 +0530, Srinivasa Ragavan wrote:
> I rebased email-factory-3-4 branch of evolution on top of gsettings
> merge. I'm away for a week in Finland, hopefully you get time to merge
> this around :-)
Okay, thanks. I'll be traveling too for the next couple weeks. Working
off
On Thu, 2012-01-05 at 14:30 +0100, Milan Crha wrote:
> I feel it's a good time to release final 3.2.3, because the 3.2.2 had
> been released on 2011-11-14 which is quite long time ago. The 3.3.4 is
> scheduled on January 16th, thus what about doing the 3.2.3 release
> the next week, say on January
ay there should be pretty inconspicuous.
Thoughts?
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
Akhil, are you still a mailing list administrator? The subscribe pages
on mail.gnome.org list you and "pg...@novell.com" but I don't know who
that is.
Anyway, I noticed a typo on the evolution-list description [1]:
"General discussion and user queries of the Evolution"
We need to remove
On Fri, 2012-01-20 at 17:24 +, Reid Thompson wrote:
> Attempting to update to 3.3.4 from gnome-3-2 using the sources below.
> I'm currently getting the build error noted at bottom. Do I need to
> bump one of the other components up, or am I missing a component?
'camel_operation_cancel' and '
On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote:
> I need to replicate some code paths of IMAPX (e.g. all paths that
> lead from the Store to imapx_untagged, so I can extend this one
> for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX
> code duplication I cannot avoid at
On Fri, 2012-02-03 at 11:38 +0100, Alexander Larsson wrote:
> IMHO we should implement actual network availibility tracking in
> EDataFactory (using NM or ConnMan) to get the real state inside the
> backends (i.e. if there is no network the backends should always be
> offline).
Alex and I talked
On Fri, 2012-02-03 at 21:27 +, Philip Withnall wrote:
> This sounds good. Do I have to make any fixes to the Google Contacts
> address book backend, or will it all be handled centrally? (i.e. With
> this GNetworkMonitor change, will there be any bugs left in the Google
> backend’s handling of
On Mon, 2012-02-06 at 12:55 +0100, Milan Crha wrote:
> I just realized that libemail-engine and libemail-utils libraries are
> installed into $PREFIX/lib, while any other evolution libraries are
> installed into $PREFIX/lib/evolution//...
>
> Is the change with libemail done on purpose or just a m
On Mon, 2012-02-06 at 09:21 -0500, Matthew Barnes wrote:
> Good catch. I think they should stay in $PREFIX/lib/evolution/
> until we start versioning them properly. Not sure we're ready for that.
> At minimum those APIs need to be fully documented for Gtk-Doc first.
FYI, I have
On Thu, 2012-02-09 at 12:12 +0100, Dan Vratil wrote:
> just a short note - thanks to Milan who has decied to dig into WebKit,
> embedding widgets into WebKit webview works again.
That's awesome news! I think I suffered that same bug early on in the
branch. Nearly drove myself crazy trying to get
On Tue, 2012-02-14 at 17:03 +0530, Chenthill wrote:
> Hi,
> The meeting goes as follows,
>
> * Project updates
> * Discussion on queries/decisions
> * Individual updates
>
> http://live.gnome.org/Evolution/CommunityMeet
I won't be able to make the meeting tomorrow as I'll be driving all day.
mplex than the rest.
http://live.gnome.org/Evolution/ESourceFileFormat
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
ng reorganized, Srini assures me it works well, my own
testing seems to confirm that, and I'm doing my due diligence to make
sure everything builds smoothly for Monday's release.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hac
pane,
I recently added an EMailReader::message-loaded signal that you can tap.
See the "mdn" module for an example of connecting to this signal:
http://git.gnome.org/browse/evolution/tree/modules/mdn/evolution-mdn.c
Hope this helps,
Matthew Barnes
__
> button that moves the selected email to the 'All mail' folder.
Of course the "All Mail" folder is specific to GMail/IMAP. So is this
button only shown for GMail/IMAP accounts? If not, what does it do for
other account types or non-GMail IMAP accounts?
Matthew Barnes
__
ined folder"
action, automatically configured as "All Mail" for GMail/IMAP accounts.
Choosing the designated "archive" folder would fit nicely in the
"Special Folders" section of the Account Editor window, perhaps with a
check box for users who pref
ent
cycle towards Evolution 3.6 should prove to be interesting. :-)
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
opment :)
I'd suggest running "git rebase -i HEAD~200" (or however many) on your
branch and squash the commits down yourself, and then merge the result.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
T
t yet in 'master' branch:
http://git.gnome.org/browse/evolution/tree/mail/e-mail-config-defaults-page.h?h=account-mgmt
Then I'll add a new function to that class for you to call to append a
new button. Not sure exactly what it will look like yet.
Matthew Barnes
g/browse/evolution/tree/modules/calendar/e-cal-shell-backend.c#n863
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
ems to be an edge case that the workaround does not cover:
Hmm. When I wrote that workaround I was under the impression that an
upstream libical fix was imminent. Perhaps we just need to bump our
minimum libical requirement, or is upstream still not thread-safe
On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote:
> Next part is, that I think network (un)availability and Evolution/E-D-S
> online/offline state are two separate things, which got mixed in the
> current implementation. Network unavailability means I cannot write my
> objects onto the se
Might want to repost your full message to the list. I assume you didn't
mean to reply to me privately?
On Tue, 2012-04-03 at 16:05 +0200, Christian Hilberg wrote:
> Well okay, that's a little more than the current EBackend "online" property,
> since it can tell me whether a certain host can be r
On Tue, 2012-04-03 at 10:40 -0400, Matthew Barnes wrote:
> g_network_monitor_can_reach() takes a GSocketConnectable -- which is
> just an interface that's implemented by several concrete classes like
> GNetworkAddress (based on host name and port number) and GNetworkService
> (bas
On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote:
> Seems to me that opening a connection in order to find out whether I could
> open a connection is more than evo-kolab would need. Unless the
> "service-available"
> check would be really cheap, it seems to me that "host-reachable" would
On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote:
> How about the "service-available" to be set much like the to-be
> "network-available", through GNetworkMonitor, as an EBackend property,
> which, when changed, emits a signal?
>
> Just rough thinking, nothing elaborate as yet - I'll be
On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote:
> How about the "service-available" to be set much like the to-be
> "network-available", through GNetworkMonitor, as an EBackend property,
> which, when changed, emits a signal?
>
> Just rough thinking, nothing elaborate as yet - I'll be
On Wed, 2012-04-04 at 21:25 +0100, Philip Withnall wrote:
> Nitpicky, but what happens if a backend has to deal with multiple hosts?
> The only example I can think of at the moment, and it's a stretch, is
> the Google Contacts backend. It connects to one host for authentication,
> and a different o
On Thu, 2012-04-05 at 12:05 +0200, Christian Hilberg wrote:
> This is why I propose a dedicated offline state, which is not dependent on
> network availability, and which is visible to the user by being displayed
> in each client that connects to E-D-S. Such a state makes it very clear to
> both, u
Given all the scrolling and selection bug reports I'm seeing from
GTK-3.4 users, none of which are present when building against GTK-3.2,
I suggest we keep our minimum requirement at GTK-3.2 until these issues
get sorted out, either by us or by Xorg/GTK+ developers.
The problems seem to have start
the message list is
already rife with such tricks, and each new one makes it harder to keep
the logic clear and thus harder to maintain. I'm happy to review a
patch, though, if you still want to attempt it.
Matthew Barnes
___
evolution-hackers ma
On Tue, 2012-04-17 at 22:25 +0100, David Woodhouse wrote:
> It's a constant PITA that you have to have the latest versions of
> *everything*, when in practice most of those dependencies aren't really
> true at all.
That's not true for Evolution.
We don't require unstable releases of base librarie
On Tue, 2012-04-17 at 17:03 -0600, Zan Lynx wrote:
> Please make sure that you have a good way to inform the user so that he
> knows Evolution is busy. He needs to know when it is okay to suspend the
> laptop or pull the networking cable out.
That's what the task bar at the bottom is for.
___
out if you're curious. Just be cautious of the account migration:
it's a one-way trip. Maybe test it on a different user account for now.
Matthew Barnes
[1] http://lists.freedesktop.org/archives/telepathy/2012-April/006072.html
___
evolutio
can take up, or even you yourself could
start on the E-D-S side if you're not too busy. Roughing in the new
D-Bus method should be a fairly simple first step.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change yo
e the
> correct version via jh?
Not a jhbuild expert but I believe it builds the HEAD revision of the
"master" git branch by default (currently version 3.5.2). Or you can
choose a stable branch by setting the 'moduleset' variable in your
~/.
ldn't think of anything I liked
better so I just dropped that part and wound up liking the result -- so
much so that my obsessiveness about consistency got the better of me on
the Evolution side. :)
Beyond requiring a clean reinstall the change should be transparent.
Matthew Barnes
_
On Thu, 2012-05-17 at 13:31 +0200, Milan Crha wrote:
> thinking about all the upcoming changes, what about removing also
> camel_folder_has_search_capability() and its corresponding flag?
+1 Do it. The less flags the better.
> P.S.: Maybe the same applies for the
> camel_folder_has_summary_cap
ile is not going to be extensible the way we need.
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
load data you speak of.
It's certainly more tedious to write in C but offers more flexibility
than a mere function pointer.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe,
PI changes.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
al again by 3.6.
Now that account information is stored in XDG-compliant directories,
we should be able to create a much nicer and fully automated test
harness that doesn't risk interfering with your own accounts.
I have several patches prepared already for other projects to help them
q
On Thu, 2012-05-24 at 16:15 -0400, Matthew Barnes wrote:
> Therefore I think it's time to retire Evolution-Exchange. That module
> has seen steadily decreasing maintenance for several years, the newest
> version of Exchange it supports is now a decade old, and frankly it was
&g
at
could help test the changes, I would reconsider.
I will, however, release an evolution-groupwise 3.5.2 with the changes
you made recently for it. That's a fair request.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote:
> W.r.t evolution-groupwise, it would be good to continue it until this
> release.
Sorry, I read "this release" to mean 3.6. If you just meant 3.5.2 then
I guess disregard my other response. Haven't had my coffee yet. :)
_
ll checking?
Enchant? Will their APIs allow us to recreate the context menu with
spelling suggestions plus other editing actions?
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
.
> I can also contribute in my free time as well for GroupWise. As
> exchange, EWS and GroupWise are good enterprise solutions for
> Evolution.
Fair enough. I'll try to make the necessary changes some time after the
merge and then hand it off so you guys can tell me what
best of it
by treating this an an opportunity to dump some old baggage so we have a
leaner code base to focus on, even if that means leaving a few users out
in the cold. No one is going to seriously criticize us for wanting to
lighten our load
may want to salvage the spell/language classes from
GtkhtmlEditor, which also talk to Enchant. I wrote those a few years
ago based on a GLib proposal called GSpell that never went anywhere.
It's still languishing in Bugzilla. If ever GLib does grow some spell
checking support,
/www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/
Neat! Does the text-highlight have to be chosen each time or is it
remembered somehow?
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
On Thu, 2012-05-31 at 12:39 -0400, Matthew Barnes wrote:
> This is a heads up that I will be releasing Evolution 3.5.2 and co. this
> weekend and then merging the account-mgmt branches for E-D-S, Evolution,
> and Evolution-EWS. Evolution-MAPI will follow sometime after the merge.
Th
On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote:
> For 3.1, I would like to provide a top-level header file for each of the
> libraries in E-D-S and deprecate including individual header files. The
> benefits should be clear by now: more flexibility to change or rearrange
>
opic for desktop-devel-list.
June 18th works for me. I'll pencil that in on the wiki.
It's still pretty early in the devel cycle so I wouldn't rule out a
3.4.4 later on if it's needed, maybe around 3.5.90.
Matthew Barnes
___
evoluti
On Mon, 2012-06-04 at 08:55 +0200, Milan Crha wrote:
> What about a "compromise", drop support for evolution-exchange when
> 3.7.x development begins? I suppose it'll be fair to have the main API
> changes done and any potential community person taking care of it will
> not need to learn all the ha
't seem
like much of a burden, but any effort to make the process more automated
is appreciated.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
re been steps taken already towards implementing this infrastructure?
Not to my knowledge, but I think step one is stubbing in a synchronize()
method in EClient and relevant backend interfaces. That much should be
easy.
Matthew Barnes
___
evolution-hac
hough we've discussed it a bit on IRC. I hope to find time to do so
soon.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
;ll hold team-wide IRC meetings as needed henceforth.
Discussion of and consensus on this decision is posted here:
http://projects.gnome.org/evolution/meeting-logs/2012-06-20.shtml
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gn
bugs.
> The account gtkhtml-maintain...@ximian.com was merged into existing
> gtkhtml-maintain...@gnome.bugs.
Thanks for taking care of this!
I think I tried unsuccessfully to have the ximian.com addresses fixed a
few years ago. Glad it inconvenienced someone enough to finally force
http://git.gnome.org/browse/evolution-data-server/commit/?id=918ad005b0a2770be84c2bb13727aa57f166cc81
I had a hard time even reproducing this failure. Finally stumbled on it
by accident while rebuilding in a clean environment.
Build break alerts are appreciated when stuff like this slips thr
On Mon, 2012-07-02 at 09:12 +0200, Milan Crha wrote:
> Is there any objection? If not, then I'll revert the mentioned commit in
> sources next week or so.
Please don't. GTK+ claims to handle this now, we should defer to them
so our Open/Save dialogs behave consistently with other GTK+ apps. If
t
On Mon, 2012-07-02 at 14:47 +0200, Milan Crha wrote:
> Well, they do not do it right, and this kind of "outsourcing" proved to
> be problematic in the past, thus why to rely on something nonworking
> with "not our fault, ask them to fix it" explanation? I always thought
> we do software for people,
On Mon, 2012-07-16 at 09:12 +0200, Milan Crha wrote:
> it's a month since 3.4.3 release, and more fixes landed into respective
> evolution core products since then, thus I propose to do 3.4.4 release.
>
> It's harder with the date, as we had 3.5.4 release today, the next week
> starts GUADEC and t
On Mon, 2012-07-16 at 13:41 +0200, Milan Crha wrote:
> there seems to be missing functionality in EBackend descendants to
> reconnect on connection lost, like is possible in Camel. With Camel,
> I check returned error for certain values and if the error is one of the
> known for connection issues,
On Mon, 2012-07-16 at 17:58 +0200, Milan Crha wrote:
> Hmm, do you mean to call things like e_book_backend_open() in a handler
> of another method (that for the async book backend), thus passing in
> EDataBook and opid dedicated to other operation on client's side? It
> sounds a bit crazy, but I'll
Client.html
Hope this helps,
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
On Thu, 2012-07-26 at 14:08 +0200, Milan Crha wrote:
> I asked for a string freeze break on gnome-3-4 branch in Evolution [1].
> I'll revert the removal, when/if they'll approve.
I meant it when I said I would consider that a regression.
___
evolution-h
In working on the create/delete remote folder API for collection
backends, I realized these backends are going to need something
equivalent to e_source_registry_authenticate().
e_source_registry_server_queue_auth_session() is a "fire and forget"
function in that the caller doesn't know when or eve
oteDeletable" interface.
With Evolution-EWS working, I'll be moving on to help Christian again
with Evolution-Kolab next week. I assume Milan will handle Evo-MAPI.
If there's time before 3.6, I think it would be cool to also support
this in the Google and Yaho
ibed in section 3.3.1 but have it run evolution instead.
Hope this helps,
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Just for the record, I made a few API changes to Camel over the weekend.
The changes help increase Camel's thread-safety. One lesson I learned
during the account-mgmt work is when returning a pointer to a reference
counted object in a multi-threaded environment, it's better to return a
new refere
On Mon, 2012-08-13 at 19:00 +0100, Philip Withnall wrote:
> This is all great work! Just a point to note: Telepathy uses the
> convention of calling refcounting getters ‘_dup_’ (e.g.
> “camel_session_dup_service()”) rather than ‘_ref_’. This seems better
> (imo) because ‘ref’ could get confused wit
On Mon, 2012-08-13 at 20:35 +0100, Philip Withnall wrote:
> Is this documented anywhere (perhaps in an introductory section in the
> EDS docs)?
Does the mailing list count? ;)
Good idea though. I guess I could document it in to the introductory
parts of libedataserver and libebackend for starte
day' operations for
> remote mail?
Those directories are for caching remote mail, correct.
The accounts themselves are in ~/.config/evolution/sources now.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To
he filters fail with "No
> such folder:... " messages
Those files just describe the account itself, not your mail folders.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
st:
[ ] Apply filters to new messages in Inbox on this server
Maybe the backend is confused as to which folder is now Inbox. Does
your Inbox folder show an Inbox icon in the folder tree?
Matthew Barnes
___
evolution-hackers mailing list
evolution-hacker
On Thu, 2012-08-16 at 19:04 +0200, Milan Crha wrote:
> ouch, I did that, I didn't think of filters at all :( The reason for
> movement to "Mailbox - User Name" is to be able to add folders of other
> users to the ews. They will then show in "Foreign Folders/Mailbox -
> other user/...", but it seems
On Fri, 2012-08-17 at 08:31 +0200, Milan Crha wrote:
>ews account name
> +-- Foreign Folders
> +-- Mailbox - someone else
> +-- some subscribed folder
> +-- Favourites (Public Folders)
> +-- Mailbox - User Name
I was suggesting to have separate top-lev
On Wed, 2012-08-29 at 16:11 +, Reid Thompson wrote:
> (evolution-calendar-factory:8178): GLib-GIO-WARNING **: Can't find
> module 'dconf' specified in GSETTINGS_BACKEND
> GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings
> will not be saved or shared with other applications
le weeks. I'll still have email and will get the 3.6.0 release out
on time. Returning the first week of October.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
ht
On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote:
> time to report on my progress in the composer port. I'd appreciate any
> feedback and ideas.
Thanks for the progress update!
The class breakdown sounds good to me. I'm all for having lots of small
classes with a well-defined purpose instead
On Wed, 2012-09-05 at 09:57 +0200, Christian Hilberg wrote:
> Thanks for the heads-up. I remember you mention some sort of API
> restructuring / rework concerning E-D-S, D-Bus and EClients you had in
> mind for 3.7/3.8 cycle. Do you have anything cooking in this regard
> already? Might be worth put
on't be on the clock, and thereafter reachable by email only until
Monday, October 8th.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/m
On Mon, 2012-09-17 at 12:18 +0200, Christian Hilberg wrote:
> Matt, I guess it'll be you pushing 3.6.0 out the door, right? (It's just
> a matter of when to expect 3.6.0 to be out so I can wrap up evolution-kolab
> for that release).
Yes, I'll handle 3.6.0 next weekend.
See: https://live.gnome.or
gnome.org/Evolution/ESourceMigrationGuide#How_do_I_create_a_new_calendar_or_address_book.3F
Hope this helps,
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.o
ation time. So it's created in its
own dedicated thread to ensure its signal emissions cannot be inhibited
by something pushing a different thread-default GMainContext. Otherwise
deadlocks occur when an ESourceRegistry method has to stop and wait for
a signal emis
alogs. Each module knows what extensions are supported by
its respective Camel/E-D-S backend.
Matthew Barnes
[1] http://git.gnome.org/browse/evolution/tree/modules
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your lis
the
backend modules can live together and share the extension classes.
Not sure if this fully addresses your question or not. I'm still at a
bit of loss as to your use case.
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
On Fri, 2012-11-02 at 14:12 +, Reid Thompson wrote:
> When compiling from current head, compilation stops on reaching
> @GNOME_CODE_COVERAGE_RULES@
You need a more recent gnome-common. 3.6 or later.
___
evolution-hackers mailing list
evolution-hack
se libraries, at
present I can only make hand-wavy motions in their general direction.
I'm hoping next year we can start taking real steps in that direction.
That's the best answer I can offer for now. In the meantime, maybe
consid
On Thu, 2012-11-22 at 08:52 +0100, Milan Crha wrote:
> I'm only waiting for an opinion from Matthew, then I'll happily change
> the build script.
I guess I don't have a strong attachment to it.
ChangeLog files are technically part of the GNU Coding Standards [1],
and strictly speaking the product
On Thu, 2012-11-22 at 09:13 +0100, Milan Crha wrote:
> What I have on mind is something what Camel already provides [1], the
> camel_session_alert_user() function, which basically provides generic
> dialog facility for asking users. The question is where to put such
> functionality for book/calenda
r libeutil will be
#include
which will bring in all headers in the library.
With all the base utility libraries under one header, maybe we can then
get serious about producing some good API documentation for this stuff.
My attempts thus far have been half-hearted at best.
Matthew Barnes
and File -> Empty Trash.
Shutdown Evolution and try running this little script:
http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb
Matthew Barnes
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or u
1 - 100 of 610 matches
Mail list logo
