Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
Le lundi 10 octobre 2016 à 10:01 +0200, Milan Crha a écrit : > On Fri, 2016-10-07 at 09:39 +0200, Gilles Dartiguelongue wrote: > > > > Also, does CMake support make distcheck yet ? As a downstream > > maintainer, I find many packages with errors in distributed sources > > would have been caught by make distcheck when releasing. > Hi, > CMake doesn't "support" it by default, but I have there custom > targets > named "dist", "distcheck" and "disttest", the same as "check". Note > that the 'dist*' targets create the tarball from a git clone first, > thus it won't work with the tarball sources. It didn't work well with > the autotools too, I think, where you better build the sources and > run > 'make check' only. I guess it is too late to talk about this but what problems did autotools had with make distcheck ? I regularly used it when contributing patches to evo/eds and still do when preparing patches for any autotooled package. -- Gilles Dartiguelongue ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
Le mercredi 05 octobre 2016 à 10:23 -0400, Paul Smith a écrit : > On Wed, 2016-10-05 at 15:13 +0200, Milan Crha wrote: > > [...] > I will point out that (a) I've had a lot of problems using CMake in a > cross-compilation environment, where autotools works flawlessly and > painlessly (at least as much as is possible when cross-compiling) and > also (b) autoconf's support for command line options that select > different features, etc. is IMO much simpler to work with and use > than > CMake's. Also, does CMake support make distcheck yet ? As a downstream maintainer, I find many packages with errors in distributed sources would have been caught by make distcheck when releasing. -- Gilles Dartiguelongue ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
Le vendredi 04 mars 2011 à 05:47 -0700, Sankar P a écrit : > > I'm working on "Enterprise" use of Evolution, and one of the big > > requirements is encryption of data at rest. The answer "just encrypt the > > whole of the user's home directory" only puts them off for so long. > > > > So I'm looking at implementing this directly in camel-data-cache, > > e-cal-backend-cache, etc. > > > > I'll probably do the encryption with a randomly-generated key, which > > itself is stored locally, encrypted with a password. > > > > That way, changing the password doesn't involve re-encrypting the whole > > of the store; you only need to re-encrypt the master key. It also means > > that we can tie the password for the cache to the password for the > > server; entering one will allow access to both. > > > > Hopefully, the changes required to code that *uses* the cache > > functionality should be fairly limited. Mostly it should be handled by > > extra arguments to camel_data_cache_new(), e_cal_backend_cache_new(), > > camel_db_open() and similar functions. > > > > I'm hoping that it's reasonable to declare that *filenames* are not > > sensitive, and that we only need to encrypt the *contents* of files. > > Does that seem fair? > > > > Any other comments on the approach? > > Will it be not simpler if we can make Evolution use a custom location for > cache, that the user/root can set ? XDG_CACHE_HOME [1] ? with pam_mount and you get everything compliant with XDG base directory specification to have encrypted cached data for free. I don't think it's healthy for an application to implement this kind of feature by itself, even if most of the heavy work is done by a library. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html -- Gilles Dartiguelongue ___ 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] libedata-cal-1.2.la: undefined reference to `e_cal_recur_ensure_end_dates'
Le vendredi 22 octobre 2010 à 20:45 +0200, tjoen a écrit : > Hi list, > gcc 4.5.1 > e-d-s 2.32.0 > ./configure --prefix=/usr --with-libdb=/usr --with-krb5=/usr > --with-openldap > compiles fine but problem installing because of relinking: > > libtool: install: warning: relinking `libedata-cal-1.2.la' > libtool: install: (cd > > /home/tjoen/rpmbuild/BUILD/evolution-data-server-2.32.0/calendar/libedata-cal; > /bin/sh /home/tjoen/rpmbuild/BUILD/evolution-data-server-2.32.0/libtool > --silent --tag CC --mode=relink gcc -g -O2 -version-info 10:0:0 > -Wl,--no-undefined -o libedata-cal-1.2.la -rpath /usr/lib > libedata_cal_1_2_la-e-data-cal-enumtypes.lo > libedata_cal_1_2_la-e-cal-backend.lo > libedata_cal_1_2_la-e-cal-backend-cache.lo > libedata_cal_1_2_la-e-cal-backend-factory.lo > libedata_cal_1_2_la-e-cal-backend-intervaltree.lo > libedata_cal_1_2_la-e-cal-backend-sexp.lo > libedata_cal_1_2_la-e-cal-backend-sync.lo > libedata_cal_1_2_la-e-cal-backend-util.lo > libedata_cal_1_2_la-e-cal-backend-store.lo > libedata_cal_1_2_la-e-cal-backend-file-store.lo > libedata_cal_1_2_la-e-data-cal.lo > libedata_cal_1_2_la-e-data-cal-view.lo > ../../calendar/libegdbus/libegdbus-cal.la > ../../calendar/libecal/libecal-1.2.la <== they should be in here > ../../libedataserver/libedataserver-1.2.la > ../../libebackend/libebackend-1.2.la -pthread -lgio-2.0 -lgobject-2.0 > -lgmodule-2.0 -lgthread-2.0 -lrt -lical -licalss -licalvcal -lxml2 > -lgconf-2 -lglib-2.0 -inst-prefix-dir /var/tmp) > .libs/libedata_cal_1_2_la-e-cal-backend-file-store.o: > In function `e_cal_util_get_component_occur_times': > /home/tjoen/rpmbuild/BUILD/evolution-data-server-2.32.0/calendar/libedata-cal/../../calendar/libecal/e-cal-util.c:1218: > > undefined reference to `e_cal_recur_ensure_end_dates' > /home/tjoen/rpmbuild/BUILD/evolution-data-server-2.32.0/calendar/libedata-cal/../../calendar/libecal/e-cal-util.c:1273: > > undefined reference to `e_cal_recur_obtain_enddate' > /home/tjoen/rpmbuild/BUILD/evolution-data-server-2.32.0/calendar/libedata-cal/../../calendar/libecal/e-cal-util.c:1289: > > undefined reference to `e_cal_recur_obtain_enddate' > collect2: ld returned 1 exit status > > Only one 2 hits in Google, no solutions. > Anyone with a tip how to continue? This was reported in gnome's bugzilla and in gentoo's. It should be fixed in master by now. -- Gilles Dartiguelongue signature.asc Description: This is a digitally signed message part ___ 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] XDG Base Directories
Le dimanche 06 juin 2010 à 12:34 -0400, Matthew Barnes a écrit : > Once thing I'd like to get done before Evolution 3.0 is dismantling > ~/.evolution and moving user-specific data to relocatable XDG base > directories [1]. I have an initial proposal of what should go where. > > Migration should just be a series of straight-forward move commands, > plus a few subtle renames. Not sure yet if I'm gonna code this all up > in C or just write a shell script to invoke. > > I'd like to get this in before I get much further on my gsettings > branch, as I'll be changing how we store account data (no more XML > blobs!) and our directory layout closely ties into it. > > See additional comments below. [...] > Comments: > > * ~/.evolution/cache moves to ~/.cache/evolution, with one exception: > just use /tmp for stuff that normally goes in ~/.evolution/cache/tmp. > > * Cached Camel provider data moves to ~/.cache/evolution/mail. This > includes folders.db. Files for local accounts will be divided up: > index files for searching would go in ~/.cache, whereas actual mail > content (mbox/Maildir/etc.) would go in ~/.local. Need to think on > that some more. > > * ~/.cache/evolution/http will eventually die when we move to WebKit, > since it uses (or will soon use) its own disk cache. > > * ~/.evolution/$COMP/local moves to ~/.local/share/evolution/$COMP. > > * I debated whether certificate and profile databases are data files or > configuration files. I decided data files, based on my rule of thumb > that configuration files should be human-readable. > > > Any comments or concerns? Have I missed anything? > sounds good. I"d like to mention again that it would be nice if evolution could take into account system certificates as a basis for user trust settings in certificate signatures, etc. I don't know if nss is just getting in the way for this, but evolution and firefox are currently the two apps that I use most often that don't actually obey my system configuration by default. -- Gilles Dartiguelongue ___ 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] Rebooting ChangeLog files in 3.x
> I'd like to clean this up in 3.0, so unless I hear objections, after > we > branch for GNOME 2.30 I'm going to remove all the ChangeLog* files in > the evolution, evolution-data-server, evolution-exchange, and gtkhtml > repositories [1] and replace them with a single top-level ChangeLog > placeholder file whose contents will be automatically populated with > commit messages when creating release tarballs. > as long as it is not the, sadly common since git migration, raw git log output, which is unreadable for downstream, then sure. -- Gilles Dartiguelongue signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
Le 1 févr. 2010 à 17:52, Jeffrey Stedfast a écrit : > > This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc > would mistakenly optimize out important sections of code > when it encountered a particular trick used in a ton of places inside > Evolution (EDList and pretty much everywhere custom single-linked lists > are used inside at least Camel and likely other places as well). > > A temporary solution is to pass the -fno-strict-aliasing argument to gcc. > > Unfortunately, the gcc developers claim that this is not a bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907 I'm sure a lot of subscribers already know, but this has been a "problem" since at least gcc 3.4 (iirc) where it started complaining about strict aliasing. If you let gcc build non compliant code, it'll indeed optimize the code wrongly. gcc just got a lot less fool proof in the last releases in order to force developers into coding more easily optimizable code (probably not the way they would put it but that's the wanted result afaik). -- Gilles Dartiguelongue gilles.dartiguelon...@esiee.org ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Want to contribute to evolution-mapi
Le mercredi 11 novembre 2009 à 15:42 -0500, Reid Thompson a écrit : > On Wed, 2009-11-11 at 15:19 -0500, Paul Smith wrote: > > Other (new enough) distributions would surely work, but my makefile > > doesn't handle them. > > It works for me on Gentoo, if you (or anyone else) are running Gentoo > and having issues I can perhaps provide some insight. > > ( for various reasons (some may be related to evo, most are not) I have > a decent number of unmasked ~x86 packages ) As a gentoo gnome maintainer, for gentoo support, I'd be glad to be submitted live ebuilds for gnome-live overlay. This goes the usual route, check latest ebuild in tree or in gnome overlay, adapt, submit to bugzilla for review. If you stick around often enough, you might even get write access. Visit us on #gentoo-desktop on Freenode if you want to discuss it or poke me on #evolution. -- Gilles Dartiguelongue signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
can we get the new user lockdown now at least ? -- Gilles Dartiguelongue ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org
Whatever you do, please do something quickly, todays spamming is at a rate that I can barely sustain. -- Gilles Dartiguelongue signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Command line
Le vendredi 06 mars 2009 à 16:16 -0200, RASKA Maria Paula a écrit : > Hi, > > Is there any way to use the command line for importing mbox files to > Evolution instead of using the wizard it comes with? I think this is currently not possible. Also it is probably a good idea to fill a RFE at http://bugzilla.gnome.org because it would much useful for git users. -- Gilles Dartiguelongue signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] go-evolution.org
Hello list, I know this is probably not the best place to send this but I'm looking for someone to pick up or help in my fight against spam on the wiki. Please help me fix this: http://www.go-evolution.org/Special:Recentchanges and this http://www.go-evolution.org/index.php?title=Evolution_Keyboard_Navigation_Specification_for_Version_2.4&action=history&offset=0&limit=500 it's been going on for months and I'm sick of trying to fix it without the proper tools/rights/whatever. Thanks for your attention. -- Gilles Dartiguelongue signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] String addition to evolution
Hi, I added 1 msgid to evolution, https://bugzilla.gnome.org/show_bug.cgi?id=568176 This string is meant to be the title of the migration dialog for evolution 2.24 summary migration. #: ../mail/em-migrate.c:2974 msgid "Migrating Folders" msgstr "" Thanks, -- Gilles Dartiguelongue signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi, first, let me tell you I perfectly agree with you that user data should be easily accessible to users. It's their data after all. Now I want to shade this a bit for what is usually called PIM data. imho, users (I mean normal non-geeky users) often only know about one way of getting to their data and can only handle few at a time. This is really important wrt to what you said about mails. Somebody replied to this thread qualifying what would be the direct (brutal) application of your proposal as a tsunami of data and I can only agree with that. This would be a poor user experience really :) About standards, evolution actually uses standards to store data, mbox for mails, ics/vcard for addressbook, events & memos. It can also export all of these data from their hidden store to another standard format. Even nicer, it has a backup plugin that saves all this and configured accounts to a tarball that you can save anywhere you want. Personnaly I've had harder times getting my data out of thunderbird last time I tried (which was probably ~1.0). Now obviously all programs probably won't be able to deal with evolution's backup tarball (but most probably can with "individual" exports) but that's probably because nobody even thought about getting started on standardizing this kind of stuff before. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution: Taking forward...
Le samedi 16 août 2008 à 12:12 +0200, Kjartan Maraas a écrit :> > I didn't think my contributions were substantial enough to warrant this > but Michael poked me about it so here you go. Permission granted for any > pieces of code I've produced. Sankar got me on irc but I forgot to send a mail so here it is. Permission granted for any pieces of code I've produced. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
As one of the gentoo's maintainers of the gnome packages, provided with bug reports and patches we will apply anything that seems critical enough until we get 2.24 in stable which usually takes 1 to 3 months after the release. We usually reduce the pace of the changes on a package when it reaches stable though so you better group submission :) -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] make dist error in evolution-data-server
Le mardi 29 juillet 2008 à 14:09 +0800, Jeff Cai a écrit : > $make dist > make: *** No rule to make target `intltool-merge.in', needed by > `distdir'. Stop. > > I'm curious about how you make it work. either it's missing in EXTRA_DIST or you need to run intltoolize --force (or just use autogen.sh, it does all the dirty first run things) -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution and ldap contacts
Le lundi 09 juin 2008 à 12:06 -0700, George Farris a écrit : [snip] > Here is a feature request. Make the LDAP view return a list of contacts > or at least a partial, user selectable number of contacts and display > them without having to do a manual search. Basically make it work like > the contacts on the local hard drive. > which is filled as http://bugzilla.gnome.org/show_bug.cgi?id=324203 -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.22 released
Congrats to all the team and contributors for the load of bug fixes and features that went into this release. I haven't been around much during this cycle but since I noticed HIG/GUI problems here and there (nothing big just little things), I'll be filling bugs again in the coming days (hopefully with patches). Keep up the good work. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failure in evo: need a lot of stuff!
Le vendredi 18 janvier 2008 à 16:34 -0500, Jeffrey Stedfast a écrit : > On Fri, 2008-01-18 at 16:32 -0500, Paul Smith wrote: > > Hi all; > > > > I'm getting a build failure in Evo and gtkhtml with the latest glib: > > editor-control-factory.c: In function 'editor_get_prop': > > editor-control-factory.c:463: error: expected expression before 'do' > > Apparently, the latest glib broke the libbonobo from Gnome 2.20, so if > > you install the latest glib you also need the latest libbonobo. > > > you might want to warn the glib guys about this then... seems they have > broken API or ABI which is a strict no-no. libbonobo-2.20.3 changelog indicates that it is intended to fix some problems with glib-2.15, make sure you have at least that version. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Ical (WebDAV) Web-Calendar read-only!?
This was discussed recently on the channel as well, Le vendredi 30 novembre 2007 à 11:56 +, Ross Burton a écrit : > On Fri, 2007-11-30 at 12:49 +0100, Artur Mücke wrote: > > > I presume its using Webdav to write to the calendar file. > > > > Yes, your presumption is right because it is using WebDAV but I > thought > > Evolution is doing the same, isnt it? > > No, Evolution uses plain HTTP. > > > There are many problems with this approach including locking, > concurrent writes, > > > and notification of changes. However if you are the only person > using > > > the remote calendar, it would work. [snip] > Unless there are extensions I'm not aware of, that sounds like its > going > to break. If both User A and User B edit the calendar, they will race > to write the changes. The second person to write will replace the > first > person's changes. publish_calendar is the closest thing to be compared to "on the web" calendar write support. It uses plain gnome_vfs_write and (although I didn't read this part yet) I suspect gnome_vfs handles most of the tricks needed (locking, ...). If it doesn't, fixes are belong to gnome-vfs probably. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Right click menu ordering
Hi list, I recently filled bug #495875 (http://bugzilla.gnome.org/show_bug.cgi?id=495875) which is about right click menu ordering for components' left-panel. There is a draft at comment #2 and #3 of how options could be organized so that it remains consistent throughout the UI. I'd like to bring up the discussion here in order to get something that could be made available on the wiki and could be used as a reference for evo hackers. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Data storage question
Le jeudi 09 août 2007 à 00:33 -0400, administrator a écrit : > I'm trying to write a php script that will create mail accounts in > evolution. > So far, everything works fine and I seem to have all changes to files > identified and covered, and all file and folder creation taken care of > in the .evolution folder and .gconf folder. > > However, I'm having the problem that .gconf/apps/evolution/mail/% > gconf.xml is being reverted when evolution is started up. > > I am stopping all evolution related processes, and all instances of > gconfd-2 (if that one matters) > I was told I need to stop gconftool-2, but that isn't running on my > system. > > What am I missing that causes the file to be reverted, or replaced with > a "first run" version? evolution --force-shutdown apply_change kill -SIGHUP `pidof gconf` evolution or something like that. Thing is modifying the file directly will give you problems about which daemon is running or not and is cashing informations while using gconftool-2 directly talks to the gconf daemon. You might still need to restart evolution-data-server depending on what you modify but at least you don't have to bother with gconf state. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution's UI, consistency and codebase
Le jeudi 31 mai 2007 à 11:01 -0400, Daniel Gryniewicz a écrit : > On Thu, 2007-05-31 at 15:00 +0530, Srinivasa Ragavan wrote: > > On Thu, 2007-05-31 at 11:19 +0200, Gilles Dartiguelongue wrote: > > > Le jeudi 31 mai 2007 à 08:59 +, Srinivasa Ragavan a écrit : > > > > On Thu, 2007-05-31 at 10:36 +0200, Gilles Dartiguelongue wrote: > > > > > I've seen that too, but the point was more: "Why are the message view > > > > > headers looking different than every other ETable I can see in > > > > > evolution ?". I've looked at different themes and it was always > > > > > different. I'm not an expert in GtkWidget hacking but can't we > > > > > "inherit" > > > > > some properties from regular list headers ? > > > > > > > > Different in what sense? I see that message-list is not consistent with > > > > GtkTreeview but so as is the other memo/task list. Im sorry, I'm not > > > > getting it. > > > > > > See attachements: > > > - in mail view, even if it's not perfect it looks like a GtkTreeView > > > header > > > - in memo view, the header looks like a button > > > > > > This is even more flagrant with the Glossy theme. > > > > Frankly, for me with Industrial, it looks the same in both places. > > For me, it looks like Gilles. I have a clearlooks-based theme. I'd > guess it's engine related? > > Daniel > indeed, for reference (and non pgo readers): http://abock.org/2007/07/02/suboptimal-theming-in-gtk/ http://blogs.gnome.org/thos/2007/07/04/re-suboptimal-theming-in-gtk/ long story short, ETree needs special handling of the gtk-engine to be drawn in a way that makes it look like a GtkTreeView and even then, it is very possible it won't be perfect. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Overview of camel-lite
Le lundi 11 juin 2007 à 10:57 +0300, Philip Van Hoof a écrit : > * "All" compilation warnings fixed (we usually compile with -Wall and >-Werror). Fixing this caused four major bug fixes in initialisation > of variables in Camel. ok, right away, let me just say evo team is interested in fixing as much compilation warnings as possible. In last week's meeting, Matthew told me he was especially interested in fixes for camel and I was about to start to work on it but if you have it all done already... :) -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
Le dimanche 10 juin 2007 à 17:05 +0400, Nickolay V. Shmyrev a écrit : > В Сбт, 09/06/2007 в 17:45 +0200, Gilles Dartiguelongue пишет: > > Le vendredi 27 avril 2007 à 10:07 +0200, Gilles Dartiguelongue a écrit : > > after reading more code, it seems bonoboui doesn't like icons starting > > with the stock_ prefix. It throws " Bonobo-CRITICAL **: > > bonobo_ui_util_xml_to_pixbuf: assertion `length > 4 * 2 * 2 + 1' failed" > > at the command line. > > > > The result is that the icon for folder->refresh and for any other menu > > item wanting to use a stock_* icon, it just won't appear. > > > > I thought it could be a problem with libbonoboui but then I remembered > > that it works perfectly fine for popup menus. > > > > As gtk-* icons are far from covering what we can add as icons in the > > menus, please, please help me fix this issue. > > Hello Gilles > > It's really hard to understand original problem and reasons for that > since not much is described. What are you trying to do really? > About way to convince bonoboui what about registration of stock icon and > then usage it in libbonoboui with pixtype=stock? I'm not sure why > libbonoboui tries to get pixbuf from your attribute (it's the task of > the function bonobo_ui_util_xml_to_pixbuf). Looks like you misunderstand > each other. What ui description are you passing to it? let's try with an example, take: http://svn.gnome.org/svn/evolution/trunk/ui/evolution-mail-list.xml there is a line in it that looks like: The icon exists and is in the same folder where are stored other stock icons (gtk-add, gtk-undelete, ...) but it doesn't show up in the UI -- Gilles Dartiguelongue <[EMAIL PROTECTED]> Élève Ingénieur ESIEE, 5ème année Majeure Informatique ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
Le vendredi 27 avril 2007 à 10:07 +0200, Gilles Dartiguelongue a écrit : > Le dimanche 08 avril 2007 à 23:11 +0200, Gilles Dartiguelongue a écrit : > > Hi list, > > > > in the process of enhancing plugins, I was looking for a mean to add an > > icon in the top level menus. After some code reading it seems it is not > > possible if the icon is not a gtk stock icon. Did I miss something ? > > > > Any pointers would be appreciated. > after reading more code, it seems bonoboui doesn't like icons starting with the stock_ prefix. It throws " Bonobo-CRITICAL **: bonobo_ui_util_xml_to_pixbuf: assertion `length > 4 * 2 * 2 + 1' failed" at the command line. The result is that the icon for folder->refresh and for any other menu item wanting to use a stock_* icon, it just won't appear. I thought it could be a problem with libbonoboui but then I remembered that it works perfectly fine for popup menus. As gtk-* icons are far from covering what we can add as icons in the menus, please, please help me fix this issue. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> EE/CS last year student, ESIEE signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introduction and Questions
Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit : > Without immediately writing to disk work, the download by itself will > consume around 120 MB of RAM, and will most likely fail due to network > timeouts and other such problems (it'll take a while, since Evolution > fetches a ridiculous large amount of headers for each message for > building its summary). > isn't the imap-features plugin's goal to reduce/customize the amount of downloaded headers ? Or is it that it's still not enough ? -- Gilles Dartiguelongue <[EMAIL PROTECTED]> EE/CS last year student, ESIEE signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution's UI, consistency and codebase
Le jeudi 31 mai 2007 à 08:59 +, Srinivasa Ragavan a écrit : > On Thu, 2007-05-31 at 10:36 +0200, Gilles Dartiguelongue wrote: > > I've seen that too, but the point was more: "Why are the message view > > headers looking different than every other ETable I can see in > > evolution ?". I've looked at different themes and it was always > > different. I'm not an expert in GtkWidget hacking but can't we "inherit" > > some properties from regular list headers ? > > Different in what sense? I see that message-list is not consistent with > GtkTreeview but so as is the other memo/task list. Im sorry, I'm not > getting it. See attachements: - in mail view, even if it's not perfect it looks like a GtkTreeView header - in memo view, the header looks like a button This is even more flagrant with the Glossy theme. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> <><>___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution's UI, consistency and codebase
Le jeudi 31 mai 2007 à 07:19 +, Srinivasa Ragavan a écrit : > On Thu, 2007-05-31 at 00:17 +0200, Gilles Dartiguelongue wrote:> > > First thing that hit me was that it didn't use GtkTreeView and that it > > doesn't understand _ markup. > > I think that can be moved to GtkTreeView and shouldn't have a issue. > Patches are welcome :). I'll fill a bug and work on a patch. > It is not that, it doesn't understand markup. The '_' is there to > provide key accelerator in visible UI items, and it isn't stripped of at > those places. I don't think that '_' makes any sense in the table/row. Yep, that's what I meant > > I know evolution has its own ETable widget > > and that it does thing that evolution needs and gtk+ doesn't provide but > > why use this widget here ? > > It is that, we have moved to GtkTreeView to in lots of places and we > have list of places where we want to move and don't want to move. > Message list is a place where we don't want to move. The why was refering to the "Customize View" dialog, not the message view. But see next point. > > > > The second thing is the "Edit" button. It is not the same as everywhere > > I looked in the preferences window, this is bad. > > This can be fixed. Will fill a bug an provide a patch unless somebody is quicker than me :) > > > > Last point is, why is the mail view headers fixed (like not look like > > buttons) in 2.10 and not the other views as well (memos, calendars, > > contacts) > > In few themes, Ive seen that it looks like a table header, but not in > all themes. If you have seen this 2.10, may be with a right theme. Im > sure that this should be fixable in widgets/table. I don't think it > would right to fix all the other themes for this. I've seen that too, but the point was more: "Why are the message view headers looking different than every other ETable I can see in evolution ?". I've looked at different themes and it was always different. I'm not an expert in GtkWidget hacking but can't we "inherit" some properties from regular list headers ? -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution's UI, consistency and codebase
Hi list, big title, but probably not a big deal (at least for the case I'm exposing) After reading [1] and [2] and part of the HIG, I started to see lots of bad dialogs in evolution. I've already tried to fix some of this UI badness (imap-features plugin) but today I came across the "Customize View" dialog and I wanted to talk about it :) First thing that hit me was that it didn't use GtkTreeView and that it doesn't understand _ markup. I know evolution has its own ETable widget and that it does thing that evolution needs and gtk+ doesn't provide but why use this widget here ? The second thing is the "Edit" button. It is not the same as everywhere I looked in the preferences window, this is bad. Last point is, why is the mail view headers fixed (like not look like buttons) in 2.10 and not the other views as well (memos, calendars, contacts) Please advise. [1] http://bugzilla.gnome.org/show_bug.cgi?id=364385 [2] http://www.go-evolution.org/User_Interface -- Gilles Dartiguelongue <[EMAIL PROTECTED]> EE/CS last year student, ESIEE signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] XML APIs in evolution
Hi list, while walking through the tree to create bug #437579 [1] patches, I've found that quite a bunch of warnings (most of them in fact) where relating to calls to libxml functions without casting. Typical situation is that you have a string "toto" and want to get the property of that node. You'll do xmlGetProp (mynode, "toto"); and paf, you got a warning because this functions wants a xmlChar * which is a unsigned char * and that by default, strings are char *. In this particular case, gcc is not smart enough to find out that this is what we want and that's perfectly fine. On the other hand, there are some xml functions from evolution in e-utils/e-xml-utils.[ch]. Guess what, they have the same problem ! I've done all the casting patchs and I think this is the right thing to do ATM. It will cleanup compilation output and allow to focus on other warnings but I feel it doesn't help with code reading. There are some places where e-xml-utils functions are mixed with libxml calls. Don't remember exactly the place though. The question is, what shall we do now ? -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases
Le lundi 21 mai 2007 à 18:39 +0200, Frederic Crozat a écrit : > Le lundi 21 mai 2007 à 20:21 +0200, Gilles Dartiguelongue a écrit : > > Le lundi 21 mai 2007 à 18:03 +0200, Frederic Crozat a écrit : > > > Le lundi 21 mai 2007 à 19:24 +0200, Gilles Dartiguelongue a écrit : > > > > Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit : > > > > > Hi Evolution / E-D-S maintainers, > > > > > > > > > > it appears that since CVS to SVN migration, no evolution / e-d-s > > > > > release > > > > > was followed by a SVN tag creation in /tags. > > > > > > > > > > These tags are very useful for you, maintainers but also for > > > > > contributors and vendors when they try to search for changes between > > > > > releases. > > > > > > > > > > Could you try to create those missing tags and make sure they are > > > > > created when releasing new tarballs in the future (I guess somebody > > > > > script was not migrated correctly to SVN ;) ? > > > > > > > > > > Thanks you in advance. > > > > > > > > in fact it seems evolution uses branches over tags > > > > > > > > evolution stable branch can be found at : > > > > http://svn.gnome.org/svn/evolution/branches/gnome-2-18 > > > > > > Branches and tags are different beast : > > > -branches are used to do developement for a particular release of GNOME > > > (here 2.18.x series) > > > -tags are pointing each release (ie tarball generation), regardless of > > > branches. > > > > > sorry I was unclear. I meant that afaics, evolution never tagged > > releases, or something definitely got lost in the cvs->svn transition. > > They did, check : > svn ls http://svn.gnome.org/svn/evolution/tags/ | grep EVOL > indeed, case sensitivity got me :) sorry for the confusion -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases
Le lundi 21 mai 2007 à 18:03 +0200, Frederic Crozat a écrit : > Le lundi 21 mai 2007 à 19:24 +0200, Gilles Dartiguelongue a écrit : > > Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit : > > > Hi Evolution / E-D-S maintainers, > > > > > > it appears that since CVS to SVN migration, no evolution / e-d-s release > > > was followed by a SVN tag creation in /tags. > > > > > > These tags are very useful for you, maintainers but also for > > > contributors and vendors when they try to search for changes between > > > releases. > > > > > > Could you try to create those missing tags and make sure they are > > > created when releasing new tarballs in the future (I guess somebody > > > script was not migrated correctly to SVN ;) ? > > > > > > Thanks you in advance. > > > > in fact it seems evolution uses branches over tags > > > > evolution stable branch can be found at : > > http://svn.gnome.org/svn/evolution/branches/gnome-2-18 > > Branches and tags are different beast : > -branches are used to do developement for a particular release of GNOME > (here 2.18.x series) > -tags are pointing each release (ie tarball generation), regardless of > branches. > sorry I was unclear. I meant that afaics, evolution never tagged releases, or something definitely got lost in the cvs->svn transition. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases
Le lundi 21 mai 2007 à 17:19 +0200, Frederic Crozat a écrit : > Hi Evolution / E-D-S maintainers, > > it appears that since CVS to SVN migration, no evolution / e-d-s release > was followed by a SVN tag creation in /tags. > > These tags are very useful for you, maintainers but also for > contributors and vendors when they try to search for changes between > releases. > > Could you try to create those missing tags and make sure they are > created when releasing new tarballs in the future (I guess somebody > script was not migrated correctly to SVN ;) ? > > Thanks you in advance. in fact it seems evolution uses branches over tags evolution stable branch can be found at : http://svn.gnome.org/svn/evolution/branches/gnome-2-18 -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org wiki & spam
Le mardi 15 mai 2007 à 19:27 +0530, Srinivasa Ragavan a écrit : > On Tue, 2007-05-15 at 15:40 +0200, Gilles Dartiguelongue wrote: > > Le mardi 15 mai 2007 à 18:51 +0530, Srinivasa Ragavan a écrit : > > > Hi Gilles, > > > > > > I dont see the spam in the Main_Page. Am I seeing elsewhere? > > > > click on "see source as text". > > It's in a tag with css style making it invisible to users (namely > id="wyikol" style="overflow:auto; height: 1px; ">) > Ah! Caught it. Removed. > > -Srini. > > > > > following meeting, I did a quick search and came up with this : http://www.mediawiki.org/wiki/Extension:ConfirmEdit hope it helps. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org wiki & spam
Le mardi 15 mai 2007 à 18:51 +0530, Srinivasa Ragavan a écrit : > Hi Gilles, > > I dont see the spam in the Main_Page. Am I seeing elsewhere? click on "see source as text". It's in a tag with css style making it invisible to users (namely ) -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] go-evolution.org wiki & spam
Hi guys, if this is off-topic, please redirect me to the proper mailing list. I've noticed since yesterday some spam across the wiki. Digging a bit I found that it was kind of widespread (see http://www.go-evolution.org/Special:Recentchanges if you are not convinced). The main page has some spam in it too but I can't fix it since I don't have the proper rights. I've seen a user's comment asking "what about turning anonymous editing off ?". Will this be done ? The version of wikipedia seems a bit old too, is an upgrade planned ? -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnomeDruid migration
Le jeudi 10 mai 2007 à 15:40 +0530, Srinivasa Ragavan a écrit : > > > > So, what should be done here, indefinitely keep the current > > implementation or get rid of one more part of libgnomeui and simplifying > > evo's implementation ? > > I would prefer to move to GtkAssistant but then it should still support > the existing EConfig structure. Hula/Groupwise/Exchange and other > providers will directly hook into EConfig via EPlugins. > > I haven't yet seen much into GtkAssistant but it should be possible to > get it working. great, I should add that I wanted to make the necessary changes to the plugins too if necessary (I believe that mixing GnomeDruid and GtkAssistant is not cool at all unless you want to express your mad g_object skills :) ). As I said, the biggest difference is that GnomeDruid bases it's operations on the access of next and previous page through pointers which is not the case with GtkAssistant. We could simulate that obviously but I think the result wouldn't be easy to either debug or maintain. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GnomeDruid migration
Hi list, I looked at the sources to get a feel of how easy it would be to migrate from GnomeDruid to GtkAssistant. I started some work on the startup config plugin and on the new mail account glade part. At that point, trying to create a new account just crashes evolution, so I decide to look deeper. I found that currently wizards are intricated with notebooks in e-utils/e-config.c. Although it worked relatively well with GnomeDruid, I tried to adapt it to GtkAssistant without much success. It seems there is no easy way to get references to previous and next page other than by calculating the prev/next page id with GtkAssistant. On the other hand, integrating new pages into an assistant seems really easy. So, what should be done here, indefinitely keep the current implementation or get rid of one more part of libgnomeui and simplifying evo's implementation ? -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plugin and menu icons
Le dimanche 08 avril 2007 à 23:11 +0200, Gilles Dartiguelongue a écrit : > Hi list, > > in the process of enhancing plugins, I was looking for a mean to add an > icon in the top level menus. After some code reading it seems it is not > possible if the icon is not a gtk stock icon. Did I miss something ? > > Any pointers would be appreciated. poke ! I'd be grateful for any information on this. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Plugin and menu icons
Hi list, in the process of enhancing plugins, I was looking for a mean to add an icon in the top level menus. After some code reading it seems it is not possible if the icon is not a gtk stock icon. Did I miss something ? Any pointers would be appreciated. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution releases and intltool brokeness
Hi list, while preparing ebuilds for gentoo gnome-experimental overlay, I came across a "fix" that was present since... who knows (years???). It's a simple call to intltoolize --force. What for ? To fix the sources released with a broken intltool. If you have generated the rules to compile translation with intltool 0.35.1 then if you have LINGUAS set to something else than what is available, the compilation breaks. intltool 0.35.[0234] handles that nicely. example: I have LINGUAS="fr en ja zh zh_CN", if ALL_LINGUAS only defines fr, zh_CN, I'm screwed. Please fix it for next release. Currently I'm sure gtkhtml-3.13.91 is affected but the fix is present on all evo related ebuild on gentoo so you might want to check these anyway. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] The recent camel-lite improvements
It'd be nice to see the work for IDLE make it to mainline too. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] NSS PKCS#11 modules
While looking at the code for bug http://bugzilla.gnome.org/show_bug.cgi?id=396645 I've found some blobs about pkcs11. I'm very interested in this at the moment since I'm trying to use an eToken (pkcs11 compatible smartcard) with evolution. Currently evolution seems to have no UI for adding such modules and I would like to know if there is any base to start something like this. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Chaning fields in the message list view
Hi Alfredo, Le samedi 13 janvier 2007 à 19:01 +, Alfredo Matos a écrit : > Hi, > > I've just started to try hacking away at evolution. But i could use a > few valuable pointers: > > In the mail view, on the message list i want to do the following: > > 1) Change the From field to display the just the Sender's name, or just > the email if the name does not exist. As I just discovered (really something like 5 minutes ago) that it is already present in evolution. Just right click on the column header, select add a column and choose "Sender" (rough translation) instead of "From". > > 2) Change the Date format from 12h to 24h. I'm not sure about this, but I think it is related to the definition of your locale in glibc. > I've reached as far as the evolution-data-server source, looking at the > camel code, particularly at CamelMessageInfo and CamelMessageInfoBase. > Am i on the right track ? Would appreciate some pointers towards where > to code this... I've found the feature of your first point by looking at mail/message-list.c -- Gilles Dartiguelongue <[EMAIL PROTECTED]> ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
