KIOWidgets and KFile

[David Faure]

I need input on solving a dependency issue.

The current kdelibs/kfile is the set of widgets that make up the contents of 
the file dialog (embeddable "file widget", tree view, places model, preview 
support, new file popupmenu, breadcrumb url navigator...).

It was separate for reasons that don't apply anymore
(reducing the number of relocations in kio, i.e. making it smaller, by 
dlopen'ing the file widget on demand).

At the last meeting we said let's just merge that into KIOWidgets.

I just tried, it adds a lot of dependencies to KIOWidgets, and leads to a 
dependency cycle.

* It adds ItemViews (for kdirsortfilterproxymodel)
* It adds KNotifications (for the notification when emptying the trash 
(useful? the user triggered it himself/herself))
* It adds XmlGui for KActionCollection, used by KFileWidget/KDirOperator
* It adds Solid for KFilePlacesModel/KFilePlacesView
* It adds KBookmarks, used by KFilePlacesModel

The last one is worst than the others, because KBookmarks depends on 
KIOWidgets, in order to use KRun (to launch the selected bookmarks when 
KBookmarkMenu is used standalone, i.e. not inside a web or file browser).
I guess this could be ported to QDesktopServices::openUrl though.

But even then: the use case is different -- IMHO kfile was only used by file 
managers and apps that embed some file management features
(kate, kdevelop, gwenview, okteta, k3b, calligra, etc.), while many more apps 
use the gui for kio jobs which is now provided by kiowidgets. So between that 
and the amount of added dependencies, I'm thinking that a separate library or 
framework might be better.

My current idea would be some middle ground: a new library in the kio 
framework, let's say KIOFileWidgets for lack of a better idea,
which still means porting KBookmarks away from KRun so that the kio framework 
as a whole can depend on kbookmarks.

Wait, this doesn't work, kbookmarks also uses KIOCore for KIO::iconNameForUrl
(which can find out protocol-specific icons and favicons, in addition to 
standard mimetype-based icons).

This is clearly because kbookmarks was written as part of kio, and with 
konqueror in mind. I guess the question is how generic we want KBookmarks to 
be, i.e. should it work without KIO altogether (at the expense of losing 
automatic favicon integration -- can still be done by the caller though, as 
long as the favicon doesn't change over time... as far as I can see from the 
code).

Help :)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5