What's the size of the .git directory of the calligra repo these days? I seem to recall it was what I thought really huge already in KDE4 days. Last time I tried git wouldn't let you push from a clone that didn't have the full history. And yes, for me there's a point where I consider the value of my few and smallish contributions don't justify wasting "that much" disk space on what's literally old history.

Our discussion is about when to create the preamble for open documents. If I were to stop that job, I wouldn't get the AST, but I want the AST. I just don't want the preamble before I've started editing the file.

As I said, I thought the possibility to cancel jobs could be a comprise (I don't get the impression you've been able to find one yet), but OK. I've started to peek around in the code to see about job control, if these are based on KJob it shouldn't be hard to add them to the existing job controller.

Rene, I'm missing context - what are you replying to? This doesn't seem to be related to the preamble?

Re: the time and resources spent by the background parser when you'd rather not:

Works fine as far as I can tell, amazing no one else noticed this before!

Well, I got as far as confirming you're probably right, when I finally got to sit at my Mac yesterday night ... and then when I woke up it was 3am.

Sorry, no. Swamped with last-minute reconstruction efforts in the, erm, structure that's supposed to become my new house next week :-/

This is a MacBook Pro Retina, 13-inch, Mid 2014 with macOS 10.15.2 with only this one disk. It's clearly not supposed to get removed, imo :)

How do you connect? The Mac OS has a built-in VNC server but it has to be activated. Once it is you should be able to connect using any VNC client (possibly using ssh tunnelling?).

The output comes from running `solid-hardware5 details` and `solid-hardware nonportableinfo` on the UID.

In D27065#608746, @mwolff wrote:

before:

[snip]

Note the Ejectable = false (bool) vs. StorageDrive.removable = true (bool). The patch here fixes it to yield StorageDrive.removable = false (bool)

You don't have control over where those pch files are written, right, other than through setting $TMPDIR?

Whatever, I'm staying at 5.60.0 anyway, with whatever patches I deem appropriate.

I might (if I can find the trouble location) but IMHO KIO should still account for the possibility of this situation too (or more in general, bail out this function for any path that cannot be a mountpoint).

Go figure... I had exactly this kind of crash the other day, despite your proposed change.

I am a firm +1 on splitting Calligra

So no urgent need for me to revisit the code?

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

KF5's Qt support strategy is sound

But why, there's nothing that requires this other than that single env. var. function that may not even be the most appropriate one (I find the documentation a bit confusing).

I disagree since it will change the current precondition of the function for the need of one of its users.

Are you not seeing these for instance when browsing an MSWin share in Dolphin (with the same or newer versions of kio-extras, Samba and MSWin)?

Apologies, I've been stretched way too thin since about the time this diff was accepted, I don't think I even noticed the fact.

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.

A little tinker tool:

And my point is that you are doing 720 translations and 360 rotations per cycle, with subsequent smoothing of an image, continuously and with sufficient temporal resolution to get a fluid animation that is completely overkill here. Indicating a busy state (a two-state entity) is not the same as indicating progress and could be done by something like a stoplight changing colour.

In D22375#541399, @sitter wrote:

The demo doesn't even use this widget

Does it happen with every code that uses QPropertyAnimation, or just with this KBusyIndicator?

I'll repeat here what I muttered on the associated commit page:

Quick question: how would you make this animate once every 2 seconds to reduce the CPU overhead (the test app runs at >12% CPU, too much for a busy indicator IMVHO)? I don't grok the 1s interval duration from the parameters (nor the API documentation).

This delay can also be used as a cheap mechanism to compress events and prevent spurious reloads, something you're bound to get when doing something potentially all-encompassing as checking out a different branch. A mod like the one below is highly effective in my own dirwatching implementation that only monitors directories for changes, but I see a comparable number of skipped redudant reloads when I use stock dirwatching implementation.

In T11753#202324, @vonreth wrote:

The most pressing issue exists on mac, Qt does not look for data in the install prefix but only in the bundle location.

Yeah, you're right that we should check system version for back-compatibility.

I haven't been able to give this much attention, sorry.

Updated to use the "cool solution" ;)

Untested: have you tried to make dolphinprivate a PUBLIC dependency of kdeinit_dolphin?

Can you try to build another kdeinit app (i.e. `khelpcenter`) to check if you get the same error?

As I thought this needs some hacking on OS X < 10.10 but a priori all one loses is the user notifications.

It's probably not a bad idea too to return early if ever the computed realname is empty, and avoid the iteration which should be pointless in that case. Right?!

Would you mind checking if using QCoreApplication::applicationName() would be an alternative? I'd do it myself but since I cannot reproduce your issue I can't answer the question fully.

Just `pinentry-qt` and then `BYE`. Backtrace and more info on https://bugzilla.opensuse.org/show_bug.cgi?id=1141883

That backtrace isn't very helpful, since missing most line numbers.

Didn't know this can happen and lgtm.

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"