KDE4 file dialog

[Rafael Fernández López]

Hi Peter and all,

>
> KFileView is not deprecated. I think it is not a good approach introducing a
> KDE 4 pedant for KFileIconView and KFileDetailView based on the KFileView
> interface, as Qt4s Interview offers already an alternative approach, so that
> no KXxxViews are needed anymore.
>

I see. Yes, probably they're not needed.

> So from my point of view there are 2 possible approaches:
>
> a) We leave the interface of KDirOperator as it is and make 2 private (!)
> implementations of KFileIconView and KFileDetailView that are not part of the
> public API. I think this is not nice, as KFileIconView and KFileDetailView
> would again mix the model/controller separation offered by Qt4s Interview.
>
> b) We change the interface of KDirOperator to:
>     QAbstractItemView* view();
>     void setView(QAbstractItemView* view);
>
> I did not check how many applications use the setView() interface of
> KDirOperator, but currently I'd go for approach b.
>

I'd go for b) solution. Without any doubt. This would also make
cleaner the API of our kdelibs. I have asked lxr:

http://lxr.kde.org/ident?i=KDirOperator

for files asking for KDirOperator. That doesn't mean they're calling
setView(), but in the worst case is not a _huge_ list.

Removing KxxxView could have a quite big impact on all the stuff that
is being proposed to be removed, almost all of them have something
like K3....View:

http://lxr.kde.org/ident?i=KFileView

I really would vote for removing this stuff. Oh man, we are running
out of time for 4.0, and this for should should be done for that time.
The release is on December, 20th as I've seen on Allen's mail, so we
have time to clean up all this stuff, even without making them
deprecated.

As a fast solution, if you agree we could mark right now this stuff as
DEPRECATED, and remove the stuff before the tagging is done.

We really have a better solution (TM), now that Qt provided us MVC.


Bye,
Rafael Fernández López.