On Fri, Oct 14, 2011 at 02:33:30PM +0200, David Faure wrote:
> On Wednesday 28 September 2011 20:00:49 Romain Perier wrote:
> > > The solution for KSaveFile is actually to split it up into two separate
> > > things.
> > > There's the class -- that one should stay.
> > > And there's a bunch of static methods which are unrelated to ksavefile
> > > and are all about backups. These should move into a new class or
> > > namespace, and for sure into new .cpp/.h files. And since that's not
> > > used inside kdelibs, we can always move it up together with kconfig
> > > itself for now.
> >
> > Ok, I will create a kbackups.{h,cpp} with a KDE5 TODO for now, we will
> > move it up with kconfig later.
>
> Great.
>
how is the split supposed to work? kbackups needs to be used by
ksavefile to be useful in any way, so you don't get rid of the
dependency.
note that there is a qt-only ksavefile (more or less) equivalent in
qtcreator/src/libs/util/ which i would like to import into qt.
speaking of qt creator classes ...
qtcprocess is a replacement for most of kprocess+kshell. i already have
a plan how to import that with a nice api.
however, it also implies importing stringutils.cpp's
abstractmacroexpander (which, of course, is the logical successor to
kmacroexpander), and i'm *much* less sure about that one, in particular
which concrete implementations should be put into qt. somebody feels
like pondering the api? ping me.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
