Bug 353642

This change is in kio master, but not in 5.15. It will be in 5.16.

The ideal solution would be to skip the installation of these files in the frameworks branch of lib/konq in kde-baseapps if the installed kio version is > 5.15. Thus would not have any effect until the version number us increased in kio master though.

Moreover, the frameworks branch of lib/konq has not been released AFAIK, and I think it never will be. Nevertheless, this should be solved, but I am unable to do anything about this in the next two weeks (and any change won't help before the kio version is increased).

Note that simply removing the files from lib/konq might be dangerous because some distros might package and release its frameworks branch in order to work around the context menu issues that the kio commit fixes.

> Moreover, the frameworks branch of lib/konq has not been released AFAIK, and I think it never will be. Nevertheless, this should be solved, but I am unable to do anything about this in the next two weeks (and any change won't help before the kio version is increased).

It's not the frameworks branch though. The Qt4 version, as released with 15.08, also installs to $PREFIX/share/templates.

> The ideal solution would be to skip the installation of these files in the frameworks branch of lib/konq in kde-baseapps if the installed kio version is > 5.15. Thus would not have any effect until the version number us increased in kio master though.

This is an approach we had for I think it was kglobacceld (moved from plasma to framework) which still causes major headache as we need to communicate that to distros so they don't ignore us, and then the grand majority of distros need to go back and adjust their packaging and rebuild the binaries. 

> Note that simply removing the files from lib/konq might be dangerous because some distros might package and release its frameworks branch in order to work around the context menu issues that the kio commit fixes.

Yes. So. What if, and I am just throwing this out here because I only had one cup of coffee yet, so it might be utter nonsense ;)... what if the kio templates installed to $PREFIX/share/kio5/templates instead? kde-baseapps (kdelibs) could potentially still be released with applications 15.12 and not conflict with KIO since the paths are different, and lib/konq (frameworks) could release whenever ready and depend on suitably high enough KIO version to get the templates from KIO rather than install its own. Additionally putting it into a kio5 dir means a kio6 (kf6) in the future will not be interfering with the kf5 files and we won't have a conflict there.

As for distributions pulling random snapshots of libkonq, I think we are best served ignoring this, or at least advising that building a temporary workaround based on the KIO change is the best way for distributions to go about this.

Sorry for the late response. I was on holiday without my laptop :-)

(In reply to Harald Sitter from comment #2)
> > Moreover, the frameworks branch of lib/konq has not been released AFAIK, and I think it never will be. Nevertheless, this should be solved, but I am unable to do anything about this in the next two weeks (and any change won't help before the kio version is increased).
> 
> It's not the frameworks branch though. The Qt4 version, as released with
> 15.08, also installs to $PREFIX/share/templates.

OK, thanks for the explanation! I had assumed that this Qt4-based stuff from kde-baseapps is installed to some other location, but I see that this is not necessarily the case.

> Yes. So. What if, and I am just throwing this out here because I only had
> one cup of coffee yet, so it might be utter nonsense ;)... what if the kio
> templates installed to $PREFIX/share/kio5/templates instead?

For me, this sounds reasonable. David, what do you think?

Note: the same problem most likely applies to the templates for the "Create New..." menu, which are provided by kde-baseapps/lib/konq in KDE SC 4.x and have been copied to KIO in https://git.reviewboard.kde.org/r/124983/

Using a different dir is indeed the solution. However
1) I would name it more generically so that users installing templates don't have to redo it again for kf6. Maybe kde-newfile-templates?
2) We need to make sure to adapt everything that was assuming share/templates.
This includes kdelibs4support/src/kdecore/kstandarddirs.cpp (where the string table needs to be regenerated as per the comment, after changing a string - I can do this part once we agree on the name), KDE4_TEMPLATES_INSTALL_DIR in kde4support, TEMPLATES_INSTALL_DIR in ECM,
the code in kio obviously, etc.

