Re: [Evolution-hackers] Evo-Plugin Coding Style

2010-07-01 Thread Tor Lillqvist
 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 that then corresponds to
obviously depends on what the current column before the tab is.

I.e., for the traditional (and I mean *really* traditional) eight
column tab width, if a line has:

abcTABdef

*that* TAB character corresponds to *five* spaces. Not eight.

--tml
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] mail address validation

2010-01-21 Thread Tor Lillqvist
 $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 with a regex? Or is it simply so that
no software actually properly implemented the spec until Jeff Friedl
constructed that regex?

--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] EVolution-MAPI

2009-10-27 Thread Tor Lillqvist
 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* Windows. Cygwin is not used.

Theoretically it shouldn't be hard to build Evolution and everything
below for Cygwin. But Evolution running on Cygwin certainly is not a
project I personally would be interested in taking part in, or using.

(Yes, I know I didn't answer his actual question.)

--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] EVolution-MAPI

2009-10-27 Thread Tor Lillqvist
(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, makefiles and all
 necessary stuff.

Yes, feel free to do that.

The overwhelmingly simplest way to build software like Evolution and
the necessary parts of the GNOME stack etc below it for Windows is to
cross-compile from Linux. Doing it like that means you have few
problems with autotools or libtool. That is certainly the direction I
am (slowly) moving, even if I still do build natively on Windows those
packages that I distribute on ftp.gnome.org.

Take a look at the openSUSE Build Service where a colleague of mine
has set up several projects cross-compiling lots of software packages
for Windows, see for instance
http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.0/noarch/

 I just wonder if one from your team could point me to way of compiling it.

my team? ;) Ack, no, I doubt people have time for that. Just start
by learning to do simpler things first, make sure you understand what
is going on, and then move on to more and more complex stuff. Don't
jump in at the deep end. Start by learning how to (cross-)compile for
instance GLib.

 That would be a great contribution to people like me wnat to get rid of MS
 desktop enviroment.

Sorry, I think you misunderstand something here. Few people work on
Evolution etc just out of idealism or a desire to hurt Microsoft.
(Besides, you said yourself that in your case you would still be using
an Exchange server, *and* obviously a Windows desktop, so I don't
fully see your point here.)

--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] How to create portable modules

2008-08-07 Thread Tor Lillqvist
 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 to avoid them would be to
restructure the code, and that isn't happening soon (?). What they
warn against works fine on all platforms that Evolution runs on anyway
(Linux, Solaris, maybe other ELF-based POSIX systems, Windows).

If Evolution would be ported to some other kind of system (non-ELF
POSIXes like (older?) AIX or HP-UX, OpenVMS, etc), there are more
serious things that need fixing, like the circular dependencies
between shared libraries.

--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Understanding (and maybe cleaning) a11y library split in evolution

2008-06-16 Thread Tor Lillqvist
 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 stuff on
Windows, where there *can't* be unresolved externals in shared
libraries (i.e. DLLs)...

It would be really nice to cut down the number of shared libraries
built in e-d-s and evolution. I guess originally there might have been
some clean hierachy and separation of functionality behind the
plethora of shared libraries, but the situation has deteriorated quite
badly, with components depending on each others, generic libraries
depending on components, etc. The ideal would be if one could build
e-d-s and evo also on Linux with the libtool switch -no-undefined
(making sure that it actually is enforced, possibly by also using the
ld switch --no-undefined or something)... Even though Windows in
general of course is quite braindead, in some respects it enforces
somewhat cleaner design... the ELF binary format is too forgiving
IMHO... but I probably am biased.

[1] Luckily, on Windows there is the concept of import libraries
which are what actually are used when linking, so the workaround is to
produce fake import libraries (referring to a DLL name that doesn't
exist yet) for bootstrapping purposes at first in the build, and then
link with those...

--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Please pay attention to evolution-exchange trunk while I commit the outstanding Win32 diffs to it

2008-05-08 Thread Tor Lillqvist
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 evolution-exchange trunk still works.

