https://bugs.kde.org/show_bug.cgi?id=385640
--- Comment #7 from RJVB <rjvber...@gmail.com> --- (In reply to Kevin Funk from comment #6) > Yes. It told me you haven't fully understood the problem I've understood (accepted) that the complexity of the plugin/toolview architecture is in large part beyond me, just like you yourself have accepted that the itemrepository issue is beyond you. I may be wrong about that, but I've been looking on and off at the seemingly random aspect of the documentation toolview for probably more than a year now (and I've been putting up with it since v4.x). And so what if we figure out where the creation comes from. We put the "don't do this when shutting down" check there? > hacks which inevitably may cause other crashes (i.e. when DocumentationView > is being destructed again, trying to cleanup resources which were never > initialized properly). Seriously? There's only a default dtor, which doesn't know about anything allocated dynamically through the ctor after the early return. > > Nothing done in that ctor is crucial unless you use the instance, and > > that's not going to happen. > > And you know that it isn't used based on...? How can you know it's not being > used if you don't know where/when the class is being instantiated? Ok, can you explain how a toolview could use the stuff it sets up for letting the user interact with it after the program exit, if it cannot stop that process? I'll give it to you that the return was maybe a bit too early and should rather exclude only the invocation of the initialisation method. In practice I've seen the warning print a few times without any further crashing. I wouldn't have committed this without testing. > https://woboq.com/blog/nice-debug-output-with-qt.html -- grep for > "backtrace" -- you can enable them for e.g. warnings exclusively. That might be useful for critical messages, but still, Linux only apparently, and I don't think you have this kind of control in the code just before a specific log output. Or is there a way to do that? > Please note that "drawn-out" review procedures are only necessary in > "special cases". They tend to get drawn out for other reasons too, ultimately leading to a core dev "remote controlling" what boils down to one of his clones to write a piece of code. It's just more efficient to skip the remote clone bit in those cases. > Yes, or the original author could have at least committed that hunk > separately, with a proper commit message explaining what this change does. I am the original author ... can I take that as a green light to commit it? (I kind of expected that Friedrich would commit this, as it's a fix for something he introduced.) -- You are receiving this mail because: You are watching all bug changes.