Not sure what you mean by "the same problem", I thought *that* was we were talking about here, the templates for the "create new" menu.

(In reply to David Faure from comment #4)
> Not sure what you mean by "the same problem", I thought *that* was we were
> talking about here, the templates for the "create new" menu.

Yes, you are right, sorry for the confusion. It seems that I misread the report first (maybe because I read it on a far too small screen) and somehow got the impression that it is about the konqpopupmenuplugin.desktop file which I added in https://quickgit.kde.org/?p=kio.git&a=commit&h=4b24b70c93523c5bc56c90c04a5a666331e96a1b

> Using a different dir is indeed the solution. However
> 1) I would name it more generically so that users installing templates don't
> have to redo it again for kf6. Maybe kde-newfile-templates?

Sounds fine. But if I understand Harald correctly, then it would have to be kio5/kde-new-file-templates or kde-new-file-templates5 or something else that contains a version number, in order to prevent that we get the same kind of conflict when there will be a "KIO 6.x". Either solution is fine for me.

> 2) We need to make sure to adapt everything that was assuming
> share/templates.
> This includes kdelibs4support/src/kdecore/kstandarddirs.cpp (where the
> string table needs to be regenerated as per the comment, after changing a
> string - I can do this part once we agree on the name),
> KDE4_TEMPLATES_INSTALL_DIR in kde4support, TEMPLATES_INSTALL_DIR in ECM,
> the code in kio obviously, etc.

Yes, that's right. I don't have much time right now, but I'll try to check which modules contain code that needs to be adjusted. If there is something in non-frameworks locations, like Plasma or KDE Applications, then we might have another problem that is very hard to solve cleanly :-(

> Sounds fine. But if I understand Harald correctly, then it would have to be kio5/kde-new-file-templates or kde-new-file-templates5 or something else that contains a version number, in order to prevent that we get the same kind of conflict when there will be a "KIO 6.x".

Exactly. We'd otherwise conflict between kio5 and kio6. Since we probably want a soft transition from 5 to 6 we ought to avoid conflicts.
On a from-source-install level this isn't a big deal (except for maybe losing translations if kio5 is installed/updated after kio6 is installed). Since binary distributions have builtin mechanisms to prevent one package from installing the same files as another package, for distributions this constitutes a file conflict that needs to be solved by a human by either packaging measures or creative patching of kio5.

That being said, not having a versioned path probably would be handy. Of the top of my head there's two ways this can be done to make everyone happy:

1) create a standalone tarball/repo which is tier0 as it were and only installs the templates. Between 5 and 6 its v5 incarnation can simply be dropped for v6 since they'd be interchangeable.

2) kio5 installs to PREFIX/share/kde-newfile-templates *UNLESS* cmake is run with -DNO_INSTALL_TEMPKATES=ON. This in the end still requires a human to do something to deal with this for binary distributions, but they'd have a very clear path of how to do that (either rebuild kio5 without the dir, or package such that the dir doesn't conflict).

Option 1 would be preferred seeing as it avoids the problem entirely by being fully interchangeable between 5 and 6. 

