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: 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
$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
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
(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
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] 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
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] 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
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()
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()
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
[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] 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] 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] 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
