Recently I ran into a weird startup issue that ultimately I traced back to the use of std::unique_ptr and its underlying implementation. It's been a while, so I'm no longer fresh on the details. Basically, if an interrupt or exception occurs during the call to std::unique_ptr, a subsequent call will hang (or crash). From what I understood it's mostly an issue on non-x86_64 platforms, but it can happen there too (as I found out). There has been at least 1 attempt to fix the problem in the underlying system library (libstdc++, I think but possibly libc) but that one was reverted because it introduced other regressions, from what I understand.

Well, that's what I get for trusting my memory, I didn't even realise at first that you'd been jumping on a PR that I started. :-/

Could you please cancel that email and paste its contents in a Phabricator comment?

Igor Kushnir wrote on 20211011::17:30:08 re: "D15532: [Astyle] Add Objective C to list of languages with formatters"

Igor Kushnir wrote on 20211011::12:38:18 re: "D15532: [Astyle] Add Objective C to list of languages with formatters"

In addition:

• I only see said button when using KWin
• KWin allows me to configure which titlebar buttons I want to see (and where).

No need for a macro even: https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/pointer_helper_p.h#L14 - that gives you the backward compatibility with older Qt versions without conflicting with the newer ones.

this instance here is just owned by this very class object,

>
> You mean to confirm to anyone who had forgotten what `private' means? 8-)

This is an orthogonal concept to private, I cannot follow what you mean here.

The point is to use the expressiveness of this highlevel language feature to tell everyone: this instance here is just owned by this very class object,

Ahmad Samir wrote on 20210316::13:50:33 re: "T13924: Unify how d-pointer is created in frameworks' classes"

When we bump minimum versions we want to use the things they have, if we  take care to not break older versions there is no point in requiring newer versions

What's the point of using std::unique_ptr here? Isn't that inherent in the fact that the instance is private and (typically) allocated in the dtor?

That's a substantial list which includes applications with a steepish learning curve that probably provide useful information in the What's This texts.

I agree but I had to draw the line somewhere. I drew it at terms like file, folder, view. Otherwise I would have to paraphrase or explain them in every other text. The context help isn't that well suited for a very basic introduction.

• It was incompletely implemented by developers, reducing the incentive to enter the mode that showed the balloons

Felix Ernst wrote on 20210210::18:07:07 re: "T9986: Delete "What's This" inline help functionality"

Not really. This is just the same Whatsthis with a button in front.

In the Kate/KTextEditor config dialog we tried to provide a lot of "what's this" stuff.
But I guess it would make sense to move that there just to tooltips.

Making it useful is not a practical option IMO since it requires implementing it for every UI control in every piece of software, which is not even feasible for our own software--let alone 3rd-party software. It's one of those things that has to be universal to be useful, and because we can't make it so, it never will be.

There have long been applications that provide a "what's this" menu item in the Help menu or equivalent. I think this is important functionality as it allows users to figure out what things do, it eases the burden on documentation writers to keep the manual up-to-date and complete (a big issue with much FOSS) and it also allows to minimise automatic tooltip clutter without giving up all hope of contextual guidance.

You must be right about the greyscale effect; I don't see any actual calculation of the intensity (from the RGB values) in the code that gets installed. And that code is JavaScript (aka QtScript); up to you to determine if your effect could be implemented in that language...

Is it? How does it work? It definitely requires distribution of a binary addon. Does KDE installer build binary addons?

As I understand 3rdparty binary effects are harder to install, very unpopular and it will take 100 years to get it packaged in all distros...

I was maybe a little quick. Consider these differences

Yup, works for me now.

Hm, and by not working you mean that the translucency effect gets canceled, but the correction itself works, right?

Something has probably changed since 5.13.3, because translucency-while-moving works fine with my KWin 5.17.5...

By the way, I've updated the patch for KDE 5.17 + fixed it to work with translucency effects correctly (I didn't use "modulation" in the previous version of the patch).

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.