If I suggest something and Milian suggests something else then Milian is right :-)

ah, then this should be simplified by using std::any_of instead

Modified as requested.
(Please double-check, it works AFAICT but it's the first time I use this construct.)

That's because of the MSVC remarks you made inline?

No problem if there's a good reason to wait!

Which version of hunspell does this raise the requirement to?

Any objections if I commit this by the end of the week?

Any objections if I commit this by the end of the week?

Arcanist does it better https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches

Thanks for answering and apologies for asking, I didn't have much time to find the entire sources online. And yes, I could easily imagine it was necessary, sorry also if I gave a different impression.

Looks good, but could you elaborate the commit message a little bit, explaining why this is necessary, preferably including what the framework's (new) name is?

add missing context (patch unchanged)

Add missing context (patch unchanged)

Qt Assistant also rolls its own Window (sans s...) menu.

I mean this patch D11075 <https://phabricator.kde.org/D11075> (the Dock menu). setAsDockMenu() is a Mac-only function.

Would not it end with having #ifdefs scattered all over the QApplication anyway?

Actually, I do not know, whether there is an API that allows to force Mac OS to create such list in the Dock menu, but if an app implements "Window" menu (systemMenu="window" in the menu xib file), then this list is generated automatically.

In addition to the inline comments:

I'm not sure if all Mac applications always show the open documents under their Dock tile (that menu can be used for anything, of course), and I also think that it would be more useful to have a Windows menu like (most) native Mac apps have.
Other than that, LGTM.

One could try to reimplement this with Objective-C, I do not know whether it makes sense though.

The legacy argc,argv is handled by QCommandLineParser.

Isn't this another case of "should be fixed in QApplication or another lower level library"?

Then again, all "not non-gui" applications need an application icon, and adding one is simple enough that it can be done in cmake with a few simple enough operations. And a little bit of extra care in the source code to avoid undoing the effect of ecm_add_app_icon.

My original implementation is used in conjunction with a build system that ensures all dependencies are available.

I can hardly NOT accept this, given I'm the original author :)

Curious, I cannot give a green light (too), please consider that done...

Thanks Gilles.

Sorry, I didn't quite get what you mean. Your patch just makes realDpiX and realDpiY global, but the rest is the same. Am I missing something?

I agree that your patch is the minimal way to have Okular compiled on Mac.

Hi Sergio,

On a sideways related note:
I have at least one patch that improves Okular/Mac integration, allowing it to act as an alternative or complement to the native Preview.app .

In D10415#203663, @sbragin wrote:

It does work. The old one uses deprecated methods, doesn't work properly and can not be even compiled, in fact.

This is hardly acceptable.

In the code shown by this patch ;) Line 80.

Unfortunately, this patch doesn't fix it. The text still isn't bold.

I can confirm that the patch appears to have no (side)effect whatsoever when using the Freetype fontengine (available also on Mac with -cocoa:fontengine=freetype!)

OK, testing. I'll let you know if I notice anything off.

Thanks for the info! So if/hen this goes in, what are the next steps?

A diagonally related anecdote that shows this location is a more central point in the font selection process than I thought first:

Is this change purely a conversation of what developers use in code to call up fonts in their applications?

The examples seem to have a circular runtime dependency on (at least) plasma-desktop. Is that just an opportunistic dependency (= they'd work fine you'd only just installed plasma-framework)?

updated as requested/discussed.

David Faure wrote on 20180119::08:33:32 re: "D9824: Optimize inotify KDirWatch backend: map inotify wd to Entry"

That's not applicable.

Also we know at least one person that isn't going to forget about this, don't we?

I don't see anything unreasonable to my request, which can also be satisfied by a argued demonstration why the same approach/fix doesn't apply to other backends. AFAIAC I'm just doing my reviewers' service like it's been shown to me how that's done.

i'm assuming the cost would be bigger then the benefit. (just an assumption here, i could be wrong)

I am going to assume you would have said so by now if the fix is not applicable to the QFSW backend because it doesn't do the same costly walk.

But I won't write mega patches like you seem to prefer.

@rjvbb why did you request changes to proceed with this patch? The fact that there are more issues in KDirWatch does not mean we should hold up this approach.

Each hash node will be approx 4+8=12 bytes, and something must point to it, so another 8 bytes, 20 in total. No big deal.

Please test this for the QFSW backend too and post a benchmark result comparison (and include the change if beneficial).