[systemsettings] [Bug 408563] Provide option for day/night color theme switching
https://bugs.kde.org/show_bug.cgi?id=408563 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 196998] Konsole should reflow the text when resizing
https://bugs.kde.org/show_bug.cgi?id=196998 --- Comment #40 from Hakan Bayindir --- I’d like to collaborate on this issue with you. While I’m experienced in C++, I had no time to work on neither KDE nor Qt. If you prefer to collaborate with a Qt & KDE noob, I’d happily do my best. Regards, Hakan > On 10 Jun 2020, at 11:04, bugzilla_nore...@kde.org wrote: > > https://bugs.kde.org/show_bug.cgi?id=196998 > > tcanabr...@kde.org changed: > > What|Removed |Added > > CC||tcanabr...@kde.org > > --- Comment #37 from tcanabr...@kde.org --- > everybody agrees that this is an important feature to have, but does anyone > have time to start implementing it? I tried to implement it twice and I > failed, > I do appreciate some help here. :) > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 --- Comment #12 from Hakan Bayindir --- Hello Alex, Thanks for the patches and all the hard work. I have a question. As far as understood, the locking in SQLite is as follows [0]: 1. In most cases many clients can have locks on a SQLite DB. 2. If a client is preparing to write, all other locks become read-only. 3. To be able to actually write, all other locks shall clear (i.e. other clients shall close connection). Otherwise writes hang until all other locks clear. Because of 3., Firefox and Chrome claims exclusive locks on all SQLite DBs on startup. Considering the DBs may get extremely big (see my survey about writes in this), can a more sophisticated logic can be implemented? It shall work as follows: 1. If the DBs are not locked, sync the changes to local Bookmark DBs. 2. If the DBs are locked and KDE integration plugins are available, sync the changes over the plugin connection (since plugins can read the bookmarks). This will further reduce the write load on system SSDs since the delta will be much smaller than copying a whole DB over and over. Since SSDs getting cheaper and TBW values doesn't increase significantly over the years, minimizing writes looks like a wise ideal to pursue. What's your opinion on this? Regards, Hakan [0]: https://www.sqlite.org/lockingv3.html On 27 Mayıs 2020 Çarşamba 15:09:15 +03 you wrote: > https://bugs.kde.org/show_bug.cgi?id=417070 > > Alex changed: > >What|Removed |Added > > CC||alexander.loh...@gmx.de Resolution|--- >|FIXED > Status|CONFIRMED |RESOLVED > > --- Comment #10 from Alex --- > I already write a patch for this (without knowing of this bug): > > https://phabricator.kde.org/D29726. > > The there were two problems: > 1: The files are deleted/copied for every match session, even if they didn't > changed. They have to be copied because they are locked if the browser is > open. 2: There was a bug that the prepare/teardown signal get called for > each letter typed, this means that the files were copied for each letter > typed (BUG 420311). This has also been fixed. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 417071] Akonadi is constantly writing to disk.
https://bugs.kde.org/show_bug.cgi?id=417071 --- Comment #1 from Hakan Bayindir --- I have found the root cause of constant writing to disk, however it needed a good amount of digging with akonadiconsole. A malformed e-mail was triggering akonadi indexer to constantly retry indexing a bunch of entries every two seconds or so. This caused constant writing to the disk. Finding the offending collection ID and removing all mails (it was luckily trash) fixed the problem. I'm leaving the state as REPORTED intentionally because I still think the behavior is suboptimal and I'm not knowledgeable enough to decide its future. If the maintainers can do the right thing, I'd be grateful. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 --- Comment #8 from Hakan Bayindir --- I've also tried to access the DB with SQLite browser but, it's not possible as you've said. Maybe we can raise the issue with Mozilla, so they can release the locking pressure on the .sqlite files. It looks like Firefox is obtaining an exclusive lock and not giving it away until the end. Can this be also a bug on their end, since the SQLite locking document [0] tells that SQLite actively trying to avoid exclusive locking on its databases? >From the document: > In order to maximize concurrency, SQLite works to minimize the amount of time > that EXCLUSIVE locks are held. [0]: https://www.sqlite.org/lockingv3.html -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 --- Comment #4 from Hakan Bayindir --- Created attachment 125673 --> https://bugs.kde.org/attachment.cgi?id=125673&action=edit Detailed KRunner activity report. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 --- Comment #3 from Hakan Bayindir --- I've done the testing. You're right. Bookmarks is the culprit. Reading and re-caching a lot of favicons and data. Creates ~100MB writes per search. Sometimes even bigger. I'm attaching a detailed report. >From report: ## TL;DR - **Bookmarks** plugin is killing your SSD. One search at a time. - Lock files are written to disk. Why not to RAM? - Software center may be optimized (if possible). -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 --- Comment #2 from Hakan Bayindir --- You're welcome. Of course I can do the analysis. I think I can provide an answer towards the end of the week. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 417071] Akonadi is constantly writing to disk.
https://bugs.kde.org/show_bug.cgi?id=417071 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 417071] New: Akonadi is constantly writing to disk.
https://bugs.kde.org/show_bug.cgi?id=417071 Bug ID: 417071 Summary: Akonadi is constantly writing to disk. Product: Akonadi Version: 5.12.3 Platform: Debian testing OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: ha...@bayindir.org Target Milestone: --- Created attachment 125624 --> https://bugs.kde.org/attachment.cgi?id=125624&action=edit One day of iotop statistics, running in cumulative mode, sorted by disk write. SUMMARY Akonadi is constantly writing to disk and creating a lot of cumulative disk I/O after some time. STEPS TO REPRODUCE 1. Run akonadi. 2. Leave it turned on for the day. 3. Enable indexer for better results. OBSERVED RESULT ~3.5GB written to the disk after 10 hours of operation. EXPECTED RESULT A milder disk write pattern. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Testing. (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.5 ADDITIONAL INFORMATION KMail is also managing a single IMAP account via Akonadi. Continually writing small amounts of data wears SSDs pretty fast. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 417070] New: KRunner makes excessive writes during searching.
https://bugs.kde.org/show_bug.cgi?id=417070 Bug ID: 417070 Summary: KRunner makes excessive writes during searching. Product: krunner Version: 5.14.5 Platform: Debian testing OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: k...@privat.broulik.de Reporter: ha...@bayindir.org Target Milestone: --- Created attachment 125623 --> https://bugs.kde.org/attachment.cgi?id=125623&action=edit One day of iotop statistics, running in cumulative mode, sorted by disk write. SUMMARY KRunner can write ~2.2GB of data to disk in a couple of searches. STEPS TO REPRODUCE 1. Call KRunner with its shortcut. 2. Write something. OBSERVED RESULT KRunner makes a lot of disk calls and writes a lot of data, genrally to .cache folder. This wears down SSD disks pretty fast. EXPECTED RESULT A more milder disk access pattern (mostly reads, much less write) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Testing. (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.5 ADDITIONAL INFORMATION System I/O is monitored via fatrace and iotop. When running fatrace with -cC krunner --filter=CWD in the home directory of the user, the effects of triggering a search is becomes very visible. Keeping iotop open for a single day in accumulation mode and ordered by disk write reveals pretty shocking write statistics for a couple of KDE processes. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 416357] New: Action modifiers during drag do not update mouse cursor immediately.
https://bugs.kde.org/show_bug.cgi?id=416357 Bug ID: 416357 Summary: Action modifiers during drag do not update mouse cursor immediately. Product: dolphin Version: 19.08.1 Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: panels: folders Assignee: dolphin-bugs-n...@kde.org Reporter: ha...@bayindir.org CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When using action modifiers (e.g. Shift) during drag the effects of the said modifiers are not applied immediately. Instead, modifiers are checked on drag event, causing bad user experience STEPS TO REPRODUCE Scenario: Moving a file. 1. Start dragging a folder. 2. Drag to target position. 3. Press shift to set action to move, do not move mouse. OBSERVED RESULT Mouse cursor is not updated to indicate file move. EXPECTED RESULT Mouse cursor is updated to indicate file move. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.5 (against 5.12.5) ADDITIONAL INFORMATION - Moving mouse slightly still holding shift and handle changes to move handle in some cases. - Pressing modifier and starting drag sets the handle correctly. It seems the code is updated only thinking about this scenario. - A similar behavior is present in context menu. Pressing shift converts "Move to Trash" to "Delete" immediately. This is the expected behavior during drag too. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 416357] Action modifiers during drag do not update mouse cursor immediately.
https://bugs.kde.org/show_bug.cgi?id=416357 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393145] Drag/drop (mv) of preselected item causes inline rename of next item
https://bugs.kde.org/show_bug.cgi?id=393145 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org --- Comment #4 from Hakan Bayindir --- I'm experiencing the same problem on 18.08 on Debian Buster (testing). The problem is happening regardless of a copy and/or move. It's triggered at the moment the cursor leaves the window, and that leave is processed as a "slow-click" for renaming. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 195044] async behaviour during file copy to a removable device is confusing.
https://bugs.kde.org/show_bug.cgi?id=195044 --- Comment #24 from Hakan Bayindir --- Currently KDE does not allow to unmount a drive while a foreground file transfer or a background sync is in progress as far as I observed. I find this behavior adequate, however I think my opinion alone is not sufficient to close this bug. >From my point of view this bug can be closed. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 196998] Konsole should reflow the text when resizing
https://bugs.kde.org/show_bug.cgi?id=196998 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 238073] Konsole doesn't support resize ANSI escape codes anymore
https://bugs.kde.org/show_bug.cgi?id=238073 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 370964] panel does not reappear after auto-hide is selected
https://bugs.kde.org/show_bug.cgi?id=370964 Hakan Bayindir changed: What|Removed |Added CC||ha...@bayindir.org --- Comment #7 from Hakan Bayindir --- I'm having the same problem on Debian Testing. Some details: - I have switch desktop on edges while moving windows switched on. - I have two panels, the panel at the top, which contains the system tray is affected. Bottom panel always works as expected. - My panel behaves correctly, but then decides to stay hidden randomly, for no apparent reason. - Nudging the panel with some system tray action (like inserting a USB device) makes it re-appear for some time. - I have three KDE systems with the same configuration (I configured them by hand), and issue is consistent on all three. I'm a developer, so I'm interested in collaborating on fixing/testing effort. Last, but not the least, while not a grave bug, it really makes the experience miserable :) Regards, Hakan -- You are receiving this mail because: You are watching all bug changes.
