Re: [Evolution-hackers] evolution-data-server without ssl
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 work? 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 all. 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. Federico ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] If an account changes, who regenerates the services?
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? Thanks, Federico ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Tables and spacing for empty rows/columns
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 implement: * 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 phase. * 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? Federico ___ evolution-hackers mailing list evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failure in evolution 2.30.0 (was Re: Patch for Evo 2.30 - size of mail sidebar)
On Tue, 2010-03-30 at 04:10 +0200, Vincent Untz wrote: Can we get a 2.30.0.1 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. Federico ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving the struct instance heap space to mmap
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
gpointer
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.
Federico
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory consumption and virtual machines
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 Summit. 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.] Federico ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory consumption and virtual machines
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 testing. 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?] Federico ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory consumption and virtual machines
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 testing. 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. Federico ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
