thanks, applied to 5.4
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Sep 20 2019
done now, thanks a lot!
I'll commit this using QFileInfo instead of going through QDir.
Sep 17 2019
Scrapping this for now, since I have a few improvements on this, but it needs to be reworked. Ill make a PR with updated version on GitLab instance.
Sep 11 2019
I would like to get this merged in if possible. The work discussed for flushing out future deadlocks should also be done, but deserves its own ticket.
Sep 10 2019
Thanks @kossebau for the review. I will create a review request at the kirigami repo.
I would propose though to add this template to the kirigami repo though, so it is also available to people using the kapptemplate tool and using a plain text editor (e.g. Kate).
There is the ECM macro kde_package_app_templates from https://api.kde.org/ecm/kde-module/KDEPackageAppTemplates.html for this purpose.
Given the big KDevelop & Kate share plugins stuff never took off, I think we shall keep them just in kate.git, this will allow to do even more "experimental" stuff in the future like having some extra interfaces for Kate specific stuff that doesn't need to keep BC.
Aug 27 2019
- outputfilteringstrategies: Removed unused include KDir
- Created private implementation of ScriptErrorFilterStrategy
- executescript: fix setting working directory to OutputView
Aug 26 2019
In D22854#517776, @apol wrote:Have you reflected on what users need changing or we're just adding this because it's possible?
I'm not opposing having this, but if something can be improved, I'd improve it for everyone first.
Aug 24 2019
Have you reflected on what users need changing or we're just adding this because it's possible?
I'm not opposing having this, but if something can be improved, I'd improve it for everyone first.
Aug 23 2019
This functionality would be great.
Aug 22 2019
In D23321#516037, @apol wrote:In D23321#516025, @kossebau wrote:In D23321#516020, @apol wrote:Don't mention the ps desktop file as the executable
It was mentioned on purpose though, cmp. commit message of ab22ca659cf337fc1de01d69b0ced949156f01e5 (result of discussion on KDevelop with @flherne )
The reason there is weird. When you press "launch" on the software center you expect to get the IDE, not an empty list of sessions.
Aug 21 2019
This patch looks like it should work as intended to me :)
In D23321#516034, @apol wrote:BUG: 410687
In D23321#516025, @kossebau wrote:In D23321#516020, @apol wrote:Don't mention the ps desktop file as the executable
It was mentioned on purpose though, cmp. commit message of ab22ca659cf337fc1de01d69b0ced949156f01e5 (result of discussion on KDevelop with @flherne )
BUG: 410687
In D23321#516020, @apol wrote:Don't mention the ps desktop file as the executable
Don't mention the ps desktop file as the executable
From what I understood, this is effectless, as _ps is referenced by <launchable>. We need to check with @mak here.
Yep, according to @mak, this should work.
Aug 20 2019
Aug 18 2019
Great! You can Abandon this revision from the Add Action... menu above the comment field if you'd like (you can always re-open it later if need be).
Aug 17 2019
In D23212#513604, @ngraham wrote:result: Git Stashes is visually grouped with Branches... and is not clickable
What you're objecting do is actually just the way menu section headers look in the Breeze widget style. I agree that it causes confusion and visual problems, but it should be fixed there, not here in KDevelop.
Here's the applicable Breeze code that draws these headers https://cgit.kde.org/breeze.git/tree/kstyle/breezestyle.cpp#n4741
Would you like to have a go at improving it there?
result: Git Stashes is visually grouped with Branches... and is not clickable
Aug 14 2019
I will look into it next week. The used icon is bogus. I was hoping for some input on that :) But i liked the idea of an icon in general.
Aug 12 2019
Maybe it would make sense to move the whole dialog into git plugin's code.
Aug 11 2019
In D23038#510320, @kossebau wrote:@pavelp Hi from a more recent contributor to KDevelop, good to see you back again once more and care for your former work :)
Hi, thank you, I'm happy to be back!
@pavelp Hi from a more recent contributor to KDevelop, good to see you back again once more and care for your former work :)
Aug 9 2019
Aug 6 2019
I created some screenshots. Icon ist in the line edit (near the mouse pointer in the first picture).
I hope it is ok to add you as reviewer directly as you orchestrated the last commit from me in this area.
Aug 2 2019
Jul 31 2019
Jul 26 2019
I have been mega busy for the last while and intend to contribute more to this project when my situation stabilizes in like two weeks. Whenever you have time, I would definitely be interested to hear what sort of challenges you have come across through experimentation. An issue which I have suspected from the onset is actually determining all that needs to be protected by DUChain's lock and those which don't since KDevelop source makes use of these locks so liberally. I'm wondering if in your experimentation there are open questions about the DUChain locking scope.
Jul 25 2019
Work-around pushed as 8a18a08cf17c85000c7082d5192855430a519bab , seems to pass build also with neon ci and the gcc 7.4.0 there.
Jul 24 2019
Seems the introduced QStringLiteral as default argument here in the template method executeCompletionTest() makes ubuntu bionic's GNU 7.4.0 C++ compiler screw up. At least there is some timely coincidence that the KDevelop builds on neon CI started to fail after this commit, with this error:
05:00:37 [100%] Building CXX object plugins/clang/tests/CMakeFiles/test_codecompletion.dir/test_codecompletion.cpp.o 05:00:37 plugins/clang/tests/CMakeFiles/test_codecompletion.dir/build.make:62: recipe for target 'plugins/clang/tests/CMakeFiles/test_codecompletion.dir/test_codecompletion.cpp.o' failed 05:00:37 make[4]: Leaving directory '/workspace/build/obj-x86_64-linux-gnu' 05:00:37 /tmp/ccrWtnBp.s: Assembler messages: 05:00:37 /tmp/ccrWtnBp.s:65174: Error: symbol `_ZZNK12_GLOBAL__N_1UlvE_clEvE15qstring_literal' is already defined 05:00:37 /tmp/ccrWtnBp.s:68144: Error: symbol `_ZZNK12_GLOBAL__N_1UlvE_clEvE15qstring_literal' is already defined 05:00:37 make[4]: *** [plugins/clang/tests/CMakeFiles/test_codecompletion.dir/test_codecompletion.cpp.o] Error 1 05:00:37 CMakeFiles/Makefile2:18121: recipe for target 'plugins/clang/tests/CMakeFiles/test_codecompletion.dir/all' failed 05:00:37 make[3]: *** [plugins/clang/tests/CMakeFiles/test_codecompletion.dir/all] Error 2
from https://build.neon.kde.org/job/bionic_unstable_extras_kdevelop_bin_amd64/220/console
Jul 22 2019
Jul 21 2019
In D22559#498486, @aaronpuchert wrote:In D22559#498026, @kfunk wrote:I do not think bumping versions "just because " has any value.
I kind of agree here. Unless we have features that we know are only available with a certain version, we might needlessly restrict how people can build this. They might assume we have a good reason for choosing that specific version and that older versions can't possibly work. When I package stuff for openSUSE, I would never try decreasing minimum versions of dependencies, because I assume that these are actually the minimum. On the other hand, I regularly stumble across software that doesn't specify minimum versions for dependencies, but assumes it's "reasonably recent".
Jul 20 2019
In D22182#495823, @mswan wrote:Also, in spite of what I said earlier, I think the explicit DUChain locking should be done and there eventually should be some work done to determine which objects will only interact with one specific DUChain per instance of that object, i.e. an object that should reference a specific DUChain, e.g. ClangSupport. We could make the first pass at this involve replacing all of those DUChainReadLocker lock; lines with DUChainReaderLocker lock(DUChain::lock());, [...]
Overall I think this is a good idea, although we need to figure out some details. Could you either remove commented out flags or add a comment why we have them (commented out)?
I don't know what would be required to support multiple DUChains, but it seems plausible that they can be locked separately. In this case it would help to have the explicit argument, I guess. It could even be inevitable, when there is no single global DUChain anymore.
In D22559#498026, @kfunk wrote:I do not think bumping versions "just because " has any value.
Can we have a test for this?
There is another condition here: `if (lastShownMenu)`. So if the QMenu object instance got deleted
Jul 19 2019
Add rtti flags since they affect defines.
Prefer not duplicating code.
Just do the simple thing. Copied the one line of code due to
the awkwardness of preprocessor directives inside template lists.
As the person who raised the Debian Stretch issue last time, I don't think it's worth caring about now that Buster is released.
Sorry for my conservative thinking again: Debian Buster (10) is still /very/ fresh; it was just released a couple days ago. The former "oldest" supported distro was Debian Stretch (9) with Qt 5.7 and KF 5.28. That'll stick around for some time.
(Using phabricator to make sure people are triggered for this central change)
Jul 18 2019
In D22424#497415, @rjvbb wrote:I'll activate the debug trace on change of my lastShownMenu though
I'm doing this (in my patch from D16882 which still applies after reverting D22424):
+ if (menu != lastShownMenu.data()) { + if (lastShownMenu) { + qCWarning(SHELL) << "Added items to new contextmenu" << menu; + } + lastShownMenu = menu; + }under the assumption that this will print a warning (enabled in qtlogging.ini) when lastShownMenu will be updated but not the 1st time a ctx menu is opened. Is that assumption wrong, because I'm not seeing any warnings after disabling the CTags menu (and restarting KDevelop for good measure).
I'll activate the debug trace on change of my lastShownMenu though
In any case there isn't much else you can do; stepping through the code with a debugger is near impossible (the menu about-to-be-opened will already have grabbed mouse and keyboard focus so you'd need to display remotely).
In D22424#497361, @rjvbb wrote:How do you think I debugged the situation? I did the same thing in Kate too.
Please add a line qDebug() << "Showing context menu" << menu; to KDevelop::TextDocument::populateContextMenu.
In D22424#497316, @rjvbb wrote:Since we're dealing with "please read/see again": idem for my comment :P which only states that a single QMenu instance is being (re)used. I've never seen it change
>> > FWIW I got to look at the KTE implementation of the context menu mechanism that is used here. It indeed uses and reuses a single QMenu instance (there's even a comment in the code about that). >> >> Please give links into the code, as I am lost what you exactly refer to here. > > see the source of `KTextEditor::ViewPrivate::contextMenu()`. The ctx menu is in fact managed by KXMLGUI. The context menu is queried every time from KXMLGUI that method is called. So if KXMLGUI internally decides to recreate the context menu, you get another object the next time. Please see again the description of this very bug.
In D22424#497271, @rjvbb wrote:The other option would have been to release 5.3.3 without a fix for ctags plugin users, rendering it unusable for people relying on packaged kdevelop.Erm, aren't you forgetting about my patch which could have been applied to the (EOL!) 5.3 branch? That does the job just as well and would have left time to find a fix for #409858 in time for the next release.
The other option would have been to release 5.3.3 without a fix for ctags plugin users, rendering it unusable for people relying on packaged kdevelop.
In D22424#497204, @rjvbb wrote:Friedrich W. H. Kossebau wrote on 20190717::00:12:44 re: "D22424: TextDocument: remove actions from contextmenu on hide already"
This revision was not accepted when it landed; it landed in state "Needs Review".
Hmm, since when is this acceptable?
Friedrich W. H. Kossebau wrote on 20190717::00:12:44 re: "D22424: TextDocument: remove actions from contextmenu on hide already"
Jul 17 2019
Jul 16 2019
In D16882#494867, @rjvbb wrote:I could try your solution, of course, but what annoys me is that it comes months after I worked on mine.
In D22424#496112, @kossebau wrote:In D22424#494980, @rjvbb wrote:However, the patch has a side-effect: I'm getting messages like this each time I switch or open documents:
kdevplatform.shell: Broken text-document: QUrl("file:///opt/local/var/tmp/kdevelop-tmp-505-%7Bf793a513-f14e-47b9-8448-06ca72900c04%7D/kdevelop_Q27955.patch")This example is for a file that indeed doesn't exist, but that I also do not have open (so WTH?!) but I also get it for files that open perfectly.
I fail to see an immediate reason for this, so I'm back to running my own patch.
Interesting. Not seen here, but giving this some stress testing now. The kdevelop_xxxxx.patch is coming from the diff review system creating text document objects for displaying the diffs, but I also see no direct relation ship to this patch here. Will poke around a bit,
Jul 15 2019
update to first review feedback
Thanks for first review & testing.
In D22456#496025, @apol wrote:LGTM can you land it?