(Yes, I know that evolution-exchange is kinda getting obsolete,
but still, better late than never...)

Cheers,
--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Post-release version incrementing

2007-12-12 Thread Tor Lillqvist
 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 the idea, others don't see the point. In any case, if
some change in convention happens, it presumably won't be in the
current development cycle.

--tml

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Post-release version incrementing

2007-12-10 Thread Tor Lillqvist
 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
http://cairographics.org/manual/cairo-Version-Information.html . The
micro version number is even in released tarballs, and odd
inbetween. The even number never exists in SVN. The micro number is
bumped by the person doing a release, and then bumped again and
committed after the tarball has been built. Thus there cannot be any
confusion between official released versions and builds from SVN at
least as far as version numbers are concerned.

--tml

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Let's clean up dead files in Subversion trunk

2007-09-24 Thread Tor Lillqvist
 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
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] your Software Evolution 2.6.2 for Win32 on ComputerBILD covermount CD

2007-01-10 Thread Tor Lillqvist
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 Open Source software. Read the license. (And anyway, even if
you would need permission, it isn't I who who would be the right
person to sign any agreements. Novell owns the copyright to Evolution,
and the copyright to the large number of Open Source libraries it uses
each have differing copyright owners.)

The only thing you *might* need permission for is to use the
Evolution trademark (which is owned by Novell). But I don't know how
strict this is? I am certainly no lawyer. Do all the Linux distros
that distribute Evolution have explicit permission to use the
Evolution name? At least, what you definitely should not do is to
claim that Novell would in any way support Evolution on Windows or
endorse your redistribution of it.

I don't have any system requirement sheet except that I know for
sure it won't work on Win9x or NT4.

Anyway, the 2.6.2 version is a bit old. Unfortunately there isn't any
all-inclusive end-user-friendly installer for the latest version,
2.8.2, like there is for 2.6.2. There is only .zip files with binaries
for the individual software packages at ftp.gnome.org.

--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Latest 'stable' CVS tag

2006-09-09 Thread Tor Lillqvist
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 are created
for gnome-2-16. 

--tml

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [PATCH 3/3] Add some missing includes

2006-08-15 Thread Tor Lillqvist
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 gtk/gtkeventbox.h
 +#include gtk/gtkimage.h

Isn't the correct thing here to just include gtk/gtk.h and not attempt
to hand-pick individual gtk headers?

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [PATCH 3/3] Add some missing includes

2006-08-15 Thread Tor Lillqvist
ti 2006-08-15 klockan 10:18 -0400 skrev Jeffrey Stedfast:
 the original idea was to speed up compile time

Sure, I can guess that, but is it worth it? Some timings would be
interesting, but on the other hand, it can't be worth spending time on
doing such timings...

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Bug: win32 evolution windows filesystem.

2006-08-02 Thread Tor Lillqvist
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, needs to be fixed. (I guess I should really open a
bug in bugzilla for this.)

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

2006-07-21 Thread Tor Lillqvist
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 Win32 porting (spring 2005,
roughly), many functions were identified that were duplicated (!) in the
evolution-data-server, evolution and evolution-exchange modules
(module in the CVS sense). They were kept in/moved to libedataserver,
simply because that seemed to be the best place as everything else
linked to it already anyway, and I didn't want to add yet another
library.

There used to be, even earlier, a module called gal (GNOME Application
Library I think) containing a library libgal, which got scrapped
(presumably because nothing except Evolution (and e-d-s) used it despite
its name) from which some of these functions had been copy-pasted. In
retrospect, perhaps scrapping libgal wasn't a good idea after all, maybe
it should just have been renamed, to libevolution-and-friends or
whatever?

Somebody please correct me if my memory serves me wrong...

--tml



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-19 Thread Tor Lillqvist
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 like a charm. I am a bit embarrassed now, though, that I
so lightly had just ifdeffified the code in ORBit2 that does FD_CLOEXEC
on the sockets, without really thinking what consequences there might be
on Windows when sockets get inherited. Oh well.

