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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel