arrowd accepted this revision.
arrowd added a comment.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 4 2019
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
Dec 9 2018
Dec 8 2018
Dec 7 2018
Refactored for current git/master.
Dec 6 2018
This revision was not accepted when it landed; it landed in state "Needs Review".
Dec 5 2018
Updated as requested.
Dec 4 2018
undesirable qWarning() removed
Dec 3 2018
FIxed and streamlined version.
Also, considering that "session" in `Core::initialize` is user-specified and defaults to an empty string, please do not use a 100% deterministic name,
No, it went beyond that: the original underlying principle was "don't assume or hardcode /usr/local anywhere, use whatever install prefix the user specified".
Dec 2 2018
Actually, issues with clang temp files is why I started to think about this kind of change but ultimately I realised it didn't seem such a bad idea at all to put all KDevelop-related temporary files in a dedicated location. I often clean out a bunch of KDevelop's own temp files that were left behind, e.g. after a crash. I just didn't mention them because they're negligible in size (and I purge before their numbers really start to grow).
On Linux quite possibly too, I think many packaging systems install into some temporary dir and then copy the deployment out of there for archiving.
Dec 1 2018
The python script changes were committed to the master branch as requested (db05710cb6931a7b44d7fc70bfcfe75c7ccc9f4a).
Nov 30 2018
The change doesn't change the default, but why would using '/usr' (instead of '/usr/local') be worse than using 'c:\Program Files' under MS Windows?
Nope. It *does* change the default if KDevelop's install prefix is not /usr/local.
Nov 27 2018
David, it seems our posts crossed, or did you actually see the new version I just uploaded?
Fixed the AppleTerminal oversight in the non-Apple lldbrc.
Nov 26 2018
A more complete draft:
bump?
Nov 25 2018
You will notice that I plan to maintain an option to disable the Apple-specific behaviour for anyone who depends on the current behaviour (that includes me, but your script would also continue to work). Cf. the APPLE_FORCE_X11 option
Allowing negative prios makes sense.
Nov 24 2018
Nov 23 2018
Can we set DATAROOTDIR=/Library/Application Support/KDE so that everything remains nicely bundled?
At that time hinting with freetype wasn't state of the art due to patent issues, but that has changed with the v40 engine in freetype 2.7.
The current KCM already has a control for that.
Found this by accident, and had only one immediate thought
That'll probably be when we move to Qt6.
Nov 22 2018
includes the root cmake file changes.
a find_packge for `KF5::WindowSystem` is missing in the root CMakeLists file.
Can you rebase it over the last master branch ?
FWIW, anyone can request changes to a review, but also accept it. And while I would probably not take that as a green light to commit unless it comes from a known KDE dev it *does* go to show demand/need for a change. And hopefully, confirmation that it doesn't only work for the author.
Refactored for the standalone DrKonqi repo and disabled the integration testing on Mac.
Sorry, I had updating this on my list but it drifted to the bottom...
Nov 21 2018
Actually, I realise this patch too is a somewhat stripped down version of a patch I've been using for a long time in my MacPorts packaging for Okular:
@rjvbb what do you say? makes sense?
This change does more than just enabling hidpi support in the plist.
Nov 20 2018
Found back my ML post entitled
("compiledb-generator and the generic Makefile proj.manager"). Francis Herne replied
*this*:
That must have been magic code then, quick, try to catch it, we all want that ;)
Not supported, since in your case KDevelop simply does not know a compile_commands.json exist,
Nov 19 2018
Well, apparently the contextmenu CAN change during a session (at least on Mac and when I open it in different opened-at-session-load documents when the initial project load and parsing activity is still in progress).
This implements and uses my idea of an ecm_add_<lang>_compiler_flags_if_supported function set for C and C++. It uses compiler ID+version conditions to determine if flag(s) are supported when those conditions are known and reliable - otherwise and only then does it resort to querying the compiler.
E.g. I would have expected before looking at things that each view has their own separate context menu instance, possibly even created on the fly per display :)