| sdepiets |
| Localization |
I set the source directory in lokalize to <src-dir> and tried to open a
file located in <src-dir>/xxx/yyy/zzz.cpp, but lokalize couldn't find
the file.
The problem is fixed with this patch by first searching the file under
the path formed by the source directory and the relative file path
from the po file.
CCBUG:403743
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
is src-dir the app source dir? or?
When you say "tried to open" what is it? from the command line? from the tree view? Doing file open? from somewhere else?
yes, in the code this path is given by 'dir' and is choosed by the user.
When you say "tried to open" what is it?
from the command line?
no, inside lokalize
from the tree view?
Doing file open?
no
from somewhere else?
I selected a translation in the translation units window and clicked on the related file path in the unit metadata window (see https://wiki.mageia.org/mw-en/images/a/ae/Lokalize_mainwindow.png)
I don't think this is the right fix.
Inside that lambda Project::instance()->sourceFilePaths() already should give you that dir you just set via
Project::instance()->local()->setSourceDir(dir);
The problem as far as i see it is that Project::sourceFilePaths() starts the job and then returns, most probably before the job finishes.
Given how that API is don't see how that ever worked, probably it should just call fillFilePathsRecursive without a runnable?
Because I'm not familiar with lokalize code base: Can someone fix this issue in the mentioned way ?
I tried reproducing this bug, but it just works fine for me in the current Applications/19.04 branch
https://i.imgur.com/9B9fIPs.gifv
Is this what you're describing or is it something else?
In this review request I wrote that the bug is triggered by clicking on a source url containing sub dirs. I don't remember exactly which file I used, but it should also be triggered by entries from https://websvn.kde.org/*checkout*/trunk/l10n-kf5/de/messages/kdesdk/umbrello.po?revision=1534318&content-type=text%2Fplain
I haven’t tested the fix myself, but I can confirm the issue on my machine (on a path with subdirs). I recently had this issue with 0 A.D., I thought it might be because of the :<line number> part but Albert’s walkthrough also has that, so maybe it is subdirectories (mine was 4 or more levels deep).
I seldom use this feature (i usually search code on github, more on that later) but I recognize it's not ideal in its behavior.
static QStringList filters = QStringList(QStringLiteral("*.cpp"))
<< QStringLiteral("*.c")
<< QStringLiteral("*.cc")
<< QStringLiteral("*.mm")
<< QStringLiteral("*.ui")
<< QStringLiteral("*rc");I'm ok with that patch, I don't see any negative side effect and it will be faster to open a file when the selected source directory is the project root (not a higher level). Feel free to push and add ".xml" to the filter as well.
NB: I plan to make this code search function a little bit more attractive and efficient once we migrate to gitlab, or potentially to have a more generic search function in code with github so that it can be put in the projects' parameters and doesn't benefit only kde.
In the review request I wrote that I used a cpp file, not an xml file. I linked to an available screenshot to show the related dock window. :-)
those files are not indexed. See src/project/project.cpp
This means that xml files and other file types that are not included in the filter are not accessible without this patch (and with this patch, but editor support not enabled )?
Does this result in an error message that this file type is not supported? If not, I think a little more work is needed here to inform the user.