A more complete draft:

bump?

You will notice that I plan to maintain an option to disable the Apple-specific behaviour for anyone who depends on the current behaviour (that includes me, but your script would also continue to work). Cf. the APPLE_FORCE_X11 option

Allowing negative prios makes sense.

Can we set DATAROOTDIR=/Library/Application Support/KDE so that everything remains nicely bundled?

At that time hinting with freetype wasn't state of the art due to patent issues, but that has changed with the v40 engine in freetype 2.7.

The current KCM already has a control for that.

Found this by accident, and had only one immediate thought

That'll probably be when we move to Qt6.

includes the root cmake file changes.

a find_packge for `KF5::WindowSystem` is missing in the root CMakeLists file.

Can you rebase it over the last master branch ?

FWIW, anyone can request changes to a review, but also accept it. And while I would probably not take that as a green light to commit unless it comes from a known KDE dev it *does* go to show demand/need for a change. And hopefully, confirmation that it doesn't only work for the author.

Refactored for the standalone DrKonqi repo and disabled the integration testing on Mac.

Sorry, I had updating this on my list but it drifted to the bottom...

Actually, I realise this patch too is a somewhat stripped down version of a patch I've been using for a long time in my MacPorts packaging for Okular:

@rjvbb what do you say? makes sense?

This change does more than just enabling hidpi support in the plist.

Found back my ML post entitled

("compiledb-generator and the generic Makefile proj.manager"). Francis Herne replied

*this*:

That must have been magic code then, quick, try to catch it, we all want that ;)

Not supported, since in your case KDevelop simply does not know a compile_commands.json exist,

Well, apparently the contextmenu CAN change during a session (at least on Mac and when I open it in different opened-at-session-load documents when the initial project load and parsing activity is still in progress).

This implements and uses my idea of an ecm_add_<lang>_compiler_flags_if_supported function set for C and C++. It uses compiler ID+version conditions to determine if flag(s) are supported when those conditions are known and reliable - otherwise and only then does it resort to querying the compiler.

E.g. I would have expected before looking at things that each view has their own separate context menu instance, possibly even created on the fly per display :)

Another fix: use the active MainWindow as the parent of the contextMenuData instance and do NOT delete it in the TextDocumentPrivate dtor.

Apologies, the tear-off bit shouldn't have been included of course.

updated as suggested:

• moves the context menu added stuff logic into a dedicated class (as an upbeat to possible future improvement)
• caches the QMenu* to which actions were last added, and removes them from that menu when the next context menu is shown. This should be equivalent to removing the items on contextMenuAboutToHide.

Sh@@t, sorry, I allowed some unrelated (and potential future) changes to pollute this version. Will fix tomorrow.

I would see the flaw also in that there is no specification in the KTextEditor API how the context menu is shared/reused.

I've made a few more usability changes, and renamed the new menu action to "Configure..." because it corresponds to what the action does.

In case anyone wonders why this has gone undetected: I think because of an undocumented feature, the fact aboutToShowContextMenu was called for all views. Indeed, with the KTextEditor fix in place the duplication issue occurs also without loading the CTags plugin (= with stock KDevelop code).

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!).