KIOWidgets and KFile

[Kevin Ottens]

Hello,

On Sunday 29 September 2013 20:50:28 David Faure wrote:
> 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.

IIRC we said "if they have similar dependencies"... it's apparently not the 
case.
 
> 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

I think that makes it clear that they should stay separated then. That said 
some of those dependencies could be trimmer a bit (I'm thinking about 
KNotifications and Solid mainly).

I don't think the notification is useful, and there might be a chance to 
create a "solid widgets" (to be investigated).

> 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.

Sounds like it.

> 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.

KFileWidgets no? It uses KIO but it doesn't really sounds like part of KIO, as 
you said it contains blocks for file management features.

> 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 :)

Personally, I think if should work without KIO altogether. I'm not sure I'm 
following the favicon integration you've mentioned.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130929/85bf759f/attachment.sig>