Preparing terrain for kio_uiserver
David Faure
faure at kde.org
Thu Dec 21 11:36:54 GMT 2006
On Thursday 21 December 2006 12:06, Rafael Fernández López wrote:
> Hi folks,
>
> I have copied trunk/KDE/kdelibs/kio/misc into branches/work/kio_uiserver for
> uploading my work on the uiserver, and having it public. For having it
> compiling and working is needed to upload some changes on kdelibs/kio/kio.
> Those changes don't need to copy that dir to branches/work, because they're
> only relative to trunk/KDE/kdelibs/kio/kio and they won't affect the current
> handling of jobs in any case. To sum up, devs won't have to change any
> single line of code referent to jobs if this patch is applied.
>
> So the idea is to work on the kio_uiserver at branches/work/kio_uiserver,
> and upload on trunk/KDE/kdelibs/kio/kio the changes that the attached patch
> indicates.
You're not actually describing the change in your email. AFAICS you added a jobIcon
and a appName parameters to every job (the factory methods and the constructors).
I object to the cluttering of all those methods with new arguments. Why not just let
the app code call job->ui()->setIcon() after getting a job from e.g. KIO::copy()?
Yes I think icon()/setIcon() belongs in JobUiDelegate rather, if Kevin agrees.
For the appname, since your code ignores it when kapp exists anyway, why not just
get it from kapp? Well, it should rather be: from KGlobal::instance(), so that there is
no requirement on kapp. Something like:
d->appName = KGlobal::instance()->aboutData()->programName()
with null pointer checks.
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel
mailing list