Luckily there doesn't seem to be that many uses of FD_CLOEXEC in the
GNOME libs that I have ported, or Evo. Most of them are in code for
functionality that is ifdeffed out for Windows completely anyway.

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-19 Thread Tor Lillqvist
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() where the unregistration is currently done
(but doesn't work) is called from the same
notify_no_windows_left_idle_cb() function (through
bonobo_object_unref()).

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-18 Thread Tor Lillqvist
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 are inherited by child processes in Windows. (Like file
descriptors in Unix.) Thus even if the Evolution process, which created
the socket and was listen()ing on it dies, the socket still exists in
LISTENING state as it has been inherited by the processes that Evolution
has started (bonobo-application-server), even though said processes are
blissfully unaware of it... This doesn't happen on Unix because ORBit2
sets FD_CLOEXEC on the sockets it creates. FD_CLOEXEC doesn't exist as
such in Windows, so that code is just ifdeffed out, and I haven't really
much thought about what consequences this might have... until now.

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.

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Windows version status?

2006-05-08 Thread Tor Lillqvist
On må, 2006-05-08 at 11:46 +0100, Pejvan BEIGUI wrote:

 I have been following the Evolution mailing list for a while now, but
 I can't seem to find any information about the Windows port,
 mentionned here:
 http://go-evolution.org/Evo2.6#W32.2Fx64_portingeven though the
 2.6 has now been released. 

It's a wiki, you are free to add stuff there if you intend to help with
a port to 64-bit Windows, if that is what the rather cryptic mention on
that page means... I personally don't have any plans to port Evolution
to 64-bit Windows. (Well, actually, building *Evolution* for 64-bit
Windows would presumably not be a big deal at all, once all the
dependencies are in place. Hint: none of them, not even a suitable
compiler, are.)

 Is there any news about that port? Are there nightly builds available
 somewhere? 

You mean the port to normal 32-bit Windows? Sure, that has been
available for quite some time already. There are binaries available on
the gnome ftp site, see
http://ftp.gnome.org/pub/gnome/desktop/2.14/2.14.0/win32/README.evolution .

(No Win32 binaries of 2.14.1, unfortunately.) Once GNOME 2.14.2 (and
Evolution 2.6.2) is released I will upload fresh builds. There are no
nightly builds (of HEAD, you presumably mean?). I build HEAD of e-d-s
and Evolution (etc) only a couple of times a month to make sure the
Win32 support doesn't bitrot.

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Re: Evolution, Evolution-Data-Server, GtkHTML, Evolution-Exchange branched to gnome-2-14

2006-03-09 Thread Tor Lillqvist
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 http://go-evolution.org/files/f/f5/E-e.tml-diffs.2006-01-18.txt )
can be committed to HEAD, so that it won't bitrot away?

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] building evolution-data-server against the already installed libdb

2006-03-05 Thread Tor Lillqvist
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


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Re: Symptom-fixing for Win32 paths

2006-01-19 Thread Tor Lillqvist
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++ = '/';
   }
 #endif
 
 IMHO this is high level symptom-fixing. Wouldn't it be better to fix
 camel in such a way that it accepts Win32 paths with \ characters?

In general, yes, and such fixes indeed have been added wherever
necessary, I hope. The code has been changed to use GLib path and URI
manipulation functions and macros instead of manually scanning for '/'
or constructing file: URIs by just prefixing file://.

But the case you mention is a special one, as base_directory is used to
set up an mbox: URI (see mc_setup_local_store()), and we don't want
backslashes in URIs. OK, so maybe it would have been cleaner to do the
backslash-to-slash change on a temporary string as late as possible, in
mc_setup_local_store(). But it might be, I don't recall if I tested
this, that this wouldn't work, if some code later compares parts of URIs
to the base_directory. Then such comparisons would have to be changed to
treat both slashes as equal, etc.

I will add a comment at that code snippet explaining the rationale for
it...

 Maybe tomorrow we'll have an Operating System that doesn't use character
 delimited paths in a string (or whatever or however).

