> On March 17, 2013, 2:05 p.m., Vishesh Handa wrote: > > But why? KFileMetadataReader and the other KFileMetadataStuff should just > > be marked as deprecated. Why are we porting them? We already have better > > alternatives in the nepomuk-widgets repository. > > Martin Tobias Holmedahl Sandsmark wrote: > Because it was a simple user of KProcess. > > But if we can just deprecate the whole class (and move it into > kde4support, I guess?) that's better. :-) > > Vishesh Handa wrote: > As far as I'm concerned it can be deprecated. We can definitely deprecate > KFileMetadataWidget which is the only user of this KFileMetadataReader. > Dolphin now uses Nepomuk2::FileMetadataWidget. The only slight problem might > be that Dolphin still likes being "Nepomuk Optional" at compile time. So they > still use it. Maybe we should talk to Frank about this? > > The only other class is KFileMetaInfo, which uses Strigi directly. I > still have to write a replacement for that in Nepomuk. > > @David: I think we talked about this in Berlin. Should we deprecate > KFileMetadataWidget? > > Kevin Ottens wrote: > Yep, that's what we discussed in Berlin, this one could move to > kde4support indeed. > > Frank Reininghaus wrote: > I think we'll keep the "Nepomuk optional for building Dolphin" thing in > KDE 4.x. Accoding to feedback I got from users, some people like to build > Dolphin with as few dependencies as possible. But for Frameworks, I don't > really see a point in it. We'll depend on many different frameworks anyway, > so replacing the parts of kdelibs that are needed for KFileMetaDataWidget by > nepomuk-core and nepomuk-widgets has hard, non-optional dependencies looks > reasonable to me. > > But then I wonder why we should even bother to keep KFileMetaDataWidget > at all? Shipping code that is unmaintained, even if it is "just" in > kde4support, does not look like a good idea to me. Couldn't it just be > removed? Porting to Nepomuk's widget is simple enough, and if people feel > that this makes porting apps to Frameworks too hard, one could still put a > simple header file into kde4support that makes KFileMetaDataWidget a typedef > for Nepomuk's widget.
We keep them around to make it easier for people to port. It's better than breaking everyone builds in one go for a gazillion of dependencies. kde4support is really a porting tool. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109538/#review29377 ----------------------------------------------------------- On March 17, 2013, 1:26 p.m., Martin Tobias Holmedahl Sandsmark wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/109538/ > ----------------------------------------------------------- > > (Updated March 17, 2013, 1:26 p.m.) > > > Review request for KDE Frameworks, kdelibs, David Faure, and Vishesh Handa. > > > Description > ------- > > KFileMetaDataReader currently uses KProcess, this ports it to use QProcess > instead. > > > Diffs > ----- > > kio/kfile/kfilemetadatareader.cpp 88cadaa > > Diff: http://git.reviewboard.kde.org/r/109538/diff/ > > > Testing > ------- > > it builds. > > > Thanks, > > Martin Tobias Holmedahl Sandsmark > >
