[Akonadi] [Bug 456923] Outgoing e-mail from GMail account to smtp.gmail.com sometimes hangs
https://bugs.kde.org/show_bug.cgi?id=456923 malcolm macleod changed: What|Removed |Added CC||mmacl...@webmail.co.za --- Comment #3 from malcolm macleod --- I have to restart akonadictl every time I want to send an email out of kmail from one of my gmail accounts. This is a usability nightmare. Is there any info that can be given to get this resolved? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 393808] New: Breakpoints are sometimes set using a path that confuses GDB (and potentially other tools?)
https://bugs.kde.org/show_bug.cgi?id=393808 Bug ID: 393808 Summary: Breakpoints are sometimes set using a path that confuses GDB (and potentially other tools?) Product: kdevelop Version: 5.2.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: mmacl...@webmail.co.za Target Milestone: --- Today I ran into a situation where no breakpoints were working inside kdevelop, breakpoints all just said "pending" even though gdb was otherwise functioning. After some bother I managed to track this down to my use of a linux "bind mount" 1) I have a folder "/home/foobar/blah/Development" 2) I have a secondary mount of this folder "/Development" 3) Kdevelop project and all tools etc. use "/Development" everywhere 4) However I accidentally opened my kdevelop project through "/home/foobar/blah/Development" instead of "/Development" 5) When setting breakpoints kdevelop is passing the path from which the project was opened to gdb "/home/foobar/blah/Development/src/foo.cpp" instead of "/Development/src/foo.cpp" 6) This confusingly leaves gdb unable to find the file, even though both paths are valid (presumably because the paths are hard compiled into the debug information or similar) While this is how it presented in this specific case, I do wonder if other tools may have similar issues - so perhaps (ideally) kdevelop should warn if the paths inside the project file and the path from which the project are opened differ from one another. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386103] Frame stack depth hard coded to 20
https://bugs.kde.org/show_bug.cgi?id=386103 --- Comment #1 from malcolm macleod --- On closer inspection I see I slightly misdiagnosed the issue. If I change kdevelop into a small windowed mode where "20 stack items" is taller than the window, then I get a scrollbar and the additional stack items appear upon scrolling. If I am running fullscreen then 20 stack items fit comfortably without a scrollbar showing, and at this point there is no way to get more stack items (except to shrink the window). So I guess the real issue then is that this should be handled differently for larger window sizes - though I still think a way to just increase the default might also be good. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 386103] New: Frame stack depth hard coded to 20
https://bugs.kde.org/show_bug.cgi?id=386103 Bug ID: 386103 Summary: Frame stack depth hard coded to 20 Product: kdevelop Version: git master Platform: Other OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: UI: general Assignee: kdevelop-bugs-n...@kde.org Reporter: mmacl...@webmail.co.za Target Milestone: --- It seems the frame stack depth to display is hardcoded here: https://github.com/KDE/kdevelop/blob/f5b25083620dc518f5fa5ed3e3e237390614d7db/kdevplatform/debugger/framestack/framestackmodel.cpp#L295 In template heavy code 20 is often not enough to see what is going on properly, especially when e.g. breaking a multithreaded program mid execution and then wanting to step through all of the threads to view what is going on at the time. It would be good as a simple solution if at a minimum this "upper limit" value could be increased via the settings/preferences, while 20 is sufficient for many people I'd prefer to set it to 40. A more complex solution could perhaps both have a configurable "upper limit" value as well as a "..." button at the bottom of the stack where the user can click to fetch more items. -- You are receiving this mail because: You are watching all bug changes.
