Apparently one can no longer contribute via email replies to the email notifications?!

Just tested this with KWin 5.13.3 (of which I had a build all set up; the patch applies cleanly except for the .desktop file).

Something like this should be part of any self-respecting desktop; per-screen colour management ("ColorSync") has been in Mac OS X since its very early days and even with a simple software calibration utility (SuperCal for Mac, Calibrize for MSWin) you can really improve how your display looks (whether you go for absolute correctness or a calibration that makes things look at their best for your own perception).

The problem is that by default QtWebEngine only allows access to local resources from local files, that is using URLs with a file scheme (this is why it works when you save the HTML code to a local file).

I can't really reproduce this issue. Which Qt version are you using?

• right-click in the WebEngine view of the startup/about page, select "View Source"
• without quitting the source viewer (Kate in my case), open the /tmp/konqueror*.html file in konqueror
• select the WebEngine view mode
• document is rendered correctly, without error.

This is exactly what I do:

David Faure wrote on 20200611::18:16:14 re: "D26253: Port the About page to QtWebEngine"

It took me way too long to figure out that this is the source of the regression below, and not a missing "konq:" kioslave ...

I assume the lineHeight usages in the renderer are easy to replace with the proper "height()" of the individual lines of the layout.

Looking at the code, might it make more sense to just move away from the fixed height we have?
It isn't used that often and in most cases one could just query the height of the current line.

the code can be smart

This new version does not cause a lineheight regression for me (after backporting it to 5.60.0). However, contrary to what I thought it does not react to emoji

With "we've ever seen" you do mean that lineheight only changes when a line that requires it scrolls into view?

I like your split, for the most part.

Yes, but look at the traditional meaning of a text editor, which typically means "plain text" editor. KTextEditor's design decision to use a single lineheight puts it squarely in that domain - to reply in style: It's "TKextEditor", not "KRichTextEditor" (and even less "KWordProcessor") ...

This patch is only needed when mixing a main Latin1 (like) alphanumeric font with occasional glyphs from a font that have a different, taller height?

I can't speak for the special cases where this change would improve matters, but for me it introduces a clear regression (waste of vertical space: 12 lines less) in a basic ascii code editing context. Font used is Ubuntu Mono 10pt.

Where?

No worry, I only followed this suggestion because I myself had looked for the open-in-tabs option in the Navigation panel more than once.

Of course, I didn't want to suggest that the documentation should already contain views from a future commit. Far from it, IMHO there's so little hurry with this kind of thing that this change could have waited a few days longer as far as I would be concerned ;)

Ha, OK, I'll let you figure this out among yourselves and update my patch once you've come to a consensus :P

Can it be a standard Breeze theme for consistency?

You mean this? 8-)

I've been addressing issues related to controller proxy instances surviving too long during shutdown and accessing stale memory.

Pity you didn't catch D29227!

I think these were the last outstanding corrections to make?

How about moving "New windows" to Navigation ?
(Not expected to be done here, could be done later)

Updated as requested.

Added spacer as requested.

In D29178#658443, @alex wrote:

Nope, that is something different, to give you an example:

QStringLiteral("cat %1").arg(KShell::quoteArg("/my/crappy filepath/"));  => cat '/my/crappy filepath/' 
KShell::quoteArg(QStringLiteral("cat %1").arg("/my/crappy filepath/")); => 'cat /my/crappy filepath/'

This causes a compile error: ‘quoteArgs’ is not a member of ‘KShell’

Fixed.

Shouldn't this be fixed in Baloo then?

What do those warnings look like, could you copy them in the commit comment ?

Updated as requested.

Please see the test plan in the diff that I mentioned. Should be readily reproducible in that scenario.

+ QString command = QStringLiteral("%1 --new-window").arg(QCoreApplication::applicationFilePath());

I think you need a KShell::quoteArgs in case there's spaces in the path

I cannot test, by the patch seems correct and not intrusive.

Remove spurious hunk.

A thought: shouldn't the KRun::run* functions use QCoreApplication::applicationFilePath() instead of invoking "dolphin" and hope the path leads to the same application?

Instead of adding Windows support where the platform *is* different, you introduce additional differences.

any bug reports for the Windows platform will be rejected immediately then.

Ultimately this wasn't difficult, so apologies for the noise!

> std::for_each(beginKey, rangeEnd, [&list,&propMap](const KFileMetaData::Property::Property& s) { list.append(propMap[s]); });

the []operator always returns the most recently inserted value for the same key according to docs. You must iterate over the values directly.

Qt 5.10. is required since KF 5.55: https://kde.org/announcements/kde-frameworks-5.55.0.php.

I'm updating some of my packaging for a set-up that should meet the minimum requirements that were current when this commit was made (Qt 5.9 and KF5 5.60.0; baloo-widgets 19.08.3 requires Qt 5.8 and KF5 5.58.0). Evidently this change wasn't checked against those requirements; the constKeyValue* iterators were introduced in Qt 5.10 (this lack of testing is also apparent in filemetadatadatedisplaytest.cpp:57!)

Don't just stop parsing files when shutting down, also ignore new document add requests.

Updated and improved version:

• the registration with the ProcessController is done "JIT", just before enqueing the first document for actual parsing
• keep track of documents via the QUrls of IndexedStrings

This addresses a few issues, notably by using a queued signal to trigger url (un)registering from the requesting (weaver) thread in the thread where the JobController lives too.

I sometimes find myself feeling this way about Frameworks too. A recent experience at a hackathon where I helped 8 students set up complete development environments from scratch reinforced this viewpoint. Not that I'm seriously recommending re-merging the frameworks, but I would like to challenge the notion that splitting a monolithic codebase across multiple repos is a boon to onboarding; I don't think it is. It may have other benefits, but I don't think onboarding is one of them.

As an aside, I think splitting up kdepim into so many repositories was a huge mistake.

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.