style. patch.shtml talks about 8-space-tabs
Just some nitpicking here: I hate it when people say loosely that tabs
correspond to 8 spaces (or four, or whatever). A TAB character indents
to the next multiple of the tab width. The tab width is a certain
number of columns. Exactly how many spaces
$RFC822PAT = 'EOF';
[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\
(etc)
I want a T-Shirt with that!
I wonder what the RFC822 authors were smoking. Or is it possible to
implement a correct RFC822 email address pattern matcher in code in a
significantly simpler way than
I wonder if can myself compile it using cigwin environment from the source
Cygwin is not Windows. Cygwin is a kind of Unix that just happens to
run on top of Windows. The existing port of (older versions of)
Evolution and the necessary parts of the GNOME stack below is
specifically for *native*
(Please don't follow-up privately to a message thread that started on
a public mailing list. I am adding evolution-hackers back to the
recipient list.)
It would be great to have a similar tutorial on how to build it from source
to port for windows, the packages required, the configure,
What configure arguments do I use to build evolution so that the following
portability warnings don't appear:
*** Warning: Linking the shared library liborg-gnome-calendar-weather.la
against the loadable module
*** libevolution-calendar.so is not portable!
Just ignore the warnings. The way
you'd get a nice dependency loop in Makefile.
Welcome to the club. The circular dependencies between shared
libraries in e-d-s and evolution are interesting. As you might
imagine some dirty hacks, er, I mean clever tricks[1], are needed to
work around the circular dependencies when building this
Hi,
I have now started committing the outstanding Windows patches to
evolution-exchange trunk. I am quite careful and try to make sure I
don't break anything on Linux, but still, it would be nice if somebody
who is able to test evolution-exchange on Linux could check now and
then that
Tor,
It may not work out here, since the micro version is what we bump during
release which is in sync with the GNOME Release micro version.
I sent the idea to desktop-devel-list and gtk-devel-list instead, as
mbarnes suggested. Let's see if anything comes out of it. Some people
seem to like
I notice we've been doing pre-release version incrementing
[...]
I was wondering if the team would be open to switching to post-release
version incrementing
May I suggest a third, in my opinion superior, way: Both.
That's what cairo uses, see
someone will
inevitably waste time maintaining them, not realizing or forgetting
they're dead.
Oh yes. I remember doing that several times when I was porting it to Windows...
--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
Konstantin Breyer writes:
Join in. For the sake of good order, please fax the signed license
agreement (please delete inapplicable terms) back to us (+49/40/34
72 93 77) and e-mail me the system requirement sheet.
You don't need any permission to redistribute Evolution. That's one
point of
fr 2006-09-08 klockan 12:02 -0400 skrev Reid Thompson:
What tag should I use to get the latest stable build from CVS?
Or is HEAD considered stable enough to use?
Well, at this fleeting moment in time, just after the release of fresh
major versions, HEAD *is* stable. Until new stable branches
må 2006-08-14 klockan 19:58 -0400 skrev Pavel Roskin:
From: Pavel Roskin [EMAIL PROTECTED]
--- a/widgets/misc/e-icon-entry.c
+++ b/widgets/misc/e-icon-entry.c
@@ -39,6 +39,8 @@ #include e-icon-entry.h
#include gtk/gtkentry.h
#include gtk/gtkbox.h
#include gtk/gtkhbox.h
+#include
on 2006-08-02 klockan 14:02 +0200 skrev Smartuser:
I've noticed that when you want to connect for example to an IMAP server that
runs on a non standard port it wants to create a file with : in it
like .evolution/mail/[EMAIL PROTECTED]:2143 this failes becouse of windows
Yup, known problem,
on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof:
It simply looks like Evolution developers didn't know where to stack all
these Evolution libraries. And thought .. oh, we already had this
Evolution data server thing .. lets simply put it there.
During the 2.6 development phase and the
må 2006-06-19 klockan 00:18 +0300 skrev Tor Lillqvist:
I think it is possible to get the same effect as FD_CLOEXEC, though, by
duplicating the socket using DuplicateHandle() to be non-inheritable,
closing the original, and using the duplicated socket instead. Will have
to try.
Indeed, works
må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast:
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is that in the idle cb, there may still be a race?
Nah... The impl_finalize()
lö 2006-06-17 klockan 02:23 +0300 skrev Tor Lillqvist:
I should still of course also investigate why the other (unknown)
mechanism which causes unregistration to happen anyway on Unix doesn't
work on Windows...
I think I have a good guess now: The problem is that all sockets by
default
to 2006-03-09 klockan 10:51 +0530 skrev Srinivasa Ragavan:
The gnome-2-14 branch for Evolution and Evolution-Data-Server, GtkHTML
and Evolution-Exchange has been created.
Does this mean the outstanding Win32 patch set to evolution-exchange
(see
As far as I can recall, when I asked the same thing, the response was
that this is how Berkeley DB is supposed to be used, embedded into
another product. That some (all?) Linux distributions choose to also
ship a separately installed instance was irrelevant ;)
--tml
to 2006-01-19 klockan 23:12 +0100 skrev Philip Van Hoof:
in mail_component_init somebody (I'm assuming you) did something like
this:
#ifdef G_OS_WIN32
{
char *p = priv-base_directory;
while ((p = strchr(p, '\\')))
*p++ = '/';
fr 2005-12-09 klockan 17:50 + skrev michael meeks:
^^
Hmm, either you have a time machine Michael, or there has been some
slight delay in the mailing list ;-)
Anyway, many of the duplicates you list (I guess that's what this is
about, interposing ?) have indeed been fixed, or are
Hey, it's very irritating to do a cvs update and notice stuff like:
cvs server: Updating libwombat
cvs server: Updating macros
cvs server: Updating mail
P mail/em-folder-properties.c
P mail/evolution-mail.schemas.in.in
P mail/mail-session.c
P mail/mail.error.xml
cvs server: Updating mail/default
on 2005-12-21 klockan 10:45 + skrev Ross Burton:
I've not looked at the source, but what does e_gettext() do that the
i18n functions in glib/gi18n.h doesn't?
Well, e_gettext() calls bindtextdomain(E_I18N_DOMAIN,
EVOLUTION_LOCALEDIR) and bind_textdomain_codeset(E_I18N_DOMAIN, UTF-8)
the
All Win32 related changes have now been committed to evolution (and
evolution-data-server already some days ago). Please test that
everything still works as expected on Unix...
There is still some cleanup to do, for instance more stuff should be
moved from evo/e-util/e-xml-utils.c to
On Thu, 2005-11-24 at 18:57 +, Ross Burton wrote:
As evolution obviously depends on libedataserver already, surely for the
files which are identical there is no problem at all?
My thoughts exactly. I couldn't control myself, sorry, and went ahead
with one of the duplicates: I changed the
On sö, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote:
There's however a few issues and things to add:
One more point is that switching GtkMozEmbed will require an unknown
amount of work on the Win32 platform. It might be (relatively) trivial,
or it might be quite difficult. I really can't say
27 matches
Mail list logo
