[kactivitymanagerd] [Bug 487698] New: Desktop folders move to different displays on login or when connecting a display
https://bugs.kde.org/show_bug.cgi?id=487698 Bug ID: 487698 Summary: Desktop folders move to different displays on login or when connecting a display Classification: Plasma Product: kactivitymanagerd Version: 6.0.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ivan.cu...@kde.org Reporter: ed...@inbox.lv CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Most of the time when I log in or connect / disconnect / connect a display, default folders that are displayed on desktop, move somewhere else - I mean they are supposed to be on primary display, but after login, they are not. Sometimes for some activities, they are on primary display as they should be, sometimes they just appear on secondary display and sometimes they just vanish, however if they are not displayed I can get them back by using sort option, just change it from name to size and back or the like. Laptop display resolution is 1080p, some additional displays I connect are 1080p (one at a time), then icons can move to different display. I observed that if I connect 1080p and 1440p and disable built-in display, then icons vanish (most likely move up & out of sight on primary display). In display settings, displays are arranged to have tops aligned. STEPS TO REPRODUCE 1. Use activities (I have 10 of them and 2 virtual desktops), I don't know whether this is an issue with workspaces only 2. Put some stuff on desktop 3. Use the computer as one do (log in, connect display, disconnect display, suspend / resume, log out, log in, etc. like real life usage) OBSERVED RESULT Icons change their location or just vanish. EXPECTED RESULT Icons stay in the same place. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Graphics Platform: X11 Graphics Processor: Mesa Intel® UHD Graphics 620 ADDITIONAL INFORMATION This started with Plasma 6.0.1 I think, on 5.x.y was ok. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 487671] New: Plasma "system widgets", like "System monitor widget", "Hard Disk activity widget", etc. ar too narrow (tiny)
https://bugs.kde.org/show_bug.cgi?id=487671 Bug ID: 487671 Summary: Plasma "system widgets", like "System monitor widget", "Hard Disk activity widget", etc. ar too narrow (tiny) Classification: Plasma Product: kdeplasma-addons Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: plasma-b...@kde.org Reporter: ed...@inbox.lv Target Milestone: --- Created attachment 169902 --> https://bugs.kde.org/attachment.cgi?id=169902=edit tiny widgets SUMMARY Plasma "System widgets" (System monitor, HDD activity, Individual Core usage, etc.) horizontal size are way too small, in the attached picture, there are 3 widgets which I separated by red lines to show the tiny width. The width is sort of ~ 2x smaller than height, which renders them very hard to see. I can not control width manually, it is set automatically. STEPS TO REPRODUCE 1. add a widget to panel OBSERVED RESULT Widget's size horizontally is too narrow. EXPECTED RESULT It is at least 2x the vertical size, otherwise it is not really useful. Ideally, I can set the size in % or otherwise. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Graphics Platform: X11 Graphics Processor: Mesa Intel® UHD Graphics 620 ADDITIONAL INFORMATION I usually use just 2 widgets, just before I filed this bug, I added 3rd just to check, whether it's my "older" config or problem in general. I think the issue started when I started using Plasma 6, probably 6.0.1, but I had to recreate all of them, so they are not "very old" config. For the proportion, the picture contains neighbouring widgets too, only the "graph" widgets are affected. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486843] New: Dolphin crash when dragging file to address bar
https://bugs.kde.org/show_bug.cgi?id=486843 Bug ID: 486843 Summary: Dolphin crash when dragging file to address bar Classification: Applications Product: dolphin Version: 24.02.2 Platform: Neon OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: eam2001@gmail.com CC: kfm-de...@kde.org Target Milestone: --- Created attachment 169360 --> https://bugs.kde.org/attachment.cgi?id=169360=edit gdb output log - received signal SIGSEGV SUMMARY When I drag a file to the address bar the dolphin crashes STEPS TO REPRODUCE 1. open a folder with a file in it 2. drag the file to a folder in the address bar OBSERVED RESULT the dolphin crashes and close EXPECTED RESULT I expected to see the sub-folders of the folder that the file was draged on SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION Also the same beaver on EndeavourOS (KDE KDE 6.0.4) Garuda (KDE 6.0.4) gdb output log attached The same happens on Wayland and X11 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 486786] New: When dragging the mouse cursor from Android to control the laptop in Kubuntu 23.10, moving the cursor to the edges from the sides automatically changes the pointer's loc
https://bugs.kde.org/show_bug.cgi?id=486786 Bug ID: 486786 Summary: When dragging the mouse cursor from Android to control the laptop in Kubuntu 23.10, moving the cursor to the edges from the sides automatically changes the pointer's location. Classification: Applications Product: kdeconnect Version: unspecified Platform: Kubuntu OS: Linux Status: REPORTED Severity: major Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: andresgarcia0...@gmail.com CC: andrew.g.r.hol...@gmail.com Target Milestone: --- SUMMARY When dragging the mouse cursor from Android to control the laptop in Kubuntu 23.10, moving the cursor to the edges from the sides automatically changes the pointer's location. STEPS TO REPRODUCE 1. Open the KDE Connect app on Android. 2. Connect the Android device to the laptop. 3. Drag the mouse cursor from Android to the laptop and move it to the edges from the sides. OBSERVED RESULT The pointer's location automatically changes when moved to the edges from the sides. EXPECTED RESULT The mouse pointer should maintain its location when moved to the edges from the sides. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 23.10 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486628] Sometimes, after screen lock timeout, screen will stay black until kwin_wayland is killed
https://bugs.kde.org/show_bug.cgi?id=486628 --- Comment #3 from Eduardo Sánchez Muñoz --- Another detail. I can reproduce this with an AMD GPU, but not with an Intel GPU. OpenGL vendor string: AMD OpenGL renderer string: AMD Radeon RX 7800 XT (radeonsi, navi32, LLVM 18.1.1, DRM 3.57, 6.8.8-300.fc40.x86_64) OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.6 OpenGL core profile shading language version string: 4.60 OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) UHD Graphics 630 (CFL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.6 OpenGL core profile shading language version string: 4.60 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486628] Sometimes, after screen lock timeout, screen will stay black until kwin_wayland is killed
https://bugs.kde.org/show_bug.cgi?id=486628 --- Comment #2 from Eduardo Sánchez Muñoz --- It happens when I move the mouse immediately after it locks to prevent locking. In "EXPECTED RESULT", I should have said that I expected the session to unlock after moving the mouse, not a password prompt. My "Lock screen automatically" and "Dim automatically" settings are set to the same value (usually 5 minutes, now 1 minute for testing). "Allow unlocking without password" is set to 5 seconds. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486628] New: Sometimes, after screen lock timeout, screen will stay black until kwin_wayland is killed
https://bugs.kde.org/show_bug.cgi?id=486628 Bug ID: 486628 Summary: Sometimes, after screen lock timeout, screen will stay black until kwin_wayland is killed Classification: Plasma Product: kwin Version: 6.0.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: eduardosanchezmu...@gmail.com Target Milestone: --- SUMMARY Sometimes, when the screen locks due to timeout, the screen will stay black with a movable cursor. The only way out is switching to a TTY and killing kwin_wayland, which will cause most applications to crash. STEPS TO REPRODUCE 1. Wait for the screen to lock. 2. Move the mouse OBSERVED RESULT Sometimes, the screen will stay black and it will not be possible to unlock the session normally. EXPECTED RESULT A password prompt should appear. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 40 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION Running "loginctl unlock-sessions" or killing plasmashell does not help to recover, only killing kwin_wayland. One of the times it happened, after killing kwin_wayland, I logged out and I was not able to log back in until I rebooted. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486464] New: X11 applications that use _NET_WM_SYNC_REQUEST do not resize correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=486464 Bug ID: 486464 Summary: X11 applications that use _NET_WM_SYNC_REQUEST do not resize correctly on Wayland Classification: Plasma Product: kwin Version: 6.0.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-x11-nested Assignee: kwin-bugs-n...@kde.org Reporter: eduardosanchezmu...@gmail.com Target Milestone: --- SUMMARY On Wayland, X11 applications that use _NET_WM_SYNC_REQUEST exhibit incorrect behavior during resizing: * Window decoration painting is not synchronized with window content painting. * At some point, the it will not be possible to resize or move the window for a few seconds. Only happens with kwin_wayland, kwin_x11 works correctly. STEPS TO REPRODUCE 1. Log in to a Wayland KDE session- 1. Open a X11 application that use _NET_WM_SYNC_REQUEST (or force it to use X11). For example: QT_QPA_PLATFORM=xcb dolphin 2. Resize the window multiple times. OBSERVED RESULT The dimensions of the decorations are not synchronized to the dimensions of the window contents. At some point, the window will stop resizing for a few seconds. During that period, it will not be possible to move the window. EXPECTED RESULT The window should resize as expected and the decorations are not synchronized with the contents. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 40 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION Reproducible with Qt and GTK applications (when forced to use the X11 backend) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 485350] In Spectacle, there is no way to do a text paragraph (Enter) without triggering the "Take Photo" function
https://bugs.kde.org/show_bug.cgi?id=485350 --- Comment #7 from Eduardo Correia --- (In reply to Nate Graham from comment #6) > Looks like you described it perfectly, because your screen recording shows > exactly what I'm doing too and it works for me! > > However I think it's only fixed in master, because I built the latest tip of > the release/24.02 branch and can reproduce your issue exactly there. Marking > as fixed in the next version. Those are very great news! Thank you for all the effort :) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 485350] In Spectacle, there is no way to do a text paragraph (Enter) without triggering the "Take Photo" function
https://bugs.kde.org/show_bug.cgi?id=485350 --- Comment #5 from Eduardo Correia --- I can always reproduce it. Both on my desktop (Nobara Linux, Plasma 6.0.3) and on my laptop (Fedora with Plasma 6.0.3 also). Both have Spectacle 24.02.1. To end any suspicions about my configuration or my spectacle shortcuts being the problem, I restored the defaults on Spectacle settings. But it still didn't solve my problem. I will link a video of what I am talking about, since I probably am not explaining the problem very well: https://drive.google.com/file/d/17Mk0LaW23LmDJohlJJNh2pAP8eO5ZxQa/view While adding text, I cannot click enter to do a paragraph or line break. It just takes the screenshot immediately. Is this a bug on my system or is the functionality actually missing from spectacle? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 485350] In Spectacle, there is no way to do a text paragraph (Enter) without triggering the "Take Photo" function
https://bugs.kde.org/show_bug.cgi?id=485350 --- Comment #2 from Eduardo Correia --- (In reply to Noah Davis from comment #1) > What version are you on? The current supported version (24.02) seems to > support multi-line text just fine. Sorry it was late at night and I forgot to fill in the versions of plasma and applications. Plasma 6.0.3, KDE Frameworks 6.6.0. Spectacle 24.02.1 . I just cannot do a multi line while in the screen area selection. Everytime I click enter it just finishes the selection and takes the screenshot. After the screenshot was taken and the screenshot/spectacle window is opened, if I edit and add text I still cannot do Enter. It just won't do anything at all here. The cursor stays at the same single line. Is there a setting that affects this that I might have turned off by mistake or is this a bug? I have no idea if this helps, but its a full AMD system on Wayland, Nobara Linux (Fedora based). -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 485350] New: In Spectacle, there is no way to do a text paragraph (Enter) without triggering the "Take Photo" function
https://bugs.kde.org/show_bug.cgi?id=485350 Bug ID: 485350 Summary: In Spectacle, there is no way to do a text paragraph (Enter) without triggering the "Take Photo" function Classification: Applications Product: Spectacle Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: noaha...@gmail.com Reporter: eduardosare...@gmail.com CC: k...@david-redondo.de Target Milestone: --- SUMMARY When doing a selection for a screenshot and then adding text to it, if we ever need to click the Enter key to add a paragraph or just do a line break to continue adding more text in the line bellow, Spectacle just immediatly takes the screenshot (because Spectacle reads the Enter key as the "accept" key). Trying the shift + Enter shortcut does not work, it still takes the screenshot. Suggestion: Spectacle should probably disable the "Enter to save the screenshot" shortcut while the user is currently editing text on a text box to the screenshot selection, and clicking Enter should do a line break instead. Or, another idea would be to make Enter finish the text box editing (but still stay in the selection screen), so the user could add another text box bellow it as needed, and also read the Shift + Enter universal shortcut as a line break on the current text box that is being edited. STEPS TO REPRODUCE 1. Initiate a selection for a new screenshot with Spectacle; 2. Right in the selection, add a text box and write some text; 3. Try to do a line break/paragraph, but notice that Spectacle just finishes the screenshot even if you were just trying to add a paragraph to your text. OBSERVED RESULT Spectacle finishes editing and takes the screenshot right when Enter is pressed (with text being added). EXPECTED RESULT Being able to do line breaks/paragraphs when adding text to screenshot selections. 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.
[i18n] [Bug 485349] Missing pt_PT localization for most of Plasma 6 (and apps) new and/or reworked features
https://bugs.kde.org/show_bug.cgi?id=485349 --- Comment #2 from Eduardo Correia --- Created attachment 168373 --> https://bugs.kde.org/attachment.cgi?id=168373=edit Dolphin example -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 485349] Missing pt_PT localization for most of Plasma 6 (and apps) new and/or reworked features
https://bugs.kde.org/show_bug.cgi?id=485349 --- Comment #1 from Eduardo Correia --- Created attachment 168372 --> https://bugs.kde.org/attachment.cgi?id=168372=edit colors and themes KCM example -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 485349] New: Missing pt_PT localization for most of Plasma 6 (and apps) new and/or reworked features
https://bugs.kde.org/show_bug.cgi?id=485349 Bug ID: 485349 Summary: Missing pt_PT localization for most of Plasma 6 (and apps) new and/or reworked features Classification: Translations Product: i18n Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: pt Assignee: j...@netcabo.pt Reporter: eduardosare...@gmail.com Target Milestone: --- Created attachment 168371 --> https://bugs.kde.org/attachment.cgi?id=168371=edit System Settings example SUMMARY After Plasma 6 upgrade, most of the new features that were added or reworked lost their correct localization. All relevant localization packages (i10n) are installed correctly and fully updated. After checking at - https://l10n.kde.org/stats/gui/stable-kf6/team/pt/ - I can see that there are in fact many missing translations for KDE 6. So this report is more of a reminder or "ping" to try and reach someone who can maybe help solve this, or maybe even ping/notify the pt_PT translation team. Many critical parts of the system are not localized now on Plasma 6. This does not only affect some obscure menus, but most importantly affects very forward facing menus, settings and descriptions. Stuff like main "1st level" menus in the system settings are not localized at all, and/or there is a serious mix of English and Portuguese. This affects specifically the European Portuguese locale (pt_PT or only "pt"). I have not tested the pt_BR (Brazilian Portuguese) locale. I will add in the attachments section some screenshots with annotations to serve as quick examples. This might also be important for this report, I don't know if this might have triggered any bug related to these missing localizations or not, but I will just link it anyway: https://mail.kde.org/pipermail/kde-i18n-doc/2023-January/001340.html OBSERVED RESULT Mixed of English and Portuguese localization all throughout the desktop and many of the KDE applications. EXPECTED RESULT As close as possible to "everything" being correctly localized to the chosen language (in this case, pt_PT). SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 389568] Feature to reset all settings to default values
https://bugs.kde.org/show_bug.cgi?id=389568 --- Comment #42 from Eduardo Correia --- As a Steam Deck user, more than one time already that I had to literally factory reset my WHOLE steam deck to be able to revert back some stupid things I changed inside KDE that I cannot find where they were or how to change them back or what was the feature even called. Steam Deck is an example of an immutable distro that can still hugely benefit from a "restore settings" button. On my main desktop, after a Plasma 5 to 6 upgrade, some settings got messed up and I had to manually delete the respective config files. This is not at all something that an average user should have to do, since the user can by mistake delete important config files from those folders. I would also say that "Restore default settings" is a better term than "Reset settings" in this context. A cool idea would be a "Support", "Troubleshooting" or similar settings page inside the settings app that could list, based on what was installed, "restore settings" buttons for each. For example, "restore default settings for Dolphin", "Restore default settings for Discover" and etc. All it could do would be maybe delete the config file for that app, because most of the KDE apps already restore their default settings automatically if you delete their config files. So this feature is already "somewhat implemented" to a point. A button that runs "rm" on the specific config file for each KDE apps would probably be enough. Maybe also backup the old settings to a .bk copy, so a button called "Revert" could appear after clicking the restore settings button, so the user can "revert the restore" if they restored settings for the wrong app. That Revert button could stay available as long as a .bk file for that specific app was still present. Another very related feature would be to have a button to completely uninstall or just disable all extensions, themes, kwin scripts and any extra stuff that the user might have installed. It would be an extremely important tool to diagnose misbehaving systems. Such feature could also be present in the same system settings "Troubleshooting" page, as mentioned above. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 484916] "Get New" dialogs do not show unsupported (but installed) add-ons so we can't uninstall them (after KDE 6 upgrade)
https://bugs.kde.org/show_bug.cgi?id=484916 Eduardo Correia changed: What|Removed |Added Summary|"Get New" dialogs do not|"Get New" dialogs do not |show unsupported (but |show unsupported (but |installed) widgets so we|installed) add-ons so we |can't uninstall them (after |can't uninstall them (after |KDE 6 upgrade) |KDE 6 upgrade) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 484916] New: "Get New" dialogs do not show unsupported (but installed) widgets so we can't uninstall them (after KDE 6 upgrade)
https://bugs.kde.org/show_bug.cgi?id=484916 Bug ID: 484916 Summary: "Get New" dialogs do not show unsupported (but installed) widgets so we can't uninstall them (after KDE 6 upgrade) Classification: Plasma Product: plasmashell Version: 6.0.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eduardosare...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY After upgrading do KDE Plasma 6, older KDE 5 global themes, cursors, icons, splash screens, etc stop showing because they are not supported. This is fine, but we also lose the ability to uninstall these unsupported add-ons. Especially with Global Themes, these can get quite big in terms of disk space used. I myself had maybe a hundred of these themes installed. After upgrading to plasma 6, all of them are gone (which is expected) but I cannot uninstall them anywhere. If I open the "Get New" dialogs, and filter by "Show only installed items" it shows "No items found" even if I have dozens of them installed (I do, I checked their respective folders). The only way to remove unsuported widgets is to manually go into their respective folders and delete them, something that is very confusing for casual users especially considering the fact that we can in fact delete very important default themes/add-ons from these folders and break functionality. Users should not need to go delete add-ons folders manually. We also have the problem that these add-ons "get lost" after becoming unsupported, in a way that while they are still there using (what can be a lot of) disk space, the user has no way to know they are still there. The "Add Widget" dialog from the desktop widgets works in a different way, and can be used as a great idea to solve this: While the "Get New" dialog for these widgets still cannot show unsuported but installed add-ons, the "Add Widgets" dialog does: it shows all the currently installed widgets, even the ones that are unsupported. These unsupported ones are greyed out and while hovering them with a mouse they show an unsupported message tooltip with a great user-friendly description. They have a "trash" icon on them that can be used to uninstall them. This way the user knows that they are unsupported, but still installed and wasting disk space, and can safely act on this without needing to go browse folders and delete stuff accidentally. My suggestion: Copy the "Add Widgets" dialog functionality by showing all of the installed add-ons everywhere (global themes, window decorations, icons etc) but have them greyed out and disabled. This way they can be uninstalled safely, just like any other currently supported add-on. They should also appear, also greyed out with an unsupported message, in the "Get New" window when filtered by "show installed items only". STEPS TO REPRODUCE 1. install any plasma 5 (not supported on 6) global theme (or any other plasma 5 exclusive add-on) 2. upgrade to plasma 6 3. all installed addons are gone, user has absolutely no idea where they are, but they are still wasting disk space, just completely hidden from the user OBSERVED RESULT Everything is still installed but hidden without any notice or way to safely uninstall them EXPECTED RESULT Every installed add-on should still be shown, just greyed out / disabled and with an unsupported label. User should be able to uninstall these addons easily without needing to go mess with folders and files manually. SOFTWARE/OS VERSIONS Linux/KDE Plasma: from 5.27.10 to 6.0.3 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 484060] The Flatpak version of Krita 5.2.2 crashes when I try to use the "Save as" option
https://bugs.kde.org/show_bug.cgi?id=484060 Eduardo Medina changed: What|Removed |Added CC||edu.rm...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 484060] New: The Flatpak version of Krita 5.2.2 crashes when I try to use the "Save as" option
https://bugs.kde.org/show_bug.cgi?id=484060 Bug ID: 484060 Summary: The Flatpak version of Krita 5.2.2 crashes when I try to use the "Save as" option Classification: Applications Product: krita Version: 5.2.2 Platform: Flatpak OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: edu.rm...@gmail.com Target Milestone: --- Created attachment 167501 --> https://bugs.kde.org/attachment.cgi?id=167501=edit Bug when I try to save a file in Krita 5.2.2 SUMMARY Hi, I saw that some Flatpak runtimes were updated yesterday and since then Krita 5.2.2 crashes when I try to use the "Save as" option. Even the "Save" option crashes the application if I try to save from a blank project. I use Fedora Silverblue 39 with GNOME 45.5 and the Wayland session. I didn't see the same behaviour in other KDE apps like Kdenlive and Okular, so it seems specify of Krita. I don't know what runtimes are used for Krita Flatpak. If you give me more instructions I can follow them. I share what I get booting the app from the terminal. STEPS TO REPRODUCE 1. Open Krita 5.2.2 Flatpak. 2. Use the "Save as" option or try to "Save" from a new project. 3. You see that the app crashes. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kidletime] [Bug 328987] Power saving should not trigger if joystick/controller/gamepad is in use
https://bugs.kde.org/show_bug.cgi?id=328987 Eduardo Ramirez changed: What|Removed |Added CC||eduardo.rami...@tuta.com -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 473127] Discover should prefer the backend for the installed version of an app when navigating to its page
https://bugs.kde.org/show_bug.cgi?id=473127 Eduardo Correia changed: What|Removed |Added CC||eduardosare...@gmail.com --- Comment #1 from Eduardo Correia --- I was just going to report/suggest this and I found this report already, so I will add my experience here. Plasma 6.0.0 (frameworks 6.0.0 too) and this still happens. I can't count the times that my parents have installed the same app 2 ou 3x on their PC because one of them is from flatpak, another is from snap and another is from the distro repo. And when they complain that their Firefox doesn't have their saved passwords and I go check it's because they logged into flatpak version of firefox but are now trying to use the snap version. Every time they launch discover and search for "Firefox" for example, if the flatpak backend is set as the default but you already have firefox installed from Snap for example, it will show in the application page as NOT being installed and with zero ways to tell that it is in fact installed from another repo/backend. My suggestions for Discover: 1 - Detect that the app is installed from another backend and open automatically the application page on the backend that it is installed from - also show that it is in fact installed in the search results (see point 3); 2 - When viewing the application page for a backend where it is _not_ installed from, show a hint on the top of the page telling the user that there this app is already installed from another source/backend with a button to jump to the installed backend and show the installed app; 3 - Try to join together, in the search results and browsing pages, the same app from multiple backends (for example if you search Firefox but have distro repos, flatpak and snap activated, only show 1 search result for firefox instead of 3 results) and automatically open the "default backend" if the app is not installed, when clicking the single search result. You can change backends as usual on the top of the application page. See point 2 - with this idea, we can safely mark the app as "installed" in the search results and listings. Discover showing the same app multiple times and having the installed version "hidden" if that is not the default backend, is extremely confusing especially for new users. And I don't mean only new linux users, I mean new KDE users too. I am glad to try help where I can. Thank you all for your effort :) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 447115] Dolphin reports "Access denied" when moving files from ext4 to ntfs
https://bugs.kde.org/show_bug.cgi?id=447115 Eduardo changed: What|Removed |Added CC||eduardo.c...@kdemail.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480078] New: Artifacts and tearing while dragging windows only under 4k high refresh rate with UI global scale
https://bugs.kde.org/show_bug.cgi?id=480078 Bug ID: 480078 Summary: Artifacts and tearing while dragging windows only under 4k high refresh rate with UI global scale Classification: Plasma Product: kwin Version: 5.27.10 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: eduardo.c...@kdemail.net Target Milestone: --- Created attachment 165059 --> https://bugs.kde.org/attachment.cgi?id=165059=edit Video showing the artifacts I got a new monitor and I started experiencing visual artifacts while dragging windows, specially if the window being dragged overlaps with the taskbar. The taskbar displays some flickering, and the window displays some crazy tearing/rectangular holes. Difficult to explain in words, please see attached video for clarification. For me this only happens on the 4k resolution (3840x2160) AND using refresh rates either 144Hz or 160Hz, AND using 150% scaling factor (might happen on other scaling factor). If I put 4k 120Hz or below, the bug doesn't trigger, it needs at least 144Hz to trigger. If I lower the resolution to anything below 4k, it doesn't happen. If I use 100% scaling, it doesn't happen, even on 4k 160Hz. So you need these 3 conditions to trigger it: 4k, 144Hz+, and a scaling factor like 150%. STEPS TO REPRODUCE 1. Own a 4k+high refresh rate monitor 2. Set the resolution to 4k, the refresh rate to at least 144Hz, and the global scaling factor to 150%. 3. Drag some window overlapping the taskbar OBSERVED RESULT Crazy tearing/rectangular holes on the window being dragged, and flickering on the taskbar. EXPECTED RESULT Smooth dragging with no artifacts SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.1.71-1-lts (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-8700K CPU @ 3.70GHz Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4090/PCIe/SSE2 nVidia driver version 535.113.01 -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 478210] New: pt_PT language all throughout KDE is not respecting the 1990 (!) Portuguese Orthographic Agreement (in use since 2009, mandatory since 2015)
https://bugs.kde.org/show_bug.cgi?id=478210 Bug ID: 478210 Summary: pt_PT language all throughout KDE is not respecting the 1990 (!) Portuguese Orthographic Agreement (in use since 2009, mandatory since 2015) Classification: Translations Product: i18n Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: pt Assignee: j...@netcabo.pt Reporter: eduardosare...@gmail.com Target Milestone: --- SUMMARY The whole European Portuguese (pt_PT) language in most if not all KDE desktop and apps is still written in an "old way" that is not correct anymore. All other main operating systems (Windows, macOS, Android, iOS, etc) have already updated their pt_PT language, as did some other desktops like GNOME (not 100% but almost) and most GTK apps. I have been holding out from reporting this bug for years now, waiting for it to somehow get "fixed", but it never did. I figured that the KDE team probably doesn't have many pt_PT contributors so they never really noticed this language was not correctly implemented, which is fine and understandable. Since we are all preparing for the big Plasma 6 release, I figured it would be worth it to finally have a KDE/Plasma release that finally addresses this. Using the old way of writing pt_PT is not considered "professional" at all nowadays, since it's been so many years already since the agreement was made. Long story short (trust me it's a very long bureaucratic story), the Portuguese Orthographic Agreement was approved first in 1990 to simplify the language and clean up unused and "silent letters" from many words to make the vocabulary a bit cleaner and simpler. While this was introduced in 1990, most people didn't really care about it for many years and it wasn't mandatory at all, only considered a "suggestion". In 2009 it started to slowly become mandatory and it entered a so called "transition period", in many official documents and important gov. stuff it was mandatory, but for the common citizens it was still only a suggestion. 2015 was the first date agreed to make it mandatory to the whole PT community, but it was later pushed back to 22 Sep 2016, when it finally became mandatory for all and everything and since then, all pt_PT written stuff has to use that new way of writing to be considered "correct" in the European Portuguese language. Examples: "Actualização" is now "Atualização" (lost the silent and useless C). "óptimo" is now "ótimo" (same thing but with P). Sources that confirm what I am talking about: #1 - Here is a wikipedia page, in English, speaking a bit about all of this and how it started back in 1990 - https://en.wikipedia.org/wiki/Portuguese_Language_Orthographic_Agreement_of_1990 #2 - publico.pt is one of our oldest, most famous and trusted newspaper, on this post talks about how the 1990 agreement is only going to get mandatory after 22 Sep 2016, instead of the previous 2015 date. Also talks a lot about what changes and what it implies - https://www.publico.pt/2015/05/13/opiniao/opiniao/o-acordo-ortografico-de-1990-nao-e-obrigatorio-a-partir-de-13-de-maio-de-2015-1695336 #3 - parlamento.pt is literally our official gov parliament website. This is the official document about this, and its like a guide teaching what changed and how to write "correctly" after this agreement. - https://www.parlamento.pt/Documents/XIILEG/Guia_Acordoortografico.pdf #4 - many more on Google, this was discussed everywhere and had national media coverage for years... Here are some KDE examples: #1 - In Discover, the words "updates" and "updating..." and everything related, in portuguese "Actualizações" and "A actualizar..." are written in the old form. The new form should be "Atualizações" and "A atualizar...". The same words "Atualizar" are wrong in System Settings. The left sidebar, the last item about "Applications Updates" is written "Actualização das Aplicações", should be without that C. If you enter that KCM, that world is also written in the old way many times. #2 - In Dolphin, if you open the three dot/hamburger menu, the third item has two words is written in the old form. It says "Acções da Vista Actual" should be "Ações da Vista Atual". The world "acções" (badly written) is repeated throughout many parts of Dolphin and other KDE apps. "acções" -> "ações". "acção" -> "ação". #3 - All of these translations should never be confused with pt_BR (Brazilian), that while similar, are written and spoken in a (very) different way. pt_PT and pt_BR are NOT the same and this report only applies to pt_PT - European Portuguese / "Português Europeu". All of these words are just "small bits here and there" but all together give this sense of "something being off". This is not a hard fix, but surely it will take some time effort and a nice amount
[kde] [Bug 478120] New: Changing locale from anything else to pt_PT on Languages KCM does not update locale files correctly
https://bugs.kde.org/show_bug.cgi?id=478120
Bug ID: 478120
Summary: Changing locale from anything else to pt_PT on
Languages KCM does not update locale files correctly
Classification: I don't know
Product: kde
Version: unspecified
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: eduardosare...@gmail.com
Target Milestone: ---
SUMMARY
I am still unsure if this is a distro-specific problem or a KDE problem I have
tested on Nobara and stock Fedora on both my machines and the problem exists on
both. I am also unsure of where to report this bug, so I ask any admin/mod to
correctly assign this report to its correct category/component.
When changing from any language to "European Portuguese" (or "Português
europeu"), the system locale is not updated correctly, even after re-login. In
region & language KCM, changing to any language usually results in locale files
being updated, and stuff like "cat /var/lib/AccountsService/users/${USER}"
returning a line "Languages=en_US.UTF-8;" .
However, when you select "Português europeu" from the language options, and
click the Apply button, when it automatically goes back to the main page of
this KCM, it still shows the previously configured language. It didn´t apply
the new locale correctly. Also, if you do "cat
/var/lib/AccountsService/users/${USER}¨ in the console, it still shows the
previous locale in the Languages line. If you change to any other language,
this line gets updated correctly. If you delete this line, and change to any
other language, this line gets added again. But if you delete this line, and
then change to pt_PT ("português europeu" option) and check that file again,
this line is NOT added. Whatever function is adding/updating this line for
other languages, it's not doing it for pt_PT . This is also reflected in the
whole system, as everything is still shown with the locale that was previously
correctly set, which means that the system locale is not being updated at all,
after choosing portuguese european. Still, if you go do change the language in
the region & languages KCM, it shows portuguese european added on that list,
even though it had absolutely no effect on the system.
If you check plasma-localerc in the user .config folder, a similar behaviour
exists: the [Translations] line is correctly updated, but the [Formats] line is
NOT updated if the language is pt_PT. If you choose any other language,
[Formats] is updated correctly.
If you add multiple languages to the list in this KCM, they are all listed
correctly in plasma-localerc, but similarly, the [Formats] line and this file:
"/var/lib/AccountsService/users/${USER}" are NOT updated if the locale pt_PT is
on the top of the locales list. If you move any other language from that list
to the top, everything is updated correctly. Move european portuguese to the
top of the list again, and all changes get ignored/don't do anything. The only
thing that gets changed, is the [Translations] line at plasma-localerc.
This might be related to the bug report #454991 , also reported by me some
months ago. Even though the problem is different, and that other bug reported
is now fixed, the fix for that bug report might have been incomplete or somehow
that fix created this new bug.
STEPS TO REPRODUCE
1. Go into Region & language settings, switch from any language to european
portuguese, or add multiple languages with european portuguese on top of the
list. Click Apply. Re-login is optional, the problem can be seen either way.
2. Language is not changed at all, files "plasma-localerc" and
"/var/lib/AccountsService/users/${USER}" still have the previous language set.
3. Choose any other language, or move any other language to the top of the
languages list and click apply, check those same files and confirm that now
everything got correctly updated.
OBSERVED RESULT
KDE locale files not updated correctly after choosing european portuguese.
EXPECTED RESULT
Everything having the same behaviour as it has changing to any other language.
SOFTWARE/OS VERSIONS
Linux: 6.6.3-203
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
--
You are receiving this mail because:
You are watching all bug changes.
[krfb] [Bug 477981] New: SHIFT key can get stuck when using the session remotely
https://bugs.kde.org/show_bug.cgi?id=477981 Bug ID: 477981 Summary: SHIFT key can get stuck when using the session remotely Classification: Applications Product: krfb Version: 23.08.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: grundleb...@googlemail.com Reporter: eduardosanchezmu...@gmail.com Target Milestone: --- SUMMARY SHIFT key can get stuck when using the session remotely. When that happens, every click and key stroke (local or remote) is handled as if SHIFT was pressed, making the session almost unusable. Closing Krfb does not fix it. A log out or reboot is required to unstuck the key. At this point, if the session gets locked, it will be impossible to unlock (unless your password can be typed with SHIFT pressed) and VT switching will not work, so the only way out is pulling the plug to reset the PC. There are two ways this can happen: a. Randomly after using the remote session for a while b. Disconnecting the VNC client with SHIFT pressed STEPS TO REPRODUCE 1. Launch Krfb 2. Connect from another PC with a VNC client 3. Close the VNC client with SHIFT pressed, or just use the the remote desktop for a while OBSERVED RESULT The SHIFT key gets stuck on the PC running Krfb. EXPECTED RESULT The SHIFT key should not get stuck. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION Wayland session and pw backend -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463047] Flatpak version doesn't behave correctly on GNOME Wayland
https://bugs.kde.org/show_bug.cgi?id=463047 --- Comment #4 from Eduardo Medina --- Created attachment 163230 --> https://bugs.kde.org/attachment.cgi?id=163230=edit Modifying Flatseal to get Kdenlive Flatpak working correctly on GNOME Wayland part 2 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463047] Flatpak version doesn't behave correctly on GNOME Wayland
https://bugs.kde.org/show_bug.cgi?id=463047 --- Comment #3 from Eduardo Medina --- Created attachment 163229 --> https://bugs.kde.org/attachment.cgi?id=163229=edit Modifying Flatseal to get Kdenlive Flatpak working correctly on GNOME Wayland part 1 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463047] Flatpak version doesn't behave correctly on GNOME Wayland
https://bugs.kde.org/show_bug.cgi?id=463047 --- Comment #2 from Eduardo Medina --- Hi. Now I see that the environment variables for Flatpak are bad configured. I have to set "XDG_CURRENT_DESKTOP=kde" to "XDG_CURRENT_DESKTOP=gnome" to get the app working correctly. Doing this I can use Kdenlive Flatpak more integrated on GNOME Wayland. Even the app boots faster. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 475938] Updates notification appears, but Discover is stuck at "Fetching updates"
https://bugs.kde.org/show_bug.cgi?id=475938 --- Comment #2 from Eduardo Sánchez Muñoz --- First, I waited around 20 minutes before giving up. After a reboot, I tried again and gave up after 5 minutes and updated with dnf, which took much less times. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 475938] New: Updates notification appears, but Discover is stuck at "Fetching updates"
https://bugs.kde.org/show_bug.cgi?id=475938 Bug ID: 475938 Summary: Updates notification appears, but Discover is stuck at "Fetching updates" Classification: Applications Product: Discover Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: eduardosanchezmu...@gmail.com CC: aleix...@kde.org Target Milestone: --- SUMMARY There is a notification about available updates, but Discover is stuck at "Fetching updates" STEPS TO REPRODUCE 1. Log in 2. Wait for the updates notification 3. Open Discover (from launcher or from notification) OBSERVED RESULT Discover is stuck at "Fetching updates" EXPECTED RESULT Discover should show the updates that caused the notification to pop up. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 38 (available in About System) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Fetching updates with dnf works fine. Opening discover from command line shows: adding empty sources model QStandardItemModel(0x560dd7916170) QObject::startTimer: Timers cannot have negative intervals file:///usr/lib64/qt5/qml/org/kde/kirigami.2/BasicListItem.qml:288:18: QML QQuickItem*: Binding loop detected for property "implicitWidth" -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 446581] plasmashell and Firefox hang in QXcbClipboard::waitForClipboardEvent() when Firefox attempts to update the clipboard and show a notification at the same time
https://bugs.kde.org/show_bug.cgi?id=446581 Eduardo Rocha changed: What|Removed |Added CC||edarocha1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358418] Allow widgets to optionally not snap to a grid
https://bugs.kde.org/show_bug.cgi?id=358418 Eduardo Baldino changed: What|Removed |Added CC||edua...@baldino.com.br --- Comment #33 from Eduardo Baldino --- It's really a shame that people have been complaining about this for so long and the developers don't seem to care. In my mind, this spills over into politics - the fact that the developers are unwilling to fix this is a political statement on their part. It takes me 10 minutes to organize my widgets trying to work around the grid-snapping. It never looks just the way I want it to look, but I get as close as I can. And every time I reboot the widgets are moved; their new positions vary, and one of them in particular is placed in a seemingly random position on the screen. Two widgets that shouldn't overlap are now overlapping, and two other widgets that should overlap no longer overlap. Then it takes me 10 minutes to organize everything again. Every time I reboot. So the question is: am I supposed to WANT to organize my desktop the way I see fit? Apparently not... -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 456310] Keyboard volume control keys don't change the volume of the default sink
https://bugs.kde.org/show_bug.cgi?id=456310 Eduardo changed: What|Removed |Added CC||eduardo.c...@kdemail.net --- Comment #6 from Eduardo --- I suffer a lot from this issue. I use pipewire with a virtual sink, and I use Carla with some LSP - Linux Studio Plugins - equalizer/crossover on top of the virtual sink routing to the real sink. My default sink is the virtual sink, and that's the one that should have the volume being controlled. However, most of the times, the applet changes the volume of the real sink. Just like the OP's video. But for me it's somewhat random, sometimes it works correctly, sometimes it doesn't. Regardless of something being played back or not. I've looked into the code, in this file https://invent.kde.org/plasma/plasma-pa/-/blob/master/src/pulseaudio.cpp there is a method called "findPreferredSink()" in line 271. >From reading the code, I understand there are 2 distinct concepts: "default sink" and "preferred sink. "Default sink" is the selected sink on the applet's UI, and "preferred sink" is a guess of what sink should have the volume controlled based on the playback state. For instance, if "sink A" is the selected "default sink" in the UI but it happens to not have any playback going on, while another "sink B" does have playback going on, then the code would select "preferred sink" as "sink B", not "sink A", and volume changes would affect "sink B" and not "sink A". That seems to be with the best of intentions, however something is not working correctly in the case of virtual pipewire sinks. I don't see any obvious logic error by reading the code and running it mentally. But I haven't managed to debug it since I don't know of an easy way to compile and run this applet and see some sort of console output. Simple fix would be to just disregard this "preferred sink" concept at all and just always adjust the volume of the selected "default sink". However that feature is there for 7 years and I guess most KDE mantainers would not agree to delete an already deployed feature like this. So... maybe someone can properly debug this code and find the bug? Perhaps pipewire is guilty of not reporting the correct state of its devices, if we can debug and show that it is the case, we should file a bug report in pipewire. Or perhaps there is a logic bug in this code that I'm not seeing now. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 430288] Static noise when scrolling fast on the volume tray icon
https://bugs.kde.org/show_bug.cgi?id=430288 Eduardo changed: What|Removed |Added CC||eduardo.c...@kdemail.net --- Comment #3 from Eduardo --- +1 for this, I've always found this to be annoying. My keyboard has a kind of a dial to adjust volume, it triggers many successive playbacks of this volume test tone. It surely could be better polished. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 469656] Dolphin cannot remember previously opened tabs
https://bugs.kde.org/show_bug.cgi?id=469656 --- Comment #25 from Eduardo --- (In reply to Bug Janitor Service from comment #23) > A possibly relevant merge request was started @ > https://invent.kde.org/system/dolphin/-/merge_requests/549 Thank you, this looks good. At least dolphin now remembers closed tabs from last time. I have not tested session restore, but I will only do it when I actually can log out and back in. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 469656] Dolphin cannot remember previously opened tabs
https://bugs.kde.org/show_bug.cgi?id=469656 --- Comment #16 from Eduardo --- Background --- I heavily rely on activity functionality to restore whole session and have all tabs in places where it was before logout (I have too many of them to handle manually), so I went investigating this issue as my time permitted. As a result I compiled my own version where part of this patch is reverted and it's working. Investigation results (may be useful to ones who will try to solve the issue) --- if I comment out almost all of the new solution in "Dolphin::dolphinGuiInstances" and put back the old solution in global.cpp, BUT still have "#if HAVE_KACTIVITIES" which relates to QEventLoop (the "first if"), the result was the same - it does not work for me. If I comment out "first if", leaving just the old solution, the issue is solved. So this leads to event loop issue which was there for "ensures the consumer is ready for query". Hope this helps, I'll attach a file with actual sample. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 469656] Dolphin cannot remember previously opened tabs
https://bugs.kde.org/show_bug.cgi?id=469656 Eduardo changed: What|Removed |Added CC||ed...@inbox.lv --- Comment #15 from Eduardo --- Created attachment 158994 --> https://bugs.kde.org/attachment.cgi?id=158994=edit Problem investigation result sample -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 469184] 23.04 version lost "blur factor" feature
https://bugs.kde.org/show_bug.cgi?id=469184 Eduardo Rocha changed: What|Removed |Added CC||edarocha1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 468077] It's now harder to draw an unfilled circle/ellipse/square/rectangle
https://bugs.kde.org/show_bug.cgi?id=468077 Eduardo Rocha changed: What|Removed |Added CC||edarocha1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 411729] Accented and dead keys do not work when QT_IM_MODULE is set to anything
https://bugs.kde.org/show_bug.cgi?id=411729 --- Comment #52 from Eduardo --- (In reply to Andrey from comment #51) > The accented symbols should work without any Input Method, though. > See the reports above. Before finding the solution, I tried to set QT_IM_MODULE to an empty string in /etc/environment, without success after restarting the session. After selecting the ibus as input method on the GUI, then QT_IM_MODULE has been redefined to "ibus" somewhere, and everything seems to be working fine now. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 411729] Accented and dead keys do not work when QT_IM_MODULE is set to anything
https://bugs.kde.org/show_bug.cgi?id=411729 --- Comment #50 from Eduardo --- Found a solution! 1. Launch the Input Method Selector 2. Select IBus (I'm on Wayland) and Logout Somehow mine was set to "No Input Method" after the upgrade. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 411729] Accented and dead keys do not work when QT_IM_MODULE is set to anything
https://bugs.kde.org/show_bug.cgi?id=411729 --- Comment #49 from Eduardo --- (In reply to Andrey from comment #48) > Please make sure you have no ibus daemons/packages. Search this report about > ibus. > Then retest all the env/platform combinations possible. I'm not running any process/daemon containing the keyword "ibus" (although there are some packages installed). I thought ibus was the solution, is it not? First time I solved this issue by changing from xim to ibus in the QT environment variable. I still don't get why the application would behave differently with mostly the same environment. > Also, what languages do you have configured, what order? Initially I had installed Fedora 37 in Brazilian Portuguese, but soon I changed it to American English alone. My current locale is: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8 -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 411729] Accented and dead keys do not work when QT_IM_MODULE is set to anything
https://bugs.kde.org/show_bug.cgi?id=411729 Eduardo changed: What|Removed |Added CC||eduardo.b...@hotmail.com Status|RESOLVED|VERIFIED --- Comment #47 from Eduardo --- Had this problem on Wayland Fedora37 some weeks ago, then fixed it with QT_IM_MODULE=ibus. One day I changed to X11 and the problem reappeared, but then vanished again when I went back to Wayland. Now I just updated to Fedora 38 (Wayland), and the issue came back, even with QT_IM_MODULE=ibus. Interesting notes: - When I launch e.g. Konsole from the launcher, I cannot type the dead keys ~´` - If I launch Konsole from itself, by running "konsole", it suddenly works - I recorded the output of `env` for both cases above and got the following diff (which I don't see anything wrong): 26c26 < KONSOLE_DBUS_SERVICE=:1.97 --- > KONSOLE_DBUS_SERVICE=:1.98 35a36 > LESS=-R 37a39 > LSCOLORS=Gxfxcxdxbxegedabagacad 41a44 > PAGER=less 56c59,60 < SHELL_SESSION_ID=458ac8224e6f49fba96d12b85f056764 --- > SHELL_SESSION_ID=9001639909854c029a48343daeac455d > SHLVL=2 84d87 < SHLVL=1 86,89d88 < PAGER=less < LESS=-R < LSCOLORS=Gxfxcxdxbxegedabagacad < LC_ALL=en_US.UTF-8 90a90 > LC_ALL=en_US.UTF-8 -- You are receiving this mail because: You are watching all bug changes.
[krfb] [Bug 468861] New: (2023) KRFB segfaults at RfbServer::updateScreen(QList const&) after a few minutes on Wayland
https://bugs.kde.org/show_bug.cgi?id=468861 Bug ID: 468861 Summary: (2023) KRFB segfaults at RfbServer::updateScreen(QList const&) after a few minutes on Wayland Classification: Applications Product: krfb Version: 22.12.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: grundleb...@googlemail.com Reporter: eduardo.b...@hotmail.com Target Milestone: --- Created attachment 158353 --> https://bugs.kde.org/attachment.cgi?id=158353=edit Pretty printed backtrace from GDB SUMMARY KRFB segfaults at `RfbServer::updateScreen(QList const&)` after few minutes on connection with remote client (KRDC) ``` Thread 1 "krfb" received signal SIGSEGV, Segmentation fault. 0x555750f0 in RfbServer::updateScreen(QList const&) () (gdb) bt #0 0x555750f0 in RfbServer::updateScreen(QList const&) () #1 0x555751c7 in RfbServerManager::updateScreens() () #2 0x764d0e96 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #3 0x764d421e in QTimer::timeout(QTimer::QPrivateSignal) () from /lib64/libQt5Core.so.5 #4 0x764c7fc5 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #5 0x771aed62 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #6 0x7649d4e8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #7 0x764ed981 in QTimerInfoList::activateTimers() () from /lib64/libQt5Core.so.5 #8 0x764ee2a4 in idleTimerSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5 #9 0x74718c7f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #10 0x7476f118 in g_main_context_iterate.constprop () from /lib64/libglib-2.0.so.0 #11 0x74715f00 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #12 0x764ee5fa in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #13 0x7649bf3a in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #14 0x764a4002 in QCoreApplication::exec() () from /lib64/libQt5Core.so.5 #15 0x55569798 in main () ``` STEPS TO REPRODUCE 1. Start server stream 2. Connect with remote 3. Use host normally and wait for a few minutes OBSERVED RESULT Sudden crash SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.1.18-200.fc37.x86_64 (64-bit) Graphics Platform: __Wayland__ Processors: 12 × AMD Ryzen 5 5500U with Radeon Graphics Memory: 11,0 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 82MF System Version: IdeaPad 3 15ALC6 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 468854] Dolphin crashed while trying to eject an external encrypted HDD
https://bugs.kde.org/show_bug.cgi?id=468854 --- Comment #1 from Eduardo Sánchez Muñoz --- I found out how to reproduce this: 1. The device appears on both devices and external devices categories. 2. Clicked on the eject button in the devices categories. 3. A spinner replaces the eject button and the disappears. 4. The eject button does not disappear from the external device category. 5. Clicking the eject button in the external device category crashes Dolphin. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 468854] New: Dolphin crashed while trying to eject an external encrypted HDD
https://bugs.kde.org/show_bug.cgi?id=468854 Bug ID: 468854 Summary: Dolphin crashed while trying to eject an external encrypted HDD Classification: Applications Product: dolphin Version: 22.12.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: eduardosanchezmu...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- Application: dolphin (22.12.3) Qt Version: 5.15.9 Frameworks Version: 5.104.0 Operating System: Linux 6.2.11-300.fc38.x86_64 x86_64 Windowing System: Wayland Distribution: "Fedora release 38 (Thirty Eight)" DrKonqi: 5.27.4 [KCrashBackend] -- Information about the crash: Dolphin crashed while trying to eject an external encrypted HDD: 1. Clicked the eject button 2. A spinner replaced the eject button for a few seconds 3. The eject button appeared again 4. Clicking the eject button again crashed Dolphin Usually, the device is ejected after clicking once the eject button. The crash does not seem to be reproducible. -- Backtrace: Application: Dolphin (dolphin), signal: Segmentation fault [KCrash Handler] #4 0x55c7f8664a02 in TerminalPanel::sendCdToTerminal(QString const&, TerminalPanel::HistoryPolicy) () #5 0x55c7f86433c3 in DolphinMainWindow::slotStorageTearDownFromPlacesRequested(QString const&) () #6 0x7f0cc4ae8651 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #7 0x55c7f8663b6a in PlacesPanel::slotTearDownRequested(QModelIndex const&) () #8 0x7f0cc6a99fd8 in QtPrivate::QFunctorSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) [clone .lto_priv.0] () from /lib64/libKF5KIOFileWidgets.so.5 #9 0x7f0cc4ae8651 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #10 0x7f0cc6a940dc in KFilePlacesEventWatcher::actionClicked(QModelIndex const&) () from /lib64/libKF5KIOFileWidgets.so.5 #11 0x7f0cc6a8f206 in KFilePlacesEventWatcher::eventFilter(QObject*, QEvent*) () from /lib64/libKF5KIOFileWidgets.so.5 #12 0x7f0cc4ab3af6 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #13 0x7f0cc57aeb65 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #14 0x7f0cc57b7456 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #15 0x7f0cc4ab3d48 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #16 0x7f0cc57b56a4 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool, bool) () from /lib64/libQt5Widgets.so.5 #17 0x7f0cc580d1a9 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () from /lib64/libQt5Widgets.so.5 #18 0x7f0cc581072f in QWidgetWindow::event(QEvent*) () from /lib64/libQt5Widgets.so.5 #19 0x7f0cc57aeb75 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #20 0x7f0cc4ab3d48 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #21 0x7f0cc4f6c44b in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /lib64/libQt5Gui.so.5 #22 0x7f0cc4f4aa0c in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /lib64/libQt5Gui.so.5 #23 0x7f0cc1f639e4 in userEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5WaylandClient.so.5 #24 0x7f0cc2911f58 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #25 0x7f0cc2971cd8 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0 #26 0x7f0cc2913233 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #27 0x7f0cc4b06936 in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #28 0x7f0cc4ab270b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #29 0x7f0cc4aba99b in QCoreApplication::exec() () from /lib64/libQt5Core.so.5 #30 0x55c7f86381d7 in main () [Inferior 1 (process 12663) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[flatpak-platform-plugin] [Bug 468773] I can't drag and navigate normally through menus in many KDE and Qt Flatpak apps on GNOME 44 with Wayland
https://bugs.kde.org/show_bug.cgi?id=468773 --- Comment #1 from Eduardo Medina --- Created attachment 158280 --> https://bugs.kde.org/attachment.cgi?id=158280=edit Videos with Flatpak versions of Krita, Shotcut and OBS Studio -- You are receiving this mail because: You are watching all bug changes.
[flatpak-platform-plugin] [Bug 468773] New: I can't drag and navigate normally through menus in many KDE and Qt Flatpak apps on GNOME 44 with Wayland
https://bugs.kde.org/show_bug.cgi?id=468773 Bug ID: 468773 Summary: I can't drag and navigate normally through menus in many KDE and Qt Flatpak apps on GNOME 44 with Wayland Classification: Frameworks and Libraries Product: flatpak-platform-plugin Version: unspecified Platform: Flatpak OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jgrul...@redhat.com Reporter: edu.rm...@gmail.com Target Milestone: --- Hi, I recently updated to Fedora Silverblue 38 and I always use the Wayland session. I see that some apps like OBS Studio and Audacious with the Qt interface don't let me to navigate through many normally. If I do one click on File (Archivo), the menu closes when I drag the mouse pointer to Edit (Editar). Both apps are in Flatpak format. By other hand, Krita and Shotcut in Flatpak format don't allow me to drag elements, so it's much harder to work with those apps on the Wayland session of GNOME 44. The menu works correctly on those apps. STEPS TO REPRODUCE 1. Open a Qt or KDE app in Flatpak format. 2. Try to navigate through the menu or try to drag and drop things/elements. OBSERVED RESULT Bad behavior of the app menu or the drag feature. EXPECTED RESULT A correct behavior of the menu and the drag, obviously. SOFTWARE/OS VERSIONS - I use Fedora 38 Silverblue with the GNOME session. - Kernel: Linux 6.2.11-300.fc38.x86_64 - GPU: AMD Radeon RX 580 working with the Open Source drivers - CPU: Intel Core i5-12600K - Motherboard: ASUS TUF GAMING B660-PLUS WIFI D4 - RAM: 32GB of DDR4. - Versions of Mesa in Flatpak: 21.1.8, 21.3.9 and 23.0.2 - Version of Mesa in RPM: Mesa 23.0.2 ADDITIONAL INFORMATION This is what I get with "flatpak list | grep kde": Adwaita theme org.kde.KStyle.Adwaita 5.15-22.08 flathub system Adwaita theme org.kde.KStyle.Adwaita 6.4 flathub system KDE Application Platformorg.kde.Platform5.15-22.08 flathub system KDE Application Platformorg.kde.Platform6.4 flathub system QGnomePlatform org.kde.PlatformTheme.QGnomePlatform5.15-22.08 flathub system QGnomePlatform org.kde.PlatformTheme.QGnomePlatform6.4 flathub system QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-22.08 flathub system QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 6.4 flathub system KGetorg.kde.kget23.04.0 stable flathub system KolourPaint org.kde.kolourpaint 23.04.0 stable flathub system Krita org.kde.krita 5.1.5 stable flathub system Codecs org.kde.krita.Codecsstable flathub system Okular org.kde.okular 22.12.3 stable flathub system The version of Shotcut is 22.12.21 The version of OBS Studio is 29.0.2 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462351] Discover crashes when I close it after an update.
https://bugs.kde.org/show_bug.cgi?id=462351 --- Comment #14 from Eduardo Baldino --- I am saddened by the lengths to which you guys go to avoid doing the work... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 466197] Implement org.freedesktop.impl.portal.Secret
https://bugs.kde.org/show_bug.cgi?id=466197 Eduardo Rocha changed: What|Removed |Added CC||edarocha1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 465996] Audio Applet "Show virtual devices" broken for newly created applets after 5.27.0
https://bugs.kde.org/show_bug.cgi?id=465996 Eduardo changed: What|Removed |Added CC||eduardo.c...@kdemail.net --- Comment #4 from Eduardo --- I noticed it when I created a brand new user on my machine. Virtual devices are not shown, regardless of the "Show virtual devices" checkbox state. Also, this checkbox state does not persist upon logoff/login: it always starts unchecked. I looked into the commit history, and commit 586fb5c315d12a02f2a3e2a524a5b6bf39ba2b52 seems to be the one to blame, apparently it was migrating the applet settings into KCM, but looks like something slipped. This commit was released into 5.27, so yes, this is a 5.27 regression. I reverted into using the old KMix, a downgrade in looks, but works for me while this doesn't get fixed. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 456210] Cannot unlock screen when using multiple monitors
https://bugs.kde.org/show_bug.cgi?id=456210 --- Comment #66 from Eduardo B. Saporski --- I would actually like better instructions to send logs to debug the error. Is it possible to attach something do SDDM and generate better logs? It's hard to reproduce this bug. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 464612] Discover creates repeated notifications of ongoing tasks when you open and close its window
https://bugs.kde.org/show_bug.cgi?id=464612 --- Comment #1 from Eduardo Correia --- Created attachment 155485 --> https://bugs.kde.org/attachment.cgi?id=155485=edit example after 3x open/close discover window Guess I forgot the attachment. Added it now. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 464612] New: Discover creates repeated notifications of ongoing tasks when you open and close its window
https://bugs.kde.org/show_bug.cgi?id=464612 Bug ID: 464612 Summary: Discover creates repeated notifications of ongoing tasks when you open and close its window Classification: Applications Product: Discover Version: 5.26.5 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: eduardosare...@gmail.com CC: aleix...@kde.org Target Milestone: --- SUMMARY Discover creates many repeated notifications of "installing updates" with the progress bar when you open and close its window repeatedly. A recent KDE update made Discover able to be closed while installing updates or apps, and a pending notification will appear with the current status. If a user closes the window while it has some ongoing action a notification will be shown with the current progress. However, if the user decides to "go check the progress" in Discover itself, or go do anything else that he reopens Discover window, and then closes it again, a new additional ongoing will be created, even though there was already one. You can spam this and create as many ongoing notifications you like. When Discover finishes its work, all these repeated notifications, as many as there are, will all spam you desktop again telling you they finished their work. The Discover icon in the taskbar also shows the number of notifications, that keeps increasing too as new notifications are created. Basically everything works as expected, except that Discover shouldn't create a new "installing stuff" notification if there was already one. Added an attachment that tries to show exactly what happens after I closed and opened Discover window many times (3 times, in the case of the attachment) while a long update was installing. (confused about if this bug report should go into "discover" component or "notifier"). STEPS TO REPRODUCE 1. Make Discover do some work that takes some time: install many updates, or many apps in a row. 2. Close Discover window, an ongoing notification will be created, as expected. 3. Open Discover window again while it hasn't finished its work, and then close it again. 4. Another additional notification will be created, not removing the old one. 5. Repeat this as many times as you want, you will created dozen of them. 6. All of this ongoing notifications will spam your desktop with "finished" when Discover completes its tasks. OBSERVED RESULT Repeated similar ongoing notifications. EXPECTED RESULT Discover should maybe check if there is already an ongoing notification similar to what it is trying to create, and not create a new one. Or remove the old one and create a new one. SOFTWARE/OS VERSIONS Linux: 6.1.4 64 bits - OpenSUSE Tumbleweed KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.8 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464322] Make Kwin capable of using one animation for opening windows and a different one for closing
https://bugs.kde.org/show_bug.cgi?id=464322 --- Comment #3 from Eduardo Correia --- (In reply to code from comment #2) I like your idea but I don't know how complex it would be to implement, and its a very niche use case. Seems very complex in terms of coding, I am not a KDE developer thought so can't say. I also really liked your mockup, but to be honest we are slowly making this effects config page overly complex and it will get very overwhelming (it already is) for many users. I think we could implement your idea (I don't know about the checkboxes and random effects though) but in a separate screen dedicated to it. Keep it "simple by default". Actually, the main desktop effects page should maybe be even more "downgraded" - it should maybe only show a simple dropdown selector for "Window Open/Close effect". This way all those hundreds of options (if you install many extra effects) will get all condensed into a single option, that dropdown selector. Would have the same functionality it already has, just a lot cleaner. You clicked the dropdown, you select an effect from all the installed, done. But! It could also have, bellow that dropdown selector, the idea of "advanced open/close effect options". By clicking it, the user could be taken to a new window/page/tab where it would list all the effects in a list way (basically the way it currently is), separated in two lists, the open effects and the close effects, where we could choose a different one for each, and here is where we could use your mockup (comment #2). The idea of choosing multiple effects could be interesting but we need a kde developer to tell us how feasible it would be to implement. Might not be worth it because it would be a very niche use case, having random effects like that, and very complex to develop. But I still think we could cleanup that effects page a lot more with that selector, since it would achieve the same thing as the current implementation. Maybe I should open a separate wishlist request with this "cleanup" idea? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 464432] New: KDEConnect: PC Ringtone playback is being delayed
https://bugs.kde.org/show_bug.cgi?id=464432 Bug ID: 464432 Summary: KDEConnect: PC Ringtone playback is being delayed Classification: Applications Product: kdeconnect Version: 22.12.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: eduardo.c...@kdemail.net CC: andrew.g.r.hol...@gmail.com Target Milestone: --- SUMMARY When receiving an incoming call on Android, the computer also plays a ringtone, which is a nice feature of KDE Connect. However, this PC ringtone playback is being delayed for some 5-10 seconds for some reason. I can confirm it is not caused by some network issue because when I'm listening to some music on the computer and the phone rings, KDE Connect is able to pause the playback instantly as soon as the incoming call is received on the phone, without any delay. So the phone is successfully communicating with the PC module instantly. It's just the ringtone playback that is delayed. If I answer the call quickly, I will start chatting on the phone to the person that called me, and about 5-10 seconds into the call, the computer will ring, annoying the call, the ringtone is even heard by the person who called me through the phone's mic. STEPS TO REPRODUCE 1. Have your phone paired to your computer with KDE Connect 2. Open a media player that's integrated into KDE Connect (I'm using Strawberry), play some music 3. Have someone call your phone 4. Answer the call quickly OBSERVED RESULT The media player will stop the music playback instantly, however the PC ringtone will not trigger. About 5-10 seconds into the call, the PC ringtone will trigger. EXPECTED RESULT The computer should play the ringtone immediately as soon as the incoming call is received on the phone, and stop the ringtone playback if I answer the call. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.6-zen1-1-zen (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-8700K CPU @ 3.70GHz Memory: 47,0 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2070/PCIe/SSE2 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464322] [Feature Request] Make Kwin capable of using one animation for opening windows and a different one for closing
https://bugs.kde.org/show_bug.cgi?id=464322 --- Comment #1 from Eduardo Correia --- Please any mod, if possible, change the severity of this bug to "wishlist". I did F5 by mistake while editing this and didn´t notice the importance/severity reverted back to "normal". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464322] New: [Feature Request] Make Kwin capable of using one animation for opening windows and a different one for closing
https://bugs.kde.org/show_bug.cgi?id=464322 Bug ID: 464322 Summary: [Feature Request] Make Kwin capable of using one animation for opening windows and a different one for closing Classification: Plasma Product: kwin Version: 5.26.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-window-management Assignee: kwin-bugs-n...@kde.org Reporter: eduardosare...@gmail.com Target Milestone: --- Created attachment 155312 --> https://bugs.kde.org/attachment.cgi?id=155312=edit Example Mockup / Draft [Feature Request] It would be cool, especially when used in combination with "burn my windows" effects, if we could select one effect for the "windows open animation", and a different one for closing. That is, have two different selection options in the "Desktop Effects" KCM, one for opening animation and another for closing. I think this could maybe be it's own option in the windows effects section. Where we currently have the default "Scale" and etc window animations options, we could at the end of this list have this additional one called "Advanced Effects" or something like that, where we could then go into the settings for this option and select the "window open animation" and a "window close animation". By default and to avoid having no animations when selecting custom animations, this could come with the default animation on both options. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462438] KWin huge memory usage after alt-tabbing for some time
https://bugs.kde.org/show_bug.cgi?id=462438 --- Comment #5 from Eduardo --- My versions are as follows: --- Operating System: Manjaro Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.16-linux-mjasnik-bmq-20230101 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 --- -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462438] KWin huge memory usage after alt-tabbing for some time
https://bugs.kde.org/show_bug.cgi?id=462438 Eduardo changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Eduardo --- It seems that this does not happen anymore, probably KDE Frameworks update fixed this. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 454991] Language KCM sets wrong language variable for European Portuguese (pt_PT)
https://bugs.kde.org/show_bug.cgi?id=454991 Eduardo Correia changed: What|Removed |Added Resolution|FIXED |--- Ever confirmed|0 |1 Version|5.24.5 |5.26.4 Status|RESOLVED|REOPENED --- Comment #3 from Eduardo Correia --- This bug is still present, if not somewhat worse after the languages KCM rework. I also suggest many visual improvements while we are at it. There is a quick list with everything at the end. Lost many hours testing and repeating all this so I hope I am giving as much details as possible for an easier debug. KDE still insists in using [pt] in all config files when european portuguese is selected. However, 99% of apps read [pt] as being the same as [pt_BR] which is Brazilian Portuguese, a completely different language in many ways, especially grammar. The new languages KCM rework was great but didn't solve this bug and even made it worse: When we try to switch language or add more, we completely lost the "third" option of "European Portuguese" (called "Português (Portugal)" or "português europeu", can't remember) that we had before 5.26 . The only two options we have are now "português" and "português (brasil)". Choosing "português" makes it add "pt" in plasma-localerc in the [Translations] part. If we then add the other option, "português (brasil)", that config file gets changed to "pt:pt_BR". The "pt_BR" part is correct, but the "pt" is not. And while theoretically using "pt" to refer to European Portuguese is not wrong, almost all third party apps on all OSs and all DEs even many KDE own apps consider "pt" to be the same as "pt_BR". So having "pt" in plasma-localerc makes all apps display their content in Brazilian. This together with this bug makes it so effectively both language options in the language picker are, in the end, actually both brazilian. If we manually edit plasma-localerc [Translations] from "pt" to "pt_PT" and re-login, the languages KCM will show "português europeu" (European Portuguese) in the title of the currently added languages, even though that option doesn't exist when we try to add it via the languages picker. Changing it manually to pt_PT also makes all apps to be correctly shown in European Portuguese including all third party ones, be it native, flatpaks, snaps, everything. If we try to change it in the KCM and choose the "português" option, it reverts back to "pt" in plasma-localerc. My suggestion would be to completely remove the "português" option from the add/edit languages KCM and instead add the "Português (Portugal)" option and make it link to "pt_PT", so we get the only two options that actually matter: "Português (Portugal)" [pt_PT] and "Português (Brasil)" [pt_BR]. Having the other "português" [pt] doesn't make much sense since all apps consider it as pt_BR anyway and will only create confusion for the final user in the UI. Also related, all of these languages should be correctly written to look more professional, and correctly capitalized. "português (brasil)" should be "Português (Brasil)" for example. All languages suffer from this (see the language picker), some are correct, others are not, it's very inconsistent. When not in the picker, the list that shows currently added languages should reflect this same improvement as it suffers from the same thing. "português europeu" as it reads when we manually edit the plasma-localerc to be pt_PT, should instead read "Português (Portugal)" as should the languages picker. Languages should all also follow a more professional naming scheme: "American English" should instead be "English (US)". British English should be English (UK), and so on and so forth. The "home page" of this "languages and region" KCM (I don't know their real names) also shows different things in the "Language" part: when we have "pt_PT" manually added in plasma-localerc, this reads "português europeu" (should read Português (Portugal) too), and when we select "português (brasil)" this reads "português" only. However the "português" option in the language picker actually is the one that means "pt" (the bug) and when this one is selected the home page also reads "português". So the home page says "português" no matter which of the two availabme options in the picker is selected. When we click "modify" to enter into the edit language settings, it
[plasmashell] [Bug 462584] Volume and brightness flyouts are too high vertically on the screen + design suggestions
https://bugs.kde.org/show_bug.cgi?id=462584 Eduardo Correia changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 456210] Cannot unlock screen when using multiple monitors
https://bugs.kde.org/show_bug.cgi?id=456210 Eduardo B. Saporski changed: What|Removed |Added CC||esapor...@protonmail.com --- Comment #62 from Eduardo B. Saporski --- This still happens to me as well. I have a dual monitor setup on X11. Operating System: EndeavourOS KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.12-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463047] Flatpak version doesn't behave correctly on GNOME Wayland
https://bugs.kde.org/show_bug.cgi?id=463047 --- Comment #1 from Eduardo Medina --- I forgot to say I use Fedora 37 Silverblue with GNOME 43. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463047] New: Flatpak version doesn't behave correctly on GNOME Wayland
https://bugs.kde.org/show_bug.cgi?id=463047 Bug ID: 463047 Summary: Flatpak version doesn't behave correctly on GNOME Wayland Classification: Applications Product: kdenlive Version: 22.12.0 Platform: Flatpak OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: edu.rm...@gmail.com Target Milestone: --- Created attachment 154586 --> https://bugs.kde.org/attachment.cgi?id=154586=edit Kdenlive Flatpak behaving bad on GNOME Wayland SUMMARY Hi, I use the Flatpak version of Kdenlive since a long ago and I see that it behaves bad on GNOME's Wayland session. If you activate the Activities (Actividades in my computer) section, you can see that the previsualizations of the current clip and the project turn transparent. Another bug I found is if you open the app and you put the mouse pointer on the opening banner, you can see that the mouse pointer turns big, breaking the consistence with the interface. And finally, you can see the the menu doesn't behave correctly because submenus are showed out of place. I see some kind of "ghost effect" when you navigate through the menu bar, but that bug wasn't captured by the video. Sorry if the description is not good (I know that my English is horrible), but I don't if this is one bug or several bugs. I will stay here to follow the instructions you give me. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 462584] Volume and brightness flyouts are too high vertically on the screen + design suggestions
https://bugs.kde.org/show_bug.cgi?id=462584 Eduardo Correia changed: What|Removed |Added Summary|Volume and brightness |Volume and brightness |flyouts are too high|flyouts are too high |vertically on the screen + |vertically on the screen + |design suggetions |design suggestions -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 462584] Volume and brightness flyouts are too high vertically on the screen + design suggetions
https://bugs.kde.org/show_bug.cgi?id=462584 --- Comment #2 from Eduardo Correia --- Created attachment 154360 --> https://bugs.kde.org/attachment.cgi?id=154360=edit KDE and Windows 11 quick comparison screen shots for reference Added two screen shots (together in a single image) from both KDE and Windows 11 just for reference about this, taken on the same monitor with the same resolution (3440x1440) and in the same hardware (both installed to disk, dual-boot). Notice the difference in position of the volume/brightness fly-out/pop-up in the Y-axis and also the lack of contrast of the KDE one. While the Windows 11 one might not be perfect, the KDE one being so high in the screen makes it cover any content that's being displayed and sometimes gets a bit annoying. When you change the volume you have to literally wait and wish for this fly-out to "get out of the way" as quickly as possible because it is actually covering what you are working on. In Windows it can cover content, but it's so down there in the screen that it very rarely gets annoying, while the KDE one almost always is. In the KDE screen shot, Plasma is using a color theme picked from my wallpaper, but this lack of contrast happens with a lot of lightly-colored wallpapers. As a fix we could take idea from Windows about making the container of the "progress bar" much darker (see windows screen shot) so it gives better contrast against the filled part of the bar, and this might be enough to fix it. Making the bar a solid color instead of an outline with a lighter fill might also help, but I can understand that this might go against KDE design philosophy, where certain things usually have an outline. Finally, about the icons, we can also compare both screen shots and notice that maybe the KDE volume icon on that fly-out is a bit too big, and maybe also the number/percentage text. And as a bonus, another suggestion is that we could maybe smoothly animate the progress bar going up or down with an "ease-out", horizontally . Currently it just "teleports" from each volume step to the next and while this is a very small detail it can help make the whole KDE experience feel more fluid in the end. The icon already smoothly changes (fades) from each state which is awesome! Maybe also while we are at it, make the percentage number animate going to the next volume step by going up/down by 1% quickly. Changing from 50% to 55% could very quickly make the numbers go 50>51>52>53>54>55%. Now I'm just throwing ideas into the air, as a developer myself (though I don´t know C++ or QML to help you guys, maybe some day) I know some things are extremely hard to make, so it's absolutely fine if some of these suggestions are not really worth the time they take. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 462676] New: It does not allow me to configure the keyboard shortcut only with the Windows key for the application launcher
https://bugs.kde.org/show_bug.cgi?id=462676 Bug ID: 462676 Summary: It does not allow me to configure the keyboard shortcut only with the Windows key for the application launcher Classification: Plasma Product: kdeplasma-addons Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Dashboard Assignee: plasma-b...@kde.org Reporter: andresgarcia0...@gmail.com Target Milestone: --- "It does not allow me to configure the keyboard shortcut only with the Windows key for the application launcher" KDE Plasma Version: 5.25.5 KDE Frameworks 5.9. 5.15.6 QT -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 462584] New: Volume and brightness flyouts are too high vertically on the screen + design suggetions
https://bugs.kde.org/show_bug.cgi?id=462584 Bug ID: 462584 Summary: Volume and brightness flyouts are too high vertically on the screen + design suggetions Classification: Plasma Product: plasmashell Version: 5.26.4 Platform: OpenSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eduardosare...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY The small popup/flyout (don´t really know the correct name) that appears when you change the volume or brightness with shortcut keys appears too high vertically, almost in the middle of the screen. If you have a huge monitor (more than 32") this problem is a lot more annoying. They constantly cover important stuff in the screen. They should be around the same Y height as the Windows 11 ones are, for example. As an extra, they could also have more padding and maybe have the icons and text slightly smaller. They look huge compared to the flyout itself. Again, we can look at the Win11 example. They could also animate smoothly the "progress bar" going up or down instead of just "teleporting" up and down (this would be better than Win11 since that one also does not animate). STEPS TO REPRODUCE 1. Just use any keyboard shortcut to change volume or brightness, look at the flyout. 2. Notice that its too high vertically on the screen, almost in the middle (in the Y coordinate), covers your content too much. OBSERVED RESULT It's too high vertically in the screen. Gets worse in big screens. EXPECTED RESULT Maybe should be a lot closer to the bottom edge of the screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.0.10 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462438] KWin huge memory usage after alt-tabbing for some time
https://bugs.kde.org/show_bug.cgi?id=462438 --- Comment #2 from Eduardo --- If I can - I'd suggest changing the importance/priority a bit higher, as this will cause system to run out of memory sooner rather than later. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462438] KWin huge memory usage after alt-tabbing for some time
https://bugs.kde.org/show_bug.cgi?id=462438 Eduardo changed: What|Removed |Added CC||ed...@inbox.lv -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462438] KWin huge memory usage after alt-tabbing for some time
https://bugs.kde.org/show_bug.cgi?id=462438 --- Comment #1 from Eduardo --- Created attachment 154168 --> https://bugs.kde.org/attachment.cgi?id=154168=edit alt-tab automation script -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462438] New: KWin huge memory usage after alt-tabbing for some time
https://bugs.kde.org/show_bug.cgi?id=462438 Bug ID: 462438 Summary: KWin huge memory usage after alt-tabbing for some time Classification: Plasma Product: kwin Version: 5.26.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: ed...@inbox.lv Target Milestone: --- Created attachment 154167 --> https://bugs.kde.org/attachment.cgi?id=154167=edit kwin alt-tab + memory ussage video SUMMARY KWin uses a LOT of memory when doing alt-tab for some time. This is what I have observed. I rarely restart the system and lately had to alt-tab quite a lot, then everything started to stutter a lot. Investigation showed that all memory was used up and almost all swap space too. Before investigation, I turned off swap. At that time checking out xrestop showed that kwin used 5GB of pixmaps (if I remember right), free -hw showed that "shared" was used for 15GB, after restarting kwin, all freed up, memory was back to normal, that is "shared" to 3.5GB and xrestop showed some 300MB pixmap usage. Since this is built-in graphics adapter, main memory is shared between system and gpu, this is why, I think, all memory went to "shared" portion and I was not able to detect this earlier. So, I wrote a script which did alt-tabbing for me, opened 25 kwrite windows and recorded a video which shows start of the alt-tabbing and the end of alt-tabbing. As you'll be able to see, memory increases A LOT, 300 times alt-tab increased used pixmap memory from 300MB to 3GB and "shared" portion of used memory from 3.7GB to 8.7GB. This is with modesetting driver, X11. Restarting kwin helps for a while. If you need more tests, please ask. I'll attach video and script to this report. Sorry for video quality but I can not upload larger video to bug report, anyhow, this should suffice. STEPS TO REPRODUCE 1. work as usual 2. alt-tab for a while 3. observe how memory gets used up OBSERVED RESULT Huge memory usage EXPECTED RESULT Normal memory usage SOFTWARE/OS VERSIONS Linux/KDE Plasma: Operating System: Manjaro Linux KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.7-linux-mjasnik-pds-20221106 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530 Manufacturer: Dell Inc. Product Name: XPS 15 9550 ADDITIONAL INFORMATION When using simple task switcher (without thumbnails), kwin eats memory at quite a lower pace. It appears that it eats memory proportionally how many window thumbnails are shown on alt-tab popup. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462351] Discover crashes when I close it after an update.
https://bugs.kde.org/show_bug.cgi?id=462351 --- Comment #6 from Eduardo Baldino --- "You have to keep clicking next." Wow. I'll forgive you condescension, but only because I did screw up when saving the images, and ended up posting repeated images. I've posted updated images. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462351] Discover crashes when I close it after an update.
https://bugs.kde.org/show_bug.cgi?id=462351 --- Comment #5 from Eduardo Baldino --- Created attachment 154152 --> https://bugs.kde.org/attachment.cgi?id=154152=edit KDE Crash Handler screen shots (the right ones) -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462351] Discover crashes when I close it after an update.
https://bugs.kde.org/show_bug.cgi?id=462351 --- Comment #3 from Eduardo Baldino --- As I tried (poorly) to explain in the original post, the KDE Crash Handler does not generate a backtrace. I have attached the Crash Handler screens. Now, if you want me figure out by myself how to install debug symbol packages, figure out by myself which one I should install, install it, and then figure out by myself how to manually get a backtrace, then I'm sorry I tried to help. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462351] Discover crashes when I close it after an update.
https://bugs.kde.org/show_bug.cgi?id=462351 --- Comment #2 from Eduardo Baldino --- Created attachment 154146 --> https://bugs.kde.org/attachment.cgi?id=154146=edit KDE Crash Handler screen shots -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 462351] New: Discover crashes when I close it after an update.
https://bugs.kde.org/show_bug.cgi?id=462351 Bug ID: 462351 Summary: Discover crashes when I close it after an update. Classification: Applications Product: Discover Version: 5.24.7 Platform: Kubuntu OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: edua...@baldino.com.br CC: aleix...@kde.org Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Open Discover 2. Install updates 3. Close discover OBSERVED RESULT Every single time I install updates with Discover, everything goes 100% fine. Then I close Discover and get a "Discover closed unexpectedly" message. Otherwise everything is fine. I tried generating a crash report but it said it couldn't find the information it needed. EXPECTED RESULT Closing the application should not cause a crash or issue an undue crash message. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Kubuntu 22.04 Jellyfish (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION None. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 459069] Navigating to root using location bar does not work
https://bugs.kde.org/show_bug.cgi?id=459069 Eduardo changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Eduardo --- It seems to be fixed for me now. I don't know how or who fixed it, but I cannot reproduce it anymore after updating everything to the latest version. I'm now on plasma 5.26.3, frameworks 5.100.0, Dolphin 22.08.3. So I'm closing. -- You are receiving this mail because: You are watching all bug changes.
[Qt/KDE Flatpak Runtime] [Bug 460531] New: Many Qt apps crash on GNOME Wayland (Fedora 36 Silverblue), I think after updating the KDE Platform and related components
https://bugs.kde.org/show_bug.cgi?id=460531 Bug ID: 460531 Summary: Many Qt apps crash on GNOME Wayland (Fedora 36 Silverblue), I think after updating the KDE Platform and related components Classification: Developer tools Product: Qt/KDE Flatpak Runtime Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: aleix...@kde.org Reporter: edu.rm...@gmail.com CC: aa...@kde.org Target Milestone: --- Created attachment 152889 --> https://bugs.kde.org/attachment.cgi?id=152889=edit The info I could get from the bug: a video, three screenshots and a TXT file SUMMARY Hi, since a week ago (more or less) there almost all the Qt apps I use in Fedora Silverblue (all of them in Flatpak format) are crashing when I use them on GNOME Wayland session. Only Krita, KGet, OBS Studio and Telegram (the latest is broken, but not by the KDE Platform) seem to keep stable. By other hand, Kdenlive, Audacious, Peazip and qBittorrent show instability issues. I can reproduce the bug opening Kdenlive first and Krita later and after, closing Krita, you can see that Kdenlive crashes. I can get the same result with Peazip and qBittorrent. Sometimes the crashes occur randomly. In apps like Kdenlive and qBittorrent, if you try to close the "About" menu, you can crash the apps. This is a message I get after closing the "About" window of Kdenlive: org.kde.kf5.kwindowsystem.kwayland: This compositor does not support the Shadow interface I think that the root of the problem are 5.15-21.08 and 5.15-22.08 version of the KDE Platform and related components like org.kde.KStyle.Adwaita, org.kde.PlatformTheme.QGnomePlatform and org.kde.WaylandDecoration.QGnomePlatform-decoration, but I'm not sure. STEPS TO REPRODUCE 1. (Example) Open Kdenlive first and after Krita on the Wayland session of GNOME 2. Close Krita OBSERVED RESULT You can see that Krita drags Kdenlive until to crash it. EXPECTED RESULT Software stability. SOFTWARE/OS VERSIONS Linux/KDE Plasma (Flatpak): KDE Platform 5.15-21.08 and 5.15-22.08 (I think) with related components like org.kde.KStyle.Adwaita, org.kde.PlatformTheme.QGnomePlatform and org.kde.WaylandDecoration.QGnomePlatform-decoration (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.15 (it seems) ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456511] VLC and Firefox freeze / stop updating their window contents after being used for a while
https://bugs.kde.org/show_bug.cgi?id=456511 --- Comment #32 from Eduardo --- Thanks for the patch, I applied this patch to 5.25.5 version of kwin, let's see whether it solves the issue. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 431351] For files that don't fit in the trash, the user isn't provided with the option to delete immediately
https://bugs.kde.org/show_bug.cgi?id=431351 Eduardo Correia changed: What|Removed |Added CC||eduardosare...@gmail.com --- Comment #7 from Eduardo Correia --- On Steam Deck (no keyboard, handheld mode) I just stumbled uppon this. This feature would be a blessing here, and we could really use it, especially because we are constantly dealing with huge game installers or folders. I know we can go into Dolphin settings and enable the "Delete" option, but a new user would absolutely never know that could be done. Even I didn´t remember this and got stuck there 5 minutes trying to figure out what to do. I was thinking about removing it using the terminal (would be fun without a keyboard I guess) when I remembered that option. There should absolutely be a "Delete Permanentely" button in the "File too large for trash" error message that Dolphin shows. This really is a case of "failed, you are on your own, good luck". This seems like a simple thing to do, just add a button in the message (and that button could trigger the exact same "confirm" modal popup that using the shift-delete triggers). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 439417] Rethink drag scrolling with left mouse button
https://bugs.kde.org/show_bug.cgi?id=439417 Eduardo changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED CC||eduardo.c...@kdemail.net --- Comment #2 from Eduardo --- https://invent.kde.org/graphics/okular/-/merge_requests/637 has been merged, giving an option to disable this feature. We discussed it inside MR and we decided that adding an option to disable it was the way to go, so I'm closing this bug report too. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457284] [NVIDIA] Lock screen wallpaper is all black after sleep
https://bugs.kde.org/show_bug.cgi?id=457284 --- Comment #18 from Eduardo --- (In reply to Nate Graham from comment #17) > This is starting to feel like a bug in the NVIDIA driver itself. There's a > long history of graphical glitches on suspend, unfortunately. It's possible... however In comment #7 he said he got the bug with AMD hardware. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457284] X11 with NVIDIA GPU: Lock screen wallpaper is all black after sleep
https://bugs.kde.org/show_bug.cgi?id=457284 --- Comment #16 from Eduardo --- Created attachment 152124 --> https://bugs.kde.org/attachment.cgi?id=152124=edit Plasma under Wayland after returning from sleep Under Wayland it is even worse. The bug lives on into plasma desktop even after I unlock the lock screen after returning from sleep. As can be seen in the picture, the desktop renders completely crazy. No icons, no labels, black background, date and time on taskbar shows only "1"... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457284] X11 with NVIDIA GPU: Lock screen wallpaper is all black after sleep
https://bugs.kde.org/show_bug.cgi?id=457284 --- Comment #15 from Eduardo --- Created attachment 152123 --> https://bugs.kde.org/attachment.cgi?id=152123=edit Normal lock screen This is what my lock screen should be. I get this when just locking without going to sleep. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457284] X11 with NVIDIA GPU: Lock screen wallpaper is all black after sleep
https://bugs.kde.org/show_bug.cgi?id=457284 --- Comment #14 from Eduardo --- Created attachment 152122 --> https://bugs.kde.org/attachment.cgi?id=152122=edit Bugged lock screen This is the lock screen I get when returning from sleep. Date and time label only shows a "5, that's very random, sometimes more pieces of the date and time are shown, sometimes it shows complete, sometimes it is missing at all. Background is black. Profile picture is grey. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 459069] Navigating to root using location bar does not work
https://bugs.kde.org/show_bug.cgi?id=459069 Eduardo changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||eduardo.c...@kdemail.net --- Comment #1 from Eduardo --- I can confirm, and it is pretty severe IMO. It was probably introduced in a recent update. I use Arch Linux, only noticed it today. It is easier to reproduce by right clicking the address bar and setting "Text Completion" to "None". This way, actually nothing works. You can try to type "/", "/etc/", "/bin", "~" nothing works. Sometimes it starts working again, seemingly random. But if you close Dolphin and open it again, the bug is always back. It is actually not a Dolphin bug, as it also happens on the Open/Save file dialogs that use the same URL location bar all over KDE apps. I suspected KIO, however I tried compiling some old KIO commit and I could not get rid of the bug. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #39 from Eduardo --- This issue is almost 2 years old for Plasma 5.20.x, it was present even before that, now it's flagged as duplicate for issue regarding Plasma 5.25.x, which does not look exactly the right way. I hope the decision was not taken because I updated the affected version from 5.20.x to 5.25.5. If this is my mistake, I'll change it back to 5.20. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 Eduardo changed: What|Removed |Added Version|5.20.5 |5.25.5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #37 from Eduardo --- Created attachment 151905 --> https://bugs.kde.org/attachment.cgi?id=151905=edit FF won't update its contents Plasma 5.25.5 For a long time I did not encounter this bug, but now it's back again... Here is my situation. Since the bug was so annoying and prevented my work to be done, I had reset all plasma to defaults and somehow I did not encounter the bug for some time. In addition to this, for some time MESA changed the driver from i965 to iris, at first I thought that this is what helped to get rid of the bug for the most part, but now I'm not sure anymore... And I'm not sure about this, because after I updated to plasma 5.25.5, I enabled a nice feature I liked - Translucency, specifically the defaults, i.e. when moving windows, they become transparent. Soon after that I got the bug reappear, Firefox won't update its contents... The weird part is that disabling and enabling composition does NOT get the contents back as it was before! I have to restart the application... Is this really related to transparency things... I'll disable the effect will report back whether the issue reappears. The attachment shows that: 1. contents are not updated 2. even new windows of the same application (FF) inherits the same buggy behaviour 3. disabling / enabling composite won't get rid of the bug -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457284] X11: Lock screen wallpaper is all black on Nvidia hardware
https://bugs.kde.org/show_bug.cgi?id=457284 Eduardo changed: What|Removed |Added CC||eduardo.c...@kdemail.net --- Comment #6 from Eduardo --- I've got the same issue, background is always black, and sometimes it aggravates a little more as the current date and time information sometimes shows up incomplete, only a few of the numbers are displayed. Only happens when directly returning from sleep. If I unlock it, then just lock the screen again without sleep, the lock screen shows up fine. It wasn't always like this. It started happening a couple months back, I don't know exactly when... Hard to tell where the bug is located down the stack, could be kernel, nvidia drivers, or kde software. I would guess it's some sort of race condition, maybe something is being requested of the graphics card while it is still not ready back from sleep. It happens on my 2 computers, both with kernel 5.18.16-zen, nvidia-dkms 515.65.01-1, kwin/plasma 5.25.4 under XOrg. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 456890] New: Spectacle says picture has been copied to clipboard even when option is disabled
https://bugs.kde.org/show_bug.cgi?id=456890 Bug ID: 456890 Summary: Spectacle says picture has been copied to clipboard even when option is disabled Product: Spectacle Version: 21.12.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: eduardo.b...@hotmail.com CC: k...@david-redondo.de Target Milestone: --- Created attachment 150723 --> https://bugs.kde.org/attachment.cgi?id=150723=edit Screenshot of the false information side-by-side with the configuration option. SUMMARY Spectacle says picture has been copied to clipboard even when option is disabled STEPS TO REPRODUCE By default, Spectacle doesn't copy to clipboard, but says it has. OBSERVED RESULT Clipboard did not change EXPECTED RESULT Picutre should be on clipboard SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 389568] Feature to reset all settings to default values
https://bugs.kde.org/show_bug.cgi?id=389568 Eduardo Correia changed: What|Removed |Added CC||eduardosare...@gmail.com --- Comment #37 from Eduardo Correia --- I also would like to see this feature implemented. There are many times that weird bugs appear after messing up with themes or config files manually that we, "casual users", need to search through Google for a way to reset everything to default and it involves finding a deleting a lot of files or terminal commands. We all love to follow tutorials on how to install themes, and sometimes we can't revert stuff back properly. This "Reset all" would be a very welcoming option for any non tech-savvy user. Every proprietary OS has this, together with the option to reset the whole system (but that's a whole other topic, KDE could support it but distros themselves would have to configure it too), but barely any linux DE has these options. I believe KDE would be the first DE to implement something like this. An additional option to "Clear KDE Cache" or something like that, would also be very handy. We could really benefit from some native "housekeeping" tools! As a random additional example, even bigger/commercial distros would feel more confortable offering KDE by default if the desktop itself would do more housekeeping without the users needing to contact support lines. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455679] Activities: window management / movement is broken in 5.25
https://bugs.kde.org/show_bug.cgi?id=455679 Eduardo changed: What|Removed |Added Version|5.25.0 |5.25.1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455679] Activities: window management / movement is broken in 5.25
https://bugs.kde.org/show_bug.cgi?id=455679 Eduardo changed: What|Removed |Added Summary|Activities: window |Activities: window |management is broken in |management / movement is |5.25|broken in 5.25 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455679] Activities: window management is broken in 5.25
https://bugs.kde.org/show_bug.cgi?id=455679 Eduardo changed: What|Removed |Added Summary|Activities: window |Activities: window |management and session |management is broken in |restore is broken in 5.25 |5.25 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455679] New: Activities: window management and session restore is broken in 5.25
https://bugs.kde.org/show_bug.cgi?id=455679 Bug ID: 455679 Summary: Activities: window management and session restore is broken in 5.25 Product: kwin Version: 5.25.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: activities Assignee: kwin-bugs-n...@kde.org Reporter: ed...@inbox.lv Target Milestone: --- Created attachment 149974 --> https://bugs.kde.org/attachment.cgi?id=149974=edit Window management broken for activities SUMMARY Window management is broken, sending window to another activity still shows the window, which is not interactive. STEPS TO REPRODUCE 1. Please check attached video for window management issue. OBSERVED RESULT Window appears to be visible, on top but can not be interacted with. EXPECTED RESULT Window is moved to desired activity and is not shown anymore. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Graphics Platform: X11 Graphics Processor: AMD Radeon RX 570 Series ADDITIONAL INFORMATION Created a completely new user to test this. -- You are receiving this mail because: You are watching all bug changes.
