Re: KIOWidgets and KFile
On Sunday 29 September 2013 22:31:38 Sebastian Kügler wrote: On Sunday, September 29, 2013 20:50:28 David Faure wrote: 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). Maybe KBookmark could just be a small API backed by plugins? This would allow us to tackle bookmark provision the other way round, so we could - use different providers, thereby hook into what's there on a given system - use Nepomuk as a backend (we use Nepomuk for browser bookmarks in Plasma Active - hook into Chrome and Firefox bookmarks (at least read-only), we have code for this in KRunner - it'd let us get away for KBookmarks itself with minimal dependencies I imagine KBookmark being a more service-like thing, rather than a mechanism to store and read bookmarks. What you say makes sense, it sure sounds like a future direction for KBookmarks. I don't think this is the time for such work though, we want to release KF5 at some point, and this is major redesign. I think it has to be done as a separate lib, later. The main problem with that is that KBookmarks is actually both bookmark storage (using the XBEL format) and bookmark gui (add-bookmark dialog, bookmarks menu, toolbar). But well, in the case of plasma active you want neither one nor the other, so future efforts are indeed rather orthogonal to the current framework ;) -- 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
Re: KIOWidgets and KFile
On Sunday, September 29, 2013 23:49:15 Mark wrote: If i'm not mistaken, Dolphin is also using KBookmarks. Would your suggestion keep it alive for dolphin? Or would that mean creating a plugin that can read/write bookmarks to any file? It would work just like it is now. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KIOWidgets and KFile
On Monday, September 30, 2013 09:03:36 David Faure wrote: On Sunday 29 September 2013 22:31:38 Sebastian Kügler wrote: [...] I imagine KBookmark being a more service-like thing, rather than a mechanism to store and read bookmarks. What you say makes sense, it sure sounds like a future direction for KBookmarks. I don't think this is the time for such work though, we want to release KF5 at some point, and this is major redesign. I think it has to be done as a separate lib, later. The main problem with that is that KBookmarks is actually both bookmark storage (using the XBEL format) and bookmark gui (add-bookmark dialog, bookmarks menu, toolbar). But well, in the case of plasma active you want neither one nor the other, so future efforts are indeed rather orthogonal to the current framework Yes, quite so. I'd love to have it hooked into our existing bookmarks, but that wasn't easy at that time. Plasma Active's bookmarks are now a really thin thing atop Nepomuk. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KIOWidgets and KFile
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
Re: KIOWidgets and KFile
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
Re: KIOWidgets and KFile
On Sunday, September 29, 2013 20:50:28 David Faure wrote: 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). Maybe KBookmark could just be a small API backed by plugins? This would allow us to tackle bookmark provision the other way round, so we could - use different providers, thereby hook into what's there on a given system - use Nepomuk as a backend (we use Nepomuk for browser bookmarks in Plasma Active - hook into Chrome and Firefox bookmarks (at least read-only), we have code for this in KRunner - it'd let us get away for KBookmarks itself with minimal dependencies I imagine KBookmark being a more service-like thing, rather than a mechanism to store and read bookmarks. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KIOWidgets and KFile
On Sun, Sep 29, 2013 at 10:31 PM, Sebastian Kügler se...@kde.org wrote: On Sunday, September 29, 2013 20:50:28 David Faure wrote: 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). Maybe KBookmark could just be a small API backed by plugins? This would allow us to tackle bookmark provision the other way round, so we could - use different providers, thereby hook into what's there on a given system - use Nepomuk as a backend (we use Nepomuk for browser bookmarks in Plasma Active - hook into Chrome and Firefox bookmarks (at least read-only), we have code for this in KRunner - it'd let us get away for KBookmarks itself with minimal dependencies I imagine KBookmark being a more service-like thing, rather than a mechanism to store and read bookmarks. Hi Sebas, If i'm not mistaken, Dolphin is also using KBookmarks. Would your suggestion keep it alive for dolphin? Or would that mean creating a plugin that can read/write bookmarks to any file? Cheers, Mark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
