Re: [Evolution-hackers] evolution-data-server without ssl

2010-12-15 Thread Federico Mena Quintero
On Wed, 2010-12-15 at 15:42 +0800, Zhai, Edwin wrote:

 After this commit, prio.h is included unconditionally so that 
 evolution-data-server depends on nspr and disable-ssl doesn't work any 
 more. It's okay for normal distribution, but we'd like to keep the 
 simplicity in embed world.
 Is it a valid limitation, and is there any possible fix for it?

Is depending on nspr a problem, or is it that --disable-ssl doesn't

Here are my arguments for each of those:

1. Depending on nspr.  We already depend on nspr in other modules, I
believe.  It is quite possible to make e-d-s not have a hard dependency,
but you'll have to modify CamelTcpStream and CamelImapxServer to have
similar conditionals as they used to have --- get an int file
descriptor, and poll on it with glib.

2. --disable-ssl.  I wouldn't trust my data to software that cannot
secure a connection :)  But making that work again shouldn't be hard.  I
think I didn't remove any of the important conditionals in the Camel
providers (the ones that select between creating SSL streams and normal
ones).  What may not be working is the actual compilation of
camel-tcp-stream-ssl.  To be honest I haven't tried --disable-ssl at

Both are easy to fix, and you are welcome to patch them up.  (1) will
probably just disappear as a problem when we start using GIO for network
connections instead of doing them by hand.


evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

[Evolution-hackers] If an account changes, who regenerates the services?

2010-10-19 Thread Federico Mena Quintero
Hi, all,

I'm trying to unwind some code in Camel and in Evolution.

