[kwin] [Bug 442846] Blocking calls to Xwayland can make kwin freeze
https://bugs.kde.org/show_bug.cgi?id=442846 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #30 from leftcrane --- I've been observing this issue for the past year on my kde install. I can only unlock the computer after wake 50% of the time, the other times input gets ignored. This means that when using KDE I have to do a hard reboot at least once a day, luckily most of my work is in the cloud so I use it as a browser terminal basically. If I used it as a desktop it would be impossible to get anything done on it because you'd constantly be losing all your work due to hard reboots. Also there is a ten percent chance of the laptop failing sleep after you tell the session to tell it to go to sleep. This means that there is a 100% percent chance of your laptop eventually frying in your backpack if you're the type to close the lid and forget it hoping it does what a normal machine always would. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 424606] KDE Connect unable to detect other computers and transfer files in Ubuntu 20.04-based (and possibly later) distros
https://bugs.kde.org/show_bug.cgi?id=424606 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #8 from leftcrane --- This hasn't been resolved lol. KDE connect still can't maintain a stable connection with a Samsung phone. To be fair even Samsungs own app can't do it. Also file browsing is now broken for whatever reason. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460115] New: Active window isn't highlighted in any way.
https://bugs.kde.org/show_bug.cgi?id=460115 Bug ID: 460115 Summary: Active window isn't highlighted in any way. Classification: Plasma Product: kwin Version: 5.25.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-overview Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Active window should be marked somehow so the user doesn't lose his place. Bear in mind that there are three areas that potentially might need highlighting: 1) the active window 2) the window that's focused via keyboard (arrow/tab keyboard navigation is currently missing but presumably it will be added later) 3) the window that the mouse hovers over, AFTER being moved. It isn't trivial to figure out the optimal UI here, so I recommend just copying whatever Gnome does for starters. Their overview is ten years old, so presumably its UI makes sense. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 438780] Accidental mouse movements will cause the wrong application to launch on hitting Enter
https://bugs.kde.org/show_bug.cgi?id=438780 --- Comment #7 from leftcrane --- If you can reproduce the behavior and agree that it's problematic, could you change the status to confirmed (or whatever the appropriate label is)? -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 438780] Accidental mouse movements will cause the wrong application to launch on hitting Enter
https://bugs.kde.org/show_bug.cgi?id=438780 --- Comment #6 from leftcrane --- Welcome, glad to help. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 438780] Accidental mouse movements will cause the wrong application to launch on hitting Enter
https://bugs.kde.org/show_bug.cgi?id=438780 --- Comment #4 from leftcrane --- Try firefox address bar too, btw. It behaves like Chromium. So these are very well charted waters in UX design. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 438780] Accidental mouse movements will cause the wrong application to launch on hitting Enter
https://bugs.kde.org/show_bug.cgi?id=438780 --- Comment #3 from leftcrane --- You either have a different trackpoint or don't use it enough to notice. It's a hardware issue with the lenovo trackpoints (it's just how the rubber gets deformed and then gets back its former shape). But the fundamental point is that accidental mouse movements should not interfere with the behavior of a keyboard-based launcher. This is clearly a KDE UX issue. Other GUIs never have this problem because they sensibly separate keyboard input from mouse input, precisely to avoid this issue. Don't believe me? Take a look at Chromium's omnibar. Move the mouse there and press enter. It will still launch the entry you've selected with your keyboard, irrespective of where the cursor happens to be. This is the logical behavior and it's how other launchers behave too, thus avoiding the problem entirely. They aren't wrong. IF you remember, for ages Krunner would actually open whatever entry the mouse was hovering over, even without movement. It was later partially "fixed" by requiring movement, but the original design which was the actual source of the problem was kept The only consequence of KDE's design of mixing keyboard and mouse input is unintended launches. Is causing accidental launches "intended behavior"? Cause that's the only feature the current design provides. So please reconsider. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 438780] Accidental mouse movements will cause the wrong application to launch on hitting Enter
https://bugs.kde.org/show_bug.cgi?id=438780 --- Comment #1 from leftcrane --- Maybe the solution is to keep the standard highlight effect for keyboard entry, and use a special hover effect for mouse selection. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 438780] New: Accidental mouse movements will cause the wrong application to launch on hitting Enter
https://bugs.kde.org/show_bug.cgi?id=438780 Bug ID: 438780 Summary: Accidental mouse movements will cause the wrong application to launch on hitting Enter Product: krunner Version: 5.22.1 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: alexander.loh...@gmx.de Reporter: leftcr...@tutanota.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY (Bug also affects the main KDE launcher) STEPS TO REPRODUCE 1. Open Krunner 2. type something 3. move mouse until it hovers over a different result 4. Hit enter OBSERVED RESULT Krunner launches whatever the mouse is hovering over after hitting Enter. EXPECTED RESULT It should always launch the first result (which can perhaps be highlighted in a special way). If someone wants to use the mouse, they can click. Enter is for keyboard launch, and keyboard launch should not be affected by mouse movements. In particular, this problem makes Krunner work especially poorly with trackpoints, because trackpoints have a tendency to move around completely unattended, even without accidental touches. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 437824] Wrong monitor enabled on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=437824 --- Comment #8 from leftcrane --- I can't reproduce the sole display being turned off issue anymore, because I just had to toggle some display configs to enable the main display (again). But after I did that, I lost the wallpaper on the secondary display. It's always something. It's sort of a catch-22 scenario, unless you have the logger running at all times. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 437824] Wrong monitor enabled on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=437824 --- Comment #7 from leftcrane --- For the display disconnect issue: kscreen-doctor yields error: qt.qpa.xcb: QXcbConnection: XCB error: 5 (BadAtom), sequence: 381, resource id: 0, major code: 20 (GetProperty), minor code: 0 -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 437824] Wrong monitor enabled on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=437824 --- Comment #6 from leftcrane --- BTW, I've seen two reports of the same category of problem on reddit in the past month. The users were too lazy to report it here though. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 437824] Wrong monitor enabled on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=437824 --- Comment #5 from leftcrane --- Or if is configured as the primary display, this doesn't seem to affect behavior. I don't see how this can be solved without simplifying display settings as follows: There are only two types of displays and display configs - primary and secondary.They apply to all primary and secondary displays regardless of make, model, resolution, other displays present etc. A primary display must always be present and turned on. This would result in sane behavior. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 437824] Wrong monitor enabled on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=437824 --- Comment #4 from leftcrane --- Now I'm finding that the sole connected display (laptop) doesn't get enabled when I disconnect the external. I've seen this behavior before as well. To mind, it's obvious that KDE simply does not have any code to guarantee that when there is only one display connected (doesn't matter what the display is), that display will be: 1. Turned on 2. Be configured as the primary display. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 437824] Wrong monitor enabled on wake-from-suspend
https://bugs.kde.org/show_bug.cgi?id=437824 --- Comment #3 from leftcrane --- I can't reproduce the behavior reliably. Sometimes it happens, other times it doesn't. In the same way, I can't reproduce KDE "forgetting" the wallpaper on a particular display, panels etc. This is why my hunch is that this is a general architectural problem. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 --- Comment #16 from leftcrane --- No, it's definitely less than that. BTW, I saw two recent reports from reddit of the same problem. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 437824] New: Chronic display configuration amnesia
https://bugs.kde.org/show_bug.cgi?id=437824 Bug ID: 437824 Summary: Chronic display configuration amnesia Product: kwin Version: 5.21.5 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: multi-screen Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Since Kwin naively ties basic desktop configs to overly-specific and fragile "display setups" (how exactly these setups are "auto-detected" internally I have no idea but it's a pretty fragile process that can be easily thrown off course). Thus KDE constantly "forgets" which monitor should use which settings, with predictably catastrophic results. And I only have two monitors - laptop and external. I only use one display at a time. It's the simplest possible configuration involving more than one monitor (dual monitors carry show-stoppers of their own - namely all windows moving to the left-most display when it's plugged in, ). Here are a couple examples of how can break: 1. The wrong display gets often gets "disabled" on wake, requiring manual intervention to enable the external display every time and disable the laptop. 2. Often, the sole existing display is disabled on wake. Thus you must either track down your secondary monitor and plug it in, or reboot the machine. 3. It is essentially impossible to change the wallpaper permanently. Wallpaper change isn't respected even on the *sole primary display.* Whenever KDE "forgets" the display (it thinks the assembly has changed for some reason), it applies the previous wallpaper. 4. Panels would probably suffer from the same problems as the wallpaper, though I can't test this because I use latte dock - which is tied to display hardware name and always respects the primary display. It seems that the source of this amnesia is two fold: 1. (plasma) The expectation that each unique "display setup" can have a totally unique plasma config for each display within that "setup", and other configurations in other setups. The number of unique setups is of course infinite. 2. (kwin) The over-specification of "display setups" - KDE tries to find an exact match for the setup and predictably fails. These problems wouldn't arise if the architecture was based on the concept of primary and secondary monitors (only two distinct classes) instead of infinite unique "setups," each with its own set of unique per-display configs. I know these are general architectural issues and don't expect a fix too soon. But are these problems at least recognized as such? KDE is the only desktop that can be rendered inoperable by the existence of multiple displays, but I don't see any recognition of this fact. Possibly related https://bugs.kde.org/show_bug.cgi?id=292419 -- You are receiving this mail because: You are watching all bug changes.
[KSystemLog] [Bug 437084] New: Can't view logs from previous boot in KSystemLog
https://bugs.kde.org/show_bug.cgi?id=437084 Bug ID: 437084 Summary: Can't view logs from previous boot in KSystemLog Product: KSystemLog Version: 21.04.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: nicolas.ternis...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- I'm not sure if KSystemLog has the ability to view logs from the previous boot but if it's there, it's not accessible to the user. I don't see it in the UI and you can't open the help page because the log viewer gui runs as root. So I'm not sure if this option is missing or just extremely difficult to find but as far as the user is concerned it doesn't exist. This means it's impossible to use the program to troubleshoot critical system failures (ones that end with a shut down) -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 417817] Notification in latte stop working
https://bugs.kde.org/show_bug.cgi?id=417817 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #10 from leftcrane --- I installed some tool called "octopi-notifier-frameworks" and experienced this issue. After removing it, I stopped receiving notifications. For whatever reason I had to reinstall knotifier and restart the relevant processes. Seems like this should be considered a plasma bug. Given that notifications are a critical core process, they should not be broken so easily by a random plasmoid. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 --- Comment #417 from leftcrane --- Windows is better, objectively, because it has a fully featured virtual desktop switcher. Now that WOULD be useful to have on KDE, as opposed to wasting resources on confusing gimmicks like per-desktop wallpapers. Sometimes removing features makes sense. Only adding features and options, especially when you have a million options already, is unsustainable. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #12 from leftcrane --- Not sure what resolved downstream means here. The bug hasn't been resolved anywhere, downstream or upstream. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #11 from leftcrane --- Can the decision of whether to cancel the logout be at least given to the user? Here's a sensible dialog for this situation, and that's how OTHER platforms handle it: > "App so and so is preventing logout, What do you want to do? > [Retry - (timer)] [Abort logout] That will fix the problem in a safe way. Allowing programs to "cancel" logout at will is actually the most dangerous approach in practice, because it encourages technically illiterate or frustrated users to solve the problem with a hard shutdown. If the software won't comply, they power button will, so that's what the user will do. I'd appreciate if this bug were reopened. Allowing random apps to cancel logout is unheard of on other platforms, and for good reason. It would be a considered a major bug on Windows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436066] Per-app color schemes
https://bugs.kde.org/show_bug.cgi?id=436066 --- Comment #6 from leftcrane --- I think it's actually more logical than cluttering up the application interface with dozens of color schemes. If you could specify the color scheme at launch in the environment variable, you could manage it via kmenueditor for all applications. Still think this is a bad idea? I think it'd be a major UI improvement - the only question is the difficulty of implementation. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436066] Per-app color schemes
https://bugs.kde.org/show_bug.cgi?id=436066 --- Comment #5 from leftcrane --- It's not a UI issue. It's about the ability to launch qt applications with a custom color scheme (just as you can launch them with a custom theme), via an environment variable. GTK has this functionality, via variants. It could look like this "QT_QPA_PLATFORMTHEME=Breeze:ColorScheme [application]" As for the UI, there is a perfectly logical place for stuff like titlebar color or app "theme:color" - the much neglected kde menu editor. (Currently, the titlebar color can be set via a combination of color scheme editor and window rule, which is a prohibitively convoluted UI solution.) -- You are receiving this mail because: You are watching all bug changes.
[calligracommon] [Bug 436800] New: Huge sidebars waste too much space, make multitasking impractical. Suggestion to move the tools into the toolbar and menus.
https://bugs.kde.org/show_bug.cgi?id=436800 Bug ID: 436800 Summary: Huge sidebars waste too much space, make multitasking impractical. Suggestion to move the tools into the toolbar and menus. Product: calligracommon Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: usability Assignee: calligra-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- This is a general UI problem that affects the entire suite. The sidebars take up anywhere from a quarter to a third of the window area on normal screens. This means you can't tile a calligra window with anything else and expect to be able to see the content. The worst thing is that most of the space in the sidebars is completely empty. Most of the tools are tiny buttons that could fit into a two-row toolbar - the gargantuan sidebars give them five times the space they actually require. I've never seen software where whitespace crowds out content to this degree. I would urge Calligra developers to adopt the kind of interface seen on other office suites and move the tools out of the sidebars. Maybe just put them all in the menubar, at least for starters, so users have at least some alternative to the sidebars. It's sad to see such an impressive project completely crippled - at least for me, though I suspect I'm not the only one - by one strange UI decision. Otherwise, a native office suite like Calligra could be a great asset for the desktop as a whole. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 --- Comment #415 from leftcrane --- Then hire a developer who will do whatever you without any questions. There are no hired hands here. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 436799] New: Ability to search attachments
https://bugs.kde.org/show_bug.cgi?id=436799 Bug ID: 436799 Summary: Ability to search attachments Product: kmail2 Version: Git (master) Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: kdepim-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- This is one thing I miss from Gmail. KDE has an indexer but it won't index or search attachments in Kmail. If it could be integrated into Kmail, this would be one of the most useful applications of baloo. I have lots of emails that are easily identifiable only by attachments. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 --- Comment #413 from leftcrane --- > Don't tell users how to work ! ... (etc.) https://xkcd.com/1172/ What kind of "work"? The only type of work that is facilitated by this gimmick is the work of endlessly fiddling with desktop backgrounds. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 --- Comment #410 from leftcrane --- > The background is a visual clue for where you are. It's a bad visual cue for the following reasons: - the desktop wallpaper might be hidden entirely by the windows. - you have to manage wallpapers for each desktop - that's very a very time consuming way of getting a "visual cue" - you have to remember which desktop background symbolizes which desktop. I don't see the rationale at all here. The visual cue should provided by a panel plasmoid. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 --- Comment #404 from leftcrane --- *If you wantED (referring to the state of affairs before the change). Most users just want to change the damn background, ONCE, and be done with it. For a long time this was impossible. Now it's at least possible to automatically propagate the change to all desktops, if not other display and login/lock. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 --- Comment #403 from leftcrane --- *If you wantED (referring to the state of affairs before the change). Most users just want to change the damn background, ONCE, and be done with it. For a long time this was impossible. Now it's at least possible to automatically propagate the change to all desktops, if not other display and login/lock. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #402 from leftcrane --- Strongly opposed to bringing this nonsense back. Changing the wallpaper should change the wallpaper, not "change the wallpaper for this particular desktop in the context of this particular display assembly, and the nowhere else." If you want to actually change the wallpaper, do it separately for each desktop, then for each display, then for each display assembly, then also for the login screen and again for the login screen. That was like a hundred clicks just to change the damn wallpaper! Meaning it was basically *impossible* to change the wallpaper for normal users. Good riddance to this unmaintainable, gimmicky anti-feature. Now if only the login screen, lock screen and all displays would obey the wallpaper change, KDE will finally gain the ability to change the wallpaper. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 --- Comment #14 from leftcrane --- I should have checked the files directly from balooctl of course, but in all likelihood this is a baloo bug, given that purging the database worked. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 leftcrane changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 --- Comment #13 from leftcrane --- Well the purge worked, after logout. So krunner/kickoff's only fault is - possibly - that they don't update results until you logout. The bug is with baloo. Try it on your system, you should get a similar result. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 leftcrane changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 leftcrane changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 353874] Baloo does not remove deleted files from index
https://bugs.kde.org/show_bug.cgi?id=353874 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #11 from leftcrane --- Not fixed on 5.21.4 Moved a whole bunch of files to an external drive several days ago. Multiple reboots AND baloo enable/disable cycles later, the files are still showing up in Krunner. I went ahead a purged the database with "balootcl --purge" and ... the nonexistent files are still being helpfully found by krunner/kickoff. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #23 from leftcrane --- Also light-dark variants in Kvantum that don't apply to the window border. It's not an issue with Breeze because breeze doesn't support the user launching apps with different color variants - but that's a deficiency of breeze compared to gtk and kvantum. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #22 from leftcrane --- But they are never getting fixed because they aren't designed for KDE and never will be. We are talking mainly about electron apps, different browser profiles (where different colors are the whole point) light and dark apps (gtk theme variants and all terminals) etc. These aren't solvable on the app level. The feature to recolor the titlebar is there so why not make it usable? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436066] Per-app color schemes
https://bugs.kde.org/show_bug.cgi?id=436066 --- Comment #3 from leftcrane --- I am talking about qt apps in general. Isn't it feasible to launch them with a particular color scheme that applies to both the app and window? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436066] New: Per-app color schemes
https://bugs.kde.org/show_bug.cgi?id=436066 Bug ID: 436066 Summary: Per-app color schemes Product: kwin Version: 5.21.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Not sure where else to put this, but some KDE apps are able to pass a color scheme property to the window manager. This is how Kate restyles the entire window for example. I wonder if this behavior could be generalized to all apps, or at least qt. Given that gtk apps use kde color schemes with breeze gtk, it might even be possible to do it for gtk. Use cases: - You have several browser profiles and want to assign different colors to each to tell them apart. - If KDE develops an overview like Gnome, Per app color schemes could help a lot in telling windows apart there. - Per app dark mode. This is possible with different Kvantum themes but not Breeze, since breeze is just a single theme with light and dark variants. etc. Related issue of making it easier to change the color of the titlebar for certain apps can be found here: https://bugs.kde.org/show_bug.cgi?id=401576 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #20 from leftcrane --- The custom titlebar color feature can really improve the appearance of certain windows, but the amount of work that it requires is just prohibitive. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #19 from leftcrane --- Does anyone think this a good idea? Currently you force a specific title-bar color by creating a whole color scheme, then creating a kwin rule, then setting the color scheme in the rule. Then the color schemes and rules will clutter up your settings. Can't this process be whittled down to fewer actions? As in: Window settings -> force titlebar color -> pick a color -> DONE. It would just set the titlebar color and inherit everything else from the active scheme. -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 436027] Kleopatra keeps asking for encryption password when sending mail.
https://bugs.kde.org/show_bug.cgi?id=436027 --- Comment #2 from leftcrane --- Actually it's probably that my keyring (KeepassXC) was closed. Still, I though it would just get the values from KWallet. But maybe it would if I had a standard config. -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 436027] Kleopatra keeps asking for encryption password when sending mail.
https://bugs.kde.org/show_bug.cgi?id=436027 leftcrane changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from leftcrane --- Actually -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 436001] Quick action to apply one wallpaper to all displays
https://bugs.kde.org/show_bug.cgi?id=436001 --- Comment #2 from leftcrane --- Well you guys still did the right thing and removed. And per-screen wallpapers make even less sense than per-desktop. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #10 from leftcrane --- > though again Kate it's the problem here Kate ISN'T the problem here. (typo) -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #9 from leftcrane --- I don't see a problem with that. The user said he want to logout, so that's what they desktop should do. "Cancel" in a Kate dialog - though again Kate it's the problem here - doesn't mean "cancel the logout." Kate isn't a session manager. The desktop on the other hand *could* give the user the option of explicitly canceling the logout. I think this might actually be how other desktops handle it. In fact, I'll add this to my script. I've never observed the issue of some random app "cancelling" a logout on any other desktop or platform. And I don't think that's because all the apps there were perfect. IIRC, the other desktops maintain control of the logout process throughout. I've used KDE for so long that I forget what exactly they did but I've never seen a random app "cancel" a logout of its own accord, permanently, other than in KDE. This kind of behavior makes absolutely no sense. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #7 from leftcrane --- Here's what I would do on my machine. Use notification triggers thankfully available on KDE to re-initiate logout after the app tries to "cancel" to. If it's safe to initiate logout the first time, it's just as safe to initiate it a second time. The second attempt would solve most of the problems because by then the stupid program would have likely closed itself already. This is the behavior I've observed. What's wrong with retrying logout? So this is the correct behavior, with no downsides. I can fix it on my machine but should the average user be expected to write a script to logout? -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #6 from leftcrane --- No app can "cancel" a logout, since that presumes the app has control of the process and not the user. The app can ask the logout process to hold and try again but it can't cancel it. Cause what does that mean? Some stupid app is going to tell me I should never logout? That's absurd. Apps like Kate don't actually cancel logout, they just ask the process to wait and then retry after the work has been saved. This is how it should be. Apps can ask to retry logout after they finish whatever they are doing but they shouldn't be able to simply abort a process initiated by user. -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 436027] New: Kleopatra keeps asking for encryption password when sending mail.
https://bugs.kde.org/show_bug.cgi?id=436027 Bug ID: 436027 Summary: Kleopatra keeps asking for encryption password when sending mail. Product: kleopatra Version: 3.1.15 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: aheine...@gnupg.org Reporter: leftcr...@tutanota.com CC: kdepim-b...@kde.org, m...@kde.org Target Milestone: --- Sometimes the the dialog has a "save password" with kwallet, sometimes it doesn't. Either way, it prompts every time kmail is opened - I think every time you open kmail. It's a KDE app, shouldn't it just get the password from Kwallet? It breaks sending signed emails in Kmail. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #4 from leftcrane --- But the app shouldn't be allowed "cancel" the logout under any circumstances. It could ask the logout process to wait and retry. This would fix the issue with most misbehaving apps, which first angrily cancel the logout and then say "ok whatever, we'll terminate." But then the user has to logout again, and again - however long it takes. Why can't the system take care of that keep retrying the logout on its own? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 436001] New: Ability to use the same wallpaper on all displays
https://bugs.kde.org/show_bug.cgi?id=436001 Bug ID: 436001 Summary: Ability to use the same wallpaper on all displays Product: plasmashell Version: 5.21.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Desktop Containment Assignee: notm...@gmail.com Reporter: leftcr...@tutanota.com CC: plasma-b...@kde.org Target Milestone: 1.0 If you set the wallpaper, it only changes for the current display. I think most users expect that when they change the wallpaper they expect that it will apply to every display configuration, instead of having the "old wallpaper" pop up on a another display. Right now to actually get rid of the old wallpaper, you have to change it on each display separately. There is nothing int the display config to indicate that the change applies only current screen. I suggest the default be changed to apply the wallpaper to all screens, like other desktops do it. Maybe there can be a checkbox if the user wants the current per-screen behavior instead. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 435997] New: Suggested improvement for left-click to cycle windows: cycle between the group and most recently used window.
https://bugs.kde.org/show_bug.cgi?id=435997 Bug ID: 435997 Summary: Suggested improvement for left-click to cycle windows: cycle between the group and most recently used window. Product: lattedock Version: 0.9.11 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- It was actually suggesed for the default task switcher https://bugs.kde.org/show_bug.cgi?id=76356 Basically instead of cycling between the group tasks and minimize, you cycle between the group tasks and the most recently opened window. So if you have terminal open in the foreground and two browser windows open in the background, clicking three times on the browser group will get you back to the terminal window. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 435938] Allow just cycling tasks instead of minimizing.
https://bugs.kde.org/show_bug.cgi?id=435938 --- Comment #1 from leftcrane --- This behavior was so undesirable that I set up a kwin rule as a hack to disable minimization entirely for all windows. This is probably a bit extreme for most people but for me it's worth it. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 435938] New: Allow just cycling tasks instead of minimizing.
https://bugs.kde.org/show_bug.cgi?id=435938 Bug ID: 435938 Summary: Allow just cycling tasks instead of minimizing. Product: lattedock Version: 0.9.11 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY I know this is intended behavior but it doesn't help the workflow. "Click cycle tasks" should cycle the tasks not minimize them, since it acts as a kind of "alt-tab" (within the current application) Imagine if Alt-Tab cycled between focus and minimize - it wouldn't be usable. There should be an option for people who don't want the minimization behavior - or better yet change the default behavior. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 435870] New: "Permanent notifications" don't auto-close after interval.
https://bugs.kde.org/show_bug.cgi?id=435870 Bug ID: 435870 Summary: "Permanent notifications" don't auto-close after interval. Product: frameworks-knotifications Version: 5.80.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: leftcr...@tutanota.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY There should be a way to force all notifications to close after a given interval. STEPS TO REPRODUCE 1. Allow notifications for a website on Chromium 2. Get a notification 3. Wait for the popup to close. OBSERVED RESULT Notification doesn't close after the interval defined in KCM (5 seconds default). The problem is compounded by the fact that there's no shortcut to dismiss notifications, nor are the popups grouped. You have to manually dismiss it by clicking a the close button on each popup, which is unusable. Theoretically, these apps could be fixed upstream to support KDE's notification system properly but realistically they aren't going to do that. Thus there needs to be a way to force their notifications to disappear. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #2 from leftcrane --- Actually Kate's behavior is fine, but obviously it's unrealistic to expect every app to behave perfectly on KDE. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 --- Comment #1 from leftcrane --- List of apps happily cancelling logout: - Clementine music player - Sartdict - yes a dictionary app! - A vpn client (ss-qt) - Recoll A search app gui (but not the underlying process) Also what about apps like Kate? They still cancel the logout first and ask questions later, right? So if you have an unsaved document in Kate and try to logout, you'll have go back and save it then hit logout again this. That doesn't usable either: even if the app has a good reason for preventing logout, this should be temporary, the logout should proceed after whatever was blocking it has been resolved. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 leftcrane changed: What|Removed |Added Platform|Other |Archlinux Packages -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 435869] New: Logout cancelled by ... without asking.
https://bugs.kde.org/show_bug.cgi?id=435869 Bug ID: 435869 Summary: Logout cancelled by ... without asking. Product: ksmserver Version: 5.21.3 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: leftcr...@tutanota.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY KDE logout (and shutdown) can be "cancelled" by any process without asking. I've experienced this with ss-qt5 and recoll (gui). Googling "KDE logout cancelled by" will yield many other examples going back years. This effectively allows any program to break basic logout functionality. In the case of recoll gui, the program first cancels the logout without asking, then closes itself. So a second attempt to logout will be successful in this case. Basically it cancels logout immediately and then gets closed like its supposed to, but that point its already late. Very silly behavior. Programs shouldn't be able to break logout. When something is blocking logout, you should get some kind of "process is preventing logout - [wait] [terminate]" or even a hack like "force logout." The logout process should never be cancelled by random apps, only paused. Whatever the solution, anything would be better than the current behavior. To the best of my knowledge, other desktops don't have this issue. There are quite a few bugs about this in the tracker, which reports of eminently closeable apps - like chat and dictionary - being granted the right to cancel the logout without asking the user. Some of these are marked as "FIXED DOWNSTREAM" but when random apps can do this to the session, that becomes a KDE bug irrespective of the problems with downstream. Operating System: Manjaro Linux KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.11.10-1-MANJARO OS Type: 64-bit Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 405380] Apt Updates fail to load in Discover
https://bugs.kde.org/show_bug.cgi?id=405380 leftcrane changed: What|Removed |Added Status|NEEDSINFO |RESOLVED --- Comment #8 from leftcrane --- I've changed it to resolved, given your report and my experience (although my experience alone is insufficient, since as I said I haven't used it much.) So it's "probably" resolved. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 405380] Apt Updates fail to load in Discover
https://bugs.kde.org/show_bug.cgi?id=405380 --- Comment #7 from leftcrane --- all the software stores *based* on packagekit. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 405380] Apt Updates fail to load in Discover
https://bugs.kde.org/show_bug.cgi?id=405380 --- Comment #6 from leftcrane --- I haven't noticed this bug recently with Discover but I also haven't been using it very much since it usually halts midway when performing updates. I've switched to native packages only because all the software stores packagekit are simply unusable. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 430136] New: "scanning" dialog floats above password dialog on open. You can't use the program without putting in the password
https://bugs.kde.org/show_bug.cgi?id=430136 Bug ID: 430136 Summary: "scanning" dialog floats above password dialog on open. You can't use the program without putting in the password Product: partitionmanager Version: 4.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. open it 2. try to enter your password 3. password can't be entered cause the password entry field is out of focus, behind some other silly dialog. OBSERVED RESULT can't enter password without manually focusing the password entry dialog EXPECTED RESULT you should just be able to type in your password. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 430135] New: KDE Partition manager creates unusable external drives (accessible only by root account)
https://bugs.kde.org/show_bug.cgi?id=430135 Bug ID: 430135 Summary: KDE Partition manager creates unusable external drives (accessible only by root account) Product: partitionmanager Version: 4.1.0 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. open it 2. create a partition table and partition ext4 3. open drive in file manager 4. try to move a file to the drive, it's impossible. OBSERVED RESULT can't write to drive via file manager (unless you're using using acient software that allows opening gui as root) EXPECTED RESULT should be able to write to drive without root access, or at least have a gui option to create a writable drive. Otherwise, what is even the point of the GUI if you have to drop to the CLI to change permissions? no root as default makes more sense, since root access for a removable drive makes absolutely no sense. I think Gnome Disks has sane behavior in this regard. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430077] New: drag and drop behavior broken. Kwin doesn't bring up the window into which you're trying to drag stuff into.
https://bugs.kde.org/show_bug.cgi?id=430077 Bug ID: 430077 Summary: drag and drop behavior broken. Kwin doesn't bring up the window into which you're trying to drag stuff into. Product: kwin Version: 5.20.2 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY On every other platform, drag and drop brings the drop target to the top on hover. Kwin doesn't do this, requiring you to carefully position windows in advance of the DND operation. Surprised it hasn't been reported yet, given that it's such a routine feature. STEPS TO REPRODUCE 1. Open two dolphin windows 2. Try to drag a file from one window to another. 3. It's not possible without repositioning the windows. OBSERVED RESULT The window into which you're trying to drop the file doesn't float to the top. EXPECTED RESULT It should float to the top. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 430076] New: Files on external hard drives should be deleted upon pressing "delete", not moved to your internal drive. Currently there is no *obvious way to delete these files at all*
https://bugs.kde.org/show_bug.cgi?id=430076 Bug ID: 430076 Summary: Files on external hard drives should be deleted upon pressing "delete", not moved to your internal drive. Currently there is no *obvious way to delete these files at all* Product: dolphin Version: 20.08.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY On every other system, when you "delete" a file from an external disk it does what you expect - DELETE the file, typically after a warning. Not Dolphin though, here it gets moved to your main disk, into the trash folder. But this is not even the worst thing here. Not only is the expected behavior not default, it's not even realistically achievable. The only way to do it, is if you know the hidden "delete permanently shortcut," which is nowhere to be found in the GUI. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388068] With the kmail version 5.7 can no longer send mails.
https://bugs.kde.org/show_bug.cgi?id=388068 --- Comment #37 from leftcrane --- Aborting the dispatcher will fix the problem of emails silently getting stuck in the outbox. However, it will not fix the new bug I've discovered (since upgrade to Version 5.15.1) wherein the composer window gets grayed out after hitting send. It will stay that way indefinitely and nothing will be sent. I have not discovered a "fix" for this. Sometimes emails do get sent out, but whenever they do you get a prompt to create a duplicate address book entry for the recipient (i.e, asks to save a contact that's already been saved and auto-suggested by Kmail in the field). Here of course you have to hit dismiss. I know all these bugs should be filed separately. But the problem with sending are so numerous and intractable that I can't justify putting in the effort. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388068] With the kmail version 5.7 can no longer send mails.
https://bugs.kde.org/show_bug.cgi?id=388068 --- Comment #36 from leftcrane --- The bandaid here is *aborting the activity* of the "Mail Dispatcher Agent" and restarting it. This is the only solution that works. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388068] With the kmail version 5.7 can no longer send mails.
https://bugs.kde.org/show_bug.cgi?id=388068 --- Comment #35 from leftcrane --- Seeing tons "no carrier" messages from various agents in Akonadi console when this happens. Takes a couple round of restarting/killing kmail to get it working again. I use Gmail btw -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388068] With the kmail version 5.7 can no longer send mails.
https://bugs.kde.org/show_bug.cgi?id=388068 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #34 from leftcrane --- Still happening. Kmail fails to send emails at random times with this error message. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 375951] locally integrated menus
https://bugs.kde.org/show_bug.cgi?id=375951 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #31 from leftcrane --- I think a more click-friendly hamburger menu would be a good compromise to drawing full menubars on each titlebar. The current menu button is a tiny circle, and the popup menu is tiny. Why not make it a large rectangle and make the popup hamburger menu bigger and more click-friendly? One could turn this popup into a rich pallette that could be customized depending on the demands of the particular application. Furthermore, a HUD could be intergrated into this popup.If necessary, you could even break up the hamburger menu into multiple menus or even extract individual menu items as separate buttons and place those in the decoration. This way you don't lose too much whitespace and you don't overtax the compositor. (Although I should add that I don't really buy the Nate's whitespace argument because clicking on titlebars to focus a window is always hairy due to the small click target. It's always easier to find whitespace to click on inside the app, to focus using middle-click, or to just use sloppy focus. Whitespace isn't necessary to ensure the window is draggable either, since there is no reason why you can't drag from widgets in the decoration - this is how GTK does it). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416763] New: UI: Move Find bar to the top right and make it compact (like Chromium)
https://bugs.kde.org/show_bug.cgi?id=416763 Bug ID: 416763 Summary: UI: Move Find bar to the top right and make it compact (like Chromium) Product: okular Version: 1.9.1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY The search bar currently appears at the bottom of the application and takes up the full horizontal distance. This has multiple disadvantages: 1. In the case of a floating windows, the entire find bar can easily disappear outside the display area. Just move the window down a bit and invoke the Find interface. You will not be able to see the find bar at all. 2. Displaying the search bar at the very bottom requires the user to shift their center of attention from the top of the screen to very bottom (whereas most applications display their tools at the top, including the find button in Okular) 3. The horizontally maximized find bar obscures much more content than it needs to. It is very rare that someone would type more than about ten characters into the search interface, so the space is stolen from the content and wasted. 4. The prev/next result buttons in the horizontally maximized find bar are located on the opposite end of the screen from where the user enters the keyword (the location of the cursor). A compact search bar would ensure that these buttons are close to the cursor. I think these are compelling reasons to change the UI. The current Find UI does not appear to offer any advantages - only disadvantages, and pretty serious ones. One problem is consistency with other applications like Kate. Kate displays the find bar at the bottom, like many other text editors. However, Kate could probably also benefit from moving this interface to the top right (see Gnome builder https://d2.alternativeto.net/dist/s/gnome-builder_443674_full.png?format=jpg=1600=1600=min=false) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 356530] Keyboard shortcuts should be searchable across components
https://bugs.kde.org/show_bug.cgi?id=356530 leftcrane changed: What|Removed |Added CC||leftcr...@tutanota.com --- Comment #3 from leftcrane --- Please no user customized "filters" on components. Just search everything and organize the search results by component, visually. There is no need for the user to "filter" anything, only to select the appropriate search result. Just make it simple. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 416146] Kate text editor area doesn't support KDE system color schemes.
https://bugs.kde.org/show_bug.cgi?id=416146 --- Comment #2 from leftcrane --- dark on dark and light on light should be reversed. Wrong descriptions but can't edit. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 416146] Kate text editor area doesn't support KDE system color schemes.
https://bugs.kde.org/show_bug.cgi?id=416146 --- Comment #1 from leftcrane --- Created attachment 125048 --> https://bugs.kde.org/attachment.cgi?id=125048=edit light on light -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 416146] New: Kate text editor area doesn't support KDE system color schemes.
https://bugs.kde.org/show_bug.cgi?id=416146 Bug ID: 416146 Summary: Kate text editor area doesn't support KDE system color schemes. Product: kate Version: 19.12.1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Created attachment 125047 --> https://bugs.kde.org/attachment.cgi?id=125047=edit dark on dark SUMMARY STEPS TO REPRODUCE 1. Set the system theme to "Breeze Dark" 2. Open Kate with "Normal" color schema - this was the default. RESULT: Dark text on dark background (shot1.png) Alternately: 3. Set the system theme to "Breeze Light" 4. Open KDE with "KDE" color schema RESULT: Light text on light background. (shot2.png) OBSERVED RESULT When the color schema is set to Normal (Kate settings), only the light system theme works properly. The dark breeze theme is Dark on Dark. When the color schema is set to KDE (Kate settings), only the dark system theme works properly. The light breeze theme is light on light. EXPECTED RESULT Kate should support system color schemes. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 416145] Krunner doesn't immediately intercept keystrokes, leading the user to accidentally type text into whatever app is open.
https://bugs.kde.org/show_bug.cgi?id=416145 leftcrane changed: What|Removed |Added Component|filesearch |general Assignee|baloo-bugs-n...@kde.org |k...@privat.broulik.de -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 416145] New: Krunner doesn't immediately intercept keystrokes, leading the user to accidentally type text into whatever app is open.
https://bugs.kde.org/show_bug.cgi?id=416145 Bug ID: 416145 Summary: Krunner doesn't immediately intercept keystrokes, leading the user to accidentally type text into whatever app is open. Product: krunner Version: 5.17.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: filesearch Assignee: baloo-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Open a text editor 2. Invoke Krunner 3. IMMEDIATELY start typing, don't wait for the dialog to pop up. OBSERVED RESULT Half of your text will be entered into the text editor, and the other half will be entered into Krunner. Krunner isn't terribly fast to open (about 0.3 sec delay on my machine), and until the dialog pops, it's not intercepting your keystrokes. This is unacceptable behavior for a launcher IMO. It never happens on Gnome or Windows AFAIK. EXPECTED RESULT The launcher should start intercepting all keystrokes entered after invoking the launcher, even if it can't draw the actual input dialog fast enough. Of course it's important to display the popup quickly - and KRunner could definitely use a performance improvement - but it is doubly important for a slow launcher to start capturing right away because otherwise the user will end up typing text into whatever window is open. This happens to me regularly when using krunner. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 416112] New: KDE Driver manager "Collecting information about your system" forever.
https://bugs.kde.org/show_bug.cgi?id=416112 Bug ID: 416112 Summary: KDE Driver manager "Collecting information about your system" forever. Product: systemsettings Version: 5.17.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Install ubuntu software preferences (gtk) 2. Launch Ubuntu software preferences -> drivers and KCM driver manager 3. Ubuntu software prefs will display some drivers within about five seconds. KCM will never display anything. Is this a kubuntu bug? -- You are receiving this mail because: You are watching all bug changes.
[kmenuedit] [Bug 416105] New: Uncategorized apps usually don't show up in the menu editor
https://bugs.kde.org/show_bug.cgi?id=416105 Bug ID: 416105 Summary: Uncategorized apps usually don't show up in the menu editor Product: kmenuedit Version: 5.17.5 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- All apps from the relevant appear in the main menu/krunner (usually) but if the .desktop file lacks the Category descriptor, it won't show up in the menu editor. Supposedly, you can find these uncategorized apps in "Lost and Found" but in my experience, they usually aren't there. STEPS TO REPRODUCE 1. Create a desktop file: #!/usr/bin/env xdg-open [Desktop Entry] Type=Application Name=OpenAudible Exec=/bin/sh "/opt/OpenAudible/OpenAudible" %U StartupWMClass=install4j-org-openaudible-desktop-Application Icon=/opt/OpenAudible/.install4j/OpenAudible.png 2. Put it into ~/.local/share/applications 3. Run kbuildsycoca5 4. Check Kmenuedit for this program. OBSERVED RESULT Desktop link isn't shown anywhere in Kmenuedit. (I actually observed this problem first after installing this program, which put the .desktop file a system folder. It also didn't show up in the menu editor.) EXPECTED RESULT Desktop links should always be shown in Kmenuedit. ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmenuedit] [Bug 416104] New: Store menu hierarchy in .desktop file
https://bugs.kde.org/show_bug.cgi?id=416104 Bug ID: 416104 Summary: Store menu hierarchy in .desktop file Product: kmenuedit Version: 5.17.5 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Currently, the hierarchy is are stored in ~/.config/menus/applications-kmenuedit.menu. This is both opaque, not portable, and may cause unpredictable behavior as the same configuration is stored in two places. Could the caterogories and just be written to actual desktop files instead? -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 414930] Widget padding changes inexplicably.
https://bugs.kde.org/show_bug.cgi?id=414930 --- Comment #2 from leftcrane --- Created attachment 124362 --> https://bugs.kde.org/attachment.cgi?id=124362=edit figure 2 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 414930] Widget padding changes inexplicably.
https://bugs.kde.org/show_bug.cgi?id=414930 --- Comment #1 from leftcrane --- Created attachment 124361 --> https://bugs.kde.org/attachment.cgi?id=124361=edit Figure 1 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 414930] New: Widget padding changes inexplicably.
https://bugs.kde.org/show_bug.cgi?id=414930 Bug ID: 414930 Summary: Widget padding changes inexplicably. Product: lattedock Version: git (master) Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- Created attachment 124360 --> https://bugs.kde.org/attachment.cgi?id=124360=edit Figure 0 SUMMARY STEPS TO REPRODUCE 1. Create a horizonal dock and add a few plasmoids like volume control and menu. Set the padding as indicated in the screenshot. (Figure 0) 2. Log out and log out. 3. Observe the size of these widgets - they disregard the padding and extend to full height of panel. (figure 1) 4. Right-click configure panel. 5. Exit the panel configuration dialog. 6. Observe the side of the widgets - they now have proper padding. (Figure 2) OBSERVED RESULT Widgets should always have the same padding, like observed in step 6. EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 414804] New: Krunner does not reliably find windows
https://bugs.kde.org/show_bug.cgi?id=414804 Bug ID: 414804 Summary: Krunner does not reliably find windows Product: krunner Version: 5.17.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: windows Assignee: k...@privat.broulik.de Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY Krunner is unable to locate windows half of the time. For example, there is no way to find the Konsole Window by typing "Konsole" or "Terminal". If you type "Discover" it won't open Discover - you have to type in the exact Window name from the beginning - eg "Featur ..." if the name is "Featured -- Discover" (and sometimes that won't work either). All this is made worse by the fact that the results of the search do not appear in an application-centric order, so when you type in the name of the window you're more likely to open an new instance of the app (or not, for certain KDE apps) or some file instead of the open window. The long and short of is that it isn't possible to search for open windows with Krunner. Operating System: Kubuntu 19.10 KDE Plasma Version: 5.17.3 KDE Frameworks Version: 5.64.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-24-generic OS Type: 64-bit -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 413413] New: Global menu applet not clickable if clicked too early
https://bugs.kde.org/show_bug.cgi?id=413413 Bug ID: 413413 Summary: Global menu applet not clickable if clicked too early Product: kded-appmenu Version: 5.16.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: export Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- I've observed this behavior with a few QT applications, notably RStudio. 1. Launch Rstudio. 2. Start clicking on the menu as soon as it is drawn. 3. None of the menus won't open. 4. Wait a bit, then try again. The menus still won't open. 5. Try to switch to another window, then switch back to Rstudio 6. Now observe that the menus function normally. Alternately, try the menu widget in the titlebar. This one will work consistently. I've observed this with several applications over a fairly long period of time (can't recall all of them) and it's always the same pattern. The menus in the plasmoid won't open until you switch from and then back to the application. At the same time the locally integrated menus work. I think it was LibreOffice "File" Menu that wouldn't open until you alt-tabbed from and back to the Libre office. There was some other bug with it to it, but this was part of the issue. (It's now been fixed upstream). I think a few other similar cases were discussed on this bugtracker. It seems like this is a general problem specific to the plasma appmenu applet for which there should be a general fix, even if the problem could also be fixed inside the various misbehaving applications individually. Operating System: Kubuntu 19.04 KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.2 Kernel Version: 5.0.0-32-generic OS Type: 64-bit -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 413124] New: KDE Connect won't connect.
https://bugs.kde.org/show_bug.cgi?id=413124 Bug ID: 413124 Summary: KDE Connect won't connect. Product: kdeconnect Version: 1.3.5 Platform: Other OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- [Marking as critical since this bug breaks the software entirely.] SUMMARY This is a continuation of the story in Bug 400010 where KDE would crash when the connection got interrupted. And it would keep crashing until you rebooted both devices. Now, it no longer crashes but it will still drop the connection at some point after working for a few days and then NEVER re-establish the connection EVER again. So for at least the past month of constantly running KDE connect on both the PC and the phone - as well as rebooting both devices, reinstalling the software and disabling firewall - the two devices haven't never discovered each other on the network. In fact, the PC wasn't visible on the network at all. As described in Bug 400010, the issue seems to arise after several cycles of enabling/disabling VPN and suspeding/resuming the machine (though I can't be sure obviously). Can KDE connect even be used with VPN software, or is there a fundamental conflict between the two by design? A google search shows that KDE Connect not Connecting is a problem that's as old as KDE Connect itself, and there are apparently no self-fixes for it. (SIDE NOTE: Is bluetooth connectivity planned or is that out of scope for this project?) Operating System: Kubuntu 19.04 KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.2 Kernel Version: 5.0.0-32-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i7-4600U CPU @ 2.10GHz -- You are receiving this mail because: You are watching all bug changes.
[kmenuedit] [Bug 412852] New: locate and edit the .desktop file (or integrate an editor)
https://bugs.kde.org/show_bug.cgi?id=412852 Bug ID: 412852 Summary: locate and edit the .desktop file (or integrate an editor) Product: kmenuedit Version: 5.16.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Many variables for desktop launchers are not supported by the menu editor. So it would be helpful to have an option to locate the actual .desktop file and edit it in a text editor (or an integrated editor). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 412548] Gui to whitelist/blacklist applications for global menu export (workaround for broken applications)
https://bugs.kde.org/show_bug.cgi?id=412548 --- Comment #5 from leftcrane --- Yeah, silly of me to not have thought of this. I don't think QT clients can be blacklisted, for example. AFAIK, the only ones that can are those that rely on appmenu-gtk module (org.appmenu.gtk-module blacklist/whitelist). So from the list that's only emacs - which should be easily fixable upstream - and that's it. So this is a limitation of DbusMenuProxy. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 412548] Gui to whitelist/blacklist applications for global menu export (workaround for broken applications)
https://bugs.kde.org/show_bug.cgi?id=412548 --- Comment #2 from leftcrane --- Sure, problem is that many people are stuck with it (at least by default) unless they are using the latest packages. In general there seem to be issues handling dynamic and lazy loaded menus, or menus that for some reason just don't load in their entirety at the start of the program. This is a different program from LO. Examples of the loading problem: * JetBrains suite (last time I used it), submenus wouldn't load - the bug was reported here. * Copy-Q, uses dynamic menus which cause the global menu to stop being exported: bug report on gh https://github.com/hluk/CopyQ/issues/1206 * Figma desktop, plugin menus and submenus will fail to load intermittently: https://github.com/ChugunovRoman/figma-linux (haven't reported the bug) Seems like there's a pattern, so maybe the problem might be fixable at the level of the toolkit or even the plasmoid. Other kinds of problems have been spotted with LO, Emacs, and Unity 3D, as already mentioned. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 412548] Gui to whitelist/blacklist applications for global menu export (workaround for broken applications)
https://bugs.kde.org/show_bug.cgi?id=412548 --- Comment #3 from leftcrane --- edit: This is a different *problem from LO. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 412602] New: Allow 1 char prefixes for web shortcuts.
https://bugs.kde.org/show_bug.cgi?id=412602 Bug ID: 412602 Summary: Allow 1 char prefixes for web shortcuts. Product: krunner Version: 5.15.90 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: webshortcuts Assignee: ro...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- In KCM, you can set 1-character long prefixes for web shortcuts. However these won't work in Krunner search. Furthermore, 1 character long prefixes can be used in both chrome and firefox, so makes sense to allow them to be used in Krunner as well, for consistency's sake (and maybe at some point KDE will gain the capability to sync its search engines with firefox and chrome) -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 412548] New: Gui to whitelist/blacklist applications for global menu export (workaround for broken applications)
https://bugs.kde.org/show_bug.cgi?id=412548 Bug ID: 412548 Summary: Gui to whitelist/blacklist applications for global menu export (workaround for broken applications) Product: kded-appmenu Version: 5.16.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: export Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Some applications are broken with global menu. Examples: - Libreoffice with GTK3 theme doubles the menuitems. - Unity3D https://www.reddit.com/r/kde/comments/dcniuz/disable_global_menu_for_unity3d/ - Emacs needs to be explictly whitelisted to display the global menu. This breakage, while infrequent, can be very serious and I don't see it getting fixed in a timely manner upstream (it's out of KDE's control), unfortunately. KDE should not attempt to fix the problematic apps by putting in overrides. If the app is broken with global menu by default, then it should be remain broken until it's actually fixed. However, the user should be able to quickly fix stuff on their own end by whitelisting or blacklisting apps. Nobody knows how to whitelist emacs for example, thus users can't access the global menu. Nobody knows where to get the experimental QT vcl to make the LOffice menubar work. Unity3D is supposedly just plain broken. So it would be nice to have a troubleshooting pane, perhaps with some presets that can be enabled or disabled. It would be nice if these overrides would propagate to latte dock and and the future HUD as well. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 410549] PPA's without a valid release file will cause Discover to stop displaying all APT repositories
https://bugs.kde.org/show_bug.cgi?id=410549 --- Comment #21 from leftcrane --- I wouldn't bet on this bug having been "fixed" by accident. It's been around for ages on both Gnome Software and Discover. It's hard to reproduce. If you play around with enough repositories you will eventually corrupt the cache. If you're on neon, I can only suggest adding a bunch of PPAs and waiting for the bug to crop up. Gnome software is totally borked on my system (now it says I'm not connected to the internet LOL), so maybe I could still answer some diagnostic questions. Discover is working fine except for the apt sources list being blank. Not sure how long it will last though. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 410549] PPA's without a valid release file will cause Discover to stop displaying all APT repositories
https://bugs.kde.org/show_bug.cgi?id=410549 --- Comment #20 from leftcrane --- Updates work, but APT repositories are not displayed. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 411753] New: KDE Connect spams the desktop with a torrent of old notifications causing the system to become unresponsive.
https://bugs.kde.org/show_bug.cgi?id=411753 Bug ID: 411753 Summary: KDE Connect spams the desktop with a torrent of old notifications causing the system to become unresponsive. Product: kdeconnect Version: 1.3.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- It takes all the unread unread notifications (on Android it could be dozens or even hundreds, depending on how many apps you have) and dumps them on the screen all at once, with each notification being a separate popup. There are so many notifications that the notifications just turn into black rectangles because the shell can't render them all. It may be worth it to look into just not showing notifications that are older than a few minutes minute. If the user wants to see them, maybe there should be a manual way to bring them up? Another idea would be to just enable mirroring of calls and sms by default, and then have the user enable others manually. I think this may be a good idea regardless, since it will prevent users from getting duplicate email, skype etc. notifications if they have the app on both phone and pc. Maybe Plasma notifications have been revamped in the latest release to guard against this sort of spamming, however this won't fix other desktops where KDEConnect is used. Either way, I don't think anyone wants their desktop to be completely overwhelmed with dozens of notifications like "Tetris was updated"(yesterday) or "new ways to pay with Samsung"(6 hours ago. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 411750] New: KDE Connect still won't connect, requiring a reboot to re-pair
https://bugs.kde.org/show_bug.cgi?id=411750 Bug ID: 411750 Summary: KDE Connect still won't connect, requiring a reboot to re-pair Product: kdeconnect Version: 1.3.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- In the past, KDEConnect would crash in these cases. Now, it no longer crashed but still won't connect reliably. The only way to resolve it is to reboot the PC (or phone, I forget which). With 1.3.5 it doesn't lose the connection as often, but it it still happens and there is no way to get the connection back. I believe it is still related to this bug: https://bugs.kde.org/show_bug.cgi?id=410316 -- You are receiving this mail because: You are watching all bug changes.
