There is another condition here: `if (lastShownMenu)`. So if the QMenu object instance got deleted

I'll activate the debug trace on change of my lastShownMenu though

In any case there isn't much else you can do; stepping through the code with a debugger is near impossible (the menu about-to-be-opened will already have grabbed mouse and keyboard focus so you'd need to display remotely).

Please add a line

  qDebug() << "Showing context menu" << menu;

to KDevelop::TextDocument::populateContextMenu.

>>   > FWIW I got to look at the KTE implementation of the context menu mechanism that is used here. It indeed uses and reuses a single QMenu instance (there's even a comment in the code about that).
>>   
>>   Please give links into the code, as I am lost what you exactly refer to here.
> 
> see the source of `KTextEditor::ViewPrivate::contextMenu()`. The ctx menu is in fact managed by KXMLGUI.

The context menu is queried every time from KXMLGUI that method is called.  So  if KXMLGUI internally decides to recreate the context menu, you get another object the next time. Please see again the description of this very bug.

The other option would have been to release 5.3.3 without a fix for ctags plugin users, rendering it unusable for people relying on packaged kdevelop.

Friedrich W. H. Kossebau wrote on 20190717::00:12:44 re: "D22424: TextDocument: remove actions from contextmenu on hide already"

Kai Uwe Broulik wrote on 20190718::07:13:16 re: "D22365: KNotification macOS native support by NSNotificationCenter"

It seems to me there's a way to tell the translators that a string shouldn't be translated. Why not use that, or put a name that doesn't require translation (like name=kded5.desktop)?

I've tested this in the 5.3 branch now, which required applying hunk #3 manually to texteditor.cpp .

I could try your solution, of course, but what annoys me is that it comes months after I worked on mine. I currently have too many other things going on in my life to dive in and figure out what on earth was going on again. I do think I outlined it well enough above in the initial description and/or exchange; I should find a moment this weekend to sit down and re-read it with a fresh mind.
It would help if you had a specific critique on my solution other than "it doesn't use this or that signal" (or, what I kind of sense, "it comes from you"). No disrespect intended, but your description in D22424 isn't that easy to read either (it felt like reading German, for some inexplicable reason ;) ).

Just a few remarks on the comments that should make them easier to understand (a priori comments should illustrate code and not require lots of different code the understand their meaning ;))

Please check the earlier discussion; IIRC there is a reliability problem with that signal, and I did try reverting to its use before coming up with the current solution.

Indeed Gitlab should simplify things a lot.

> I suggest to do a `arc amend` (to basically update the commit message with current reviewers, "Differentiatl Revision" line, etc.) and then `git push` your change manually to the right branch. Let's you use your normal git command-line to actually push changes, which to me is a much more thrust-worthy approach than to rely on arc to do that for me...

Probably this should be added to the guide. And probably it should also be added that the commits should be squashed (thing that `arc land` does automatically).

code wise looks good

you are removing a feature

Sounds good enough for me then!

You identified an event chain which leads to the browsing mode not being restored correctly. This should happen less often with the Alt modifier but it can still happen (hit Alt to display a tooltip or open a menu and then move the mouse over that tooltip or select a menu item?).

I didn't read the full encyclopedia of discussions here, I only looked at the patch.

(User, not VDG member)

Do you mean something like `#include <Foo>` which then contains a `#include <foo.h>`?

1. "simplifies the code by removing the dynamic item text logic"

(Sorry for the inconvinience, I've never been very friendly with arc/phab)

Not really: it says that a temporary directory for every kdevelop instance is created

no need for making it "deterministic" in any way. There is no benefit in doing that.

OK, I stand corrected on this. OTOH, the rest of my notes about this being wrong anyway still stand.

using the user ID is definitely wrong here: with this change, opening a second kdevelop will erase the temporary directory of the first...

Milian Wolff wrote on 20190312::20:02:54 re: "D17289: KDevelop/Shell: set dedicated TMPDIR"

...aaaaaand that's exactly what happened. :(

Re: reparsing reliably each time a headerfile is changed: wouldn't the use of forwarding headers increase the chance of missing a change?

And there are probably places where the simpler QProcess API was used
instead.

On, with the partially reverted patch:

But now the state is just like it was before: If you have a font that does fallbacks for some glyphs

I would rather keep the current behavior and let people use sane fonts if the want unicode.

FWIW, Calligra Words can (idem QWE and QWK) so I guess you mean KTE cannot without a complete rewrite of how text is displayed?

Just load the XML file from bug 404713.
Before this changes here, you did overpaint the next line randomly with the "oversized one", now you "cut" the oversized line.

So it seems that the partial revert works; you lost me re: what would break again by doing that?

We just can't use one fixed height for such texts.

That is a good observation: @cullmann Could you give this partial revert a try?

@loh.tar The line edit in the search bar was once used before the floating message widgets in the view even existed. I guess it's legacy and possibly can be removed?

Next Frameworks Tag is on Saturday, 2nd, i.e. in 2 days. Revert, or give it a try?

Causes https://bugs.kde.org/show_bug.cgi?id=404907

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

Even in your screenshot it looks fine to me.

Here's a very good example of an overly large problem report:

About the combined popups: could you downsize the 2 components so they always have the same (reasonable) size which could be coupled to screen height?

Omitting the problem tooltip if it's large makes it a bit unpredictable to the user. He/she then won't know in advance whether hovering over a location that might show a combined tooltip will actually show it or not.

For me it is exactly the opposite. I hover the range that is underlined red

Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.

This seems like a big productivity progress (can't test it yet because using the 5.3 branch) but I have a concern that it is only a sufficient solution for those of us with (very) big screens. Esp. problem reports can be long, and I've never seen a scrollbar in them, AFAICR. Another concern is that the combined popup might be so big it's going to obscure parts of the code you'd want to keep visible for context.

This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).

Time to rebase this proof-of-concept and restore its full scope, for reference even if only parts ever get upstreamed (there was a blocking disagreement last time).

This patch also changed the logic of openProjectConfig().

I'd appreciate if this were cherry-picked to the 5.3 branch, if/when possible. (I can do the rebasing.)

Sometimes it works, sometimes it doesn't. Often I have to mock-edit a file to force reparsing when some header has changed.

To some extent this resembles the classic latency/throughput discussion.

Well, if among developers you cannot find a solution that covers all use cases a configurable setting (applying only to setting the preamble-on-first parse flag or not) could well be the only compromise. And this one doesn't have to be hard to understand, which doesn't mean it has to (probably means that it should not) indicate exactly what it does.

What's the minimum viable change here?

Or, you add a flag to one of the relevant settings panels. There are already a number of options that aren't exactly easy to understand for everyone, this one could be something like "Make code-completion results available faster (can require significant resources)".

auto* action = new QAction(tr("Reparse the Entire Project"), this);

Updated as requested.

So this is just going to become a victim of the better-is-the-enemy-of-good principle?

Question to @apol: from what I can grasp CMakeTargetItem::m_builtUrl is cmake-internal cuisine so there shouldn't be any need to store it in canonical fashion but rather reason(s) to store it exactly as cmake knows it?

Is the parser triggered again if the entire project has been parsed already?

Updated as requested (minus the potential change to iProjectController::reparseProject).

Comment removed.

Now tested more exhaustively and with unittest.

No, sorry, I am a bit confused by your notation and the fact you seem to consider only files that are open when you start a session and then probably confused myself a bit more while answering.

where (1) = entire project is parsed on import. Is that correct?

Is Milian's suggestion different from mine of setting the flag only when projects are not parsed entirely on import (which may be easier to test for where the flag is set, I haven't checked)?

never seen this, please investigate and fix it

What I meant is that tooltips in the problem reporter appear when you hover the mouse over an entry, and disappear again when you move the mouse back to the text editor (and certainly when you need to scroll the editor window because the tooltip covers the area where you need to be). But for some reason I'm not getting any tooltips in that reporter at all at the moment.