Superseded by https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/466.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jul 22 2023
Dec 18 2022
From https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html:
The generated source file will be added to the variable with the name <sources_var_name>. If the given argument is a target though, instead both the generated header file and the generated source file will be added to the target as private sources (since 5.80). The target must not be an alias.
Aug 19 2022
Doesn't seem to be relevant anymore.
May 3 2022
The replacement merge request was just merged into release/22.04. Therefore this review is obsolete and should be abandoned.
Nov 27 2021
Created the text/x-objc++src merge request here: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/158. But no one has even commented on it in 1.5 months. The maintainers of shared-mime-info don't review merge requests regularly lately.
Oct 31 2021
@mswan, there is renewed interest in these fixes: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/277. But we no longer use Phabricator for code reviews. Would you like to convert this review into a merge request at KDE's GitLab instance yourself? Or let someone else do that?
Oct 13 2021
Well, that's what I get for trusting my memory, I didn't even realise at first that you'd been jumping on a PR that I started. :-/
Oct 12 2021
In D15532#678830, @rjvbb wrote:Is text/x-objc++src the canonical name used in macOS or is there some other reason to select one of these names?
No idea to be honest, nor how I'd figure that out...
In D15532#678830, @rjvbb wrote:Theoretically, Objective-C headers could be detected with #import magic, but that wouldn't be reliable, because Objective-C headers can start with a comment or with #include, which share C's syntax. So I am inclined to remove the references to text/x-objchdr from KDevelop.
I'm pretty certain I have a patch that improves ObjC support in KDevelop, and also that I put it up for review at some point. Maybe it was never incorporated because of the mime info not being in the mimeinfo database, I can't remember.
Here is your patch: D15530. One of your comments in that review is:
Removed the x-objchdr mimetype (to avoid additional confusion what a .h file could be) and added my current x-objc+src definition to kdevclang.xml .
This comment sort of resigns to remove mentions of x-objchdr from KDevelop's code.
Could you please cancel that email and paste its contents in a Phabricator comment?
Oct 11 2021
In D15532#678827, @rjvbb wrote:In the reply I thought I sent yesterday (it got held up for moderation for the kdevelop-devel ML; I assumed it was delivered to the other "reply-all" destinations):
René J.V. Bertin wrote on 20211009::22:00:04 re: "Re: D15532: [Astyle] Add Objective C to list of languages with formatters"
Igor Kushnir wrote on 20211011::17:30:08 re: "D15532: [Astyle] Add Objective C to list of languages with formatters"
In D15532#678825, @rjvbb wrote:
- Will create a KDevelop merge request that removes all mentions of text/x-objchdr.
I already indicated why I think that's not a good idea (but I can always just patch it back)
Igor Kushnir wrote on 20211011::12:38:18 re: "D15532: [Astyle] Add Objective C to list of languages with formatters"
If no one has objections or suggestions on this topic, I am going to create a shared-mime-info merge request tomorrow: this patch plus tests
Oct 9 2021
I would like to eliminate the following warnings from KDevelop's output:
Sep 16 2021
Update for those watching: I have just posted a new version of the script to Invent which uses vswhere.exe to locate the installed versions of Visual Studio. I'll be abandoning this revision since IMO vswhere is the best way forward. Check it out here: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/259
Aug 29 2021
In D18758#678707, @apol wrote:Let's abandon it, I'd be wary of bringing in such a big dependency into our codebase just like that.
Aug 27 2021
In D18758#678706, @arrowd wrote:So, do we want to get this in?
Short recap:
- Project::open() executes KIO jobs synchronously at the moment.
- To make the code asynchronous we need some 3rd-party library implementing futures, like QtPromise.
- The original bug that made me work on this is fixed already.
Should we abandon this?
Aug 26 2021
So, do we want to get this in?
Jun 21 2021
Jun 20 2021
Indeed, that must have slipped me at the time. Will not wait for the next Monday now ;)
@kossebau Can this now be closed?
Jun 8 2021
Nov 4 2020
yes, I guess if you open a project that uses that in qtcreator, you also wouldn't be able to open the debug.h header then
ecm_qt_declare_logging_category adds only the debug.cpp file, but not the debug.h file. Is this a bug in ECM?
Generated files should usually be added to the corresponding cmake target - if you don't then yes they won't show up after filtering the build dir (or when using a totally different path for the build dir).
I just noticed that when the build directory is filtered out, auto-generated headers, like build/app/debug.h do not appear in the Quick Open list. Apparently these headers are not pulled in by CMake targets. I think that losing these particular headers is not a big deal. But could this filtering remove more useful files from the list and the project tree? I guess not - because the auto-generated files in the build directory are not supposed to be edited and should usually be uninteresting.
Oct 19 2020
From https://community.kde.org/Infrastructure/GitLab: "Task management is transitioning to Invent/GitLab but most projects still use https://phabricator.kde.org for now."
AFAIK, Phabricator is being retired in favor of GitLab. Why not create an issue there? https://invent.kde.org/kdevelop/kdevelop/-/issues
Oct 18 2020
Oct 7 2020
Jul 23 2020
What is missing:
- Declaration with alias into grouped namespace are not processed: use Foo\ { const C as FooC };
- There is no test
- The mix between UseImportType, ParserUseImportType, DeclarationType is not clean
Jul 20 2020
Jul 18 2020
Jul 15 2020
Or anything directly in the zone of the active coding, like the konsole and code browser, to retain its active and focused status.
Maybe have a couple of panels take precedent like the project tab in use and anything vertical of the zone, breaking off any lateral distraction.
Better? It is using the active but unfocused color. It leads me to a question, how is what known to be active and focused, on my crappy mock up is seems rather arbitrary.
Yeah... Maybe use the lighter hover blue from other mock ups in sections that aren't focused on, like if I'm using the left panel I expect the UI to focus on the panels interface and not have the screaming deep blue in other sections. It's 3am so I'll sketch it up tomorrow and see how it turns out.
Seeing a main window with several tab bars (some toolviews, some multi-document views) makes me feel like there's too much blue. I feel like my eyes are being pulled in multiple directions.
Jul 14 2020
Updated. check images on description.
Yeah, I've been intrigued as what to do with it. Since this mock up is a straight rip off of @manueljlin I didn't give it much thought but now that I'm setting which styles are for what and where I need to update them.
I'm noticing that we have two tab styles here which do not appear to be used consistently:
Edit: Will update tab style to use full area.
Jul 12 2020
Jun 6 2020
In D17908#674690, @Petross404 wrote:Is vswhere included when VS is installed? Unless the user explicity installs it, it shouldn't exist. Am I wrong here?
Jun 5 2020
In D17908#674686, @sredman wrote:I suspect it's not necessary to ship with KDevelop: Either Visual Studio >= 2017 is installed, in which case the vswhere tool should be on the path, or VS is not installed, in which case the tool wouldn't do us any good.
I have installed Build Tools for VS2019 and the installation is at
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
I found this string inside HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\1eb19443 which honestly doesn't seem the proper key to extract this value but anyway.
In D17908#674685, @Petross404 wrote:Do we want to ship this with KDevelop? So that the .bat script can rely on this utility?
In D17908#492410, @sredman wrote:Actually, a pleasant surprise for today is that this whole mess of registry keys and environment variables is mostly unnecessary as of VS 2017, since Microsoft provides a tool which does all the locating work for us: https://github.com/microsoft/vswhere
May 6 2020
The test output:
2: FAIL! : Php::TestDUChain::classMemberVar() 'var->type<IntegralType>()' returned FALSE. () 2: Loc: [/home/hmitonneau/kde/src/kdev-php/duchain/tests/duchain.cpp(449)]
May 5 2020
I had a look at this again. Updated to latest master of both kdevelop and kdev-php just to make sure I didn't miss a commit in kdevelop that might have influenced this, but my tests still pass just fine. Furthermore, I don't see what your patch would fix. The change you made is in a code-path that's unaffected by property types, and if there is a crash there it should've triggered just the same before the change.
In D29444#663891, @zhigalin wrote:Are the trailing commas from T6804 supported?
Are the trailing commas from T6804 supported?
May 2 2020
Where?
May 1 2020
I've now pushed another patch which will suspend TUs to reduce memory consumption further.
Apr 28 2020
I've been addressing issues related to controller proxy instances surviving too long during shutdown and accessing stale memory.
Apr 23 2020
Apr 15 2020
I have compiled from scratch with kdesrc-build (with cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo). The duchain test still doesn't pass.
After some debug, it seems that m_gotTypeFromTypeHint is not always initialized correctly.
The following patch fix the problem for me:
Apr 12 2020
Don't just stop parsing files when shutting down, also ignore new document add requests.
Apr 11 2020
Updated and improved version:
- the registration with the ProcessController is done "JIT", just before enqueing the first document for actual parsing
- keep track of documents via the QUrls of IndexedStrings
Apr 9 2020
Hmm, this is odd.
Sorry for the very late comment...
Before this commit, the type of properties were deduced from the assign default value:
Since this commit, the type is <no type> if it is not explicitly specified (either in php7 style or in doc-comment)
Mar 27 2020
Mar 22 2020
Pushed in commit 4097c98f90020f4cf9990a0cf472fd5d34ff970f
Mar 17 2020
This addresses a few issues, notably by using a queued signal to trigger url (un)registering from the requesting (weaver) thread in the thread where the JobController lives too.
Mar 14 2020
Mar 9 2020
Mar 8 2020
I have started updating some of the photos and some text changes. I am really looking over what is there and what can be improved where.
Following https://cgit.kde.org/kdev-css.git/log/parser/CMakeLists.txt, it should fix Windows build and not fail Linux one
Mar 7 2020
Our discussion is about when to create the preamble for open documents. If I were to stop that job, I wouldn't get the AST, but I want the AST. I just don't want the preamble before I've started editing the file.
Mar 6 2020
In D18551#623098, @rjvbb wrote:As I said, I thought the possibility to cancel jobs could be a comprise (I don't get the impression you've been able to find one yet), but OK.