[kdevelop] [Bug 382289] Long-standing bug: Bookmarks are often forgotten.
https://bugs.kde.org/show_bug.cgi?id=382289 --- Comment #5 from Tim E. Real --- Hi thanks for taking a look. The bug remains very elusive, I still cannot pin down exactly what triggers it. Here is one thing that does usually trigger it, virtually every time: Occasionally KDevelop will crash. When I restart KDevelop and open the project, it will ask if I want to clear the cache. When I do that, I often find that my bookmarks are missing, or very messed up - being moved around especially into 'bunches' where I never originally placed them. It is not entirely clear to me that KDevelop is at fault. Rather Kate might be at fault. Possible? I thought I had mentioned this before, but I could swear that once I caught Kate running alone forgetting its bookmarks. But alas, it has been too long to be sure. Overall the bug is an annoyance but not a showstopper. May KDevelop continue to Rock! Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 412707] KDevelop leaves hundreds of megabytes of temp files if it crashes
https://bugs.kde.org/show_bug.cgi?id=412707 --- Comment #9 from Tim E. Real --- Ah yes. Good idea I suppose, since we do still have to manually clear the temp files out after a non-lockup crash to the desktop. The trouble for me was when KDevelop occasionally crashed by locking up the computer, then I had all those temp files left over upon reboot. (I work on huge projects, maybe I need more RAM). But this 'leftover temp files upon reboot' problem seems to have gone away for me. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 412707] KDevelop leaves hundreds of megabytes of temp files if it crashes
https://bugs.kde.org/show_bug.cgi?id=412707 --- Comment #7 from Tim E. Real --- I suppose this report could be closed now, as the particular reported problem has gone away, with respect to the leftover reboot tmp files. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 412707] KDevelop leaves hundreds of megabytes of temp files if it crashes
https://bugs.kde.org/show_bug.cgi?id=412707 --- Comment #6 from Tim E. Real --- Hm, you are right. I put a file in there and it was gone on reboot. It surely was not working at the time of this bug report. In fact at the time, Konsole was also leaving a lot of trash that was not cleared even on reboot, (the file dates and times proved this) so I filed a report with them as well, and they fixed leaving any trash at all. So that is why I was having so much trouble with KDevelop. On reboot tmp was not clearing KDevelop files, causing big trouble. I'm on SUSE Tumbleweed, so things just gradually fixed themselves. I wonder why it was not working before. I remember researching at the time whether tmp should be automatically cleared at all. Thanks for your help. A fan of KDevelop since the KDE2 days. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 412707] KDevelop leaves hundreds of megabytes of temp files if it crashes
https://bugs.kde.org/show_bug.cgi?id=412707 --- Comment #4 from Tim E. Real --- Thanks for looking into this. Lately it seems to be behaving much better. Now at least, if a crash occurs, it seems that upon reboot the temp files are gone. I find that I am having to do much less manual cleanup than before. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412705] Konsole leaves hundreds of megabytes in thousands of temp history files
https://bugs.kde.org/show_bug.cgi?id=412705 --- Comment #7 from Tim E. Real --- Thanks for the tip. I did not know that about QTemporayFile. It does not appear to specifically mention that in the docs. I began using that class in our app recently. I read a topic somewhere "How long do temporary files made with mktemp last?" with posts explaining in detail and mentioned checking 'TMPTIME', or /etc/cron.daily/tmpwatch. Both don't seem to exist here. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412705] Konsole leaves hundreds of megabytes in thousands of temp history files
https://bugs.kde.org/show_bug.cgi?id=412705 --- Comment #5 from Tim E. Real --- I almost forgot, KDevelop is another app that populates the /tmp folder. KDevelop does not leave anything there upon reboot, and cleans up despite being a 600lb gorilla having a big project open and many huge temp files. Something wrong in Konsole? Konsole was for a long time crashing upon reboot until recently. Maybe some bugs still being worked out. This is openSuse Tumbleweed after all, where things update daily... I'm ready to quickly test anything you might want to try, as soon as it comes down the pipeline. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412705] Konsole leaves hundreds of megabytes in thousands of temp history files
https://bugs.kde.org/show_bug.cgi?id=412705 --- Comment #4 from Tim E. Real --- Verified: Konsole cleans up after itself if I manually close it. But Konsole does not clean up if left open and reboot. I began with a clean plate and started Konsole and verified it cleans up if I close it. But if I leave Konsole open and reboot, the temp files are still there. Each time I reboot, a whole new set of Konsole temp files appears. After several reboots, I now have dozens of files. Hope I'm not 'barking up the wrong tree'. Maybe a system problem? (Seems that's taking reboot 'restoration' to an extreme. Is normal?) I have several apps open but none seem to use temp files. I will try to find another app which uses temp files and verify. Any suggestions or ideas of cause? Thanks. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412705] Konsole leaves hundreds of megabytes in thousands of temp history files
https://bugs.kde.org/show_bug.cgi?id=412705 --- Comment #3 from Tim E. Real --- Thank you for the response. Konsole (ver 19.08.1) does not crash, nor the system. The only thing I can think of that might be unusual is that I leave Konsole open when I shut down, ie. I leave Konsole open all the time so that it is opened upon reboot. I will try some experiments to see if that might be the problem, maybe Konsole is not being given enough time to clean up as the system shuts down. Until recently Konsole was indeed frequently crashing upon shutdown. That appears to have been fixed here in openSuse Tumbleweed. But the temp files still seem to be appearing and left around despite cleaning. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 412707] New: KDevelop leaves hundreds of megabytes of temp files if it crashes
https://bugs.kde.org/show_bug.cgi?id=412707 Bug ID: 412707 Summary: KDevelop leaves hundreds of megabytes of temp files if it crashes Product: kdevelop Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: termt...@rogers.com Target Milestone: --- SUMMARY If KDevelop or the system crashes, hundreds of megabytes of temporary files are left behind in /temp, especially preamble-*.pch files. This can cause failure to boot the system due to low disk space, requiring manual cleaning of /tmp, sometimes from another distro, before even being able to boot. STEPS TO REPRODUCE 1. Use KDevelop 2. Experience a crash in KDevelop or general system. 3. Attempt to restart OBSERVED RESULT Cannot restart system because there is no disk space left. EXPECTED RESULT No junk in /tmp. SOFTWARE/OS VERSIONS OpenSUSE Tumbleweed ADDITIONAL INFORMATION Please make KDevelop check for stale temp files on startup and delete them before continuing. Because it is often when starting KDevelop again that the disk becomes full and then total chaos occurs. Note: Somewhat similar report is found in bug ID 378909 Thank you. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412705] New: Konsole leaves hundreds of megabytes in thousands of temp history files
https://bugs.kde.org/show_bug.cgi?id=412705 Bug ID: 412705 Summary: Konsole leaves hundreds of megabytes in thousands of temp history files Product: konsole Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: history Assignee: konsole-de...@kde.org Reporter: termt...@rogers.com Target Milestone: --- SUMMARY Every week I must manually clean out thousands of konsole-*.history temporary files from /tmp totaling hundreds of megabytes. STEPS TO REPRODUCE 1. Use konsole for some days or weeks. OBSERVED RESULT Low disk space on drive, sometimes causing complete failure to boot system. Must manually clean them out from /tmp, sometimes from another distro before even being able to boot. Average user has no clue what is going on behind their back, and why the system won't boot. EXPECTED RESULT There should be no history files hanging around when konsole is not running. SOFTWARE/OS VERSIONS OpenSUSE Tumbleweed. ADDITIONAL INFORMATION Please make konsole clean up after itself when it closes. Even better: When konsole starts, please check if stale history file are hanging around and delete them before continuing. (Can you see the bizarre irony that these are supposed to be 'temporary' files but they hang around forever?) Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 382289] New: Long-standing bug: Bookmarks are often forgotten.
https://bugs.kde.org/show_bug.cgi?id=382289 Bug ID: 382289 Summary: Long-standing bug: Bookmarks are often forgotten. Product: kdevelop Version: 5.1.1 Platform: unspecified OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: bookmarks part Assignee: kdevelop-bugs-n...@kde.org Reporter: termt...@rogers.com Target Milestone: --- Hello. For a long time now, if I recall even back in Qt4 before the switch to Qt5, KDevelop keeps forgetting my bookmarks. It happens in all distros I've used, like KUbuntu or this current openSUSE Tumbleweed. As a seasoned tracker, all I have been able to do so far is watch, and try to observe when it happens. But it's elusive, hard to pin down. The only clue I can provide is that it seems to have something to do with large files in a large project and/or the number of files open in the editor. I can only point you in the direction of our CMake based C++ project: Project: https://github.com/muse-sequencer/muse Website: http://muse-sequencer.org/ To recreate the problem, open the MusE cmake project. Open say, ten or twenty of the large "juicy" project files in the editor. As a test, which I just tried, also open the >2000 line "midi.cpp" file. Add some bookmarks to "midi.cpp", close and reopen KDevelop and MusE. The bookmarks are gone in "midi.cpp". If not that file, try some of the other files, surely sooner or later you'll hit several files where all bookmarks are forgotten. Some of our files are over two thousand lines long. Hope I can assist further. Thanks. Tim. Coding MusE and other projects in KDevelop since its inception. KDevelop rocks! -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 Tim E. Real <termt...@rogers.com> changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REOPENED|RESOLVED --- Comment #28 from Tim E. Real <termt...@rogers.com> --- This seems to be working now. I noticed a couple of situations after switching desktop styles where it was frozen if I clicked on the title bar, but I was able to continue simply by (I think) clicking once more, or by using the title bar icons to restore/minimize. Minor graphical artifact: The MDI shadow is not drawn on a 'normal' subwin sometimes after a style change, but IIRC maximizing/minimizing cures it soon after. Our project seems OK now. It uses MDI with styles/stylesheets. It's the good ol' MusE midi/audio sequencer project. Hope it's OK to change to this status. Thanks very much for your help! Tim. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #22 from Tim E. Real <termt...@rogers.com> --- (In reply to Hugo Pereira Da Costa from comment #21) > (In reply to Tim E. Real from comment #20) > > Created attachment 105939 [details] > > Simple cmake based Qt MDI program sets stylesheet > > > > Hi, can you spare some more time? 5.10 packages came down the line > > (with your fixes in the Oxygen/Breeze package change logs). > > Strange, I looked at git repo and didn't see Oxygen changes. Wrong git? > > > > No clue. > But I double checked that the oxygen changes are _in_ (both master and > Plasma/5.10) > > > At first it seemed to work. But no, still not working. > > Style and/or stylesheet are still freezing. > > Can you confirm? Several ways to reproduce the problem: > > > > METHOD A (stylesheet freeze): > > 1) Set Plasma workspace Look and Feel to Breeze. > > 2) In Qt5Designer (or Creator), open my previously supplied > > frozen_MDI_1.ui attachment (with stylesheets). > > 3) Maximize one of the sub windows. > > 4) Observe the sub window is frozen after maximizing. > > > > METHOD B (style freeze, no stylesheets involved): > > 1) Set Plasma workspace Look and Feel to Oxygen. > > 2) In Qt5Designer (or Creator), open your previously > > supplied mdi-2.ui file (without stylesheets). > > 3) Maximize one of the sub windows. > > 4) Observe the sub windows should still both be OK. > > 5) Now set Plasma workspace Look and Feel to Breeze. > > 6) Observe the maximized sub window is frozen. > > (After switching to Breeze, one of two open KDevelop > > instances was completely frozen. Repeatable. Unrelated?) > > 8) Now set Plasma workspace Look and Feel back to Oxygen. > > 9) Observe all is OK. (Well, except for KDevelop...) > > 10) Repeat switching Oxygen <- -> Breeze , observe the > > maximized MDI sub windows toggling freezing. > > > > METHOD C (stylesheet freeze): > > 1) Run this newly attached small demonstration program. > > 2) Observe the sub window is frozen. > > 3) Also, try the test in METHOD B (switching between Oxygen/Breeze) > > and observe the freeze toggling. > > So methods A and methods C are essentially the same, right ? (setting a > stylesheet on a MDI window) Yes, thanks. Most importantly the maximizing effect. Further info: For METHOD 'A': I discovered that you can cause the bug simply by grabbing the lower right corner of the MDI sub window and expanding its geometry /beyond/ the size of the MDI area. As soon as that is done, the window freezes. >From the right-click context menu, selecting 'Cascade' or 'Tile' un-freezes it. So the bug seems to be oh-so-borderline sensitive to over-sized geometry. To within a few pixels. Maybe explains why it seems to work in some conditions (say, with Oxygen) but not others. > Will investigate > > Will investigate also method B. Here the common denominator is maximizing > windows. > > PS: for changing the status of the bug, just change the combobox in front of > "status" (here to "REOPENED") Hm, don't see that here. Thanks very much for your help. Tim. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #20 from Tim E. Real <termt...@rogers.com> --- Created attachment 105939 --> https://bugs.kde.org/attachment.cgi?id=105939=edit Simple cmake based Qt MDI program sets stylesheet Hi, can you spare some more time? 5.10 packages came down the line (with your fixes in the Oxygen/Breeze package change logs). Strange, I looked at git repo and didn't see Oxygen changes. Wrong git? At first it seemed to work. But no, still not working. Style and/or stylesheet are still freezing. Can you confirm? Several ways to reproduce the problem: METHOD A (stylesheet freeze): 1) Set Plasma workspace Look and Feel to Breeze. 2) In Qt5Designer (or Creator), open my previously supplied frozen_MDI_1.ui attachment (with stylesheets). 3) Maximize one of the sub windows. 4) Observe the sub window is frozen after maximizing. METHOD B (style freeze, no stylesheets involved): 1) Set Plasma workspace Look and Feel to Oxygen. 2) In Qt5Designer (or Creator), open your previously supplied mdi-2.ui file (without stylesheets). 3) Maximize one of the sub windows. 4) Observe the sub windows should still both be OK. 5) Now set Plasma workspace Look and Feel to Breeze. 6) Observe the maximized sub window is frozen. (After switching to Breeze, one of two open KDevelop instances was completely frozen. Repeatable. Unrelated?) 8) Now set Plasma workspace Look and Feel back to Oxygen. 9) Observe all is OK. (Well, except for KDevelop...) 10) Repeat switching Oxygen <- -> Breeze , observe the maximized MDI sub windows toggling freezing. METHOD C (stylesheet freeze): 1) Run this newly attached small demonstration program. 2) Observe the sub window is frozen. 3) Also, try the test in METHOD B (switching between Oxygen/Breeze) and observe the freeze toggling. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #12 from Tim E. Real <termt...@rogers.com> --- (In reply to Hugo Pereira Da Costa from comment #9) > Here at least it seems setting the stylesheet creates the freeze. > Removing it on your ui file unfreezes things > Adding it on mine freezes things. Yes, strange eh? Today I noticed that even after you do File > Close, then try to create another new blank form, wham - it's frozen too! As if the freeze 'carried over' to the next form or something, having 'infected' Qt5Designer until restarted. I did not want to bombard with too much info at first, just something clearly demonstrate-able. But what is not so easily shown is that these problems are also occurring on calls to qApp->setStyle(). The freeze can occur when a new MDI sub window is created. The sub windows can freeze simply by maximizing or minimizing or restoring them, no joke. That's /without/ stylesheets. But as we see, stylesheets also make it worse. I was really surprised to see the stylesheet freeze on openSuSE. I was looking more for the style issues. To me, it's clear the style and stylesheet problems are related. Breeze and Oxygen sure don't seem to like MDI. I've been tracking this bug for a while... I found an awkward workaround. It mostly works, but not always. I found that calling qApp->setStyle() TWICE makes it work. setStyle() has a sort of toggling on/off effect on freeze. But due to the differences in distros, it's not consistent. Hope I can further assist in squashing this. T. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #11 from Tim E. Real <termt...@rogers.com> --- (In reply to Hugo Pereira Da Costa from comment #8) > Created attachment 105543 [details] > another ui file with mdi windows, that work > > Can you test this ui locally (it has mdi windows, no stylesheet) > Here nothing is frozen (which is why I reported that I cannot reproduce in > the first place) > If confirmed that neither oxygen-demo5 nor this ui are frozen, it means that > there is something specific to the ui you sent that makes the freeze happen. > > That could be a good base for further investigations Works OK here but this has nothing to do with ui files, read "steps to reproduce" above. It happens when previewing a newly created form, as described, and selecting 'Preview in...' Breeze or Oxygen. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #10 from Tim E. Real <termt...@rogers.com> --- (In reply to Hugo Pereira Da Costa from comment #7) > Can you check with oxygen-demo5 if the mdi-window tab is responsive there ? > It is, here. Yes. In the openSuSE Tumbleweed. There's no oxygen-demo5 in the older KUbuntu 16.04 LTS -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #5 from Tim E. Real <termt...@rogers.com> --- Wow! When the attached UI file is opened, it is not only the MDI sub windows that are affected - it is the ENTIRE QMainWindow containing the QMDIArea. In fact, I am unable to even move the window around in Qt5Designer ! I can place items on the form, but I cannot select anything afterwards. The rest of Qt5Designer is OK, of course. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #4 from Tim E. Real <termt...@rogers.com> --- Wow. I never tried saving/re-opening a test-case UI file before. This fresh suse installation is on Breeze by default. So the attached UI file's MDI sub windows are frozen even without previewing the form. They are frozen right in the Qt5Designer editor ! Qt Version 5.7.1 As mentioned, also observed on KUbuntu 6.0.4 LTS, worse it happens even without setting any stylesheet on the QMDIArea. (The supplied UI file has a stylesheet set on the QMDIArea.) Also observed on another, older PC running same KUbuntu 6.0.4 LTS. Others in our group have also reported the problem. Only commonality I can think of, at least in my setup, is the Nouveau nVidia drivers. But I think I tried an ATI card at one point. Everything is fine if the attached UI file is opened in Qt4Designer! Indeed, our Qt app was fine in Qt4 (and Qt3, Qt2, Qt1, he he.) Thanks. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 --- Comment #3 from Tim E. Real <termt...@rogers.com> --- Created attachment 105534 --> https://bugs.kde.org/attachment.cgi?id=105534=edit Frozen MDI test UI file 1 Open in Qt5Designer or Creator. The MDI sub windows are frozen in Breeze or Oxygen. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 379790] New: MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen
https://bugs.kde.org/show_bug.cgi?id=379790 Bug ID: 379790 Summary: MDI SubWindows are frozen (non-responsive) with Breeze and Oxygen Product: Breeze Version: 5.9.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: QStyle Assignee: hugo.pereira.da.co...@gmail.com Reporter: termt...@rogers.com Target Milestone: --- Steps to reproduce: In Qt5Designer (or Creator), create a widget, add an QMDIArea, and add one or more sub windows. Set a stylesheet on the QMDIArea, such as a font or colour or gradient. Preview the form in Breeze or Oxygen styles. The MDI sub windows are frozen. Other styles are OK, such as Fusion. This is under latest OpenSuse tumbleweed. But also under KUbuntu 16.04 LTS the problem is worse: The MDI sub windows are frozen even without setting a stylesheet on the QMDIArea. This has plagued our app since Qt5 was released. Please help. Thanks. -- You are receiving this mail because: You are watching all bug changes.