Considering how many details that had to be fixed here and there in
Evolution and dependencies just for Win32, where pathnames after all are
*almost* like Unix, such an operating system would then surely need
massive changes. 

Anyway, I don't really think there is much chance that such an operating
system will appear; no matter how non-Unixish some future operating
system might be in the core, I find it very likely that it will offer a
POSIX layer with POSIX file names on top (or, heaven forbid, a Win32
layer...) Didn't even VMS transmogrify into OpenVMS, providing POSIX
pathnames, too, or am I mistaken?

 Wouldn't fixing the implementations for camel_session_construct and
 camel_mkdir be a better solution?

camel_mkdir() has been replaced with g_mkdir_with_parents() in HEAD, and
that function, like all GLib functions, and the underlying Microsoft C
library and Win32 API functions, accept both kinds of slashes.

--tml

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] symbol ugliness ...

2006-01-10 Thread Tor Lillqvist
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 being fixed, in
HEAD. And the libgal library doesn't exist any longer. Anyway, the list
you provided sure needs to be scrutinized.

Odd that your script didn't notice some duplicated functions from code
generated the ORBit2 IDL compiler. There should have been such in, lemme
recall, the libevolution-mail and libeshell DSOs, for instance. Or maybe
those cases had been introduced only in HEAD? (Anyway, they should be
fixed now.) Or isn't this finterpose script about just finding duplicate
symbols, but something more complex?

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Don't forget to write ChangeLog entries!

2005-12-31 Thread Tor Lillqvist
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
cvs server: Updating mail/default/C
cvs server: Updating mail/default/de

Notice: no update to mail/ChangeLog. You get the feeling somebody is
trying to sneak in something without telling... Sure, it's trivial to
run cvs log and/or cvs diff on the changed files (I didn't do that yet)
(and that of course is the only way to *really* find out what's changed
by who and when, ChangeLog entries can and should be just summaries).
But still, please try to write also a ChangeLog entry for each change,
no matter how trivial or cosmetic.

All this IMHO, of course.

--tml

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?

2005-12-21 Thread Tor Lillqvist
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 first time it is called. I don't think any GLib functionality would
take care of that?

OTOH, those calls could well be taken care of by the appropriate main
program, i.e. shell/main.c. And actually, surprise surprise, there
already are calls bindtextdomain (GETTEXT_PACKAGE, EVOLUTION_LOCALEDIR)
and bind_textdomain_codeset (GETTEXT_PACKAGE, UTF-8) there. Presumably
the E_I18NDOMAIN in evo/e-util/e-util.c is the same as GETTEXT_PACKAGE
in main.c? Could uses of e-i18n.h be replaced by, eh, gi18n.h? e-i18n.h
include also gnome-i18n.h. what role does that play? Does the fact that
Evo HEAD should be buildable against GLib 2.4 (and whatever is the
corresponding old GNOME version) confuse issues any further?

Argh, this mess is so weird...

 Is it just legacy code from the
 days before decent i18n in glib?

Sure. 

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Win32 changes are now committed to evo (and e-d-s)

2005-12-18 Thread Tor Lillqvist
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
e-d-s/libedataserver/e-xml-utils.c.

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

2005-11-24 Thread Tor Lillqvist
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 inclusions of e-time-utils.h
in evolution end evolution-exchange to include it from libedataserver
instead, and committed. Now the evolution copy of e-time-utils.h can be
dropped from being installed. Presumably we can drop e-time-utils.c also
from the sources of libeutil, or does Evo need to maintain 100% ABI
compatibility in its shared libraries between releases? Is there
3rd-party code (plugins) in the wild that would expect to find these
entry points in the libeutil shared library?

I think it would be fine to just go ahead with changes like this that
are obviously right and don't affect code behaviour, instead of waiting
for discussion and approval which might never appear.

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Making the editor component replaceable (some first idea's, overview what would need to be done)

2005-10-16 Thread Tor Lillqvist
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 yet. How likely is it
that the switch will happen? Would it be feasible to keep support for
both gtkhtml and gtkmozembed in the code, and have them selectable at
configure time?

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers