KIOWidgets and KFile
David Faure
faure at kde.org
Mon Sep 30 07:03:36 UTC 2013
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, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
More information about the Kde-frameworks-devel
mailing list