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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
