Preparing terrain for kio_uiserver

[David Faure]

On Thursday 21 December 2006 18:02, Rafael Fernández López wrote:
> 2006/12/21, David Faure <faure at kde.org>:
> >
> > On Thursday 21 December 2006 16:27, Rafael Fernández López wrote:
> > > Hi,
> > >
> > > I think that should force devs to call more methods than expected.
> > Look at the Qt4 API, that's how it works. Simple constructors, setter
> > methods.
> Ok, if you think is the best think, I will change all my code... but I don't
> vote on that.
You'll see how much the patch becomes much shorter and simpler too ;)

> If you (or the app) don't wanna set them, just obey them, on the constructor
> them all are of type "const QString &var ..... = QString()" at the end of
> constructor parameters. On the last constructor (KIO::Job constructor) if
> that QString is null (=QString()) it gets data from KInstance, as you
> suggested.
Of course. But only for now. What happens in the future? One day we decide that
we don't want e.g. the icon argument anymore, what happens then? If we just remove it,
the apps that were calling  theMethod("a","b") where b was the icon, still compile
but "b" is now understood as the appName. No way to catch that with the compiler.
On the other hand, if we deprecate setIcon, then it's very easy to catch the code that
was setting the icon, we can just remove the method or mark it as deprecated.
For long-term maintainance and lots of code using the API - as is the case in kdelibs -,
methods with many arguments and default values are really a pain.

> I was talking about that too. And the icon has nothing to do with it
The icon as nothing to do with the UI? ???

> so I don't find the point of adding into that delegate (job->ui()) the icon.
It belongs there, not in the job. Think about jobs are core-only things - as KJob is.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).