• Free unneeded struct pointer

Oops. Stable branch.

I think this refactor is only in master anyway?

Thanks

Oops. Stable branch.

@Gregor: That the terminal does not get focus on show was a regression in konsole part and should be fixed. I don't think there is any action item left for now.

"Show/hide Terminal" should definitely move focus to the terminal when the terminal first opens. If it doesn't, that's a bug that should be fixed.

I am a little late but I would like to add something. In Kate - at least for me - the by far most used action is "Focus/defocus Terminal". This function also opens the terminal if it was not open before.

• Only rename methods

TBH the "increased maintenance burden" argument doesn't sit well with me. Every new feature or net addition to the code adds to the maintenance burden. In and of itself, this is not a problem; you have to weigh it against the value brought by the addition or change in question. We should be thinking about whether this feature is worth adding. If we find that it is, we'll find ways to offset or reduce or deal with the increased maintenance burden, the way we do for all net code additions.

Not in the current version, I'm afraid.

Go for it

Do you mind splitting this into a renaming-only patch and another patch for the changes to the logic?

@elvisangelaccio?

Follow up from D22594: https://phabricator.kde.org/D22594?vs=on&id=67500&whitespace=ignore-most#inline-139176

Clean up code and fix localization string puzzles

Yeah I'd still like to give this a shot.

Rebase

In D25651#570894, @ngraham wrote:

This doesn't seem to work for me. When I click on the new menu item, the view refreshes but the item I told it to forget it still visible in the ioslave.

ping @asturmlechner

@ngraham Do we want to get this reviewed and merged ?

Name should be more clear, marking as done for now.

String role was not the best option. Function's comment was also wrong.

oh ok, I will start with some other issue then.

I already submitted a patch: https://phabricator.kde.org/D25878

Do we need to make changes in code to remove this ambiguity? I want to start working with KDE softwares.

In D25741#579933, @gvgeo wrote:

As for the multicase, the are still these cases that don't benefit (if I'm not wrong) from the natural sorting and case insensitive:

AccessTimeRole
PermissionsRole
ImageDateTimeRole
OrientationRole
WordCountRole
DurationRole
BitrateRole
AspectRatioRole
FrameRateRole

The rest should not matter.

NoRole
IsDirRole
IsLinkRole
IsHiddenRole
IsExpandedRole
IsExpandableRole
ExpandedParentsCountRole
RolesCount

It is possible to use stringRolesTrue, but already have the switch.

default: {
    const QByteArray role = roleForType(m_sortRole);
    const QString roleValueA = a->values.value(role).toString();
    const QString roleValueB = b->values.value(role).toString();
    if (!roleValueA.isEmpty() && roleValueB.isEmpty()) {
        result = -1;
    } else if (roleValueA.isEmpty() && !roleValueB.isEmpty()) {
        result = +1;
    } else if (stringRolesTrue(m_sortRole)) {                      <------------
        result = stringCompare(roleValueA, roleValueB);  
    } else {
        result = QString::compare(roleValueA, roleValueB);
    }
    break;
}

So is this (the feature not the current patch) going to be accepted or not?

As for the multicase, the are still these cases that don't benefit (if I'm not wrong) from the natural sorting and case insensitive:

Fixed style.
Move 'roleLessThan' part in lambda code.

Natural sort problem was indeed locale problem. The bug was irrelevant, removed from summary.

Add funciton roleLessThan. Kept 'nameLessThan' instead of changing it to 'stringLessThan'
Add funciton stringRolesTrue. To compare multiple values to m_sortRole
Added stringRolesTrue in KFileItemModel::sort for parallelMergeSort. To speed up now that have natural sorting.

ping @sourabhboss
That's a nice change, not much work still needed IMO

Good idea, I'll do that next.

In D25416#578195, @elvisangelaccio wrote:

LGTM otherwise.

In T11663#213940, @squeakypancakes wrote:

You have a lot more room to work with if you want to put the full path into the split title.

In T11663#213940, @squeakypancakes wrote:

You have a lot more room to work with if you want to put the full path into the split title.

In T11663#213152, @joricke wrote:

In T11663#213094, @manueljlin wrote:

"Keep a single URL Navigator in the toolbar, but change it dynamically to show the path for the active split view" is probably the best option

The issue with that approach is that you can never be 100% sure you're in the right directory on your inactive split view. A minor issue, yes, but an issue nonetheless.

• Rebase and adapt tests

• Use QStringLiteral

...Now with more accuracy

Make the comment accurate

Sure, no rush.

Fair enough.

LGTM otherwise.

I have tested the patch on tags, it works.
It does not break existing tests.

Makes sense to me.

(forgot to paste more details about the archeology: kdelibs commit d3a9f1037d1410, bugs 213799 and 219547)

Thanks for your well thought-out reply.
The usual solution to 1. and 2. is rather "call canonicalFilePath, and if the return value is empty, use the original path". We do this in many places. But indeed this means, if a non-existing dir gets created later, it won't be canonicalized. But that's not worse than the current situation, and not an issue for the problem at hand (different use case, could be fixed in KDirWatch if needed one day).

And tests fail with or without this patch. see bug 413660.

In favor of D25891

For reference I had a similar patch https://phabricator.kde.org/D25323 and a potential fix in KSyntaxHighlighting https://phabricator.kde.org/D25328

Clarify updateTagSelector logic

We can thank Qt for deprecating QHash::iterator::operator-- which allowed Laurent to catch this :-)

Ping ?:)

Fix other code

See D25891 (not tested by myself, only saw it) for another approach to this. So seems in general setTheme() always needs an explicit rehighlight() afterwards (but why only in some cases)?
AbstractHighlighter::setTheme claims that "Subclasses can re-implement this method to e.g. trigger re-highlighing or to do general palette color setup. ", so SyntaxHighlighter actually is missing to comply here?

performance improvement: only do one round of highlighting (skip the one run in the constructor of QSyntaxHighlighter)