Friedrich W. H. Kossebau wrote on 20181115::17:41:58 re: "D16882: [KDevelop/Shell] prevent duplicate added contextmenu actions"
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Nov 15 2018
_If_ it is found that the root bug is in KTextEditor, sure.
Sorry to say, but you want to add the feature, so you would have to scratch this itch
So multiple contextMenu signals arrive in Kate too except they don't have any visible consequence.
Let's see what the KTextEditor devs have to say about this. I'd rather stay away from getting too familiar with that framework, KXMLGUI even more.
Please, let's find the root causes and fix things at the base instead of adding such
Nov 14 2018
Patch cleaned up, stripped the LevelDB and Kyoto backends that never satisfied me.
I did leave the original file-based storage backend, not because I think it has to be preserved if this ever gets in but to provide a quicker way to compare performance (and behaviour if ever someone testing this runs into issues).
Aaron's last suggestion made me realise I forget a few things when porting the patch back to using QSocketNotifier.
The shutdown procedure was intended to (and now does) include closing the signal pipe, verifying the descriptor before writing to it makes sense. So does handling failure there by re-raising the signal with the default handler.
I thought it would be even more robust to move the actual write into the if and check whether it succeeded, after all we want to be certain that these signals are always handled.
Nov 13 2018
This adds a safety against a race-like condition I've seen happen once in KDevelop.
It may not be required to make m_mWin a QPointer but it seemed sensible to do.
Ah, yes, I'll have to remember to clean it up and keep only the LMDB backend.
Nov 12 2018
updated as requested.
Don't worry, the commit message would have looked like that.
Or rather, it will say
Don't worry, the commit message would have looked like that.
Nov 11 2018
Nov 10 2018
Done by someone else by now.
refactored for master/head
Nov 9 2018
I'm a bit confused... I thought KDevelop had much more advanced plugins/features for this? What does KDevelop need this old plugin for? Non-C/C++ languages or what?
Merged in changes from an older attempt I forgot about (apologies!).
Nov 5 2018
Exactly what is the feature we're talking about?! I highly doubt that Qt will NOT show the popup window with the what'sthis text when you request it via
Nov 4 2018
I actually like the feature as a way to provide more complete (and better formatted?) contextual help for UI aspects that could use it, without obliging the user to open the handbook. AFAIK you have to find the relevant paragraph or section in there yourself, so it's less than ideal in terms of optimising productivity. Handbooks *are* important ("RTFM"...) but I think the whole KDE help centre feature could use a good overhaul too.
I would prefer to set this in the ui file: The maximum is already set to 99.
For the tooltip stuff: I am not sure if that is not inconsistent with the remaining stuff on these pages.
Oct 29 2018
... you want to add the feature
Oct 28 2018
But do they change things behind our back after this method has been entered?
Oct 25 2018
How about
Oct 22 2018
updated for the current git/head.
Oct 20 2018
One more thing: could establishing the project file name not simply be done by a method in the ProjectController class rather than by a dedicated class? Because, in how many different functions would you split that logic?
Arguably that still stands, but it's outside my area of expertise to comment on it.
The current patch I still cannot oversee (though also due to the existing code), so I would have to grab the -1 sign for now if on the jury.
updated as requested.
Oct 19 2018
Drops the potentially unsafe qDebug output in the signal handler, makes handlingSignal an std::atomic_bool (since we can use locks here anyway) and adds copious comments.
Still working on this and waiting on more background info from the Qt Interest ML.
Oct 18 2018
You can't use std::atomic_flag, because it's an `int`.
Any idea how we could test the race-condition scenario? I've been trying by re-raising the signal from just before and just inside the if(handlingSignal) loop and until now it has always been behaving as expected (= the if is executed only once).
Sorry for the delay; I thought this would be straightforward and then ran into questions...
This is determined by hardware support. With relevant architectures I meant architectures on which Qt/KDE applications can run, like x86, PPC, ARM. > These all have lock-free `std::atomic<bool>`, as far as I know.
I guess you can also use `std::atomic_flag`, which is guaranteed to be lock-free, and should offer enough functionality for our use case.
...
Not in the middle of an assignment, but between the read in `if (!handlingSignal)` and the write `handlingSignal = 1` it can be interrupted. That's not atomic.
Oct 16 2018
At least std::atomic<bool> is lock-free on all relevant architectures. (I'm aware that the standard doesn't guarantee it, probably because of some embedded architectures.
Updated as suggested
Where in the code would you want a documentation of the intent of this change?
The best place might be a in the handbook or the project import wizard GUI ... but we're in string freeze, no?
Oct 15 2018
- Dropped the semaphore-based alternative as it would only be less resource-intensive when manhandling pthreads
- moved almost everything back out of the CorePrivate class, keeping only the slot required for QSocketNotifier operation.
- dropped the SIGHUP shortcut, to be resubmitted in the future
I would recommend to just not think about the Windows requirement, if you cannot test it anyway.
If there is no solution which does not require two different code paths for handling this problem, I'm against merging this, non-conformant old behaviour or not, sorry.
- Why does this patch look so much more verbose than the solution proposed on http://doc.qt.io/qt-5/unix-signals.html?
In D16218#343340, @arrowd wrote:
Adds the missing #endif
Re: the testing I did on FreeBSD: that's with a dedicated demonstrator; I cannot currently build KDevelop5 there.
Oct 9 2018
I'd be pushing less if this hadn't already been committed and then reverted because of an issue that got through the initial review process.
In absence of instructions to the contrary I'll interpret Milian's "feel free to respin" as "feel free to recommit", and push a commit during the day. This has been waiting to be re-applied long enough.
Oct 3 2018
Sep 29 2018
Another fix for the generic Makefile project manager; I had missed the fact that URLInfo::isDir is undefined when URLInfo::isValid is false. This lead to personalised project files of the type `/path/to/projectFoo/projectFoo.kdev4/customname.kdev4```.
Updated as discussed. This variant is less different from stock code than my previous proposal. It complements the current checks with a comparison using canonicalised paths. As a result it should catch all cases that are not caught by either one of the comparisons when performed in isolation.
I think there might be a simpler solution to that situation
Sep 28 2018
Updated as discussed: any previous project settings file in .kdev4 will be removed if and before overriding/writing it (instead of simply trashing the entire .kdev4 directory).
I'm doing it now and will test it as part of this patch; afterward there are 3 options
Attributes are not keywords — they're a (C++-specific) generic syntax that was introduced with C++11. Again, the idea is not starting from scratch, but introducing small changes that reduce the number of errors programmers
In any situation where we'd already be overwriting the settings file but where there are other projects defined in the same sourcetree. The summary of this DR argues how and why that could be the case.
Sep 27 2018
This fixes a mix-up that slipped through and above all, puts deleting the .kdev4 under user control.
Apparently there are situations where this directory should be deleted because its presence (empty) can confuse the project manager when overwriting an existing project (?!, T6262). /Methinks that's something that must be fixed in the confused place(s), not worked around by removing .kdev4. The whole point of this patch is to allow the creation of multiple projects in a single source tree, after all.
Exactly how can the project manager be confused when you don't remove the .kdev4 directory, knowing that it will be recreated almost immediately after deleting it? (In any case I don't see how it could *not* be recreated given that it will hold the new settings file).
You can use comments <https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/>, or `__attribute__((fallthrough))` in C.
Using Q_UNREACHABLE