Getting the user's desktop style was easier than I thought.

This should now work as intended in all situations.

constifies KThemeSettings.

Patch updated as requested.

A few snapshots obtained with runtime theme changes (see also D13881)

A couple of snapshot (with my current KMessageWidget facelift; styles and themes switched "on-the-fly"):

Updated as (hopefully) requested.

Otherwise LGTM (I also checked the in-app palette change myself: seems to work fine).

Seems my reply per email went AWOL:

Since there's been mention about aligning Kirigami and re: the (IMHO) controversial approach of using foreground (text) colours for background purposes:

KThemeSettings moved to its own header+implementation files, and extended so different groups can be read. I don't think it needs much else in terms of functionality or complexity, if anything. There's no point in exporting it anyway (so it has a very specific target audience).

Turns out it's trivial to check if and what custom theme was activated through the KColorSchemeManager.

A few examples showing the subtle effect of brightness matching, comparing to the Breeze theme (the brightness reference):

Using the theme's normal foreground colour for message text for more reliable readability with darker themes.

A new revision:

The need for an extra check in qColorFromSettings() meant I changed the API to put all tests in there and added a default return value argument. IOW, basically the same API as KConfig has.

cleanup

Version using the suggested colour values from ~/.config/kdeglobals , if the file exists and has a Colors:Window group.

Another idea would have been to have the widget style alter the appearance like it already does for things like KTitleWidget

5.47.0 (stock) vs. 5.42.0 (stock), QtCurve (top) vs. Macintosh native (below):

This revision incorporates the feedback and implements the approach already evoked:

refreshed/rebased.

In D13736#283140, @chrstphrchvz wrote:

In D13736#283134, @drosca wrote:

Do you have dev account?

Nope.

You're right, didn't notice that - and couldn't imagine that anyone would bother, too. You probably end up with all QtBase sub/split packages installed pretty quickly anyway.

LGTM - but is QtNetwork ever installed as a separate package rather than as a part of QtBase?

If no objections are made I'll interpret Milian's "feel free to respin" as "feel free to commit" in a couple of days.

How about I clean this up a little (removing at least the KyotoCabinet backend) and then push it to a branch so it's easier to pick up for anyone else who like to work on this or even just check it out?

This revision brings some code cleanup (including the use of a qresource in the unittest/benchmark) and above all, a signficant performance improvement.
It turns out that the default LMDB environment uses synchronous I/O. In our case we can take the risk to use async I/O because we would at most lose the last few changes if a crash occurs - and most of the time the entire cache will be deleted after a crash anyway.

EDIT: while C++ exceptions are apparently with almost zero cost as long as they don't occur (https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow) there must also be a reason why they're disabled by default for KF5. Should I expect a benefit of rewriting lmdbxx so topducontextdynamicdata_p.cpp doesn't require exception support?

so what's your plan with this now?

Please double-check if the issue is indeed solved and no new regressions are introduced.

I'm pretty sure this is due to `QUrl::RemoveFilename`, which removes the last directory if the URL refers to a directory.

That's possible (your analysis I mean) and annoying that we missed it during the review. I'm away from my dev environment for a while, so cannot do much right now. IIRC most of the changes are around the location where it's also decided whether an override dialog has to be posted. If that's also where the last path component is removed, it should be possible to make that removal conditional on whether or not the selectedUrl points to a file or to a directory.

Actually, no. I haven't been following that part at all (and am taking 2 weeks off of intensive dev stuff ;) )

Could you please push it for me? I probably won't be able to do so for at least a week and it'd be a pity if the change just misses a release because of that.

Unnecessary rebump, pardon, rebase.

That was quick! :)

Updated as discussed.

> "Except", are you sure about that? I'm pretty certain I got the override dialog when I forced a new import from, say, the project's CMake file, and <dirname>.kdev4 existed already.


Ah, yes - that could be it. Then we should probably change the code to first construct a projectFileUrl that actually points to a .kdev4 file, and then use that in the conditional. And add comments that explain what is going on here.

@rjvbb does this solve issues you are having and trying to workaround with https://phabricator.kde.org/D7930 ?

(oh how I hate arc)

I can try to test with 5.2.1, but not before tonight.

This is about better and more concise English. The queued connection is the indirect explanation why the patch is necessary, and thus comes after the direct explanation (the fact that there may be pending signals). Think of it as a courtesy to people who want to get to the point first and maybe deal with the finer detail later.

I don't get this change, can you explain? the old code checks whether the profileFileUrl (which should *always* ends on .kdev4, no?) exists. In that case, we want to ask the user if he wants to override, except if the project file is equal to what we'd write out anyways.

(Oops, missed that one :-/)

(sorry, keep forgetting to set the action. Consider this a change request at least for the typo in the comment ;))

So the difference here is that finishNotification isn't called if notification == nullptr, with the crucial difference probably being the fact that m isn't added multiple times to the list of reusable items?

next iteration