New patch, same purpose, active principle as outlined in the reopening comment.

Re-opening because I found an actual flaw in KDevelop after noticing that context menu duplication still occurred when only the active view receives the aboutToShowContextMenu signal.

I'm late to this party, but what about projects where the user generates the missing compile_commands.json file manually, e.g. via the compiledb utility? Does this change mean clazy analysis is now possible only for projects where you do NOT need to generate that json file by hand?

Btw., the 2 nullptr in the disconnect can be left out, or?

Something side-ways related: I went down this hole because cmake's generate_export_header failed because of an unsupported flag that was added.
Regardless of how we implement things here, shouldn't there be something like ecm_generate_export_header which empties CMAKE_CXX_FLAGS temporarily because calling CMake's version and then restores the variable? There's no feedback at all in this function, the generated export header just contains dummy EXPORT macros, leaving the user to wonder why the linker fails. Or should the visibility flags also be set conditionally, after setting all other compiler options?

Thus these places need to be turned into:

  ...
  if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS "3.8")
  elseif(CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS "8.1.0")

A simpler version, setting CMAKE_<LANG>_FLAGS directly (also fixes a persistence error in my previous implementation).

Friedrich W. H. Kossebau wrote on 20181115::17:41:58 re: "D16882: [KDevelop/Shell] prevent duplicate added contextmenu actions"

_If_ it is found that the root bug is in KTextEditor, sure.

Sorry to say, but you want to add the feature, so you would have to scratch this itch

So multiple contextMenu signals arrive in Kate too except they don't have any visible consequence.
Let's see what the KTextEditor devs have to say about this. I'd rather stay away from getting too familiar with that framework, KXMLGUI even more.

Please, let's find the root causes and fix things at the base instead of adding such

Patch cleaned up, stripped the LevelDB and Kyoto backends that never satisfied me.
I did leave the original file-based storage backend, not because I think it has to be preserved if this ever gets in but to provide a quicker way to compare performance (and behaviour if ever someone testing this runs into issues).

Aaron's last suggestion made me realise I forget a few things when porting the patch back to using QSocketNotifier.
The shutdown procedure was intended to (and now does) include closing the signal pipe, verifying the descriptor before writing to it makes sense. So does handling failure there by re-raising the signal with the default handler.
I thought it would be even more robust to move the actual write into the if and check whether it succeeded, after all we want to be certain that these signals are always handled.

This adds a safety against a race-like condition I've seen happen once in KDevelop.
It may not be required to make m_mWin a QPointer but it seemed sensible to do.

Ah, yes, I'll have to remember to clean it up and keep only the LMDB backend.

updated as requested.

Don't worry, the commit message would have looked like that.
Or rather, it will say

Don't worry, the commit message would have looked like that.

Done by someone else by now.

refactored for master/head

I'm a bit confused... I thought KDevelop had much more advanced plugins/features for this? What does KDevelop need this old plugin for? Non-C/C++ languages or what?

Merged in changes from an older attempt I forgot about (apologies!).

Exactly what is the feature we're talking about?! I highly doubt that Qt will NOT show the popup window with the what'sthis text when you request it via

I actually like the feature as a way to provide more complete (and better formatted?) contextual help for UI aspects that could use it, without obliging the user to open the handbook. AFAIK you have to find the relevant paragraph or section in there yourself, so it's less than ideal in terms of optimising productivity. Handbooks *are* important ("RTFM"...) but I think the whole KDE help centre feature could use a good overhaul too.

I would prefer to set this in the ui file: The maximum is already set to 99.

For the tooltip stuff: I am not sure if that is not inconsistent with the remaining stuff on these pages.

... you want to add the feature

But do they change things behind our back after this method has been entered?

How about

updated for the current git/head.

One more thing: could establishing the project file name not simply be done by a method in the ProjectController class rather than by a dedicated class? Because, in how many different functions would you split that logic?

Arguably that still stands, but it's outside my area of expertise to comment on it.

The current patch I still cannot oversee (though also due to the existing code), so I would have to grab the -1 sign for now if on the jury.

updated as requested.

Drops the potentially unsafe qDebug output in the signal handler, makes handlingSignal an std::atomic_bool (since we can use locks here anyway) and adds copious comments.

Still working on this and waiting on more background info from the Qt Interest ML.

You can't use std::atomic_flag, because it's an `int`.

Any idea how we could test the race-condition scenario? I've been trying by re-raising the signal from just before and just inside the if(handlingSignal) loop and until now it has always been behaving as expected (= the if is executed only once).

Sorry for the delay; I thought this would be straightforward and then ran into questions...

This is determined by hardware support. With relevant architectures I meant architectures on which Qt/KDE applications can run, like x86, PPC, ARM. > These all have lock-free `std::atomic<bool>`, as far as I know.

I guess you can also use `std::atomic_flag`, which is guaranteed to be lock-free, and should offer enough functionality for our use case.

...

Not in the middle of an assignment, but between the read in `if (!handlingSignal)` and the write `handlingSignal = 1` it can be interrupted. That's not atomic.

At least std::atomic<bool> is lock-free on all relevant architectures. (I'm aware that the standard doesn't guarantee it, probably because of some embedded architectures.

Updated as suggested

Where in the code would you want a documentation of the intent of this change?
The best place might be a in the handbook or the project import wizard GUI ... but we're in string freeze, no?

• Dropped the semaphore-based alternative as it would only be less resource-intensive when manhandling pthreads
• moved almost everything back out of the CorePrivate class, keeping only the slot required for QSocketNotifier operation.
• dropped the SIGHUP shortcut, to be resubmitted in the future

I would recommend to just not think about the Windows requirement, if you cannot test it anyway.

If there is no solution which does not require two different code paths for handling this problem, I'm against merging this, non-conformant old behaviour or not, sorry.

• Why does this patch look so much more verbose than the solution proposed on http://doc.qt.io/qt-5/unix-signals.html?

In D16218#343340, @arrowd wrote:

Adds the missing #endif

Re: the testing I did on FreeBSD: that's with a dedicated demonstrator; I cannot currently build KDevelop5 there.

I'd be pushing less if this hadn't already been committed and then reverted because of an issue that got through the initial review process.

In absence of instructions to the contrary I'll interpret Milian's "feel free to respin" as "feel free to recommit", and push a commit during the day. This has been waiting to be re-applied long enough.

Another fix for the generic Makefile project manager; I had missed the fact that URLInfo::isDir is undefined when URLInfo::isValid is false. This lead to personalised project files of the type `/path/to/projectFoo/projectFoo.kdev4/customname.kdev4```.

Updated as discussed. This variant is less different from stock code than my previous proposal. It complements the current checks with a comparison using canonicalised paths. As a result it should catch all cases that are not caught by either one of the comparisons when performed in isolation.

I think there might be a simpler solution to that situation

Updated as discussed: any previous project settings file in .kdev4 will be removed if and before overriding/writing it (instead of simply trashing the entire .kdev4 directory).