[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-commits
Subject: Re: kdelibs/kdecore
From: Frerich Raabe <frerichraabe () gmx ! de>
Date: 2001-12-11 20:16:11
[Download RAW message or body]
Am Dienstag, 11. Dezember 2001 10:15 schrieb David Faure:
> On Monday 10 December 2001 20:15, Frerich Raabe wrote:
> > Am Montag, 10. Dezember 2001 18:48 schrieb David Faure:
> > > kdelibs/kdecore kapplication.cpp,1.489,1.490 kapplication.h,1.252,1.253
> > > Author: faure
> > > Mon Dec 10 17:48:41 UTC 2001
> > >
> > >
> > > Modified Files:
> > > kapplication.cpp kapplication.h
> > > Log Message:
> > > invokerMailer improvements. Provide an API that doesn't require
> > > encoding things into a URL. Support multiple urls to be attached.
> > > Removed support for attach= in the URL-taking method, I don't want
> > > websites to automatically attach my /etc/passwd or anything else....
> >
> > Perhaps I missed a very important case which justifies that additional
> > method, but isn't something like this more suitable?
>
> Oh, actually.... now I remember why I didn't do it that way.
> I wanted the method with the 7 arguments to have the same signature
> as KMail's method. For consistency, and in case of switching to DCOP maybe.
> That's incompatible with the idea of merging with the old (address,subject)
> method.
I'm not quite convinced that it's justified to add yet another method to an
already fairly large API just to make a library compatible with an
application. If we want that signature compatibility, the change should be
done on KMail's side, I think.
- Frerich
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic