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.

So according to you, this line is useful ? from my point of view, it's needless and just looks like a syntax error.

Forget that. The syntax is confusing, please remove this HASFLAG

There are tests for other ECM modules in the **tests** subdir.

Updated as requested.

Right, but I was saying all this because I think IF_SUPPORTED (the keyword in the arguments) should be SUPPORTED_IF.

So there should indeed be some real-world benchmarking data to do a cost/benefit analysis that includes the human-in-the-loop aspect and huge projects like the ones Aaron uses. We already have an estimated 10% gain for a full reparse of a small project after its initial import.

In that sentence, one can read "if supported" for the macro name, ...

To put it bluntly: you should have asked that 3 months ago ;)
I really can't remember if I had a specific reason or if this is just the result of a search/replace.

Aaron, don't your arguments apply to parsing an entire project on startup as well? I can easily imagine that opening and parsing entire projects of the size you mention must have a non-negligible cost regardless of all optimisation and caching that is currently implemented
There is a setting for this feature. A similar switch for the preamble thing will probably be difficult to label comprehensively but maybe a coupling can be made with the full-project-parse switch?

This follows David's suggestion, but using QUERY_IF instead of the suggested TRY_IF to make it clear that this parameter controls the querying of the compiler.
I haven't yet tested the new logic exhaustively but the as far as I can tell the macro behaves as intended as used in the two compiler settings modules.

we use CXTranslationUnit_CreatePreambleOnFirstParse to get code completion results fast. otherwise the first code completion request would create the preamble, which felt much worse

On my test file, time spent in clang_codeCompleteAt goes down from ~700ms

Replying to a remark by Milian on D17289 where this idea came up:

Usually if you have a conditional behaviour the associated condition specifies when to trigger it, no?
You're right that the names don't suggest exactly how the condition is being evaluated (with extra checks or not), but that was also a bit the idea.
Don't bother the user with such details, just provide a macro that will add the flag(s) if they are supported, with an optional conditional expression that can make things faster.

Renamed macro and parameter names as announced in my last comment.

In D16894#400949, @dfaure wrote:

This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading that, one thinks "well, if we know the compiler flag is supported, why are we testing that it is?".

like René says, this is quite surprising

Hmmm, did I say exactly that? :)

But still, isn't there another way? Now the header and view are locked together. One doesn't work without the other.

In case someone thinks that creating the pch file when you open a file causes a noticeable lag during the opening process: if so this would also be the case when configuring KDevelop not to parse the entire project on import. I use that mode all the time and never noticed any such lag.