The problem I have is that if you change an email account's extra
options (e.g. imapx's apply filters to new messages), then those
changes don't take effect until you restart Evolution.

That option is a filter parameter in a CamelURL - the URL for the
IMAPX service.

As far as I can tell, the only place where an IMAPX service gets this
URL is at construction time.  However, a breakpoint at imapx_construct()
only gets hit when I start up Evolution, not afterward (e.g. after
changing the account's options in the account editor).

There is a lot of code around the account editor to apparently propagate
changes.  But I'm rather lost in the structure.

em-account-editor changes the EAccount in emae_commit(), by calling
e_acount_import().  Then it does e_account_list_change().  Both of those
functions emit signals about something changing.

That's where I'm lost.

Does anyone know what links both parts of the code - the account editor
and the actual construction of Camel services?



evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

[Evolution-hackers] Tables and spacing for empty rows/columns

2010-04-18 Thread Federico Mena Quintero
I just noticed that GtkTable requests and allocates size for rows and
columns that are empty, or that have no visible widgets in them.  This
leads to surprising spacings in the end.

For example, say we have a 3x3 table like this, and the table has a
certain row spacing.

  child11child12 child13
  child21child22 child23
  child31child32 child33

If I hide all the widgets in the second row, this gets drawn:

  child11child12 child13
  [gap equal to row1.spacing + row2.spacing]
  child31child32 child33

When I just expected

  child11child12 child13
  [gap equal to row1.spacing]
  child31child32 child33

The result is worse if some of the rows you hide are adjacent to the top
or bottom of the table.  If you take the original table above and hide
rows 1 and 3, then you get this:

  widgets above
  [gap equal to row1.spacing]
  child21child22 child23
  [gap equal to row2.spacing + row3.spacing]
  widgets below

Both gaps are actually larger, as visually they include the spacing of
the table's parent container (i.e. the normal spacing between the
widgets outside the table and the table itself).

I think it would be better to have GtkTable *not* add the spacings for
rows/columns that are empty.  This doesn't look terribly hard to

* GtkTableRowCol already has an 'empty' field; this gets used only
during the size allocation phase.

* We could use that 'empty' field as well during the size requisition

* In gtk_table_size_request(), there is an unconditional

  for (row = 0; row + 1  table-nrows; row++)
requisition-height += table-rows[row].spacing;

We could make that += conditional on whether the row is empty.

* Similarly, where gtk_table_size_allocate_phase2() does

  y += table-rows[row].spacing

that could be made conditional on the row's emptiness.

Backstory:  in Evolution we have a bunch of widgets for the preferences
dialog, and we would like to hide some of those widgets when Evo is
running in Express mode.  Read that as we have too many stupid options,
and we are experimenting with reducing their number.  But just hiding
the widgets produces incorrect spacing.

Opinions?  Should I just patch it and see how things look?


evolution-hackers mailing list

Re: [Evolution-hackers] Build failure in evolution 2.30.0 (was Re: Patch for Evo 2.30 - size of mail sidebar)

2010-03-30 Thread Federico Mena Quintero
On Tue, 2010-03-30 at 04:10 +0200, Vincent Untz wrote:

 Can we get a tarball that uses some non-deprecated API or, even
 better, that doesn't use -DGTK_DISABLE_DEPRECATED by default?

Ugh, sorry about the breakage.  I'm building Evo on GTK+ for GNOME 2.28;
that's why I didn't notice this.  Thanks for the quick fix.


Evolution-hackers mailing list

Re: [Evolution-hackers] Moving the struct instance heap space to mmap

2006-09-07 Thread Federico Mena Quintero
On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:

 The *new*/*extra* idea is to create a second index file which contains
 the offsets to the pointers in the camel summary file. Then mmap also
 that file. Extra because the idea will build on top of the existing

Ummm, but this won't reduce your working set by very much, will it?

I haven't looked at the details, but can't you just keep an array in
memory with pointers to the *start* of each summary block, and then
compute the other pointers on demand?

Sort of

gpointer *pointers_to_message_summaries;
gpointer base;

base = mmap (summary);

pointers_to_message_summaries = g_new (gpointer, num_messages);

pointers_to_message_summaries[0] = base;
pointers_to_message_summaries[1] = ...;

and then a set of functions

gimme_ptr_to_subject_for_message_number (int n)
   return pointers_to_message_summaries[n] + SUBJECT_OFFSET;

etc.  Then, instead of 120 bytes per message, you'd have just
sizeof(pointer) and a little more code to compute the offsets on demand.


Evolution-hackers mailing list

Re: [Evolution-hackers] Memory consumption and virtual machines

2006-07-19 Thread Federico Mena Quintero
On Wed, 2006-07-19 at 17:40 +0200, Philip Van Hoof wrote:

  ... On the other hand, Philip, next time we meet in person I'll happily
  buy you dinner :)
 oh ... what about Boston? :)
 I'll check with my daytime employer whether it's okay if I can visit the

I don't know for sure whether I'll be at the Summit.  If not, next
GUADEC, maybe?

[Where do you live?  I'm in Boston this week and the next.]


Evolution-hackers mailing list

Re: [Evolution-hackers] Memory consumption and virtual machines

2006-07-18 Thread Federico Mena Quintero
On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote:

 I'm waiting for the decision (yours) of making this optional using a
 compilation flag or at run-time.

Let's do this in the usual manner:

0. Polish the patch in the usual way:  make sure it follows the
indentation and naming conventions of the surrounding code, etc.

1. Branch evolution-data-server into HEAD (development, with Philip's
patch), and the stable branch (without the patch).

2. Make the patch *mandatory* in HEAD, so that it gets a good amount of

3. ???

4. Profit!!!

I'd suggest that (3) become write a good stress-test suite for Camel,
independent of Evolution.  We need that anyway.

Novell already has a bunch of LDTP stuff to test the Evo mailer from the
user's viewpooint - run those tests on the patched version to see how
well they work.  [Varadhan, those tests are already part of our QA
process, aren't they?]


Evolution-hackers mailing list

Re: [Evolution-hackers] Memory consumption and virtual machines

2006-07-18 Thread Federico Mena Quintero
On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote:
 I have to wonder if it's even worth ever merging the mmap hack into
 Evolution at all. If the plan is to finish Zucchi's disk-summary branch,
 which also solves the memory problems (afaik) as well as:
 1. introducing an API for using cursors to get at message infos
 2. better designed on-disk format that uses B-Trees

Let's put that discussion on Pause until someone actually starts
resurrecting the disk-summary branch.

If Philip's patch turns out to work well for daily use, it may be a good
stopgap measure.  The disk-summary branch will need way more QA time
than the mmap() stuff, and a lot more performance tuning work as well :)

 the problem with philip's mmap file format is that the strings that will
 be hit for sorting/viewing/etc are all spread out over a huge number of
 pages. I just see this being re-examined later to try and design the
 format to better optimise it by compacting all the strings into a strtab
 type thing.

I've been talking to Philip on IRC, and gave him these requirements for
his patch:

1. Don't change the external ABI of Camel, so that Evo needs no changes,
*OR* also submit a patch to update Evo for the changed API.

2. Make sure the summary format on disk works with older Evos without
making *them* rewrite the summaries.  This is for deployments which have
machines with old and new versions of GNOME, but NFS homedirs accessible
from any machine.

3. Keep the coding style, variable naming convention, indentation, etc.

It may be possible to change the summary format by *just* adding a
nul-terminator to strings; that may work with older Evos if we are lucky
enough that they'll just ignore the nul byte at the end.  This needs

I'd say that (1) and (2) are hard requirements.  (3) is the usual stuff.

 I just don't get the feeling this is really all that well thought out
 and it scares me.
 I'd just hate to see a rush job come out of this

Yeah, it needs good testing.  Philip says he'll cook a patch so that I
can use it with my system's e-d-s RPM for daily use.  Then I can test it
with my normal mailbox.


Evolution-hackers mailing list