Preparing terrain for kio_uiserver

[Rafael Fernández López]

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.

> Using this constructors we are not forcing to call additional methods.
> No, we are forced to read unreadable calls with N arguments without
> knowing which
> one does what. This isn't kde3 anymore, the qt4/kde4 way is readable code
> with separate
> setters. Besides, I doubt that most code that uses a kio job needs to set
> an icon or an appname,
> it most cases the application's defaults from the aboutData are just fine.


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 (and is OK).

> The icon has nothing to do really with the delegate I think, since there
> is
> > no need of own delegate for having an icon on the kio_uiserver, are
> > different things.
> Err I'm not talking about itemdelegates here, but about the ui part of a
> job,
> which is job->ui(). The icon is a GUI thing so it belongs there.


I was talking about that too. And the icon has nothing to do with it, so  I
don't find the point of adding into that delegate (job->ui()) the icon.

Bye,
Rafael Fernández López.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061221/14758a3c/attachment.htm>