<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/117511/">https://git.reviewboard.kde.org/r/117511/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 12th, 2014, 11:12 a.m. UTC, <b>Kevin Krammer</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant for KDE applications porting, right?
IMHO this would fit best in an explicit porting framework</pre>
</blockquote>
<p>On April 12th, 2014, 11:22 a.m. UTC, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I don't want to put this in kdelibs4support because apps are supposed to port away from that and stop linking to it (thus avoiding "I link to everything"),
while they are supposed to keep the migration code for quite some time (not everyone will upgrade to 5.0 right away).
I don't think it makes sense to create yet another framework for one class. We are going crazy already with the number of frameworks and the small size of some of them.
So this leaves.... kcoreaddons, unless you have a better suggestion.
</pre>
</blockquote>
<p>On April 14th, 2014, 3:02 p.m. UTC, <b>Kevin Ottens</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">If that's really only about configuration, why not kconfig? That's where we have the config update tooling too. I'd find it less surprising there. If not strictly about configuration kcoreaddons seems the only sane option indeed.</pre>
</blockquote>
<p>On April 14th, 2014, 3:18 p.m. UTC, <b>Kevin Krammer</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">It is not just for config, there is already a function for returning "KDE data home".
However that brings up a new question from me: what about the other resource types?
If I were to port away from KStandardDirs I would like to be able to find old locations of my files and my access right now might not be to just config and data.
All my initial assumptions on porting were based on KStandardDirs still existing and finding the paths as usual.
My understanding is taht this is no longer true, i.e. because KStandardDirs behaves differently in the porting framework version.
So this "legacy dir support class" needs to be basically be KStandardDirs's user local implementation, e.g. allowing locate(), etc.</pre>
</blockquote>
<p>On April 17th, 2014, 6:10 p.m. UTC, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Which other resource types would be useful, exactly?
In my ~/.kde4/share, apart from "config" and "apps", I can only see (after cleaning up some useless cruft like applnk and mimelnk) "wallpapers" and "kde4/services" (due to a locally-defined searchprovider). Most "services" would be kde4 plugins that wouldn't make sense in kf5 though. I can move my custom searchproviders definitions by hand ;)
Anything else you guys have?
locate() is not very useful in the context of migrations: it searches at all levels, while we only want to care for files in the user's home. This is why most of the KStandardDirs logic doesn't really apply anymore. locateLocal() is basically what we're doing with QFile::exists(configHome()+"kfoorc").
"wallpapers" is however a good example of a resource type that is missing. So maybe we can make this based on resource strings again like kstandarddirs used to be, to support the resources that make sense without adding too much api... ?</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, locateLocal(), sorry. Didn't mean that resource lookup would need to search the hierarchy, just that it might be nice for migration code to be able to use the same resource identifiers.
That is if your application is currently doing something like
dirs.saveLocation(resourceType, fileName);
the respective migration code could find the file using an as close as possible syntax, e.g.
migration.saveLocation(resourceTpype, fileName)
or locateLocal()
I.e. right now application developers do not need to know how resource types are mapped onto subdirectories, so having the same kind of lookup helper would be nice.</pre>
<br />
<p>- Kevin</p>
<br />
<p>On April 12th, 2014, 11:01 a.m. UTC, David Faure wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer.</div>
<div>By David Faure.</div>
<p style="color: grey;"><i>Updated April 12, 2014, 11:01 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kcoreaddons
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Add class for finding the kde4 config and apps home dirs.
To help applications migrating to the kf5/qt5 directories.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>autotests/CMakeLists.txt <span style="color: grey">(7ab7bc43be1434ae93f7c77af90e41bbde5168ac)</span></li>
<li>autotests/kdelibs4migrationtest.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/lib/CMakeLists.txt <span style="color: grey">(1d17874f0da428bd34ea85ee98683f6fef620c81)</span></li>
<li>src/lib/util/kdelibs4migration.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/lib/util/kdelibs4migration.cpp <span style="color: grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/117511/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>