keditfiletype binary

[David Faure]

Hi, sorry for not getting around to replying to this earlier.

On Tuesday 29 April 2014 17:19:20 Jonathan Riddell wrote:
> keditfiletype is in kde-cli-tools in workspace category and used to be in
> kde-runtime. I've submitted a review to rename it for coinstallability and
> noticed that it gets used in frameworks in a couple of places
> 
>   frameworks/kio/src/widgets/kpropertiesdialog.cpp
>   frameworks/kwidgetsaddons/src/kmimetypechooser.cpp
> 
> should it be moved to frameworks and where abouts?
> 
> https://git.reviewboard.kde.org/r/117884/ rename review

Right, we currently treat it as an integration point with the workspace....

It's possible to imagine scenarios where this would break: using dolphin in 
gnome or Mac or Windows, bringing up the properties dialog for a file, 
clicking on the "File Type Options" button (to change icon or associated 
app)... nothing happens if keditfiletype isn't installed.

Moving keditfiletype to KIO means in fact moving the whole kcm_filetypes
there, since they share the same code (both are built by the "keditfiletype" 
directory currently in kde-cli-tools).

>From a maintenance point of view, moving it makes a lot of sense too. It was 
always awkward that when working on the mimeapps.list stuff I had to do the 
reading part in kio and the writing part (including unittests etc.) in kde-
runtime (= much potential for breaking a unittest when making a change in 
kio).

I'm still no good with moving code in git and preserving history, who could do 
this for me?

Looking at Aurelien's comment in RR 117884 this would only leave the issue 
that KMimeTypeChooser from kwidgetaddons would still have a runtime dependency 
on KIO, but we can just remove the "edit mimetype" button if keditfiletype 
isn't present (i.e. ignore the "EditButton" flag, the code already makes this 
an option). I can take care of that.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5