>> 2) We need to make sure to adapt everything that was assuming
>> share/templates.
> If there is something in non-frameworks locations, like Plasma or KDE Applications, then we might have another problem that is very hard to solve cleanly :-(

Tried lxr, but failed to come up with a suitable enough query :(. I think a very nifty grep would be the most feasible approach to this. Other than that we could have an opt-in kio cmake switch that installs a symlink from share/templates to share/kde-newfile-templates to provide a compatibility gap closer where needed; not sure that would be all too useful though.

(In reply to Harald Sitter from comment #6)
> That being said, not having a versioned path probably would be handy. 

Yes, I agree. A version in the path bears the risk that stuff will break if the version changes, and the path is not updated everywhere.

> 1) create a standalone tarball/repo which is tier0 as it were and only
> installs the templates. Between 5 and 6 its v5 incarnation can simply be
> dropped for v6 since they'd be interchangeable.

I didn't even know that a tier 0 exists :-)

This might be a solution. It will require some effort though, and I'm not sure if it could be done before the next frameworks release.

> 2) kio5 installs to PREFIX/share/kde-newfile-templates *UNLESS* cmake is run
> with -DNO_INSTALL_TEMPKATES=ON. This in the end still requires a human to do
> something to deal with this for binary distributions, but they'd have a very
> clear path of how to do that (either rebuild kio5 without the dir, or
> package such that the dir doesn't conflict).

This is probably not a good idea. A user who notices the lack of the menu items cannot know if the packager decided to set this option, and for the user, it would be far from obvious how to resolve the problem.

> >> 2) We need to make sure to adapt everything that was assuming
> >> share/templates.

The more I think about it, the more afraid I get of changing the path in multiple modules, especially changing it shortly before the planned tagging of 5.16 on November 7. Considering the (for me totally unexpected) trouble that this apparently simple fix caused, I am not too optimistic about the outcome of such an operation. I will be away for much of next week, so I might not be able to do much about any possible problems.

Unless anyone has a very clever idea or is brave enough (and has enough spare time) to proceed with one of the suggested approaches, I see only two quick and easy solutions:

1. Revert the commit that adds the templates to KIO.

2. Rename the files that KIO installs, maybe by prepending their names with "New". This will not solve the problem with a possible future transition to KIO 6.x though (unless we include the version number in the file names).

I don't think this is worth a separate tarball.
Let's just have a 5 in the name, and possibly an API for locating templates, so 5->6 will be easy.
And for user templates (under $HOME), we should not have a version number, so 5->6 won't lose their templates.

An additional idea, in line with Christoph Cullmann's recent work: shipping the templates from kio as part of the library using a .qrc file, to simplify deployment. It also solves a conflict such as this one ;) I'll look into that.

-> https://git.reviewboard.kde.org/r/125928/

Git commit 6ec29b03e4433c93bf5c2e5da977d019440020a9 by David Faure.
Committed on 03/11/2015 at 09:44.
Pushed by dfaure into branch 'master'.

Ship the "new file templates" in the kiofilewidgets library using a .qrc

This solves the conflict with kde-baseapps 15.08.x, and simplifies deployment
on Win/Mac.
REVIEW: 125928
Change-Id: Id4f9e364ceeea6b1b93910aa100ff22ce3fd76a7

M  +2    -2    autotests/knewfilemenutest.cpp
M  +0    -1    src/CMakeLists.txt
M  +2    -0    src/filewidgets/CMakeLists.txt
M  +13   -3    src/filewidgets/knewfilemenu.cpp
D  +0    -20   src/new_file_templates/CMakeLists.txt
A  +18   -0    src/new_file_templates/templates.qrc

http://commits.kde.org/kio/6ec29b03e4433c93bf5c2e5da977d019440020a9

So, there remains a conflict with libkonq frameworks-branch only: /usr/share/kservicetypes5/konqpopupmenuplugin.desktop

Thank you very much for taking care of this issue, David!

(In reply to andreas.sturmlechner from comment #12)
> So, there remains a conflict with libkonq frameworks-branch only:
> /usr/share/kservicetypes5/konqpopupmenuplugin.desktop

Thanks for reporting this. Proposed patch to fix this in the frameworks branch of kde-baseapps: https://git.reviewboard.kde.org/r/125995/

Git commit b919367c8550024aca53c7f4d219a5b4c3317964 by Frank Reininghaus.
Committed on 11/11/2015 at 19:16.
Pushed by freininghaus into branch 'frameworks'.

Only install konqpopupmenuplugin.desktop if the KF5 version is < 5.16

Since version 5.16, this file is installed by KIO.

REVIEW: 125995

M  +8    -1    lib/konq/src/CMakeLists.txt

http://commits.kde.org/kde-baseapps/b919367c8550024aca53c7f4d219a5b4c3317964