[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Abstracting date handling.
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2002-03-31 11:25:43
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 31 March 2002 11:21, Zack Rusin wrote:
> On Saturday 30 March 2002 09:31, Marc Mutz wrote:
<snip>
> > - - with the above two, you also don't need to disable copying.
>
> Point well taken, but I still don't see why anyone would want to be
> passing this one around.
<snip>

I don't either, but why add extra lines of code to disable somthing that's 
neither potentially harmful nor potentially useful? ;-)

> > - - overload the dateString method to take time_t, as well as
> > QDateTime args. - - add a method that returns a rfc2822-formatted
> > date as QCString, so we can use it later to construct headers in
> > KMime.
>
> Both fixed/implemented.
<snip>

Hm, the ::zone() method seems expensive to me. Can't one obtain the timezone 
from libc? I remember that localtime() sets a global variable that contains 
the offset to GMT, but that could be a GNU-ism.

> Which comes down to the fact that every single item
> from your list has been fixed/implemented.

;-)

> > Sorry for so much criticism :-(
>
> It was awesome. That's exactly what I need before I really get going. I
> was wondering could we put a HACKING file on CVS so that people wanting
> to start coding would at least have easy access to informations about
> coding conventions that we're using?

The conventions I cited were _my_ conventions that I (as maintainer) plan to 
enforce for _KMime_. KMail's coding style may be much different or 
non-existent. It's general KDE-style to name members either with as m_var or 
mVar.

> I know that such file would remove
> at least two items from your list above. Oh, could we maybe also decide
> on a consitant indention style

Indention style for KMime is 2 spaces, with a series of eight spaces possibly 
abbreviated by a tab.

> and member variable naming scheme. I
> know that people hate having other's style pressured on them, but
> having one consistant style across application is good.

If indent(1) wasn't so bad at formatting c++, I'd write a indent.pro.

> Going back to the class I think it's now commit ready, I could do it as
> soon as David will give me cvs access, but if anyone wants to do that
> before you're free to do so, just email me to send you the test case
> file.
<snip>

Personally, I can wait until you have cvs access. Do as you like.

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8pvI33oWD+L2/6DgRAuxpAKCcC+BGgRreChyIsdEAM4JXFZEFvACgxzNv
46g2g1AzNHB97aBi+pnx1Bs=
=nqQE
-----END PGP SIGNATURE-----

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]