I've tried making the new implementation of layout_with_preedit
(widgets/table/e-cell-text.c)
The new code - http://makuchaku.pastebin.ca/84013
Old code - http://makuchaku.pastebin.ca/84015
It builds fine works as expected (i did a brief testing).
I would request the calendar developers to
On Wed, 2006-07-12 at 13:46 +0530, Harish Krishnaswamy wrote:
Resending the message as the mail bounced off your gnome id.
Something didn't work with [EMAIL PROTECTED] I haven't changed
configuration at my side, so it's probably a problem with the GNOME mail
servers.
I think it would be a
Hey Jules! Thanks a lot for your reply. I know my questions weren't so
clearly worded. So I guess I can boil down my questions to this question (and
least until I think of more questions): is there a one-to-one relationship
between an e-source and an e-cal backend?
For my purposes, I don't
On Tue, 2006-07-11 at 23:14 +0530, Harish Krishnaswamy wrote:
I'm removing the patches mailing list ;-)
On Tue, 2006-07-11 at 16:47 +0200, Philip Van Hoof wrote:
Currently it's obviously consuming more memory when new messages arrive
(compared to the mmap technique). In Evolution, such a
On Tue, 2006-07-11 at 09:28 -0400, Chris Toshok wrote:
No opinion on the rest of the patch, but this:
+static void
+free_token (gchar *token)
+{
+ gint i=0;
+ gboolean no=FALSE;
+
+ for (i=0; (i tokens_len); i++)
+ {
+ if (tokens[i] ==
On Wed, 2006-07-12 at 10:17 -0400, Jeffrey Stedfast wrote:
On Sun, 2006-07-09 at 13:04 +0200, Philip Van Hoof wrote:
These can be replaced with the new camel_pstring_add using FALSE as
parameter. Replacing them will also remove the need for the normal
camel_pstring_strdup and therefore also
On Wed, 2006-07-12 at 02:27 +0530, Ritesh Khadgaray wrote:
On Tue, 2006-07-11 at 09:28 -0400, Chris Toshok wrote:
No opinion on the rest of the patch, but this:
+static void
+free_token (gchar *token)
+{
+ gint i=0;
+ gboolean no=FALSE;
+
+ for (i=0; (i
On Tue, 2006-07-11 at 17:06 -0400, Chris Toshok wrote:
On Wed, 2006-07-12 at 02:28 +0530, Ritesh Khadgaray wrote:
out of curiosity, the first patch reads through the list
and this patch, return if any one of the token is equal, anf not any
following it.
Would the below not be better
On Tue, 2006-07-11 at 09:28 -0400, Chris Toshok wrote:
static void
free_token (gchar *token)
{
gint i;
for (i = 0; i tokens_len; i ++)
if (tokens[i] == token)
return;
g_free (token);
}
ps. Maybe for real efficiency you can also
On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote:
Okay, forking Camel is not what I want. Nobody wants that. It's not a
good idea.
However, it would be more easy (for me) if Camel would have its own
configure.ac file. That way would it be more easy to do a 'make dist' of
just Camel,
On Wed, 2006-07-12 at 16:30 +0100, Ross Burton wrote:
On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote:
What advantages does being able to dist camel on its own have, over
simply packaging it in a separate package like OpenEmbedded and Debian
do:
It's cleaner in my opinion :-), and I
Hi guys.
Anybody know the fix for this error? Evolution crashes on me about 30 times a day with this message. I have to kill evolution-data-storage and evolution violently for it to start working again.
thanks!
Tim
___
Evolution-hackers mailing
hi tim,
On Wed, 2006-07-12 at 11:09 -0500, TimD Smith wrote:
Anybody know the fix for this error? Evolution crashes on me about 30
times a day with this message. I have to kill evolution-data-storage
and evolution violently for it to start working again.
please post user questions to the
On Wed, 2006-07-12 at 17:00 +0100, Ross Burton wrote:
On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
It's cleaner in my opinion :-), and I can more easily create a tar.gz
release.
Cleaner for what reasons?
Because it will be more easy to pick which libraries you will use (in
There's a couple problems that I can think of that will need to be
solved in order for mmap to work (at least for Evolution, altho at least
a few of the problems also apply to tnymail)
1. (Evolution only?) fd usage will easily max out on systems like
Solaris and/or installations where the user
Hi,
On Wed, 2006-07-12 at 13:34 -0400, Jeffrey Stedfast wrote:
1. (Evolution only?) fd usage will easily max out on systems like
Solaris and/or installations where the user has a large number of
folders. Each mmap'd file requires a persistantly open file descriptor,
which, especially combined
On Wed, 2006-07-12 at 13:34 -0400, Jeffrey Stedfast wrote:
There's a couple problems that I can think of that will need to be
solved in order for mmap to work (at least for Evolution, altho at least
a few of the problems also apply to tnymail)
1. (Evolution only?) fd usage will easily max
Hi,
I was looking at Evolution's code, when I saw that
insert_preedit_text() in e-text.c (widgets/text/e-text.c) and
layout_with_preedit in e-cell-text.c (widgets/table/e-cell-text.c) so
almost the same thing : fetch the preedit string, add it to the
current cursor location update the layout.
I know I made many many changes to the summary implementation and stuff.
However. Some change caused the Fetching summary information for new
messages in % to only consume 18MB of ram in stead of 60MB of ram which
the default Camel as shipped on Ubuntu Dapper consumes.
I didn't expect this. The
On Wed, 2006-07-12 at 20:05 +0200, Philip Van Hoof wrote:
On Wed, 2006-07-12 at 13:34 -0400, Jeffrey Stedfast wrote:
[snip]
It also seems to me that if we were really going to be serious about
using mmap as a real solution (and not just a hack), we'd have to
redesign the summary files to
On Wed, 2006-07-12 at 17:19 -0400, Jeffrey Stedfast wrote:
On Wed, 2006-07-12 at 20:05 +0200, Philip Van Hoof wrote:
-- Oh by the way. There's a huge amount of Re: strings in my memory
at this moment. We can probably improve that too ;-) --
Yea, I've been wanting to overlap strings in
21 matches
Mail list logo
