Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products

2016-10-10 Thread Gilles Dartiguelongue
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 <eva@whyte.ninja>

___
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] libedata-cal-1.2.la: undefined reference to `e_cal_recur_ensure_end_dates'

2010-10-22 Thread Gilles Dartiguelongue
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 gilles.dartiguelon...@esiee.org


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

2010-10-15 Thread Gilles Dartiguelongue
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. Id 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 gilles.dartiguelon...@esiee.org


___
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] gcc 4.4 may be causing a number of bugs in Evolution

2010-02-01 Thread Gilles Dartiguelongue

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

2009-11-13 Thread Gilles Dartiguelongue
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 gilles.dartiguelon...@esiee.org


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

2009-07-26 Thread Gilles Dartiguelongue
Whatever you do, please do something quickly, todays spamming is at a
rate that I can barely sustain.

-- 
Gilles Dartiguelongue gilles.dartiguelon...@esiee.org


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

2009-03-08 Thread Gilles Dartiguelongue
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 gilles.dartiguelon...@esiee.org


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

2009-02-11 Thread Gilles Dartiguelongue
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.4action=historyoffset=0limit=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 gilles.dartiguelon...@esiee.org


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

2009-02-04 Thread Gilles Dartiguelongue
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 gilles.dartiguelon...@esiee.org


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

2008-09-18 Thread Gilles Dartiguelongue
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] bug fixing in stable 2.22.x branch

2008-08-20 Thread Gilles Dartiguelongue
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

2008-07-29 Thread Gilles Dartiguelongue
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

2008-06-11 Thread Gilles Dartiguelongue
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] Ical (WebDAV) Web-Calendar read-only!?

2007-11-30 Thread Gilles Dartiguelongue
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


Re: [Evolution-hackers] evolution's UI, consistency and codebase

2007-07-04 Thread Gilles Dartiguelongue
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

2007-06-11 Thread Gilles Dartiguelongue
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

2007-06-09 Thread Gilles Dartiguelongue
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

2007-06-07 Thread Gilles Dartiguelongue
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

2007-05-31 Thread Gilles Dartiguelongue
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

2007-05-30 Thread Gilles Dartiguelongue
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


Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Gilles Dartiguelongue
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 module_name/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] Missing svn tags for e-d-s / evolution 2.18 releases

2007-05-21 Thread Gilles Dartiguelongue
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 module_name/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

2007-05-21 Thread Gilles Dartiguelongue
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 module_name/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] go-evolution.org wiki spam

2007-05-16 Thread Gilles Dartiguelongue
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  div
  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


[Evolution-hackers] go-evolution.org wiki spam

2007-05-15 Thread Gilles Dartiguelongue
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] go-evolution.org wiki spam

2007-05-15 Thread Gilles Dartiguelongue
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  div
id=wyikol style=overflow:auto; height: 1px; )


-- 
Gilles Dartiguelongue [EMAIL PROTECTED]

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] GnomeDruid migration

2007-05-10 Thread Gilles Dartiguelongue
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] GnomeDruid migration

2007-05-10 Thread Gilles Dartiguelongue
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] evolution releases and intltool brokeness

2007-02-13 Thread Gilles Dartiguelongue
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

2007-02-07 Thread Gilles Dartiguelongue
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

2007-01-14 Thread Gilles Dartiguelongue
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

2007-01-13 Thread Gilles Dartiguelongue
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