- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 27 2019
Jan 26 2019
It'd be interesting to have an estimate of how much faster this makes that initial parse.
This is in fact cmake's fault, or ECM's for not taking a cmake quirk into account.
There are mechanisms to ensure cleanup in any event by removing an open file on POSIX compatibles (close will then
See also https://phabricator.kde.org/D16894 which (initially) aimed to tackle this in a more general fashion.
Jan 25 2019
This version saves the original TMPDIR value, and adds a wrapper around QProcessEnvironment::systemEnvironment() that restores that original value. To keep changes to a minimum I've added that wrapper to the Core class itself.
Updated as discussed.
Where or how can I find what to put in the JSON comments?
I was referring to @mwolff's comment D17289#395163.
Jan 24 2019
Use qobject_cast.
As far as I know, using qobject_cast is faster than comparing class names, because it only compares metaclass pointers. Additionally, it allows subclasses.
If you don't use systemd, for example because you're not on Linux, there are certainly other tools for doing the same thing.
How does that systemd thing clean tmp dirs at runtime, IOW, how can it know it's safe to clean up a given file if the application that created it doesn't do something explicit to guarantee cleanup?
David, Andreas, any idea why the name column all of a sudden jumps to a larger width when the widget is used in a side-bar and you're making the view narrower and approach the minimum width? It works in our favour here because the end result is that the name column becomes about as wide as the view itself (and I ensure it won't change size again).
It just nags me a bit that I haven't been able to figure out why it happens...
Jan 23 2019
I completely forgot about this one, for some reason the patch was moved out of my active set (possibly because of lineheight calculation issues).
In D17289#395491, @aaronpuchert wrote:
The behavior is better now, thanks.
Jan 22 2019
the change to the headerfile was now redundant.
Well, that was "interesting".
I'm still going to try to fix this
Yikes, and I can reproduce that. Did you notice this with previous versions that used font stretch? (Probably not if stretch had no effect for the font(s) you tried it with...)
Jan 21 2019
This version uses letterspacing rather than font stretch, so works regardless of whether a stylename has been set on the font.
The discussion in that bug kind of petered out, unfortunately.
Oh sh@@t, I understand what's happening here.
Jan 20 2019
I don't see the squeezed text when using Breeze and Noto Sans. Am I missing something?
Final attempt at being a bit clever :)
One thing we might be able to do is use QFont::setStretch() to make the text a bit more compact. I'll follow that thought for a bit.
I agree that reducing the size column width isn't as easy as I thought. I find it takes up more space than necessary when horizontal space is at a premium and I was hoping to get a more compact read-out that can still be interpreted ... and that would show itself in full in a tooltip.
Jan 19 2019
If there's still enough room to show everything without a horizontal scrollbar, then we're still good.
tentative fix for "very narrow views".
Maybe we can incorporate some more intelligence here
Setting explicit sizes is best done in a mode that supports doing so... =/
Also, sections can be movable (again) now (I often like to see dates first, sizes 2nd).
I realised the 1st version introduced a regression. This update restores automatic sizing when the dialog is resized.
The fix currently has the effect of undoing any column sizing the user may have done before resizing the entire dialog, but that doesn't seem entirely unjustified. It won't be hard to preserve the interactive resize mode for sections that have a custom size but AFAIAC we can put off implementing that until there's a clear demand for it.
Jan 17 2019
Updated as requested.
Jan 15 2019
Jan 14 2019
Should I check if current master works as I intended, WITHOUT your patch, because it does not apply to current master.
Jan 13 2019
placeholder text + dropped manpageplugin hunk.
Jan 12 2019
Adds tooltip to the import dialog's "Installation Prefix" entrie widget.
Note that environment variables are per-process, not per-thread.
Milian Wolff wrote on 20190112::12:35:11 re: "D16882: [KDevelop/Shell] prevent duplicate added contextmenu actions"
Jan 10 2019
+++V
++V
Jan 9 2019
V3
Should I de-obfuscate and remove that lambda expression too while we're at it? Its body could be the body of clangBuiltinIncludePath() itself, AFAICT.
Updated as discussed in my previous comment. I've also followed flherne's suggestion to move the check for the reference file file into ClangHelpers::clangBuiltinIncludePath(). This does require some changes elsewhere because it can now fail (return an empty string).
In D17858#388948, @flherne wrote:Perhaps the check found in plugins/clang/clangsupport.cpp:185 should be moved into this function
Jan 4 2019
arrowd accepted this revision.
arrowd added a comment.
Dec 29 2018
Users shouldn't change the dependencies and expect things to work without a rebuild.
Dec 27 2018
Shouldn't these come from the project manager?
Dec 26 2018
Yes, I'm hoping that others will chime in here on this aspect too.
Again, I strongly doubt that you can build kdevelop and all of its dependencies without having pkgconfig installed. Someone using kdevelop for development with libraries that provide .pc files will almost certainly have pkgconfig installed too. So really, the platform argument is moot IMHO. But if you really want to push it: as a Mac user I can guarantee that we (as in developers working on Mac) will have pkgconfig installed through one of a handful of package managers which we'll also be using to install the libraries we need for our development. IOW, pkgconfig *will* be installed in a more-or-less standard location (certainly considered standard on the local set-up) and you can bet it's on the path. Having used cygwin extensively in the past I am certain pkgconfig will be on the path in that universe too, and in the end that's all that counts (if you cannot configure the location of the executable).
Dec 25 2018
Continuing from a few thoughts I launched on the original T10209, mainly aimed at keeping the project configuration dialog's left side-bar as unencumbered as possible. I think the current plugin could be merged into the customdefinesandincludes plugin because it provides a programmatic way to add include paths and/or defines.
This plugin may be useful for any c/c++ project. For example indexer for CMake project KDevelop (sources of ide) don't see all required includes for me.
That could be useful for project managers that lack proper build system integration (IOW, there shouldn't be much use for it with the CMake and QMake project managers?)
Dec 14 2018
Dec 11 2018
No objections?
Dec 10 2018
The current master is fontconfig only, since there is no way to leave the fontconfig specific parts out of QML.
It's not clear who wrote that about being fontconfig specific (or the IMHO incorrect suggestion that Freetype is implemented 3x).
Why not make these separate KCMs? I don't know how usual it is to open just the fonts KCM (kcmshell5 fonts) or if the vast majority of users gets to that config page only via the systemsettings app. For those you don't need to implement a tab-like mode switch because systemsettings already provides that for different KCMs. And users who go through kcmshell5 can probably learn quite easily to modify their commandline.
This approach also means you don't have to worry about whether and how to implement mode persistence.
I can commit if you want (if nobody else beats me to it).
I'm not finding any information on a QStringLiteral header file in the official documentation; it certainly doesn't exist in Qt 5.9.7 yet. AFAIK the header to include is the one for QString.
Better late than never: I also figured out how to make the plugin's toolview display correctly in KDevelop: https://commits.kde.org/kate/3cd03f408eed2d66ae008fb8349f8b5af24260e9