- User Since
- Apr 15 2016, 12:33 PM (113 w, 5 d)
Sat, Jun 9
Sun, Jun 3
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.
Sat, Jun 2
LGTM - but is QtNetwork ever installed as a separate package rather than as a part of QtBase?
Mon, May 28
If no objections are made I'll interpret Milian's "feel free to respin" as "feel free to commit" in a couple of days.
May 18 2018
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?
May 15 2018
May 9 2018
May 8 2018
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.
May 7 2018
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?
May 2 2018
Apr 30 2018
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.
Apr 18 2018
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.
Apr 16 2018
Actually, no. I haven't been following that part at all (and am taking 2 weeks off of intensive dev stuff ;) )
Apr 14 2018
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.
Apr 7 2018
Unnecessary rebump, pardon, rebase.
Apr 5 2018
That was quick! :)
Apr 4 2018
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.
Apr 3 2018
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?
Mar 28 2018
Mar 26 2018
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.)
Mar 25 2018
That's because of the MSVC remarks you made inline?
Mar 24 2018
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?
Mar 22 2018
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?
Mar 14 2018
Mar 11 2018
add missing context (patch unchanged)
Add missing context (patch unchanged)
Mar 9 2018
Mar 7 2018
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.
Mar 6 2018
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.
Mar 5 2018
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"?
Mar 1 2018
Feb 25 2018
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 :)
Feb 21 2018
Feb 17 2018
Feb 11 2018
Curious, I cannot give a green light (too), please consider that done...