[kwin] [Bug 379111] New: Vertical sync causes flickering on screen capturing
https://bugs.kde.org/show_bug.cgi?id=379111 Bug ID: 379111 Summary: Vertical sync causes flickering on screen capturing Product: kwin Version: 5.9.4 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Vertical synchronization causes screen capturing to flicker. I discovered it during tests with OBS and simplescreenrecorder. Disabling vertical sync stops flickering completely but introduces small, sporadical screen tearing when moving windows so it's desirable to have this option on, however, it conflicts with screen capturing programs. I already informed OBS developer about it to see if he can do something about it on his end, but the fact that this bug happens in more capturing programs shows a basic problem on kwin end. I made a video showing how disabling and enabling vertical sync influences the flickering: https://www.youtube.com/watch?v=XutOV1wffMQ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379111] Vertical sync causes flickering on screen capturing
https://bugs.kde.org/show_bug.cgi?id=379111 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379111] Vertical sync causes flickering on screen capturing
https://bugs.kde.org/show_bug.cgi?id=379111 --- Comment #2 from Michał Dybczak --- Version === KWin version: 5.9.4 Qt Version: 5.8.0 Qt compile version: 5.8.0 XCB compile version: 1.12 Operation Mode: X11 only Build Options = KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_INPUT: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === Vendor: The X.Org Foundation Vendor Release: 11903000 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration == Plugin: org.kde.kwin.aurorae Theme: __aurorae__svg__Freeze Blur: 1 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 5, 3, 4, 2 decorationButtonsRight: 9, 1 borderSize: 3 gridUnit: 10 font: Noto Sans,11,-1,5,50,0,0,0,0,0,Regular smallSpacing: 2 largeSpacing: 10 Options === focusPolicy: 1 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 750 delayFocusInterval: 300 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: false focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: true killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 glSmoothScale: 2 xrenderSmoothScale: false maxFpsInterval: 1666 refreshRate: 0 vBlankTime: 600 glStrictBinding: true glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 101 glPlatformInterface: 1 windowsBlockCompositing: true Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 20 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens === Multi-Head: no Active screen follows mouse: yes Number of Screens: 1 Screen 0: - Name: eDP1 Geometry: 0,0,1920x1080 Refresh Rate: 60.0204 Compositing === Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) OpenGL version string: 4.5 (Core Profile) Mesa 17.0.3 OpenGL platform interface: GLX OpenGL shading language version string: 4.50 Driver: Intel GPU class: Unknown OpenGL version: 4.5 GLSL version: 4.50 Mesa version: 17.0.3 X server version: 1.19.3 Linux kernel version: 4.10.10 Direct rendering: Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --- zoom slidingpopups kwin4_effect_login wobblywindows screenshot kwin4_effect_translucency magiclamp kwin4_effect_windowaperture desktopgrid cubeslide coverswitch colorpicker kwin4_effect_fade kwin4_effect_morphingpopups kwin4_effect_maximize presentwindows highlightwindow kwin4_effect_dialogparent contrast startupfeedback screenedge kscreen Currently Active Effects: - contrast Effect Settings: zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: wobblywindows: stiffness: 0.01 drag: 0.76 moveFactor: 0.25 xTesselation: 20 yTesselation: 20 minVelocity: 0 maxVelocity: 1000 stopVelocity: 0.5 minAcceleration: 0 maxAcceleration: 1000 stopAcceleration: 0.5 moveEffectEnabled: true openEffectEnabled: false closeEffectEnabled: false moveWobble: true resizeWobble: true screenshot: kwin4_effect_translucency: magiclamp: animationDuration: 250 kwin4_effect_windowaperture: desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true cubeslide
[kwin] [Bug 379111] Vertical sync causes flickering on screen capturing
https://bugs.kde.org/show_bug.cgi?id=379111 --- Comment #4 from Michał Dybczak --- OpenGL 2 didn't help, although it seems to cause a bit less flickering but that's hard to assess really, because flicker can get erratic. About xorg modesettings ddx, I have no idea about it. I found that's some sort of alternative driver? I would rather not mess with gpu drivers. I use none-free bumblebee with intel and nvidia. Flickering happens on both GPUs, no difference here. Can't you reproduce this bug? Is it happening only for me? I might try to run a system in a live version, add OBS and see if the problem occurs under such circumstance. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379111] Vertical sync causes flickering on screen capturing
https://bugs.kde.org/show_bug.cgi?id=379111 --- Comment #5 from Michał Dybczak --- Look at this video of another arch user (Antergos KDE): https://www.youtube.com/watch?v=ZIpO2NcTkvw&index=55&list=WL Can you notice panel flickering? That's EXACTLY the same bug. I'm not the only one. People just accepted and ignored it but it exists. -- You are receiving this mail because: You are watching all bug changes.
[Plasma SDK] [Bug 378650] Could not locate service type file kservicetypes5/kpackage-genericqml.desktop
https://bugs.kde.org/show_bug.cgi?id=378650 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #2 from Michał Dybczak --- Also had this bug but it went away with a reboot. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 379111] Vertical sync causes flickering on screen capturing
https://bugs.kde.org/show_bug.cgi?id=379111 --- Comment #6 from Michał Dybczak --- I was given some kind of solution to this problem, I checked it and it realy works: create file /home/user/.config/plasma-workspace/env/kwin.sh with: #!/bin/sh export __GL_YIELD="USLEEP" export KWIN_TRIPLE_BUFFER=0 export KWIN_USE_BUFFER_AGE=0 add to /etc/X11/xorg.conf.d/20-intel.conf: Option "AccelMethod" "SNA" Option "TearFree" "true" Option "DRI" "3" Option "TripleBuffer" "False" Reboot. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] New: Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 Bug ID: 383069 Summary: Corrputed mp3 files when sent through KDE Connect Product: kdeconnect Version: 1.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: michal.dybc...@gmail.com Target Milestone: --- KDE Connect version 1.0.3-1 KDE 5.36.0 / Plasma 5.10.4 Qt: 5.9.1 Kernel: 4.12.3-1-MANJARO I've been sending mp3 podcast files to my Android device through KDE Connect wireless "send a file" option. It worked relatively fine (only possible to system memory, no external card accessible that way) but lately any file that I sent becomes corrupted and players either stop playing them after few seconds or skip parts of the recording. I rechecked it and original mp3s are fine and get unusable after sending them through KDE Connect. When I use cable, then mp3s are fine. The only thing that comes to mind is some update (KDE Connect itself, framework, qt?) that may have caused it. Can anyone check if that's some general bug or just for me? I cannot find anything on that and I have no idea where to turn to help with such problem. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #2 from Michał Dybczak --- (In reply to Albert Vaca from comment #1) > How were you sending the files? > > a) right click on the file -> send to using kdeconnect > > or > > b) copy the file, open the phone from the places menu, paste the file I click on KDE Connect tray icon and then click on folder icon, which opens dolphin file manager. From there I move to the place I need. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #4 from Michał Dybczak --- When I right click a file and choose the option "send to with kde connect" it does nothing. I cannot use it to send any files. When I open my device from places in Dolphin it opens sftp mount: /home/username/.config/kdeconnect/fe7b01a9475a2ad7/kdeconnect_sftp/fe7b01a9475a2ad7/storage/emulated/0/Folder-Phone/ It doesn't matter if I drag/drop the file or copy/paste it, it results with corrupted file. I checked other file types and with small ones, md5 sums are the same. But with larger files (like 10MB+) sums are different so it's not only mp3s are affected but the whole transfer of larger files. This is serious and excludes usage of KDE Connect wifi transfer. The question is, is it caused by KDE Connect or another system element and then we should file a bug in another place? Using cable with mtp connection all is fine. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #8 from Michał Dybczak --- Thank you kishor...@gmail.com. Now at least we have something to watch and hope for fix. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #9 from Michał Dybczak --- (In reply to Albert Vaca from comment #7) > I can effectively confirm that this is an SSHFS 3.0 bug, which has been > fixed in 3.1 but for some reason reintroduced in 3.2 (??). > > We already have a fix for it on the desktop side [1], that disables the > buggy feature of SSHFS. But, since we can't guarantee distros are gonna > adopt the fixed version of KDE Connect before they adopt SSHFS 3.0 (or 3.2) > I've also written a "fix" for the Android app, which will just abort the > transfer with an error. This way, at least we don't cause data > corruption/loss. Does that mean, when we update KDE Connect and will have faculty sshfs version, transfer fail? If I didn't know the cause, I would see it as bug as well ;). Maybe some additional info with that error would be helpful to understand what is going on for people who didn't see that thread? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #11 from Michał Dybczak --- (In reply to Albert Vaca from comment #10) > There is no way to surface this error to the user in a backwards compatible > way :( It might be seen as a bug, but I think it's way better than just > succeed with a corrupted file. I agree. But error message comes with a message, right? Why not create some condensed, smart message that will shed some light? Like for example: "Error, faulty sshfs version detected (3.0 and 3.2)" Yeah, I know, it's also bad way to show it. But maybe with some brainstorming, it will be possible to design error message in a more informative manner? Hmmm... "Error, sshfs version 3.0 and 3.2 are not supported." It's still cryptic but at least it looks like a design and not a bug. Or maybe add: "Error, sshfs version 3.0 and 3.2 are not supported due to a serious transfer bug" This is bolder and less eloquent message but I'm not sure how shorter this could be explained. Of course, that's just my proposition and I trust KDE Connect development team will choose the best solution or wording of that message. Maybe use some words that allow users find easier the info about that sshfs bugs? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395442] Framework 5.47 bug with systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 --- Comment #14 from Michał Dybczak --- I checked on two different machines (hardware installs) and all is well on both of them (both had the issue). Maybe we are talking about different things? My initial mistake was to dump more things into one topic since I thought they are all the same systray issue. 1. Notification setting least getting empty is fixed - this is what I meant and what this topic is mainly about. Changing any settings don't make the list empty anymore. 2. tab/num notification works flawlessly now. 3. media icon bug is an entirely different bug 395442 This can be fixed by updating the media icon file with the one from breeze theme. Some popular themes did the fix, others didn't so it's up to users to edit the theme. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 395455] Discover buttons install/remove/launch disappear
https://bugs.kde.org/show_bug.cgi?id=395455 --- Comment #4 from Michał Dybczak --- There were lately some updates in Discover's kirigami (Plasma 5.13.1), or at least I think I saw something like that. Is it fixed? I don't know how to go back to those bugged window size to test it... maybe aside deleting conf. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 395455] Discover buttons install/remove/launch disappear
https://bugs.kde.org/show_bug.cgi?id=395455 --- Comment #6 from Michał Dybczak --- Ah thanks. In two panel mode bug still exists. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 186181] Add config options for wallpaper slideshow order
https://bugs.kde.org/show_bug.cgi?id=186181 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #4 from Michał Dybczak --- I support this idea because I had the same one recently, after reading this article about dynamic wallpapers: http://technastic.com/macos-mojave-dynamic-wallpaper-on-linux/ I also tried it and had no success because of the randomness of the slideshow setting and thought that having an option to disable randomness would do the trick. So with 16 pictures, I could set change of picture every 1,5 hour, count which one should be used at certain hour (like 3 pm) and then next-skip to the appropriate one and then natural time progress would make it work. I soon realized, we need more then that. Suspending system suspends also time tracking for wallpaper switcher, so we would also had option to change from independent time to real (computer) time to make this work. I'm not talking about generally disabling randomness or independent time - current slideshow options is great and works fine. Just those additional options would allow for creation of time depended wallpaper sets. This would be an obscure setting but still a fun thing to do and a good topic for articles on "how to do this on Plasma". Just a thought ;). Hopefully someone will think about it some day and add this. Thanks :) -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 396140] Proposed UX improvements for update behavior
https://bugs.kde.org/show_bug.cgi?id=396140 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #5 from Michał Dybczak --- I applaud this proposal. There is really no problem with many progress bars when we see pacman or apt output in terminal - they nicely show what is being done. We could always go with spinning circle... but that's not a thing that would satisfy a Linux user if there is a way to show it better. There is something hypnotizing and satisfying in seeing an update info and that is being done right. Currently Discover's update behavior is everything opposite: unsatisfying and confusing. Clicking on "Update" does not show any graphical, immediate response, like: changing UI for update info: preparing, initializing, checking, downloading, etc. It invokes feeling of being stuck, frozen, like something bad had happened so this proposal is important and can lead to only better result. - Having bar cleared out and filled up again on next update phase feels quite ok - many programs or systems follow that step by step progress bar pattern. - Having multiple progress bars that are filled to the end after each phase is completed feels also ok, although a bit busy and this could take more space. - Having a single progress bar for all operation is not great IMO. Each phase can take different time, it's hard to have accurate % info (maybe I'm wrong), such progress bar moves much slower (less satisfying), has more opportunities to stuck on certain level (again: not good). Linux users tend to want more info what is happening, even on GUI programs. Single progress bar is ok for single program/package installation but for the system update this feels like too simplistic approach which don't take into account user's intelligence and need to know what is happening. There is a reason why most people end up using Synaptics, Muon, terminals or other less graphically pleasing but more accurate and informative programs. It would be cool if Discover was ahead of normal software centers and presented seemingly simple, nice for newbie and yet, had more "juice" in it. Clear info on package source (and other options timed to it) is a move toward this direction. Improving update experience would be another step. Sure, it won't be ideal at first but once the step will be done, it can be improved. So in the end Discover would be "simple by default, powerful when needed" ;). Another thing is: how package managers questions re handled by Discover? Is it already implemented when we need to delete/replace some packages or there might be info on unresolved dependencies (which can point to manual solution on what to do to fix the update)? So far GUI programs are not always showing enough info so on rolling systems terminal is the advised method of updates. Or maybe allowing users to use terminal for update can be a thing? Octopi does that nicely, I always shows an option to use terminal and I always agree as it's right thing to do on Arch based system. This is ideal, because I either confirm update in GUI program or click to open terminal. There is no additional prompt that would annoy users. Just a bunch of thoughts. Thanks for making PLasma better and better every day? :D -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395485] Media Controls Plasmoid (Dark Icon)
https://bugs.kde.org/show_bug.cgi?id=395485 --- Comment #6 from Michał Dybczak --- Here is another thread about this problem: https://forum.manjaro.org/t/kde-breath-theme-invisible-media-control-systray-icon/51644/2 It seems that not only media icon is touched with this issue. I could easily replicate it on Neon vbox install when using any non-breeze theme. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395485] Media Controls Plasmoid (Dark Icon)
https://bugs.kde.org/show_bug.cgi?id=395485 --- Comment #7 from Michał Dybczak --- Here is another thread of a lost user... People are confused by this "invisible" icon. https://forum.manjaro.org/t/media-reproductor-icon-not-showing-in-trey-area/52392 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 396942] Icon view: Left sidebar "jumps" when moving from workspace behavior KCM to other KCMs
https://bugs.kde.org/show_bug.cgi?id=396942 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #2 from Michał Dybczak --- I confirm that I could observe the same on Manjaro KDE on different theme. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 397082] The new media player icons rely on the icon theme instead of the desktop theme
https://bugs.kde.org/show_bug.cgi?id=397082 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #11 from Michał Dybczak --- Uh, what happened? There were two other bug reports on incorrect media icon. Mine bug report was marked as a duplicate of: https://bugs.kde.org/show_bug.cgi?id=395485 Now 395485 have been marked as duplicate of this bug here but this has status: unresolved invalid. WHAT??? This is still an issue and here is only sparse discussion about adapta theme. So far only Breeze, Breeze Dark, Breeze Light has corrent media icon. Adapta, Breath, Maia, Andromeda, Air, Oxygen and all other themes show this incorrect, black (color isn't changing based on light or dark theme), square off looking icon. Many distros comes with dark panel and then dark media icon becomes invisible. So far many users reported this issue and so far this has been circling to resolved, invalid status? Looks like someone incorrectly pointed 395485 bug to this as this thread wasn't well processed. Since Plasma 5.13 update all non-breeze themes are broken and no one seems to care or do I read it wrong? Many people having problem with it (I put links to topics on mine and other threads) and this circled back to here. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 397082] The new media player icons rely on the icon theme instead of the desktop theme
https://bugs.kde.org/show_bug.cgi?id=397082 --- Comment #13 from Michał Dybczak --- I'm also a maintainer of some themes and this is puzzling to me. So if I get it right, Plasma 5.13 broke the themes compatibility on purpose? If so, why isn't there any clear info how to fix it? This way 99% of available themes have just broken media icon. This is a really bad decision and should be somehow either fixed upstream of communicated officilally like: "Since Plasma 5.13 we had to change X due to reason Y and that resulted in (issue Z), Please update your themes to make it compatible with the Plasma 5.13+ by doing this:" >From what I can tell, correct icon is in my theme and others but system is not reading it as before. Also, so far for me there is no other theme that would fix it, despite many, many theme updates lately. With each update I hoped to see Arc or Breath fixed to ask what they did but nothing. I went through "get new" and uninstalled those themes and seems as if I have them only from packages and yet the bug is still present. Where is this theme cache you are talking about? I don't have any other themes in ~/.local/share/plasma/desktoptheme/ aside mines. Rest is installed from Manjaro repo which is pulled from Arch repo. This is all very confusing and badly resolved IMO. And now we don't even have valid bug thread about it since this one was narrowed down to Adapta which wasn't even the bug itself. It was about all themes compatibility break. Also, I don't understand how this one could have been "the original thread" since this was posted on 2018-08-02 08:13:04 UTC, while others ones were earlier? This was was way earlier: https://bugs.kde.org/show_bug.cgi?id=395485 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 397082] The new media player icons rely on the icon theme instead of the desktop theme
https://bugs.kde.org/show_bug.cgi?id=397082 --- Comment #18 from Michał Dybczak --- Thanks for the info Filip. The fact that you have to use git versions from AUR to have fixed version from top, trendy themes, while those in repos of cutting edge distros are broken + hundreds of other themes elsewhere makes the situation very bad. And that's quite some time after the 5.13 release. I'm also a maintainer of some themes and I would like to fix them but I don't know how. I have no idea what has changed under the hood and what needs updating. As far I check, all themes do have correct media icon, but it's not showing up because of the recent changes so paths are broken somehow. If the change that broke almost all the non-breeze themes is justified, then fine, but we are waiting for official announcement and how to fix our themes. Still, most of themes will stay broken. This creates a very bad precedence where people have easy access to hundreds of themes on opendesk sites (like kde store) but no warning or info about their compatibility. We are used to that themes usually work. On Gnome breakages and hunting for versions that suit Gtk/Gnome version is normal but KDE is not prepared for it. On Gnome plugins have already notification about which version they are compatible with. Yeah, they have a mess but people learned how to deal with it. For example, Plasma themes now need some additional info like: Compatible up to Plasma 5.12; Compatible with Plasma 5.13+. Without it we either find out that effect is bad after using it or looking when the theme was changed. In latter case it doesn't even say that it was fixed for this compatibility, it may have not been. Also, users on Plasma are not use to paying attention to that kind of info. Plasma do create some compatibility breakages but they are usually under the hood, not with external, abundant third party sources as with themes. IMO the issue is huge and creates dangerous complications for user experience. The question is, was this breakage really worth it? There is a great and funny video how Linus Torvalds treats the breakage of user space: https://www.youtube.com/watch?v=FUsJ-Lr4kww Of course, kernel and Plasma desktop themes are not the same even in the slightest, but still some thought about breaking user experience must be made. Oftentimes developers have different priorities in mind and conflicts arise. Since developers have upper hand and can create change on whim, this tempts to go too far since they see a code problem, not a usability and experience problem. So once again, is this theming change so important that we should sacrifice whole desktop stack as incompatible from now on? Was there no other, smoother way to resolve it? At least with some legacy lines that uphold compatibility but allow for the change somehow? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 397082] The new media player icons rely on the icon theme instead of the desktop theme
https://bugs.kde.org/show_bug.cgi?id=397082 --- Comment #20 from Michał Dybczak --- Thanks. I didn't even know that svg files can be opened in text editor. I analyzed the file but didn't understand much of it. So I just decided to use breeze file instead. I went to /usr/share/plasma/desktoptheme/default/icons/media.svgz and copy it over to my media.svgz file. Now it works. I experimented with the fixed Adapata theme and also was able to add its icon for my theme (I had to change it from svg to svgz in Inkscape first) but it wasn't the breeze one, it was just the play/pause without the square around it but had the right color. It was not so bad in the end. That square around it was making the issue, plus the wrong color. Anyway, I decided on the default breeze media round icon that I like. I'll upload fix on kde store soon. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395442] Framework 5.47 bug with systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 --- Comment #11 from Michał Dybczak --- I believe the bug is somehow related to Qt? Neon and Manjaro use the same, newest version. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395442] Framework 5.47 bug with systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 Michał Dybczak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Michał Dybczak --- I checked today on Manjaro and the notification bug is fixed. I guess some Qt or Plasma and KDE updates since then changed something and now all seems to be OK. Closing. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] New: Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 Bug ID: 371954 Summary: Gdrive doesn't show all files/folders Product: kio-gdrive Version: 1.0.3 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: elvis.angelac...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 101948 --> https://bugs.kde.org/attachment.cgi?id=101948&action=edit Gdrive view in Dolphin and in browser. In Dolphin 3 folders are missing. Gdrive doesn't show all folders. In one of folders I have 4 folders yet I see only one of them. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #2 from Michał Dybczak --- I don't have ~/.config/QtProject/ folder :( -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #4 from Michał Dybczak --- Created attachment 102039 --> https://bugs.kde.org/attachment.cgi?id=102039&action=edit Output of "journalctl -b | grep kf5.kio.gdrive" -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #6 from Michał Dybczak --- How can I print intput of "journalctl -b | grep org.kde.kgapi" into file? It's too big to mark it all. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #7 from Michał Dybczak --- I meant output* -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #9 from Michał Dybczak --- Created attachment 102086 --> https://bugs.kde.org/attachment.cgi?id=102086&action=edit Output of "journalctl -b | grep org.kde.kgapi" -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #11 from Michał Dybczak --- I used "alt+h" and folders showed themselves! Thanks! I would never thought that linux folders can be hidden without "." So trivial issue. However I don't see any settings with "hidden" to those folders. How can I make them unhidden then? -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #13 from Michał Dybczak --- Deprecated? You mean that this feature will be removed in some feature updates? Because so far it works, although I do agree that it's pointless feature so it needs to go. That's not ideal at the moment, because I often switch between hidden/unhiden and by default it's hidden but I can live with it. Will wait for the updates. Most important is that gdrive works. Thanks! Off topic: Will there be some additional dolphin implementation like quick access to gdrive account? At the moment I had to add it manually so I wouldn't have to open it from start menu. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 371954] Gdrive doesn't show all files/folders
https://bugs.kde.org/show_bug.cgi?id=371954 --- Comment #15 from Michał Dybczak --- Thanks :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389479] Plasma not mount disk
https://bugs.kde.org/show_bug.cgi?id=389479 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #21 from Michał Dybczak --- I confirm. Just updated Manjaro to Plasma 5.12.1, KDE Framework 5.43.0 with kernel 4.15.3-2, Qt 5.10.0 and automounting is gone. After pluging in my external hard drive I see notification about the device on my panel and I can mount it from there but it's not automounted like before which is very annoying. Other Manjaro Plasma users report the same problem here: https://forum.manjaro.org/t/stable-update-2018-02-17-kernels-kde-mate-firefox-libreoffice-mesa-systemd/40582/4 It's very important to me that external devices are automounted so I consider this a serious drawback. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 390667] New: Physical power button stopped working in Plasma 5.12.1
https://bugs.kde.org/show_bug.cgi?id=390667 Bug ID: 390667 Summary: Physical power button stopped working in Plasma 5.12.1 Product: systemsettings Version: 5.12.1 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- I just upgraded from Plasma 5.11.5 to 5.12.1 and physical power button on my laptop stopped working. I have set it to power off the system while pushed on a working session (in all scenarios, so with AC plugged in, on a battery and in a critical state) and this has always worked without problems before. Now I can push/click it as many times I want, there is no reaction from the system. I checked if settings are not changed but no, all looks fine. To be sure I applied different setting and then again power button as shutdown action. No change, still not doing anything. I checked kernels 4.15, 4.14, 4.9 - issue exists on all of them. Laptop: Alienware 17 R3 Is there any place I should look for more details to help with the issue? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 390667] Physical power button stopped working in Plasma 5.12.1
https://bugs.kde.org/show_bug.cgi?id=390667 --- Comment #2 from Michał Dybczak --- Yes, it does seem that this is the same bug. My screen brightness key shortcuts also stopped working - I didn't realize that earlier. I tried the solution of from comment 22 but it didn't help and actually, the lines that I copied and moved from one section to another were identical as far I could evaluate quickly, so I don't see the point of the whole manual fix. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 389991] Sleep key no longer initiates sleep
https://bugs.kde.org/show_bug.cgi?id=389991 --- Comment #36 from Michał Dybczak --- I have the same problem after upgrading Manjaro from Plasma 5.11.5 to 5.12.1. Power button stopped working, also brightness keys doesn't work anymore (brigness down fn+f9 and brightness down fn+f10). I did manual fix as advised in comment 22 but it didn't help at all. Previously I had in [org_kde_powerdevil]: PowerOff=none,Power Off,Wyłącz After the fix: PowerOff=Power Off,Power Off,Wyłącz Still Power Off is not happening (I have assigned power button to power off). Similar changes were made on other lines but they didn't work either. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 389991] Powerdevil global shortcuts not working after 5.12 config migration
https://bugs.kde.org/show_bug.cgi?id=389991 --- Comment #39 from Michał Dybczak --- Thanks, @ulusu, it now makes more sense. However, I switched [kded5] lines with [org_kde_powerdevil] but it still doesn't work. After I log off/log in, old lines (or at least some of them) get restored. I did edit it with GUI editor (kwrite). How can I prevent restoring old, bugged settings? Why doesn't it stick? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 389991] Powerdevil global shortcuts not working after 5.12 config migration
https://bugs.kde.org/show_bug.cgi?id=389991 --- Comment #41 from Michał Dybczak --- Unfortunately not. I edited original ~/.config/kglobalshortcutsrc file with kwrite and still the same - it gets overwritten with every logoff/ login so it never works :(. I checked permissions and I had oddly 0777 on original file so I lowered it to 0755 but still no luck, it gets overwritten. What gives? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 389991] Powerdevil global shortcuts not working after 5.12 config migration
https://bugs.kde.org/show_bug.cgi?id=389991 --- Comment #44 from Michał Dybczak --- (In reply to David Edmundson from comment #42) > A secondary migration will be in 5.12.2 > > >What gives? > > Same reason as my original update script didn't work; kglobalaccel is still > running whilst you're editing it. Thanks! I switched to LXQt session, made the changes, relogged to Plasma and now it works! Power button and screen brightness work as intended. That is the peace of the advice that is missing in comment 22. -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 391868] New: Incorrect Libre Office first topmenu item when office file launched directly
https://bugs.kde.org/show_bug.cgi?id=391868 Bug ID: 391868 Summary: Incorrect Libre Office first topmenu item when office file launched directly Product: kded-appmenu Version: 5.12.3 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: top menubar Assignee: plasma-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 111404 --> https://bugs.kde.org/attachment.cgi?id=111404&action=edit Libreoffice - global menu issue, screenshot Not sure if that was reported but at the moment when launching office files (libreoffice-fresh, 6.0.2-1) directly there are two possible incorrect outputs in LO: 1) First topmenu item (in global menu) - File, is not clickable. 2) Or before correct menu items, there are some sub-menus as main ones. It's temporal and disappears when changing window focus resulting in correct, fully working global menu (first item is clickable). When trying to click those incorrect menus latte with AWC (Active Window Control) crashes and upon restore clean menu items are restored. Because of that behavior it's very hard to make screens but I manged and I'm attaching it here. You can see on the screenshot bogus menu items in that order (in Polish language): New, (empty space) Help, LO -info, close LO and then goes my dummy menu item LO and finally the correct menus. When LO files are opened through LO launcher, the issue is not happening. Temporal workaround for it is to create some dummy, first menu item so the "Files" becomes second and always accessible. The same situation happens for others as described in this thread: https://forum.manjaro.org/t/gtk-global-menu-is-coming-to-plasma-5-13/42112/20 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391868] Incorrect Libre Office first topmenu item when office file launched directly
https://bugs.kde.org/show_bug.cgi?id=391868 --- Comment #2 from Michał Dybczak --- So how do I set LO global menu to use appmenu-gtk-module? I have it installed along with gmenu-dbusmenu-proxy and did export SAL_USE_VCLPLUGIN=gtk3 to ~/.xprofile -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391868] Incorrect Libre Office first topmenu item when office file launched directly
https://bugs.kde.org/show_bug.cgi?id=391868 --- Comment #4 from Michał Dybczak --- I'm not sure if I did it correctly. I changed ~/.xprofile export SAL_USE_VCLPLUGIN=gtk export GTK_MODULES=appmenu-gtk-module Result is, I see situation 2) for a split of second and it automatically switches to situation 1) unclicable first menu So it's a bit better but still broken. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391868] Incorrect Libre Office first topmenu item when office file launched directly
https://bugs.kde.org/show_bug.cgi?id=391868 --- Comment #6 from Michał Dybczak --- Is there a chance to cooperate this with libreoffice developers? Or maybe with someone from Munich KDE team? I'm not a software developer or any IT specialist so I can only report what's on my machine and system. Bug is reproducible so it should be possible to test it somehow, I hope ;). P.S. By the way, thanks Kai for the gmenu-dbusmenu-proxy! Aside this LO issue, all seems to work great for me. I love global menus and I'm happy that Plasma have it finally the way it was supposed to be. Now it's only a matter of polishing (LO issue) and in the future extending it to FF and Thunderbird :D. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391868] Incorrect Libre Office first topmenu item when office file launched directly
https://bugs.kde.org/show_bug.cgi?id=391868 --- Comment #8 from Michał Dybczak --- Great! That's one thing to go. Once git is updated I can test it myself. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 390911] While updating, app/package list should sort by completion percentage
https://bugs.kde.org/show_bug.cgi?id=390911 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #6 from Michał Dybczak --- I also find this a big issue and I really thought once that Discover got stuck or something. As to solution, a usual update bar and "show details" list with "GUIed terminal output" (Octopi or Pamac do that correctly) would do the trick but that's just one of many possible solutions. I think that packages to update shouldn't be tied to their own progress bars like it is now. Upon hitting "Update" should open a new update area (progress bar, info bar or whatever) showing what it's doing. Let the package list be the list. This joined functionality is not working well in that case. I frankly doesn't understand how it works. In terminal output is very clear, at least on pacman side (Arch based systems) so we get shown each package and their download progress bar one by one and once it's done, similar thing for update progress and additional stuff. As I recall apt is doing it similarly. My question is: if the update process is sequential, why packages on Discover list get downloaded simultaneously? Many simultaneous process are in fact slower then when done one by one, at least it's often true to operation on files so I get the same feeling when everything is downloaded at once. Maybe it's just psychological effect but at the moment Discover creates very unease and confusing feeling during update. And there is a matter of not asking for root credentials... Has someone filed a bug for it? I cannot trust Discover without it and it feels like exploit... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 393755] New: No corresponding option in conf for GUI's pad "Mouse click emulation"
https://bugs.kde.org/show_bug.cgi?id=393755 Bug ID: 393755 Summary: No corresponding option in conf for GUI's pad "Mouse click emulation" Product: systemsettings Version: 5.12.4 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 112371 --> https://bugs.kde.org/attachment.cgi?id=112371&action=edit Pad "Mouse click emulation" option with grayed out sub-options At the moment Plasma's pad settings are stored in ~/.config/touchpadrc Enabling the "Mouse click emulation" in GUI is adding a line: Tapping=true Disabling the option is either making that line disappear or adds: Tapping=false The issue is: in GUI we have 3 sub-options for 1, 2 and 3 finger taps and they are grayed out. So either corresponding options are not developed yet or unknown, or incorrectly applied in conf. I'm raising this issue because this is how it looks like since a long time and middle click (3 finger tap) is producing notices with pasted text on a desktop which is supper annoying. On the other hand 1 finger tap is a necessity so it forces us to have this on (true) and yet don't allow us to disable 3 finger tap (middle mouse click emulation). This may create conflicts with libinput-gestures where we can define 3 finger swipes which they work wonderfully but not on Plasma, because each 3 finger swipe is interpreted as two actions: swipe and tap, producing unwanted notes on desktop space or pasting clipboard output to windows. I tried to counteract it with adding a line to: /etc/X11/xorg.conf.d/30-touchpad.conf Option "MiddleEmulation" "False" Didn't work, even after deleting touchpadrc and reboot. So far there seems to be no working method to disable 3 finger taps and if tap is on, it's on for all options. Some workaround would be to add an option to define what middle click (wheel click) does in mouse settings and we could choose: no effect, but mouse settings don't have such GUI option so far. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 393755] No corresponding option in conf for GUI's pad "Mouse click emulation"
https://bugs.kde.org/show_bug.cgi?id=393755 --- Comment #1 from Michał Dybczak --- To add some info, libinput documentation is here: https://www.systutorials.com/docs/linux/man/4-libinput/ Middle click emulation that I want to turn off is described: Option "MiddleEmulation" "bool" Enables middle button emulation. When enabled, pressing the left and right buttons simultaneously produces a middle mouse button click. What is suspicious, you can't press left and right when using pad so this option may be only for mouse and that would explain why Option "MiddleEmulation" "False" is not working in /etc/X11/xorg.conf.d/30-touchpad.conf This would also imply, that at the moment there is no correct libinput option for that GUI options. Can someone more knowledgeable look into it? Another course of action could be: filing a bug to libinput to add such option so it could be finally linked with Plasma's pad settings GUI and its config. What do you think? We can't have such nice options be indefinitely grayed out... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391868] Incorrect Libre Office first topmenu item when office file launched directly
https://bugs.kde.org/show_bug.cgi?id=391868 --- Comment #10 from Michał Dybczak --- I updated git version recently and I still have the issue with additional, crashy menu. Is the fix not in git version yet? -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 394629] New: Plasma integration extension disappeared from Google Web Store
https://bugs.kde.org/show_bug.cgi?id=394629 Bug ID: 394629 Summary: Plasma integration extension disappeared from Google Web Store Product: plasma-browser-integration Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Chrome Assignee: k...@privat.broulik.de Reporter: michal.dybc...@gmail.com Target Milestone: --- Not sure what happened but Plasma integration extension disappeared from Google Web Store. My Chromium still has it installed and it works great (it worked always better then on Firefox although I noticed improvement lately on Firefox part) but it is not possible to find and install for new users. I've been searching the web for some information about it but so far nothing. What happened? Is it just a temporary issue? Will it be back? This is even stranger in face of incoming Plasma 5.13 where plasma integration is one of the flagship features. I send the extension to one of my friends directly from my Chromium install and it works as expected for him. I also can't see any issues with it so why is it gone from Google Web Store? -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 394629] Plasma integration extension disappeared from Google Web Store
https://bugs.kde.org/show_bug.cgi?id=394629 --- Comment #2 from Michał Dybczak --- I'm not talking about the package. In order for Plasma integration to work we need to install browser extensions as well. Unless they won't be needed anymore? If that so, it's not clearly stated anymore and chrome extension is deleted prematurely. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 394629] Plasma integration extension disappeared from Google Web Store
https://bugs.kde.org/show_bug.cgi?id=394629 --- Comment #5 from Michał Dybczak --- I still can't find it (I cleared the cache first) but I suspect that there is some propagation time or something like that, will check tomorrow. I assume that we will still need those extensions when Plasma 5.13 hits? -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 394629] Plasma integration extension disappeared from Google Web Store
https://bugs.kde.org/show_bug.cgi?id=394629 --- Comment #7 from Michał Dybczak --- Thanks for clarifying it. I didn't know it was possible. By the way, you said "for all supported browsers", does that include Falcon? It would be weird if Falkon had not been supported. I don't use it (because of lack of extensions) but still, KDE projects should be supported by other KDE projects. On quick glance, I can't see plasma integration on Falkon. I have at the moment AUR version of Plasma integration git. Maybe the version coming with Plasma 5.13 will have those extensions but the git version is not there yet... -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 394629] Plasma integration extension disappeared from Google Web Store
https://bugs.kde.org/show_bug.cgi?id=394629 --- Comment #10 from Michał Dybczak --- Yes, I confirm, plasma integration is showing again on google web store. Everything is all right now :). -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #17 from Michał Dybczak --- So with sshfs 3.2.0-1 it works correctly? Or do we have to wait till 3.2.1? Oh wait, I can test it ;). I managed to send some mp3 music file with right-click option "send to" and mp3 is fine, no corruption. So on Arch systems it all should be fine now. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 383069] Corrputed mp3 files when sent through KDE Connect
https://bugs.kde.org/show_bug.cgi?id=383069 --- Comment #19 from Michał Dybczak --- You're right. When using Dolphin and dragging a file between panels/locations, it shows "cannot write /path1 to /path2". When I used a small text file, everything went ok. So I guess, we're still waiting for sshfs 3.2.1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384030] New: Plasmashell freezes and crashes when panel is moved on left or right side of screen
https://bugs.kde.org/show_bug.cgi?id=384030 Bug ID: 384030 Summary: Plasmashell freezes and crashes when panel is moved on left or right side of screen Product: plasmashell Version: 5.10.4 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Desktop Dashboard Assignee: notm...@gmail.com Reporter: michal.dybc...@gmail.com Target Milestone: 1.0 Since Plasma 5.10.4-2 update, moving panel on the left or right causes panel to freeze before attaching to the side of the screen, after half of minute plasmashell crashes. After relaunching plasmashell, panel is back in the old place. So basically panel up or down works ok, right or left causes crashes (in moment of saving config, which fails). -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 384474] New: Gwenview is not adding extension automatically with "Save As"
https://bugs.kde.org/show_bug.cgi?id=384474 Bug ID: 384474 Summary: Gwenview is not adding extension automatically with "Save As" Product: gwenview Version: 17.08.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- When opening for example a png file and using "Save As" and choosing a different format like jpeg, name of the file is wiped out (inconvenient). After pasting the name without extension and hitting enter, gwenview shows error message about unsupported format, because it didn't add extension that was chosen on the list below. All other programs (like Krita) allow for either having name as: nameofthefile or nameofthefile.jpg. Chosen format from the list takes precedence and if not present in the name, it's added automatically. Again, this doesn't happen in Gwenview. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 384474] Gwenview is not adding extension automatically with "Save As"
https://bugs.kde.org/show_bug.cgi?id=384474 --- Comment #1 from Michał Dybczak --- >From feedback on Manjaro forum it might not be a general bug, because it was reported to me it works as expected, Gwenview adds extension chosen from the list even if there is no one specified in file name. At this point I have no idea why it works that way for me and how to debug it. Since it may be some local bug, it's not of a importance. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 384474] Gwenview is not adding extension automatically with "Save As"
https://bugs.kde.org/show_bug.cgi?id=384474 --- Comment #5 from Michał Dybczak --- I made video of that bug and... I noticed a small box to check: "automatically use jpeg extension" Well, this is confusing. In many places when saving something (from browser), it tried to add incorrectly bin extension, so I turned it off and never looked twice at it. Surprisingly in Gwenview this checkbox works correctly. Or maybe some recent update fixed it? Sometimes it's hard to keep up on rolling release with all changes ;). Anyway, sorry for the confusion. You can close it as there is no bug. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391539] Pinned icon changes after application closes
https://bugs.kde.org/show_bug.cgi?id=391539 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #8 from Michał Dybczak --- For me it doesn't matter if icon is set by ice-ssb or manually from system (through properties of a file) so I actually also can't reproduce the problem. However, the issue is different. a) If StartupWMClass=Chromium or any browser name, this desktop file assigned icon is set for the said browser, so in effect, setting ice-ssb app, the new icon overwrite chosen browser. I assume this doesn't happen in other DEs so the question is, is this a bug or a feature. If it's the latter, how it can be overcome? b)If StartupWMClass= is set to something else (non browser), then the window uses default browser icon and is grouped with browser, which is undesired. Again, not sure if it's a bug or a feature and if how can it be overcome? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391539] Pinned icon changes after application closes
https://bugs.kde.org/show_bug.cgi?id=391539 --- Comment #10 from Michał Dybczak --- ice-ssb is an app that allows for creating separate browser wrapped apps, so for example instead using facebook in browser tab, you can create a facebook app using firefox, chrome or chromium. ice-ssb creates desktop file that opens that created tab. This is basically peppermint-os feature but the ice-ssb app is available for everyone to use and as it happens, it doesn't work well in Plasma, but we're not sure if that's because of how some things in Plasma work or it may be a bug? I thought you red the link above to the ice-ssb issue (on github) which triggered this bug report. However, this initial bug seems to be not reproducible on your or mine machine because it works completely different than on posted video. Since there is much more to it and it's hard to explain when you're completely out of the topic, I don't think it's appropriate to dig deeper and change the original subject, so sorry about creating a confusion and let's forget about my comments. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 391539] Pinned icon changes after application closes
https://bugs.kde.org/show_bug.cgi?id=391539 --- Comment #12 from Michał Dybczak --- Thanks Elke, maybe at some later time, because ice-ssb developer should be involved in it and at this moment he is occupied with the new peppermint release. -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395442] New: Plasma 5.13.0 systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 Bug ID: 395442 Summary: Plasma 5.13.0 systray notifications: list empty and other issues Product: ksystraycmd Version: unspecified Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 113353 --> https://bugs.kde.org/attachment.cgi?id=113353&action=edit notifications list gets emptied 1. All works fine till we don't change something and apply settings. List becomes empty. This is easily reproducible and noticed on many occasions by many users. Not sure what I did, but after few minutes, list became visible. Hitting on "apply" again made the list empty. 2. New keyboard notification setting seems to work by default, meaning: caps lock's notification is enabled, num lock's disabled and when hitting caps lock there is a correct notification (an arrow). After "applying" notification settings, this stops working entirely. I set it to "always visible" but it didn't help. 3. Not sure if that falls to the same category, but new (and ugly - what was wrong with the old icon? it fit elegantly to other icons, the new one stands out in a bad way) media icon is now static, meaning: it barely changes between desktop themes (it becomes only thinner or thicker) so it can't be changed (unfortunately) but what is more important, it has only dark color for light panels. It stays black on dark panels. This one may not be a general bug, will have to investigate more. -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395442] Plasma 5.13.0 systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 --- Comment #1 from Michał Dybczak --- Created attachment 113354 --> https://bugs.kde.org/attachment.cgi?id=113354&action=edit media icon bug Adding additional print screen because I couldn't do it with first post. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 395442] Plasma 5.13.0 systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 --- Comment #3 from Michał Dybczak --- The thing is, I'm not sure if those are multiple issues - it's all about systray. It can be one bug but with multiple consequences. It also doesn't matter if you use latte of plasma panel - I tried it and you can reproduce empty list and keyboard caps not working even after hitting OK on notifications settings. It's systray issue and has nothing to do with latte. Please, change the product accordingly, otherwise there must be another submission as this is clearly incorrectly assigned. -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395442] Plasma 5.13.0 systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 Michał Dybczak changed: What|Removed |Added Assignee|mvourla...@gmail.com|kdelibs-b...@kde.org Product|lattedock |ksystraycmd Component|application |general --- Comment #4 from Michał Dybczak --- Steps to reproduce: 1. Open settings of system tray 2. Go to notification settings tab and click OK or change settings and then "Apply" 3. Works every time on system panel or latte panel. Issue is gone when panel (latte or system's) is restarted so system's tray widget's restart is restoring proper behavior (for point 1 and 2). Point 3 seems to be different bug so please disregard it in this topic. -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395442] Plasma 5.13.0 systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 --- Comment #5 from Michał Dybczak --- Steps to reproduce: 1. Open settings of system tray 2. Go to notification settings tab and click OK or change settings and then click "Apply". 3. Check notification tab settings list again, it's empty. 4. Works every time on system panel or latte panel. Issue is gone when panel (latte or system's) is restarted so system's tray widget's restart is restoring proper behavior (for point 1 and 2). Point 3 seems to be different bug so please disregard it in this topic. -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395442] Framework 5.47 bug with systray notifications: list empty and other issues
https://bugs.kde.org/show_bug.cgi?id=395442 Michał Dybczak changed: What|Removed |Added Summary|Plasma 5.13.0 systray |Framework 5.47 bug with |notifications: list empty |systray notifications: list |and other issues|empty and other issues -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 395455] New: Discover buttons install/remove/launch disappear
https://bugs.kde.org/show_bug.cgi?id=395455 Bug ID: 395455 Summary: Discover buttons install/remove/launch disappear Product: Discover Version: 5.13.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: discover Assignee: aleix...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 113358 --> https://bugs.kde.org/attachment.cgi?id=113358&action=edit Missing buttons Steps to reproduce: 1. Open Discover 2. Go to the installed top program (in my case Krita), see Launch and Remove buttons, they are displayed correctly at this stage. 3. Go to the some not installed program (in my case Digicam), see Install button which is displayed correctly at this stage. 4. Go back to main programs menu and go again to the first or others programs windows, they don't have the buttons to install/launch/remove program Works every time. In fact, all it takes is to go to the few random top programs and in second or third view buttons are gone. I tried it on test, clean user and the issue is visible there as well. -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 395463] New: Plasma 5.13 Global menu in Firefox and Thunderbird don't work
https://bugs.kde.org/show_bug.cgi?id=395463 Bug ID: 395463 Summary: Plasma 5.13 Global menu in Firefox and Thunderbird don't work Product: kded-appmenu Version: 5.13.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: export Assignee: plasma-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Qt: 5.11.0 KDE Framework: 5.47.0 Plasma 5.13.0 OS: Manjaro Kernel: 4.17 Expected behavior: Global menu in Firefox and Thunderbird work like in Neon Developer Preview. Real behavior: No global menus for Firefox and Thunderbird Steps to reproduce: 1. Have global menus in panel or titlebar. 2. Open Firefox or Thunderbird. Reproducible: always. Is it because of some missing package, some manual configuration is needed or maybe unity patch isn't working aside Ubuntu based distros? Or maybe something different? -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 395463] Plasma 5.13 Global menu in Firefox and Thunderbird don't work
https://bugs.kde.org/show_bug.cgi?id=395463 --- Comment #3 from Michał Dybczak --- Thanks Anotonio. This is what I feared. From talks here, devs weren't sure if it will work on other distros and it seems it doesn't. I also checked my Neon vbox install (so regular neon instead developer preview), updated it and firefox/thunderbird menus work there as well, so all is well on ubuntu's side. I guess we will have to wait for more general solution and that will probably take some time. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 395519] New: Minimize applet stops working correctly - regression?
https://bugs.kde.org/show_bug.cgi?id=395519 Bug ID: 395519 Summary: Minimize applet stops working correctly - regression? Product: kdeplasma-addons Version: 5.13.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: General Assignee: plasma-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Plasma 5.13.0 KDE Framework 5.47.0-1 OS: Manjaro KDE Kernel 5.17 Using Minimize All applet which comes by default on Manjaro KDE. In the past there was Minimize to desktop and Minizmie All, now it seems to be only Minimize All (which is fine, since Minimize to desktop was unsuable anyway). Steps to reproduce: 1. Open few program windows (so they appear on desktop one over the other). 2. Use Minimize All widget 3. Click on panel/dock (doesn't matter if applet is on system panel or latte) icon to un-minimize chosen window Expected behavior: Only chosen window should be un-minimized. What happens - All windows get un-minimized and they are placed in random or previous layers (so it works like Minimize to desktop, Minimize All lost its functionality) so the wished window usually gets covered behind thus requiring to click second time for it to appear. This effect happens when window is chosen from overview. - Also, after minimizing all and opening a file from the desktop and closing that file window, all minimized windows jump on the screen, again with random layers placement (there is no way to control and have expected windows order in that way). Works: Always A workaround is to use alt+tab or overview (assigned to pad gesture, shortcut or active corner) to change workflow of choosing the window. Still, this is not a fix and the bug is limiting Plasma’s ability to choose proffered workflow. It also disturbs any workflow with automatic raising windows and placing them in random or unclear manner (first window is always DIFFERENT then the last minimized one!) on the desktop. At first I thought this may be somewhat related to the bug: https://bugs.kde.org/show_bug.cgi?id=395473 but on second though, clicking on the applet minimize and un-minimize windows on the second stroke so it's not that. This is the most serious bug discovered in Plasma 5.13 that can't be ignored and is disturbing normal work on the system, hence I set severity to "major". -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 395455] Discover buttons install/remove/launch disappear
https://bugs.kde.org/show_bug.cgi?id=395455 --- Comment #2 from Michał Dybczak --- Indeed, by resizing window buttons appeared (together with a layout change) giving quite nice 3 column look. Awesome. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 389479] Plasma not mount disk
https://bugs.kde.org/show_bug.cgi?id=389479 --- Comment #62 from Michał Dybczak --- There was a bug in old Plasma version but it was fixed long time ago. I also can't confirm this bug. Mounting works fine on Manjaro Plasma 5.13.0 and KDE Framework 5.47 as it was in previous version. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 389479] Plasma not mount disk
https://bugs.kde.org/show_bug.cgi?id=389479 --- Comment #67 from Michał Dybczak --- My all SSD and HDD partitions are correctly mounted on boot. When pluging in external hard drives and USB's, they are also correctly auto-mounted and I get proper indication in systray. In System Settings > Removable Storage > Removable Devices I have only checked one of the HDD partitions and my external hard drive but my fstab had entries to mount all available computer partitions. Again, as to any other external mounts, they get auto-mounted just fine. I recall having auto-mount issue and many users on Manjaro forum mentioned it as well after certain update. Then fix arrived (after a week or so) and problem went away immediately and people stop mentioning it on Manjaro forums.That plus fact that others also can't reproduce the issue points that Dr. Chapatin's problem is an individual one and not a general Plasma bug. What is the journalctl or dmsg output when plugging in the external drives/usb's on your system Dr. Chapatin? Maybe there is an error pointing out where to look at? Or actually I would browse through errors to find if something is not related to the problem. For current boot: - errors journalctl -b -p3 - warnings and erros journalctl -b -p4 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 389479] Plasma not mount disk
https://bugs.kde.org/show_bug.cgi?id=389479 --- Comment #70 from Michał Dybczak --- Maximize Konsole window before marking a log output. At the moment everything is cut in the middle. Not sure what is the etiquette of this bugtracker? Maybe it's better to save output to pastebin/hastebin and post a link? I would check times. Just plug in something and then check journal if in that time showed something suspicious. Did you plugged in something at times showed in the log? However the fact that Gnome session mounts everything correctly suggest some bug on Plasma level. It looks like something bad is happening with baloo. It's worth to check it out (refresh baloo, check configuration, etc.) although it has nothing to do with the problem, although... this unhandled device action may be somewhat connected? Interesting line is: kernel: FAT-fs (sdd1): Volume was not properly u> I hope that someone more knowledgeable will chip in. Actually those sort of problems are better to be posted on forums where more users can find them and answer, while devs should take care of general Plasma and KDE bugs. Maybe there are better ways to look for mounting errors. -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395619] New: Media icon defaults to fallback on non breeze themes on Plasma 5.13.0
https://bugs.kde.org/show_bug.cgi?id=395619 Bug ID: 395619 Summary: Media icon defaults to fallback on non breeze themes on Plasma 5.13.0 Product: ksystraycmd Version: unspecified Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 113436 --> https://bugs.kde.org/attachment.cgi?id=113436&action=edit Square media icon on a light panel OS: Manjaro Plasma 5.13.0 KDE Framework: 5.47 Kernel 4.17 Steps to reproduce: 1. Switch to none-Breeze theme (some of the popular themes like Paper could have fixed it internally). Most if not all tested non breeze themes had this issue so far. 2. Relogg session. 3. Start some media program to activate media icon. Expected result: The usual, round media icon What is happening: Instead usual media icon we see ugly, square icon that has only black color so it becomes invisible in dark panels and doesn't suit other panel icons. See attachments. Switching back to Breeze, Breeze Dark, Breeze Light and relogging session (sometimes in the same session) restores the proper, round media icon. Now is the question, is it a bug that can be fixed in Plasma level or should all themes update to be properly usable on Plasma? -- You are receiving this mail because: You are watching all bug changes.
[ksystraycmd] [Bug 395619] Media icon defaults to fallback on non breeze themes on Plasma 5.13.0
https://bugs.kde.org/show_bug.cgi?id=395619 --- Comment #1 from Michał Dybczak --- Created attachment 113437 --> https://bugs.kde.org/attachment.cgi?id=113437&action=edit Square media icon on a dark panel -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 395351] Touchpad settings are disabled in Wayland
https://bugs.kde.org/show_bug.cgi?id=395351 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #8 from Michał Dybczak --- I have different touchpad hardware and its settings on wayland are working correctly. However, mouse settings are completely grayed out. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 389479] Plasma not mount disk
https://bugs.kde.org/show_bug.cgi?id=389479 --- Comment #74 from Michał Dybczak --- >From journalctl most striking to me were: UdevQt: unhandled device action "unbind" This may not be the same but check this out: https://bbs.archlinux.org/viewtopic.php?id=236289 Solution there was to reinstall the kernel or try a different one. Also: Some data may be corrupt. Please run fsck. -> self explanatory. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395485] Media Controls Plasmoid (Dark Icon)
https://bugs.kde.org/show_bug.cgi?id=395485 --- Comment #5 from Michał Dybczak --- Manjaro OS Plasma 5.13.1 KDE Framework: 5.47.0 Qt: 5.11.1 Kernel: 4.17 I confirm this bug. So far EVERY non-breeze theme I tried causes media icon to fallback to the square one which is only in dark color so is visible only on light panels. Breeze, Breeze Dark, Breeze Light have proper media icon. Issue appeared after updating to Plasma 5.13. All non-breeze themes use this default, round media icon and yet newest Plasma can't register it. Is it a bug or maybe a change in Plasma theming that requires from themes developers to update their themes? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 417716] With non-breeze aurorae theme and "No Borders" setting it's no longer possible to get resize cursor on titlebar's upper edge
https://bugs.kde.org/show_bug.cgi?id=417716 --- Comment #8 from Michał Dybczak --- Plasma 5.27.1, the bug still exists, also in Wayland session. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 417716] With non-breeze aurorae theme and "No Borders" setting it's no longer possible to get resize cursor on titlebar's upper edge
https://bugs.kde.org/show_bug.cgi?id=417716 Michał Dybczak changed: What|Removed |Added Version|5.18.0 |5.27.1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466369] New: Third party aurorate titlebars don't update graphics correctly when resized under new tiling in Wayland
https://bugs.kde.org/show_bug.cgi?id=466369 Bug ID: 466369 Summary: Third party aurorate titlebars don't update graphics correctly when resized under new tiling in Wayland Classification: Plasma Product: kwin Version: 5.27.1 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: aurorae Assignee: kwin-bugs-n...@kde.org Reporter: michal.dybc...@gmail.com Target Milestone: --- Created attachment 156683 --> https://bugs.kde.org/attachment.cgi?id=156683&action=edit Tiled-Gwenview SUMMARY *** When I tried out the new tiling in Plasma 5.27, I noticed that some (not all) apps get completely distorted titlebar graphics, sometimes during a tiling, sometimes after coming out of the tiling mode. This was noticed under Wayland. *** STEPS TO REPRODUCE + OBSERVED RESULT 1. Log in into Wayland session 2. Have third party aurorae theme, like WhiteSur-dark 3. Apply new tiling (shift+drag window), resize the titled windows, then drag the window out of tiling. Some apps (didn't find a rule yet), like for example Gwenview, get completely distorted titlebar graphics - see the attached screenshot. EXPECTED RESULT Third party titlebars should maintain properly updated graphics during and after tiling. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.13-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530 Manufacturer: Alienware Product Name: Alienware 17 R3 System Version: 1.13.1 ADDITIONAL INFORMATION I am still finding a rule, but so far it looks like a random occurrence. Once I saw it with Thunderbird, then I couldn't repeat it. Then I saw it under Dolphin, then I couldn't repeat it. Now, I caught this bug on Gwenview and made the screenshot. Sometimes the problem is visible during a tiling, and then it's fixed when the app is out of tiling mode. Sometimes the bug stays. Weirdly, when the graphics returns to normal out of tiling, when the app is tiled, the same visual bug appears right away, as if it was remembered. During the writing this bug description, I couldn't repeat it on Dolphin, but then I tried again, and the bug came again and is repeatable. When the window is widened above half of the screen, the titlebar is widened horizontally. When the window is below the half of the screen, the titlebar is shortened beyond the windows width and the titlebar graphics is distorted. I haven't tested it under X11, so I don't know if the bug happens there as well, but I suspect it may be a Wayland thing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466369] Third party aurorate titlebars don't update graphics correctly when resized under new tiling in Wayland
https://bugs.kde.org/show_bug.cgi?id=466369 --- Comment #2 from Michał Dybczak --- I can confirm this issue on Manjaro as well. I also noticed, that it's not always after resizing in tiling mode. Sometimes I just opened a window (Krusader), resized it and got this weirdly distorted titlebars. I assume the fix will be in 5.27.2? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465790] resizing a window leads to malformed decoration under Aurorae
https://bugs.kde.org/show_bug.cgi?id=465790 --- Comment #13 from Michał Dybczak --- I can confirm this issue on Manjaro as well. I also noticed, that it's not always after resizing in tiling mode. Sometimes I just opened a window (Krusader), resized it and got this weirdly distorted titlebars. I assume the fix will be in 5.27.2? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466369] Third party aurorate titlebars don't update graphics correctly when resized under new tiling in Wayland
https://bugs.kde.org/show_bug.cgi?id=466369 --- Comment #3 from Michał Dybczak --- Disregard the last comment. I meant to post it to the original bug report, but got confused and clicked a wrong tab in the browser ;). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445449] Shutting down from Plasma Wayland causes shutdown to be delayed while stopping SDDM
https://bugs.kde.org/show_bug.cgi?id=445449 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com --- Comment #38 from Michał Dybczak --- I confirm that issue on Plasma 5.27 on Wayland on Manjaro. With X11 shutdown is quick, with Wayland it's 1,5 minute delayed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465790] Resizing an Aurorae-decorated window leads to malformed decorations
https://bugs.kde.org/show_bug.cgi?id=465790 --- Comment #30 from Michał Dybczak --- I just noticed the same bug on 5.27.2 when I resized VLC window in single monitor setup in Wayland. The same visual effect as previously, so the bug is not squashed yet. Hybrid graphic with GTX 970 M Operating System: Manjaro Linux KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.2.1-2-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530 Manufacturer: Alienware Product Name: Alienware 17 R3 System Version: 1.13.1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465790] Resizing an Aurorae-decorated window leads to malformed decorations
https://bugs.kde.org/show_bug.cgi?id=465790 --- Comment #31 from Michał Dybczak --- To add more details to me previous comment: No scaling (100%) Aurorae: WhiteSur Dark The issue happens more likely on Qt apps, like Konsole. You need to adjust the width of a window to trigger it. This time, I got even a new effect: the titlebar was expanding down, and the graphics was expanding along the way, which is looked as if it was melting Quite trippy... Once I closed the Konsole from the dock (I couldn't interact with the enormously extended buttons) and launched it again, it was immune to that glitch. Maybe all apps became immune, because I couldn't trigger it anymore. Non-qt apps like Firefox also can get it, but it happens rarely. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424485] GDbus-DBusMenu-Proxy does not work for GTK Wayland apps
https://bugs.kde.org/show_bug.cgi?id=424485 Michał Dybczak changed: What|Removed |Added CC||michal.dybc...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483645] Drag and drop files to web browser only work for the first file
https://bugs.kde.org/show_bug.cgi?id=483645 --- Comment #21 from Michał Dybczak --- Although I have various issues with drag-drop actions (inconsistent ones), it seems to be entirely different. On my system, I couldn't replicate the issue using the same site as showed on the video. This may suggest that this is some config or hardware issue? Did you try doing this on a vanilla, test user? Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-3-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics (desktop running in hybrid session with Ryzen, Radeon on demand) Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: TUXEDO Product Name: TUXEDO Sirius 16 Gen1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483645] Drag and drop files to web browser only work for the first file
https://bugs.kde.org/show_bug.cgi?id=483645 --- Comment #24 from Michał Dybczak --- Lately, I don't have any drag-drop issues, so the ones you are describing is probably something else. Without finding out why the bug shows up for you and not for others, I don't think this will be fixed soon. Again, please check a test user with vanilla settings. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483645] Drag and drop files to web browser only work for the first file
https://bugs.kde.org/show_bug.cgi?id=483645 --- Comment #26 from Michał Dybczak --- Great! Now everyone who has that bug, let us know what distro and a browser are you using. Maybe this is some packaging issue of the distro itself, or the browser? I only saw @Matija letting us know he uses Neon. I'm on Manjaro and Firefox myself and have no such bug. The suspicious part is, that there are no multiple people reporting it, so it's hard to pinpoint the conditions, but I guess we need to cover the basics, like configs, distro, browser. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483645] Drag and drop files to web browser only work for the first file
https://bugs.kde.org/show_bug.cgi?id=483645 --- Comment #27 from Michał Dybczak --- Ah, sorry @Dilam, you also mentioned Neon. That is at least the common thing between two persons reporting it. I guess, it would be nice to check out different distros. I could check TUXEDO OS, which is similar to Neon in many ways. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483645] Drag and drop files to web browser only work for the first file
https://bugs.kde.org/show_bug.cgi?id=483645 --- Comment #29 from Michał Dybczak --- I checked TUXEDO OS, as promised, and... I could replicate the bug right away with Plasma 5.27 and X11 session, so it seems, we have confirmation, that Neon packages are somehow at fault here. Second, Wayland doesn't matter here, something else is causing it. I guess, it's time for the devs to start debuging it in more details. Maybe some terminal data during drag-drop action would prove handy? I'm currently updating TUXEDO OS and see if it helped, but I suspect, given your info, it won't. -- You are receiving this mail because: You are watching all bug changes.
