In D25494#592751, @bmwiedemann wrote:

This should work fine with a producer GNU-tar >= 1.28

We use the option only when SOURCE_DATE_EPOCH is set, and we assume that a recent enough tar is available then. Basically we say that if reproducible builds are desired, the proper tools should be available.

I would really like to have this in 5.5, so if there's no review by next weekend I'll merge as is.

No further need, thanks. I got the assist in your previous reply already I was looking for :)

So no urgent need for me to revisit the code?

This should work fine with a producer GNU-tar >= 1.28 , but what will be the consumer of the tar file?

In D25494#592508, @kossebau wrote:

No insight myself, but would trust you you know what you are doing here :) and it also matches what I just read on https://reproducible-builds.org/docs/archives/

No insight myself, but would trust you you know what you are doing here :) and it also matches what I just read on https://reproducible-builds.org/docs/archives/

Thanks for having had a look again, and confirming that I was not seeing things wrongly half-asleep still :) I am about to touch this code in some days anyway, and would twist things then as needed.

Difficult to wrap my head around this, so much later!

I just came across this logic (for reasons) and wonder if the logic does what you intended with the patch:
given the const auto canonicalPathToCheck = checkPathIsFile ? pathInfo.canonicalFilePath() : QStringLiteral("");, when checkPathIsFile is false, canonicalPathToCheck is an empty string.

add some tests

Looks good :)

fix: const are case sensitive
improve tests

Looks good :)

No problem.
You can use hugues@mitonneau.me
Thanks

Sorry this took so long! I have it ready to merge, just need to know the email you'd like me to use for the commit author

This new patch re-implement KDevelop::BasicRefactoring::applyChangesToDeclarations and KDevelop::BasicRefactoring::applyChanges in Php::Refactoring.

No, I don't have commit access.

I appreciate the effort, but I think this is the wrong approach. I really think the $ is part of the variable.

Hi! Sorry, I was just really busy and didn't have time to take a closer look.

Is there something wrong with the second diff ?

Thanks!

Looks good to me :)

Can someone else land the patch? I don’t think I have the required permissions.

Good enough as for me.

@starbuck Thanks. Tried a first link with https://store.kde.org/p/1334948 and adapted the KNSRC file of KDevelop, worked as wanted.
(well, once I added a workaround for some strange KNewStuff behaviour on archive extraction, cmp. 39a8a51d33 ;) )

I added the new category now here:
https://store.kde.org/browse/cat/606/order/latest/

Thanks for the reply, sounds good.

We certainly can add a new category = API Documentation QCH Files.
Linking files are possible via "Add url", simply pointing to a file as endpoint.
I'm not sure what needs to be done client-side, so Dan can likely help there.
I just need to know what the category name should be and when to add it.

@starbuck @leinir H. Please see "Question to store.kde.org managers" (but better to read first whole text to get the context). I would like to sort this out before end of year.

Move variadics from IndexedContainer to ArrayType

I agree that conceptually this should be moved to (or supplemented by) the actual language plugins, but also agree that this might be out of scope for this change.
As far as the PHP changes are concerned this is fine with me. However, I'd prefer those patterns to be unit tested and not just documented in comments.
Could you have a look at adding those tests?

Conceptually, this looks fine. However, like this we end up with two different descriptions of "Array of" types in the navigation popups.
While this shows integer arrays as int[], for variadics it will show array of (int). I think at the very least both should be displayed the same.

Rebased for the 5.4 branch. Still working perfectly for me, without noticeably slower reaction times on local filesystems.

Rebased for the 5.4 branch.

I'm not suggesting to not create a preamble at all, but to create it only when we **know** it is needed.

I've just stumbled into a case where I would need -stdlib=libc++, which this change would solve.

I still think this is the right change, but if there is no consensus I will implement @mwolff's suggestion. That would certainly be an improvement, but it doesn't really solve my problem. I'm currently working on Clang and have around 6 files open, which is really not a lot. I haven't changed any of them. The result:

e.g. look at https://doc.qt.io/archives/qt-4.8/qcolor.html#predefined-colors

hey! can you also show a screenshot of PHP or Qt documentation showing? these can contain arbitrary HTML and sometimes even contain colored text that expects to be shown on bright backgrounds which would break with this patch. At least that was the case years ago when I worked on this the last time.

Would it be possible and interesting to reuse code highlighting for the code quote ?

With the patch :

thanks, applied to 5.4

done now, thanks a lot!

I'll commit this using QFileInfo instead of going through QDir.

Scrapping this for now, since I have a few improvements on this, but it needs to be reworked. Ill make a PR with updated version on GitLab instance.

I would like to get this merged in if possible. The work discussed for flushing out future deadlocks should also be done, but deserves its own ticket.

Thanks @kossebau for the review. I will create a review request at the kirigami repo.

I would propose though to add this template to the kirigami repo though, so it is also available to people using the kapptemplate tool and using a plain text editor (e.g. Kate).
There is the ECM macro kde_package_app_templates from https://api.kde.org/ecm/kde-module/KDEPackageAppTemplates.html for this purpose.

Given the big KDevelop & Kate share plugins stuff never took off, I think we shall keep them just in kate.git, this will allow to do even more "experimental" stuff in the future like having some extra interfaces for Kate specific stuff that doesn't need to keep BC.

• outputfilteringstrategies: Removed unused include KDir

• Created private implementation of ScriptErrorFilterStrategy
• executescript: fix setting working directory to OutputView

In D22854#517776, @apol wrote:

Have you reflected on what users need changing or we're just adding this because it's possible?
I'm not opposing having this, but if something can be improved, I'd improve it for everyone first.

Have you reflected on what users need changing or we're just adding this because it's possible?
I'm not opposing having this, but if something can be improved, I'd improve it for everyone first.

This functionality would be great.

Landed as https://invent.kde.org/kde/kdevelop/commit/12bf83b0abd064f22c0a137b0ec7123f155c3097

In D23321#516037, @apol wrote:

In D23321#516025, @kossebau wrote:

In D23321#516020, @apol wrote:

Don't mention the ps desktop file as the executable

It was mentioned on purpose though, cmp. commit message of ab22ca659cf337fc1de01d69b0ced949156f01e5 (result of discussion on KDevelop with @flherne )

The reason there is weird. When you press "launch" on the software center you expect to get the IDE, not an empty list of sessions.

This patch looks like it should work as intended to me :)