bruns added a comment.
In D19098#415713 <https://phabricator.kde.org/D19098#415713>, @astippich wrote: > In D19098#414973 <https://phabricator.kde.org/D19098#414973>, @bruns wrote: > > > In D19098#414729 <https://phabricator.kde.org/D19098#414729>, @astippich wrote: > > > > > It already does at two different places, because it fuses different information into a single QMap later on (xattr, file size etc...) > > > https://phabricator.kde.org/source/baloo-widgets/browse/master/src/extractor.cpp$65 > > > https://phabricator.kde.org/source/baloo-widgets/browse/master/src/filefetchjob.cpp$62 > > > > > > This can be done by using a KFM::PropertyMap directly, and adding property types for the UserMetaData (tags, comment, rating). Note, the strings returned by PropertyInfo::name() are not shared ... > > > It is not only xattr, also everything from kfileitems{group,size,owner...}. Adding these as property with no users in KFileMetaData does not seem clean. > Also, you would have to construct the properties from the name. Why not use the names directly then? Changing everything to a PropertyMap requires a rewrite of large parts, and I certainly will not rewrite baloo-widgets right now. > This is just for a small cleanup. It is also not clean to expose an interface in KFileMetaData which is only used by baloo-widgets, and **internal** to baloo-widgets. If you want to consolidate the implementations, combine the two implementations **inside** baloo-widgets. REPOSITORY R286 KFileMetaData REVISION DETAIL https://phabricator.kde.org/D19098 To: astippich, bruns, ngraham Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
