My comments updated on
http://bugzilla.gnome.org/show_bug.cgi?id=337996
-Harish
On Wed, 2006-06-14 at 09:03 -0400, Matthias Clasen wrote:
> evolution-exchange-2.7.3 is translation-less
>
>
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gn
Tor,
Please commit the patch to HEAD as well as the stable branch. The
change looks fine to me. I will also get the unregister action tested
in the regular builds on the branches and perhaps in MacOS (I do not
know if it matters, but anyway!) as a routine but I do not expect any
surprises.
Tha
ah, okay.
Jeff
On Mon, 2006-06-19 at 17:03 +0300, Tor Lillqvist wrote:
> 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
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()
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? Even
if not, tho, I feel it would be cleaner to unregister in a ::destroy()
if that's a possi
On Mon, 2006-06-19 at 11:56 +0200, Florian Boor wrote:
> as long as we talk about individual senders this is true, but if you think
> about
> mailinglists and all this automated server notifications this could save
> quite
> some memory. As long as it is possible to implement this without a too
Hi,
[EMAIL PROTECTED] wrote:
> H... I am not really convinced yet; I mean even when I have
> 100 mails with the same email address in my Inbox (which seems
> a lot from one person!). The email-address would be 20 chars; now having
> 'm all in one string saves me, even in this extreme case, on
On Mon, 2006-06-19 at 00:18 +0300, Tor Lillqvist wrote:
> 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.)
Ah - we had some wonderful b-a-s bugs for the few sockets we didn't
CLOEX
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, work