[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