[Evolution-hackers] Evo-Plugin Coding Style

2010-07-01 Thread Christian Hilberg
Hi all,

searching evolution-hackers about Evolution coding style, I found

http://projects.gnome.org/evolution/patch.shtml

referenced as the coding style reference ;-) for Evolution. Is this document 
still fully valid so we may use it as style guide for our project? Are there 
any sections in this document which do no longer apply (e.g. Evolution moved 
to C99 or something the like)?
Thanks for any input on the issue.

Greetings,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


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] Evo-Plugin Coding Style

2010-07-01 Thread Christian Hilberg
On Thursday 01 Juli 2010 at 13:01:22 Matthew Barnes wrote:
 On Thu, 2010-07-01 at 11:43 +0200, Christian Hilberg wrote:
  searching evolution-hackers about Evolution coding style, I found
  http://projects.gnome.org/evolution/patch.shtml
 [...] 
 That's still more or less valid.  There's details there I would nitpick
 but if you're writing your own module you have more freedom to do it the
 way -you- want.

I'll  propose this as our style guide then. Just like Ross in one posting (I 
think back in 2009), I'm interested specially in getting to know about indent 
style. patch.shtml talks about 8-space-tabs (and true tabs instead of blanks). 
Since there are other Gnome projects (like Gimp) which do not allow tabs - but 
use blanks for all indentation, for purposes e.g. of alignment of parameters 
in multi-lined function signatures - I wanted to be sure here that we follow 
the proper Evolution-path.

 If in doubt, look at code samples from evolution/shell, as that's all
 been rewritten recently and follows our preferred coding style these
 days.

Okay, thanks.

Best regards,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


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] Evo-Plugin Coding Style

2010-07-01 Thread Tor Lillqvist
 style. patch.shtml talks about 8-space-tabs

Just some nitpicking here: I hate it when people say loosely that tabs
correspond to 8 spaces (or four, or whatever). A TAB character indents
to the next multiple of the tab width. The tab width is a certain
number of columns. Exactly how many spaces that then corresponds to
obviously depends on what the current column before the tab is.

I.e., for the traditional (and I mean *really* traditional) eight
column tab width, if a line has:

abcTABdef

*that* TAB character corresponds to *five* spaces. Not eight.

--tml
___
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] Evo-Plugin Coding Style

2010-07-01 Thread Matthew Barnes
On Thu, 2010-07-01 at 13:16 +0200, Christian Hilberg wrote:
 I'll  propose this as our style guide then. Just like Ross in one posting (I 
 think back in 2009), I'm interested specially in getting to know about indent 
 style. patch.shtml talks about 8-space-tabs (and true tabs instead of 
 blanks). 
 Since there are other Gnome projects (like Gimp) which do not allow tabs - 
 but 
 use blanks for all indentation, for purposes e.g. of alignment of parameters 
 in multi-lined function signatures - I wanted to be sure here that we follow 
 the proper Evolution-path.

I would side with Gimp on any new projects I start -- I hate tabs, and I
especially hate mixing spaces and tabs.  So our coding style is far from
what I would personally prefer but we're stuck with it and I adhere to
it for the most part.

I use spaces to align function parameters -- one parameter per line.
But I doubt you'll find much consistency here.

Because of my Python background I also prefer short, simple statements
using as many local variables as necessary.  And I try to avoid complex
expressions or nested calls in function calls.  It's easier to read and
easier to debug.

Also avoid one-letter variable names, especially in for-loops.  They're
very difficult to grep for.  e.g. Use something like 'ii' instead of 'i'
for simple integer counters.

That's all the pet-peeves I can think of off the top of my head.  :)


___
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] Evo-Plugin Coding Style

2010-07-01 Thread Christian Hilberg
On Thursday 01 Juli 2010 at 13:30:26 Tor Lillqvist wrote:
  style. patch.shtml talks about 8-space-tabs
 Just some nitpicking here: I hate it when people say loosely that tabs
 correspond to 8 spaces (or four, or whatever).

For good reason. :-) Just quoted 
http://projects.gnome.org/evolution/patch.shtml (Coding Style), which may 
not be too accurate about this...?

 A TAB character indents
 to the next multiple of the tab width. The tab width is a certain
 number of columns. Exactly how many spaces that then corresponds to
 obviously depends on what the current column before the tab is.

Maybe the Evolution Patch Guidelines could use a little updating, if there is 
enough consent about how to deal with the nitpickable parts.

Greetings,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


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] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

2010-07-01 Thread chen
On Thu, 2010-07-01 at 13:41 +0200, Christian Hilberg wrote:
 On Thursday 01 Juli 2010 at 08:58:32 Milan Crha wrote:
  Hi all,
  I'm working on a way to be able to report detailed errors from
  addressbook/calendar backends to UI, so users will be able to see
  something more sensible than just Other error message in Evolution.
  This is bug report for this [1], which I'm working on right now.
  [...]
 
 Are there any plans to backport this to Evo/EDS 2.30.x (I suppose not)?
All freezes (api/abi/string/feature) etc. hold good with the stable
branch (gnome-2-30 or 2.30.x). So we will not back-port.

- Chenthill.
 
 Greetings,
 
   Christian
 
 ___
 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 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] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

2010-07-01 Thread Patrick Ohly
On Thu, 2010-07-01 at 08:58 +0200, Milan Crha wrote:
 I'm working on a way to be able to report detailed errors from
 addressbook/calendar backends to UI, so users will be able to see
 something more sensible than just Other error message in Evolution.
 This is bug report for this [1], which I'm working on right now.

Will that break libebook and libecal APIs? The issue only mentions
backends, but the subject of your emails includes EBook and ECal.


-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
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] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

2010-07-01 Thread Milan Crha
On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote:
 Will that break libebook and libecal APIs? The issue only mentions
 backends, but the subject of your emails includes EBook and ECal.

Hi,
for EBook it is, all the async API there uses 'status' as an indicator
of the operation result in the async callback. I'm changing it to GError
too. I'm still on ECalBackend, but it seems some similar change will be
in ECal too, though I'm not sure yet, I'm not that far. I'll summarize
changes in the bug report when I'll be done with it, to have them
written somewhere.
Bye,
Milan

___
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] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

2010-07-01 Thread Patrick Ohly
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote:
 On Thu, 2010-07-01 at 14:42 +0200, Patrick Ohly wrote:
  Will that break libebook and libecal APIs? The issue only mentions
  backends, but the subject of your emails includes EBook and ECal.
 
   Hi,
 for EBook it is, all the async API there uses 'status' as an indicator
 of the operation result in the async callback. I'm changing it to GError
 too. I'm still on ECalBackend, but it seems some similar change will be
 in ECal too, though I'm not sure yet, I'm not that far. I'll summarize
 changes in the bug report when I'll be done with it, to have them
 written somewhere.

If this was about the synchronous APIs that SyncEvolution depends on,
then I'd be really worried about this change. If those functions are not
changed, SyncEvolution binaries from syncevolution.org  will continue to
work (full list of called functions attached).

Having said that, are you sure that there is no way to preserve the old
APIs? Perhaps the new implementation can be made available under a new
name and the old one be implemented by mapping the GError to the old
error code?

I suspect that quite a few projects will have to adapt their source code
if that's not the case. OpenOffice might be another candidate which
tries to be binary compatible with different versions of Evolution.

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/

e_book_add_contact
e_book_authenticate_user
e_book_commit_contact
e_book_error_quark
e_book_get_addressbooks
e_book_get_changes
e_book_get_contact
e_book_get_contacts
e_book_get_supported_auth_methods
e_book_get_uri
e_book_new
e_book_new_default_addressbook
e_book_new_from_uri
e_book_new_system_addressbook
e_book_open
e_book_query_any_field_contains
e_book_query_unref
e_book_remove_contact
e_cal_add_timezone
e_cal_component_get_icalcomponent
e_cal_component_get_last_modified
e_cal_component_get_type
e_cal_create_object
e_calendar_error_quark
e_cal_get_component_as_string
e_cal_get_object
e_cal_get_object_list_as_comp
e_cal_get_sources
e_cal_get_timezone
e_cal_get_uri
e_cal_modify_object
e_cal_new
e_cal_new_from_uri
e_cal_new_system_calendar
e_cal_new_system_tasks
e_cal_open
e_cal_remove_object
e_cal_remove_object_with_mod
e_cal_set_auth_func
___
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] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes

2010-07-01 Thread Matthew Barnes
On Thu, 2010-07-01 at 14:57 +0200, Milan Crha wrote:
 for EBook it is, all the async API there uses 'status' as an indicator
 of the operation result in the async callback. I'm changing it to GError
 too. I'm still on ECalBackend, but it seems some similar change will be
 in ECal too, though I'm not sure yet, I'm not that far. I'll summarize
 changes in the bug report when I'll be done with it, to have them
 written somewhere.

If I understand all this correctly, it looks like what's being done here
is allowing backends to report both an error code and a detailed error
mesage to the client library, rather than having to set some generic and
often less-than-helpful message from an error code alone.

Looks like most of the impact in libecal and libebook is in the callback
function signatures for asynchronous operations.  The synchronous APIs
will remain unchanged AFAICT.  Chen/Milan: correct me if I'm wrong.

You know, this might be a good time to starting talking again about a
common base class for ECal and EBook.  That would allow us to resolve
some of the stupid inconsistencies between the two classes for common
operations like opening, online/offline mode, ERROR REPORTING (ties into
this thread), server crash detection, etc.  It would also let us rewrite
some of the async ops GIO-style.

The window for API cleanups and ABI breaks in these libraries is closing
fast.  We could at least rough in a common base class now with a private
data section and get the ECal/EBook ABI break out of the way.  Then add
API to it later.

I had the name EClient in mind for the base class:

GObject
  |
  +-- EClient (implements GInitable)
|
+-- EBook
|
+-- ECal


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers