Re: [Evolution-hackers] Evo-Plugin Coding Style
> 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: abcdef *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
> $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
(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] EVolution-MAPI
> 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] How to create portable modules
> 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
> 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
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
> 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
> 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
> 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] ANNOUNCE: Evolution 2.10.0, Evolution-Data-Server 1.10.0, GtkHTML 3.14.0 and Evolution Exchange 2.10.0
> > I'm sorry to spoil the fun, but you guys left
> >
> > g_print ("\n\a Header string finally is ** \n%s\n",
> >header_spec->str);
> >
> > in e-d-s, camel/providers/imap/camel-imap-folder.c:2367, which is pretty
> > annoying,
Ah. So *that* is why my wife keeps waking me up at night asking "what
was that noise"...
Not entirely seriously,
--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
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
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
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] [PATCH 3/3] Add some missing includes
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 > #include > #include > +#include > +#include Isn't the correct thing here to just include 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] Bug: win32 evolution windows filesystem.
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
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
[Evolution-hackers] My ORBit2 Win32 problem today
I spent much time today debugging a problem related to evolution-exchange. When quitting Evolution, and then after a while starting it again, it hang. bonobo-activation-server was waiting for a reply from evolution-exchange-storage.exe (which had been staying around even after Evolution quit). That process isn't actually supposed to stay around after Evolution quits .(Unlike gconfd-2, evolution-data-server and evolution-alarm-notify.) So, why didn't it go away? It actually was hung in a quite spectacular fashion, so no wonder it couldn't be contacted. (Its sockets were still in LISTEN and ESTABLISHED state, so bonobo-activation-server didn't notice the process was in fact dead as a dodo.) Well, the root cause why it didn't go away was the atexit() call in ORBit2's CORBA_ORB_init(). (Well, g_atexit(), but that is just a #define for atexit() in Win32.) The exact semantics for atexit() are hard to define on modern systems with shared and dynamically loaded libraries. What if one DSO registers an atexit() function that calls a function in another DSO? Apparently especially on Windows the environment in which the functions registered with atexit() eventually run can be rather random. My personal opinion is that atexit() should be banned... On Windows, atexit()-registered functions run when the registering DLL is being unloaded. As far as I know, there is no way to be sure what other DLLs are still present at the time. Apparently not even WinSock necessarily works at all then. This was what caused the hang. Why evolution-exchange-storage has affected but not other processes that link to libORBit2, I don't know, probably just a coincidence. As I said, atexit() behaviour has much randomness. So, I simply ifdeffed out the atexit() usage on Windows... Just let the process die, and any TCP peers should notice that the connections break and act accordingly. Seems to work fine, although I guess there is a risk that, like the comment in corba-orb.c says, the atexit() functionality really is needed "to clean up any remaining UDS and to flush any remaining oneway traffic in buffers". A safe way around this would be to explicitly flush and shut down CORBA and Bonobo before exiting main() in evolution-exchange/storage/main.c. Unfortunately I couldn't find any API to do that cleanly. Calling bonobo_debug_shutdown() (twice, as bonobo_init_full() apparently gets called twice and bonobo_debug_shutdown() needs to be called as many times to actually do anything...) causes a g_error() from bonobo_context_shutdown(): "In-proc object has no servant association this probably means you shutdown the ORB before you shutdown libbonobo". I wonder if that is a bogus error message? Anyway, there are now fresh zipfiles for ORBit2, libbonobo, evolution-data-server and evolution in http://ftp.gnome.org/pub/gnome/platform/2.14/2.14.2/win32/ and http://ftp.gnome.org/pub/gnome/desktop/2.14/2.14.2/win32/ . In addition to the fix for the problem described above, they also contain the fixes mentioned in my recent mails: - There is no absolute need any longer to kill the processes that stay running when one quits Evolution, or to clean out state files. - Evolution on Windows now works for users with any random Unicode characters in their username, or if installed in a folder with spaces (or any random Unicode character) in the pathname. (This of course is one main point which the porting effort has had to take into consideration from start; but only recently did I actually test it thoroughly.) Enjoy, --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()
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()
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()
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] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
> If my analysis is correct, this means that attempting to do a CORBA
> object unregistration in the GObject finalize method is too late, isn't
> it?
I tested by applying this simple patch to e-shell.c, moving the
bonobo_activation_active_server_unregister() call from impl_finalize()
to notify_no_windows_left_idle_cb():
Index: shell/e-shell.c
===
RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
retrieving revision 1.272
diff -p -u -r1.272 e-shell.c
--- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
+++ shell/e-shell.c 16 Jun 2006 23:17:50 -
@@ -360,13 +360,18 @@ static gboolean
notify_no_windows_left_idle_cb (void *data)
{
EShell *shell;
+ EShellPrivate *priv;
shell = E_SHELL (data);
+ priv = shell->priv;
set_interactive (shell, FALSE);
g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
+ if (priv->iid != NULL)
+ bonobo_activation_active_server_unregister (priv->iid,
+
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
bonobo_object_unref (BONOBO_OBJECT (shell));
return FALSE;
@@ -467,10 +472,6 @@ impl_finalize (GObject *object)
shell = E_SHELL (object);
priv = shell->priv;
-
- if (priv->iid != NULL)
- bonobo_activation_active_server_unregister (priv->iid,
-
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
e_free_string_list (priv->crash_type_names);
And lo and behold, it works! Now the ESHell gets unregistered, and when
starting Evolution again it manages to register its EShell and contact
the already running e-d-s etc.
OK to apply this patch to HEAD and stable? ChangeLog entry:
2006-06-17 Tor Lillqvist <[EMAIL PROTECTED]>
* e-shell.c (impl_finalize): Don't call
bonobo_activation_active_server_unregister() here, it's too late,
the EShell Bonobo object has already been deactivated and its
associated CORBA object is NULL.
(notify_no_windows_left_idle_cb): Instead, call
bonobo_activation_active_server_unregister() here, when the EShell
Bonobo object is still fully active.
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...
--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
I am debugging why Evo on Windows doesn't manage to reuse the evolution-data-server process that is left running when you quit Evolution. One possible hint to the cause is that when you quit Evolution on Windows, for some reason it seems that it doesn't manage to unregister the EShell from the bonobo-activation-server. (If one checks with bonobo-browse, it still says that the Shell is Active.) Debugging the code where Evolution tries to unregister turns up some interesting stuff. It's the impl_finalize() in evolution/shell/e-shell.c that calls bonobo_activation_active_server_unregister(). However, at that stage the BonoboObject::corba_objref field of the BonoboObject (EShell) object is already NULL. This is obvious, because if one checks the backtrace from impl_finalize(), what causes it do be called is the call to g_object_unref() in bonobo_object_finalize_internal_T() (libbonobo/bonobo/bonobo-object.c). And that function has a few lines earlier called bonobo_object_corba_deactivate_T(), which sets corba_objref to NULL. Anyway, this means the second parameter to bonobo_activation_active_server_unregister() is NULL, which is then passed on as third parameter to Bonobo_ObjectDirectory_unregister(). This NULL eventually ends up as the object parameter to remove_active_server() in libbonobo/activation-server/object-directory-corba.c in the bonobo-activation-server process, and it obviously doesn't match the registered EShell server, so no removal happens. If my analysis is correct, this means that attempting to do a CORBA object unregistration in the GObject finalize method is too late, isn't it? Apparently, unregistration still works on Unix, though, as if you run bonobo-browse after quitting Evolution on Unix, there indeed is no Shell listed as Active. Maybe the bonobo-activation-server notices that the socket connection hangs up and then automatically unregisters, or something? Hmmm. Oh well, why this other mechanism then doesn't work on Windows needs to be debugged now... --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Windows version status?
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
Re: [Evolution-hackers] URGENT: Anyone knows why evolution is using both GNUTLS and NSS as security libraries
ti 2006-03-21 klockan 23:33 +0800 skrev Irene Huang: > I am confused why GNUTLS is a necesity when NSS is used for security > connection? Isn't it libsoup that uses gnutls? No idea why it doesn't use NSS (I assume they offer mostly the same functionality?) > Can't it be removed? Hear, hear! Using NSS in libsoup would also be great for Win32 portability, as I never managed to get the libsoup-over-gnutls working, so TLSified GroupWise connections don't work on Win32. (The problem was discovered only in December when I visited Bangalore.) --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
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
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] Please pay attention to "compiler warnings".
Veerapuram Varadhan writes: > I just saw another one in plugins/bbdb/bbdb.c. The very same gfree > thingy. Would using -no-undefined on all platforms catch errors like this at build time already? --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
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] Checking filename validity by e_filename_make_safe() have some problem.
on 2006-01-11 klockan 17:57 +0800 skrev simon.zheng: > Is it necessary to modify or add a new function > that removes this limitation? I would suggest adding a new function, and then change callers carefully one by one in places where you can be sure it doesn't have any ill effects. (I would assume the behaviour can't be changed in places where it would affect the names of files and directories kept on disk between evolution sessions, and that it can be changed in places where it affects file names used only ephemerally.) --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] symbol ugliness ...
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!
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?
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] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?
to 2005-12-22 klockan 12:13 +0800 skrev Simon.Zheng: > #include "e-i18n.h" This file should stay in evo/e-util, and also the e_gettext() function that it declares. e_gettext() should presumably be moved into a file of its own, e-i18n.c or e-gettext.c. The (merged) e-util.c in e-d-s/libedataserver doesn't use any i18n functionality. > #include "e-util-private.h" That file should also stay in evo/e-util. It contains only things related to the Win32 port (for instance #defines O_BINARY as zero on Unix). The functions it declares are in e-win32-reloc.c. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Spam attack on go-evolution.org
Check out the Recent Changes page... Lots of pages have been filled with spam. Apparently only pages that were empty until now, though? --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)
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
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)
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
[Evolution-hackers] Re: Strings not marked for translation.
On ti, 2005-10-04 at 03:14 +0300, Žygimantas Beručka wrote: > * 'Personal' (Contacts, title of sidebar) > * 'On This Computer', 'Personal', 'On LDAP Servers' (Contacts sidebar) > * 'General', 'Addressbook' (Contacts sidebar, right click on > 'Personal' -> 'Properties...') > * 'Birthdays & Anniversaries', 'On The Web', 'Weather', > 'Contacts' (Calendar sidebar) > * 'Calendar', 'On This Computer' (Calendar sidebar, right click on > sidebar item -> Properties... > * 'On This Computer', 'On The Web' (Tasks sidebar) Could this be related to the issue I reported some month ago, where I noticed that if you start Evolution the very first time in English, for instance, then later start in some other language, some English UI strings have already been written to GConf and are presented from there? Did you initially run Evolution in English, and then switch to your own language? --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: [maemo-developers] Ross' D-BUS port of evolution-data-server on maemo x86
On on, 2005-09-28 at 01:39 +0200, Philip Van Hoof wrote: > However. Building "servers" first also temporarily fixes the issue. But shouldn't it have been built first in any case? It's mentioned first in e-d-s/Makefile.am's SUBDIRS. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] More MAC'ness (s/C/d)
Shreyas Srinivasan writes: > As can be seen, this is because the symbol "e_account_list_set_default" > is actually present in two libraries libedataserver-1.2.dylib and > libeutil.dylib. The Welcome to the club. Lots of functions (or functionality, but using different function names) are duplicated here and there in e-d-s, evo and evo-exchange. This mess needs cleaning up. I have listed some of the points I have noticed on the Evo2.6 page in the wiki, please add more. > The only solution my measly brain could figure out till now was to > move the redundant files out of libeutil.dylib ( remove those files > from makefile ) and then change all references of e-util/e-account* > with libedataserver/e-account* I guess what should be decided is whether libedataserver is the right library for more or less generic functions usesd in several places in e-d-s, evo and evo-exchange? Sure, its name is perhaps a bit misleading, but so what? (We got rid of the separate "gal" module, so perhaps introducing a new "application library" now would seem silly?) --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
