[Breeze] [Bug 484228] In Plasma 6 a line separator remains even when header colour is the same as window backgroud colour
https://bugs.kde.org/show_bug.cgi?id=484228 --- Comment #1 from Gauthier --- Created attachment 167595 --> https://bugs.kde.org/attachment.cgi?id=167595=edit Plasma 6 with a separator -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 484228] New: In Plasma 6 a line separator remains even when header colour is the same as window backgroud colour
https://bugs.kde.org/show_bug.cgi?id=484228 Bug ID: 484228 Summary: In Plasma 6 a line separator remains even when header colour is the same as window backgroud colour Classification: Plasma Product: Breeze Version: 6.0.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Color scheme Assignee: plasma-b...@kde.org Reporter: g.gue...@posteo.net Target Milestone: --- Created attachment 167594 --> https://bugs.kde.org/attachment.cgi?id=167594=edit Plasma 5 with no separator In Plasma 5, when setting the same colour for Window Normal Background and Header Normal Background the same then there is a smooth transition between the Header and the Window. If the colours are different then there is a separator line. In Plasma 6, the separator line remains even if the colour are the same. See screenshots. I don't know if that change was intended or not but I personally find it much nice without a line separator. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 482937] New: Dolphin crashes when ejecting unmounted cdrom via physical button
https://bugs.kde.org/show_bug.cgi?id=482937 Bug ID: 482937 Summary: Dolphin crashes when ejecting unmounted cdrom via physical button Classification: Applications Product: dolphin Version: 24.02.0 Platform: Neon OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: a...@lab.underwares.org CC: kfm-de...@kde.org Target Milestone: --- Application: dolphin (24.02.0) Qt Version: 6.6.2 Frameworks Version: 6.0.0 Operating System: Linux 6.5.0-25-generic x86_64 Windowing System: Wayland Distribution: KDE neon 6.0 DrKonqi: 6.0.0 [KCrashBackend] -- Information about the crash: I was dumping old CDs off of a usb dvd drive to images, for archival purposes. After finishing the raw dump via command line tools (which just reads the block device), and then copying the resultant image files to storage via Dolphin over cifs kio, I briefly checked that the media had not been mounted (it hadn't) and pressed the physical eject button on the drive to get my disc back. Dolphin immediately crashed with the following stack trace. I can reproduce this somewhat reliably, as it does not systematically occurs, but reoccurs the majority of the time. I in fact did it just now by reinserting the physical media, starting dolphin, waiting for everything to settle (not mounting anything) and just hitting the eject button. If it helps, since Dolphin helpfully reads the disk labels and presents them in the side bar for easy mounting, the media was an Apple HFS disk. I am unsure of how much this helps, but here is the disk layout and properties: --- /dev/sr0 Block device, size 647.7 MiB (679211008 bytes) CD-ROM, 1 track, CDDB disk ID 02114501 Track 1: Data track, 647.7 MiB (679211008 bytes) Apple partition map, 3 entries Partition 1: 31.50 KiB (32256 bytes, 63 sectors from 1) Type "Apple_partition_map" Partition 2: 647.4 MiB (678871040 bytes, 1325920 sectors from 64) Type "Apple_HFS" HFS Plus file system Volume size 647.4 MiB (678871040 bytes, 165740 blocks of 4 KiB) Volume name "Microsoft Office 2004" Partition 3: 8 KiB (8192 bytes, 16 sectors from 1325984) Type "Apple_Free" Blank disk/medium The crash can be reproduced sometimes. -- Backtrace: Application: Dolphin (dolphin), signal: Aborted [KCrash Handler] #4 __pthread_kill_implementation (no_tid=0, signo=6, threadid=137239995239104) at ./nptl/pthread_kill.c:44 #5 __pthread_kill_internal (signo=6, threadid=137239995239104) at ./nptl/pthread_kill.c:78 #6 __GI___pthread_kill (threadid=137239995239104, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #7 0x7cd1b1e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #8 0x7cd1b1e287f3 in __GI_abort () at ./stdlib/abort.c:79 #9 0x7cd1b2adb017 in qAbort () at ./src/corelib/global/qglobal.cpp:161 #10 0x7cd1b2ad64e5 in qt_message_fatal (message=..., context=...) at ./src/corelib/global/qlogging.cpp:2003 #11 qt_message(QtMsgType, const QMessageLogContext &, const char *, typedef __va_list_tag __va_list_tag *) (msgType=msgType@entry=QtFatalMsg, context=..., msg=, ap=ap@entry=0x7fff43e57e40) at ./src/corelib/global/qlogging.cpp:378 #12 0x7cd1b2adba43 in QMessageLogger::fatal (this=, msg=) at ./src/corelib/global/qlogging.cpp:901 #13 0x7cd1b2aa9c94 in qt_assert (assertion=assertion@entry=0x7cd1b49fcbd8 "dev->backendObject() != nullptr", file=file@entry=0x7cd1b49fcba8 "./src/solid/devices/frontend/devicemanager.cpp", line=line@entry=234) at ./src/corelib/global/qassert.cpp:68 #14 0x7cd1b49746dd in Solid::DeviceManagerPrivate::_k_deviceRemoved (udi=..., this=) at ./src/solid/devices/frontend/devicemanager.cpp:234 #15 Solid::DeviceManagerPrivate::qt_static_metacall (_o=0x622d3f223c90, _c=, _id=, _a=) at ./obj-x86_64-linux-gnu/src/solid/KF6Solid_autogen/include/moc_devicemanager_p.cpp:139 #16 0x7cd1b2a2baab in doActivate (sender=0x622d3f20ac20, signal_index=4, argv=0x7fff43e580f0) at ./src/corelib/kernel/qobject.cpp:4051 #17 0x7cd1b498eb99 in Solid::Ifaces::DeviceManager::deviceRemoved (this=, _t1=...) at ./obj-x86_64-linux-gnu/src/solid/KF6Solid_autogen/include/moc_devicemanager.cpp:189 #18 0x7cd1b49b9855 in Solid::Backends::UDisks2::Manager::slotInterfacesRemoved (interfaces=..., object_path=..., this=) at ./src/solid/devices/backends/udisks2/udisksmanager.cpp:249 #19 Solid::Backends::UDisks2::Manager::qt_static_metacall (_o=, _c=, _id=, _a=) at ./obj-x86_64-linux-gnu/src/solid/KF6Solid_autogen/include/moc_udisksmanager.cpp:161 #20 0x7cd1b2a2baab in doActivate (sender=0x622d3f20ac38, signal_index=4, argv=0x7fff43e583a0) at ./src/corelib/kernel/qobject.cpp:4051 #21 0x7cd1b49d1371 in OrgFreedesktopDBusObjectManagerInterface::InterfacesRemoved (_t2=..., _t1=..., this=) at
[i18n] [Bug 482416] New: Incorrect french translation of "Highlighting" in Konsole
https://bugs.kde.org/show_bug.cgi?id=482416 Bug ID: 482416 Summary: Incorrect french translation of "Highlighting" in Konsole Classification: Translations Product: i18n Version: unspecified Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: fr Assignee: kde-francoph...@kde.org Reporter: a...@lab.underwares.org Target Milestone: --- SUMMARY In Konsole under profile settings -> scrolling, the options to display the light blue bar to identify newly drawn lines has an incorrect and confusing translation. It reads "Coloration syntaxique : Réaliser une coloration syntaxique dans les lignes allant être affichées". This unfortunately refers to Syntax Highlighting, which is absolutely not what this setting is about. Consistent with the rest of the translation for Konsole where "highlight" is used, I would suggest instead: "Mise en évidence : Mettre en évidence les nouvelles lignes de l'affichage" This conveys "highlight" as in "to bring attention to" instead of syntax highlighting. STEPS TO REPRODUCE 1. Open Konsole 2. Modifier le profil actuel -> Barre de défilement 3. See weird last option at the bottom OBSERVED RESULT User is confused, unsure of what this does EXPECTED RESULT User understands that this controls the highlighting widget on the left hand side of the window. SOFTWARE/OS VERSIONS KDE Neon 6.0 KDE Frameworks: 6.0 QT: 6.6.2 Konsole package: 4:24.02.0-0xneon+22.04+jammy+release+build35 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11/Wayland, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 --- Comment #33 from Gauthier --- Actually very odd, it's now working all working fine on the Kubuntu laptop. I cannot reproduce (the bug was there only a few days ago). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11/Wayland, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 Gauthier changed: What|Removed |Added Summary|On X11, all windows moved |On X11/Wayland, all windows |to be mostly offscreen |moved to be mostly |after disconnecting |offscreen after |external monitor|disconnecting external ||monitor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 --- Comment #32 from Gauthier --- I'm still experiencing this issue on Plasma 5.27.9 on KDE Neon (on Intel graphics) and on a fresh install of Kubuntu 23.10 (On AMD graphics). On my end it does affect any kind of windows, including native KDE apps like Dolphin (in fact I notice it often with Dolphin). My set-up is: _ | A | |3440x1440 | || _ |B | |1920x1080 | || To reproduce (first way): 1. open a window (say Dolphin) in screen A and stretch it over most of the height of that screen (i.e. a height that's higher than the height of screen A) 2. unplug that screen To reproduce (another way): 1. open a window (say Dolphin) in screen A and stretch it over most of the height of that screen (i.e. a height that's higher than the height of screen A) 2. close the window 3. unplug that screen 4. relaunch that same application (again say Dolphin) that will now open on screen B but it remembers its previous size Result: both the title bar AND the bottom of the window are outside of screen B so I have to use Ctrl+F5 to move and resize so the window fit within the screen again. It does feel there need to be a systemic logic (of the kind I proposed - though of course not necessarily that one, I trust dev to think of something much better) to remember and applied window size and placement when changing monitor set-ups (both for plugging / unplugging events and when for opening a new window to the correct size after a change in monitor set-up). @KDEdevs, Is this lined up for Plasma 6? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343690] Missing windows tabbing
https://bugs.kde.org/show_bug.cgi?id=343690 --- Comment #39 from Gauthier --- I have to say I agree. This feature was SO good! ...and greatly missed since Plasma 5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428483] meta/super/win key shortcut for app launcher menu doesn't work if the launcher widget is only on the desktop
https://bugs.kde.org/show_bug.cgi?id=428483 --- Comment #2 from Gauthier --- (In reply to David Edmundson from comment #1) > This bug was reported against an outdated version of KWin. We have made many > changes since the. > If the issue persists in newer versions can you reopen the bug report > updating the version number. Yep it seems to be working fine now :) I only tried on Wayland and not on X11 (and cannot easily switch due to a bug where I loose Firefox windows) but I imagine that's since wayland is the focus right now this bug can be marked as solved. Well done for all those Kwin improvements anyway :) -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 470548] New: [Feature request] Option to enable spdif passthrough
https://bugs.kde.org/show_bug.cgi?id=470548 Bug ID: 470548 Summary: [Feature request] Option to enable spdif passthrough Classification: Applications Product: Haruna Version: 0.11.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: g.gue...@posteo.net Target Milestone: --- SUMMARY I very much like Haruna but when I need to play files in Dolby Digital I have to use another player that supports SPDIF passthrough like vlc or SMPlayer so I wondered if it'd be possible to have the option in Haruna too. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 --- Comment #29 from Gauthier --- (In reply to Gauthier from comment #24) > I also have an issue along similar lines on Wayland (so also posted there > bug 468184) > > When unpluging my external screen from my laptop, many windows (e.g. firefox > and gnucash) are not (or not appropriately) resized when moved to the laptop > screen. Specifically they are too heigh with the title bar being out of the > screen, meaning I cannot move/minmize/maximize/close them, I have to use the > shortcut Ctrl + F5 to move them and then resize manually. > > External screen is a 34" 3440x1440 whereas laptop screen is 14" 1920x1080 > (no scaling applied to either). > > Operating System: KDE neon 5.27 > KDE Plasma Version: 5.27.4 > KDE Frameworks Version: 5.105.0 > Qt Version: 5.15.9 > Kernel Version: 6.1.22-060122-generic (64-bit) > Graphics Platform: Wayland > Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz > Memory: 15.3 GiB of RAM > Graphics Processor: Mesa Intel® UHD Graphics 620 > > I have no idea how Kwin handles this currently (and so I don't want to tell > dev how to do things) but just in case it's useful, it sounds like a > systematic approach when it comes to window size and placement could be: > > To define window size on any given screen: > > width ratio = (window width in px / screen width in px) > height ratio = (window height in px/ screen height in px) > >> those width/height ratios can then be applied to different size screens' > >> height / width in plug / unplug events which would conserve the same > >> relative window size across any screen (independently of absolute screen > >> size or aspect ration). > > To define windows placement: > = > horizontal ratio: distance between screen left edge and window horizontal > centre / distance between screen left edge and screen horizontal centre > (i.e. half screen width) > vertical ratio: distance between screen top edge and window vertical centre > / distance between screen top edge and screen vertical centre (i.e. half > screen height) > >> Those ratio can then be applied to the window (horizontal / vertical) > >> centre in plug / unplug events so the relative placement is conserved > >> across any screens (independently of absolute screen size or aspect > >> ration). The case that this does not cover is if a window is spread across several screens. In this case (only) then the size / placement ratio should be worked out taken the full width / height of all screens the window is spread across. Then in plug / unplug events those ratio can be applied just fine to the new screen config. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 --- Comment #28 from Gauthier --- So this is not only about plugging / unplugging events but also just about open applications (that may have had a large size last time it was opened on a bigger screen). So I reckon plasma has an issue altogether in the way it deals with remembering window sizing and it might be time to think of a new, more consistent, approach. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 --- Comment #27 from Gauthier --- (In reply to Vlad Zahorodnii from comment #26) > Can you check whether the issue is reproducible after making the panel > autohide? I am using auto-hide panels and have window sizing issues. I should say that this is getting worst. I now regularly get windows opening in the size that's bigger than the screen when opening or restoring an application. I have to use Ctrl + F5 a lot these to move and resize those windows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470168] New: highlight remains on title bar context menu items - wayland
https://bugs.kde.org/show_bug.cgi?id=470168 Bug ID: 470168 Summary: highlight remains on title bar context menu items - wayland Classification: Plasma Product: kwin Version: 5.27.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: g.gue...@posteo.net Target Milestone: --- Created attachment 159204 --> https://bugs.kde.org/attachment.cgi?id=159204=edit menu highlight remains When opening menu from title bar and move across the different item, the highlight remain on all item that have been hoovered on, and not only on the one under the mouse cursor. See attached gif. This bug has been around for as long as I've tried the wayland session (at least since plasma 5.25. Works just fine on X11. Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.3-060303-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452118] On X11, all windows moved to be mostly offscreen after disconnecting external monitor
https://bugs.kde.org/show_bug.cgi?id=452118 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #24 from Gauthier --- I also have an issue along similar lines on Wayland (so also posted there bug 468184) When unpluging my external screen from my laptop, many windows (e.g. firefox and gnucash) are not (or not appropriately) resized when moved to the laptop screen. Specifically they are too heigh with the title bar being out of the screen, meaning I cannot move/minmize/maximize/close them, I have to use the shortcut Ctrl + F5 to move them and then resize manually. External screen is a 34" 3440x1440 whereas laptop screen is 14" 1920x1080 (no scaling applied to either). Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.22-060122-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 I have no idea how Kwin handles this currently (and so I don't want to tell dev how to do things) but just in case it's useful, it sounds like a systematic approach when it comes to window size and placement could be: To define window size on any given screen: width ratio = (window width in px / screen width in px) height ratio = (window height in px/ screen height in px) >> those width/height ratios can then be applied to different size screens' >> height / width in plug / unplug events which would conserve the same >> relative window size across any screen (independently of absolute screen >> size or aspect ration). To define windows placement: = horizontal ratio: distance between screen left edge and window horizontal centre / distance between screen left edge and screen horizontal centre (i.e. half screen width) vertical ratio: distance between screen top edge and window vertical centre / distance between screen top edge and screen vertical centre (i.e. half screen height) >> Those ratio can then be applied to the window (horizontal / vertical) centre >> in plug / unplug events so the relative placement is conserved across any >> screens (independently of absolute screen size or aspect ration). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468184] Kwin moving windows and resizing them very poorly to unusable states on multi-monitor setups during unplug events
https://bugs.kde.org/show_bug.cgi?id=468184 --- Comment #3 from Gauthier --- Also wonder if this is related to the bug 452118, at least they both relate to window resizing on plug / unplug. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 468184] Kwin moving windows and resizing them very poorly to unusable states on multi-monitor setups during unplug events
https://bugs.kde.org/show_bug.cgi?id=468184 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #2 from Gauthier --- I also have an issue along those lines. When unpluging my external screen from my laptop, many windows (e.g. firefox and gnucash) are not (or not appropriately) resized when moved to the laptop screen. Specifically they are too heigh with the title bar being out of the screen, meaning I cannot move/minmize/maximize/close them, I have to use the shortcut Ctrl + F5 to move them and then resize manually. External screen is a 34" 3440x1440 whereas laptop screen is 14" 1920x1080 (no scaling applied to either). Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.22-060122-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 I have no idea how Kwin handles this currently (and so I don't want to tell dev how to do things) but just in case it's useful, it sounds like a systematic approach when it comes to window size and placement could be: To define window size on any given screen: width ratio = (window width in px / screen width in px) height ratio = (window height in px/ screen height in px) >> those width/height ratios can then be applied to different size screens' >> height / width in plug / unplug events which would conserve the same >> relative window size across any screen (independently of absolute screen >> size or aspect ration). To define windows placement: = horizontal ratio: distance between screen left edge and window horizontal centre / distance between screen left edge and screen horizontal centre (i.e. half screen width) vertical ratio: distance between screen top edge and window vertical centre / distance between screen top edge and screen vertical centre (i.e. half screen height) >> those ratio can then be applied to the window (horizontal / vertical) centre >> in plug / unplug events so the relative placement is conserved across any >> screens (independently of absolute screen size or aspect ration). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464130] "Show in Activities" option disappears from the titlebar context menu
https://bugs.kde.org/show_bug.cgi?id=464130 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #8 from Gauthier --- Also got hit by this a couple of time after updates (it happened today after update neon packages to Framework 104). Had to reboot twice to see again the "Show in Activities" menu in window title bar (the same menu did not disappear in the task manager). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461907] Incorrect icons for LibreOffice apps under Wayland
https://bugs.kde.org/show_bug.cgi?id=461907 --- Comment #7 from Gauthier --- Same message as above but with more correct English grammar...sorry it's late in my time zone and my brain can't process a foreign language. What do you mean by change its icons? LibreOffice has several components which share the same base and so while different LO apps (writer, calc, etc) can be launched independently and have different icons, when you actually start any of them it calls the overarching LO program and then branch into the separate applications. Under Wayland and Qt only the overarching LO program is detected and so it displays the standard LO icon (the black one) and currently there is no easy way to identify the separate apps. So I agree it is certainly the case that LO could change something in their code to change how they call their apps on launch but this behaviour has been there for ages and was working fine in X11, and there've been a patch in gtk for it to work on Wayland...so it seems more sensible for it to be patch in Qt, especially as I doubt LO is the only app doing it that way. But to be honest you probably know much better than me, I'm only sharing the knowledge I have on this topic. I know it feels ugly and really not the right way of doing things, but what do you think about implementing a hack for it behaves well in plasma? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461907] Incorrect icons for LibreOffice apps under Wayland
https://bugs.kde.org/show_bug.cgi?id=461907 --- Comment #6 from Gauthier --- What do you need by change it's icons? Libre office has several components which share the same base and so while different LO apps (writer, calc, etc) can be launch independently and have different icons, on launch it still calls the overarching LO program and then branch into the separate applications and under Wayland Qt does not have an easy way to identify though separate windows. So I agree it is certainly l the case that LO could change something in there code to change how they call their apps on launch but this behaviour has been their for ages and was working fine in X11, and they've been a patch in gtk for it to work on Wayland...so it seems more sensible for it to be patch in Qt, especially as I doubt LO is the only app doing it that way. But to be honest you probably know much better than me, I'm only sharing the knowledge I have on this topic. I know it feels ugly and really not the right way of doing things, but what do you think about implementing a hack for it behaves well in plasma? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461907] Incorrect icons for LibreOffice apps under Wayland
https://bugs.kde.org/show_bug.cgi?id=461907 --- Comment #4 from Gauthier --- Just a quick precision: for the hack to work it has to be done this way: Open say LibreOffice Calc, right click on title bar > More Actions and then go to: Configure Special Application Settings (and not Window Settings as described in the LO bug report) Then Add Property... > Window Title > there select Substring Match and leave only LibreOffice Calc Then Add Property...> Desktop file name > there select Force and enter libreoffice-calc Et voila :) Thank you Almighty Kwin : -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461907] Incorrect icons for LibreOffice apps under Wayland
https://bugs.kde.org/show_bug.cgi?id=461907 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #3 from Gauthier --- (In reply to Nate Graham from comment #2) > Pretty sure this is a bug in LibreOffice where it inappropriately changes > its window properties after launch, but kwin_wayland can probably support it > like kwin_x11 does. Hi Nate, actually this likely related to a bug in QT not in LO (or at least something QT does not yet support for wayland). See (https://bugs.documentfoundation.org/show_bug.cgi?id=125934) and (https://bugreports.qt.io/browse/QTBUG-77182). I was going to open a new issue with the text below to ask for an enhancement cause a hack has been found but I'm putting it on here and feel free to move it to a new one if you prefer. There is QT bug (https://bugreports.qt.io/browse/QTBUG-77182) opened in 2019 but yet unsolved which prevents to select the correct icon when using LibreOffice under wayland (and which therefore makes it quite annoying to manage several open documents). The issue was also there for GTK but has been fixed. This is well document in the LO bug report (https://bugs.documentfoundation.org/show_bug.cgi?id=125934) and there is nothing to be done on there side, it has to be fixed in QT. However someone found a hack to get the correct behaviour in Plasma using kwin window rules (https://bugs.documentfoundation.org/show_bug.cgi?id=125934#c15). I have tried it and it works great! This greatly improve the experience of using LO in Plasma wayland and so it'd seems worth implementing by default either at the Plasma level (if possible) or distro specific level. I reckon this is also what was hit the bug 443334 but it seems worth opening a new issue regarding implementing this hack as the bug was original opened in relation to flatpack app -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Link files / folders to activity is broken
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #14 from Gauthier --- Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 5.15.0-58-generic (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Link files / folders to activity is broken
https://bugs.kde.org/show_bug.cgi?id=458337 Gauthier changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Gauthier --- The issue is now fixed! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351217] Desktop widgets get absorbed by auto-hide top panels
https://bugs.kde.org/show_bug.cgi?id=351217 --- Comment #16 from Gauthier --- Created attachment 154397 --> https://bugs.kde.org/attachment.cgi?id=154397=edit video of the bug Here a video of the bug. I'd say the behaviour is a little better than what it used to be in that it's not as sensitive as before (I'm now on 5.26.4). On a few instance I was able to bring widgets all the way up without them getting swallowed by the panel. In other cases as soon as I reach the width of the panel (if it was visible) then the widget gets swallowed as if the panel was there even though it's hidden. The attached video is kind of between the two. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Link files / folders to activity is broken
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #12 from Gauthier --- Something went very weird as I also quotes that same bug report in comment 8 and it definitely wasn't that one. So I don't know what's happened but now bug 343110 is a different bug, indeed unrelated. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 447774] File system expose cannot expose certain folders on Android 11
https://bugs.kde.org/show_bug.cgi?id=447774 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #7 from Gauthier --- Any idea how to resolve this? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 424620] external monitors do not appear in settings display configuration
https://bugs.kde.org/show_bug.cgi?id=424620 Gauthier changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #3 from Gauthier --- (In reply to Nate Graham from comment #2) > Thank you for the bug report. Unfortunately we were not able to get to it > yet. Can we ask you to please check if this is still an issue with Plasma > 5.25 or 5.26? > > If it is, please change the status to CONFIRMED when replying. If not, or if > you can't because you no longer use this setup, you can change the status to > RESOLVED WORKSFORME. Thanks a lot! > > --- > > Gauthier, if screens show up in the KCM but aren't *enabled* properly, your > issue is different. oscar6echo's issue is that external screens aren't > appearing in the KCM at all. If you're still having this issue with Plasma > 5.25 or 5.26, please file a new bug report for it. Thanks to you too! Hi Nate, Sorry if I wasn't clear but in my case the screens were also not appearing at all in KCM. This is why trying xrandr was a breakthrough as they did appear there. Then using the arandr gui I could see the screens were not enabled. Once enabled in arandr then they would show up in KCM. So what that meant was that xrandr/arandr was more reliable at *detecting* screens (or kscreen not reliable picking up the info from xrandr). Now, this issue was quite sporadic and not easy to reproduce, and to reply to your question what I can say is that I haven't had it in a while now so I'll mark it as RESOLVED WORKSFORME. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Link files / folders to activity is broken
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #9 from Gauthier --- Is anyone else reproducing this? -- 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 Gauthier changed: What|Removed |Added CC||alexander...@gmail.com --- Comment #33 from Gauthier --- *** Bug 343661 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343661] stops drawing window content after some time, likely SyncObject related
https://bugs.kde.org/show_bug.cgi?id=343661 Gauthier changed: What|Removed |Added Resolution|WORKSFORME |DUPLICATE --- Comment #74 from Gauthier --- *** This bug has been marked as a duplicate of bug 456511 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343661] stops drawing window content after some time, likely SyncObject related
https://bugs.kde.org/show_bug.cgi?id=343661 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #73 from Gauthier --- I am hitting this bug. Seems like it happens mostly in windows that are playing videos / media content (radio, videconference, youtube, etc). Had it both in Firefox and Brave but it is definitely not linked to the as some FF windows work fine while other don't. Also when you click on the window title bar the content refreshes. Restarting compositor solves the problem. Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.15.0-48-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Link files / folders to activity is broken
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #8 from Gauthier --- Possible duplicate of Bug 343110 ? Except I'm pretty sure the issue only started since updated to framework 5.97 and not before (perhaps there was also an update of KDE gears that got pushed at the same time in Neon repo so the issue could possibly come from there too but I can't remember for sure) -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 459673] Error -272 184 064 / 2 020 314 368 unknow
https://bugs.kde.org/show_bug.cgi?id=459673 --- Comment #2 from Jean-Francois GAUTHIER --- Perfect! Thank you for your answer (very fast) Sincerely. Jef. P.S.: Do we have to do something to close the bug report ? Envoyé avec la messagerie sécurisée Proton Mail. --- Original Message --- Le dimanche 25 septembre 2022 à 20:27, Stefano Crocco a écrit : > https://bugs.kde.org/show_bug.cgi?id=459673 > > Stefano Crocco stefano.cro...@alice.it changed: > > > What |Removed |Added > > CC| |stefano.cro...@alice.it > > --- Comment #1 from Stefano Crocco stefano.cro...@alice.it --- > > Do you have this error when starting Konqueror from the quick launcher in the > task bar? Does it happen if you start it from KRunner (Alt+F2) or from > terminal? If you only have it when using the quick launcher, then it's a known > issue. The reason is that the taskbar entry is wrong: it points to the > kfmclient_html.desktop file instead of konqbrowser.desktop. I think that, > unfortunately, this is Plasma issue rather than one of Konqueror itself. I > don't know how the taskbar decides which buttons to add, so I can't fix it. I > tried to contact the Plasma developers about this issue in the past, but with > no results. > > As a workaround, you can go to /usr/share/applications using a graphical file > manager and drag the file konqbrowser.desktop to the quicklaunch area in the > task bar, just besides the broken one: even if the icons are the same, you can > recognize the new one because it has a tool tip. > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 459673] New: Error -272 184 064 / 2 020 314 368 unknow
https://bugs.kde.org/show_bug.cgi?id=459673 Bug ID: 459673 Summary: Error -272 184 064 / 2 020 314 368 unknow Classification: Applications Product: konqueror Version: 21.12.0 Platform: Debian stable OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: general Assignee: konq-b...@kde.org Reporter: jefgauth...@protonmail.com Target Milestone: --- Created attachment 152422 --> https://bugs.kde.org/attachment.cgi?id=152422=edit window Konqueror 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 *** Bonjour Je suis désolé, je ne suis pas un professionnel de l'informatique, pas doué pour les langues et pas un génie. Konqueror est devenu inutilisable après la mise à jour Linux 5.10.0-18 J'ai donc réinstallé le système ce week-end. Maintenant j'ai : Code d'erreur 2 020 314 368 inconnu. Hello I'm sorry, I'm not a computer professional, not good at languages and not a genius. Konqueror became unusable after the Linux 5.10.0-18 update So I reinstalled the system this weekend. Now I have: Error code 2 020 314 368 unknown. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Operating System: Debian GNU/Linux 11 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-18-amd64 OS Type: 64-bit Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz Memory: 31.2 Gio of RAM Graphics Processor: Mesa Intel® UHD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Link files / folders to activity is broken
https://bugs.kde.org/show_bug.cgi?id=458337 Gauthier changed: What|Removed |Added Summary|Folder view did not show|Link files / folders to |files linked with activity |activity is broken |on desktop | -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Folder view did not show files linked with activity on desktop
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #7 from Gauthier --- Just tested in Neon unstable (18/09/22) with Plasma 5.25.80 and Framework 5.98 and the bug is still present. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Folder view did not show files linked with activity on desktop
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #5 from Gauthier --- I have marked this bug as confirmed cause I can reproduce but I am not sure this is the right thing to do or whether these kind of actions should be left to KDE developers. I looked up the bugs.kde doc and this point is not very clear (and so I thought I'd try and if I need some particular privileges it would tell me so). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Folder view did not show files linked with activity on desktop
https://bugs.kde.org/show_bug.cgi?id=458337 Gauthier changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #4 from Gauthier --- I wanted to wait for the update to 5.98 before following this up but I'm afraid to report the issue is still there. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455701] WindowHeap-based effects don't tell you what middle click does or let you configure it
https://bugs.kde.org/show_bug.cgi?id=455701 --- Comment #2 from Gauthier --- (In reply to Gauthier from comment #1) > Yes I think that would be useful. > > Actually the default middle click closing windows with those effects really > makes it problematic if: > 1. you have three finger tap = middle click and > 2. you use the three finger swipe gesture to activate the effect (like for > the overview effect). > > It means that when you activate the effect, if your cursor happen to be on a > window displayed by the effect the window closes automatically! > > I thought it was a bug in Overview effect until I realised the three finger > swipe also activate the three finger tap which triggered the close. Being able to configure middle click action would still be nice but ignore my last comment about the issue I'm facing. This is only the case in X11 using touchegg gesture and not the case with native KDE gestures on wayland. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 428675] Missing keyboard layout button on SDDM login screen
https://bugs.kde.org/show_bug.cgi?id=428675 --- Comment #5 from Gauthier --- (In reply to Nate Graham from comment #4) > Or maybe we could make keyboard layouts global, such that the SDDM user > could see them too. Yes this is probably easier and would be good enough for all use cases I can think of :). The only thing to be careful with with making it global is that if one user has several layouts because they speak several languages, and another user on the same machine doesn't, the latter should not get confused with having several keyboard layouts available in their session since switching layout can get triggered accidentally. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458834] In WindowHeap-based effects, middle click closing windows can cause accidental window closings when combined with three finger tap = middle click and the three fingers swipe gestur
https://bugs.kde.org/show_bug.cgi?id=458834 --- Comment #5 from Gauthier --- (In reply to Nate Graham from comment #4) > Oh that makes perfect sense. Touchegg emulates mouse clicks so it is sure to > trigger this issue. > > That's an unsupported setup and I would recommend using a four-finger > gesture as a workaround. Sadly I still experience issues on wayland so I'm stuck with X11 and cannot use the native gestures with the lovely 1 to 1 effect :( But yes as a workaround I can reassign gestures in touchegg is it uses 4 fingers for WindowHeap-based effects. However, there is still a slight usability issue with any 3 fingers gestures as they still triggers a middle click (i.e. "paste" in most cases and so not as annoying as "close windows" with WindowHeap-based effects). Are you sure this issue is not present on Wayland with the native KDE gestures? I cannot test myself but thought I would flag it up to you anyway for consistency of the newly (and awesome) KDE gesture feature :) To be clear: not an issue for me as I can happily disable three fingers tap = middle click, I don't use it that often. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458834] In WindowHeap-based effects, middle click closing windows can cause accidental window closings when combined with three finger tap = middle click and the three fingers swipe gestur
https://bugs.kde.org/show_bug.cgi?id=458834 --- Comment #3 from Gauthier --- On second thought I realised this might be a rather niche issue since I think default gesture for Overview on Wayland is a 4 finger swipe or pinch and not a three fingers. I use gestures on X11 with touchegg kde which is why it is a three finger swipe for Overview. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 428675] Missing keyboard layout button on SDDM login screen
https://bugs.kde.org/show_bug.cgi?id=428675 --- Comment #3 from Gauthier --- (In reply to Nate Graham from comment #2) > Can reproduce on the actual SDDM login screen. But in test mode > (`sddm-greeter --test-mode --theme ~/kde/usr/share/sddm/themes/breeze/`), I > see the keyboard layout chooser! So there seems to be a problem with > displaying it on the real greeter when run with SDDM's user; perhaps it's a > permissions issue where the data it needs to grab is in the user's home > directory so the greeter's user doesn't see it. Yes it is likely a permission issue since keyboard layout are a user specific setting. It therefore makes sense that it works fine on lock screen (where the user session is already opened) but not on login screen (user session has not yet been opened). We somehow need keyboard layout settings for each user to be accessible by/exposed to SDDM before login and when a user is selected on login screen, the default layout is the one used last in that user session with the possibility to change it using the keyboard layout switch button. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458834] middle click closing windows is an issue if combined with three finger tap = middle click and the three fingers swipe gesture
https://bugs.kde.org/show_bug.cgi?id=458834 --- Comment #2 from Gauthier --- Somewhat related to: https://bugs.kde.org/show_bug.cgi?id=455701 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458834] middle click closing windows is an issue if combined with three finger tap = middle click and the three fingers swipe gesture
https://bugs.kde.org/show_bug.cgi?id=458834 --- Comment #1 from Gauthier --- Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.15.0-46-generic (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 458834] New: middle click closing windows is an issue if combined with three finger tap = middle click and the three fingers swipe gesture
https://bugs.kde.org/show_bug.cgi?id=458834 Bug ID: 458834 Summary: middle click closing windows is an issue if combined with three finger tap = middle click and the three fingers swipe gesture Product: kwin Version: 5.25.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: libinput Assignee: kwin-bugs-n...@kde.org Reporter: g.gue...@posteo.net Target Milestone: --- Hello, Behaviour of the overview effects and other window management effect can get problematic with the default setting: middle click = close if: 1. you have three finger tap = middle click and 2. you use the three finger swipe gesture to activate the effect (like for the overview effect). It means that when you activate the effect, if your cursor happen to be on a window displayed by the effect the window closes automatically! This drove me insane as my windows were disappearing randomly when activating Overview with three finger swipe. I thought it was a bug in Overview effect until: 1. I realised the three finger swipe also triggered the three finger tap which then caused the window to close. 2. This made me learn about middle click = close in KDE (I knew it was a behaviour for tabs in browser but never realised it extended beyond that) 3. It also made me realised I had three fingers tap = middle in touchpad settings -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455701] WindowHeap-based effects don't tell you what middle click does or let you configure it
https://bugs.kde.org/show_bug.cgi?id=455701 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #1 from Gauthier --- Yes I think that would be useful. Actually the default middle click closing windows with those effects really makes it problematic if: 1. you have three finger tap = middle click and 2. you use the three finger swipe gesture to activate the effect (like for the overview effect). It means that when you activate the effect, if your cursor happen to be on a window displayed by the effect the window closes automatically! I thought it was a bug in Overview effect until I realised the three finger swipe also activate the three finger tap which triggered the close. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Folder view did not show files linked with activity on desktop
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #3 from Gauthier --- I wonder if the product should be set as frameworks-kactivities instead of frameworks-plasma? -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 396291] Activities - improve firefox integration
https://bugs.kde.org/show_bug.cgi?id=396291 --- Comment #6 from Gauthier --- (In reply to Gauthier from comment #3) > Is there still a plan to improve firefox integration and behaviours with > activities. > > When restarting the computer (e.g. because of updates) with several > activities and several firefox windows, those windows are restored more or > less randomly to the different activities (for some reason some firefox > windows almost always restore in the right activity but others are just > restored randomly). > > This issue makes rebooting a bit of a pain. I wanted to report that since Plasma 5.25 this behaviour seems much improved and all windows restore properly on reboot. I don;t know if any work was done on the firefox integration side of things or on the activity stack or on plasma but it works :) Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.15.0-46-generic (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455429] kwin sometimes composes windows in the wrong order when using the Slide Back effect
https://bugs.kde.org/show_bug.cgi?id=455429 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Folder view did not show files linked with activity on desktop
https://bugs.kde.org/show_bug.cgi?id=458337 --- Comment #2 from Gauthier --- And so to be clear, the issue is wider than with the folder view widget. In dolphin the files don't show up either (activity folders are empty). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 458337] Folder view did not show files linked with activity on desktop
https://bugs.kde.org/show_bug.cgi?id=458337 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #1 from Gauthier --- I can reproduce this. Since update to 5.97 all activity folders are empty and trying to link file to an activity does nothing. Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.15.0-46-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20KGS02G0K System Version: ThinkPad X1 Carbon 6th -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456873] Unable to use activities since Plasma 5.25.0
https://bugs.kde.org/show_bug.cgi?id=456873 --- Comment #20 from Gauthier --- (In reply to Zamundaaa from comment #17) > Are you using the "slide back" effect? The problem you're describing sounds > like bug 455429 Indeed disabling the slide back effect seems to solve the issue completely for me. Both windows AND menus have been behaving completely normally for the past 24h with 4 my activities running. As much as I like the slide back effect, I have to say it's a relief to be able to work again :) I thought something went very wrong with 5.25 which made me sad cause I was so excited about this release and even after several point release the desktop was properly broken. Hope you'll get to the bottom of the issue with slide back and the compositor when several activities are running. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456873] Unable to use activities since Plasma 5.25.0
https://bugs.kde.org/show_bug.cgi?id=456873 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #15 from Gauthier --- Sadly I can confirm that at least the window/menu/tooltip focus issue does not seem to be fixed in 5.25.4. When using more than one activities, and after a while working with several windows, some windows remain displayed on top (though not actionable) even if another one should be in focus, context menu (like right click) remain hidden/invisible behind the window. You can see it as even context menu on plasma panels (right click on a panel) appear behind the panel instead of on top. It "seems like" things starts going wrong especially after using apps like Firefox and LibreOffice (I'm using the repo versions, not snap or flatpak)but I can't say I'm sure. Things work perfectly fine if using a single activity. The more activity I use the more things go wrong (with only two activity it seems like switching back and forth between the two resolve the issue but with more than two that does not work) Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.15.0-43-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected
https://bugs.kde.org/show_bug.cgi?id=356225 --- Comment #401 from Gauthier --- Also experiencing exactly the same behaviour when trying to use KCM to switch things around as Oded Arbel Comment 399 https://bugs.kde.org/show_bug.cgi?id=356225#c399. The primary screen selected is still the correct one even though the panel have moved to another screen. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected
https://bugs.kde.org/show_bug.cgi?id=356225 --- Comment #400 from Gauthier --- Same here, the problem seemed gone for a while and started again recently (since Plasma 24 I'd say but cannot be 100% sure). I'm using Neon Stable (more config details below). Using a set-up with two external screens and laptop lid closed (so technically 3 screens but one of them is usually turned off). i also use 4 different activities. On my default activity panels and widgets which are normally on my primary screen are moved to the other external screen. The panels which are normally in the other external screen remain there and are not moved. On other activities, only the primary screen panels seem to move while the other desktop widgets (e.g. notes / folder view) remain on the correct screen (those who were on the primary screen do remain there). I also notice that when the panel issue happens, other configs also seem to be off, for example the wallpaper on one screen and on one activity goes back to the default plasma one so I have to manually change it back to a custom image. Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.13.0-44-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 376065] auto-hide panel flickers
https://bugs.kde.org/show_bug.cgi?id=376065 --- Comment #17 from Gauthier --- Mesa 21.2.6 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453465] Some firefox windows disappear on a session restore on wayland
https://bugs.kde.org/show_bug.cgi?id=453465 --- Comment #2 from Gauthier --- (In reply to Ömer Fadıl USTA from comment #1) > is this bug exist even if you run firefox on wayland support ? ( i mean > normally firefox full wayland support only enabled when you run firefox with > MOZ_ENABLE_WAYLAND=1 system variable . > > Add this lines at the end of your .bashrc file and after a relogin/reboot > could you check if that bug exist or not. > > if [ "$XDG_SESSION_TYPE" == "wayland" ]; then > export MOZ_ENABLE_WAYLAND=1 > fi Hi, sorry it took me a while to try this. Sadly it did not work, some windows were still missing on restore in Wayland. Moreover, ever since I did that, when I log back to X11 from Wayland firefox hangs on restore and I loose everything. I did the test twice and both times I could not recover any of my firefox windows. This was a bit of a bummer when it happened first have I to say as I lost a lot of pages! But hey the price to pay when trying things out without saving I suppose. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 376065] auto-hide panel flickers
https://bugs.kde.org/show_bug.cgi?id=376065 --- Comment #16 from Gauthier --- Created attachment 149311 --> https://bugs.kde.org/attachment.cgi?id=149311=edit bottom edge flickering Noticing a light flickering at the bottom edge of the panel during the hide/unhide animation. See the attached GIF. I believe this is the flickering issues reported here: https://youtu.be/lm0LIy0yv5Y?t=107 I tried on both X11 and wayland with same result. Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.13.0-44-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453465] New: Some firefox windows disappear on a session restore on wayland
https://bugs.kde.org/show_bug.cgi?id=453465 Bug ID: 453465 Summary: Some firefox windows disappear on a session restore on wayland Product: kwin Version: 5.24.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: g.gue...@posteo.net Target Milestone: --- SUMMARY If rebooting or logout / login with several firefox windows opened on several screens and desktops, some firefox windows disappear on a session restore on wayland, whereas it works fine on X11 (in fact the windows have gone missing on wayland even reload fine when re-login back into X11). I only use several windows for firefox, so this is the only app I could see the bug, but it might not be limited to it and it is possibly a wider problem. STEPS TO REPRODUCE 1. Open several firefox windows on several screens and desktops on X11 2. Logout 3. Login on Wayland 4. Logout again 5. Login again (maybe need to repeat 4. and 5 several times to see the bug) OBSERVED RESULT On the first login on Wayland, everything is restored properly, all the firefox windows are restored. But then on subsequent logins, some of them are missing. They are not anywhere on any screens or desktops (out of 7 firefox windows, only 2-3 are restored). When login back into X11, everything restores fine. This makes me think wayland is just not displaying the windows but they musty be somewhat still opened/running for them to restore when login back into X11. EXPECTED RESULT Everything should restore properly on wayland every time, as it does on X11. Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.13.0-40-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 443334] Some flatpak programs don't show icons in taskbar
https://bugs.kde.org/show_bug.cgi?id=443334 --- Comment #12 from Gauthier --- Actually for LO at least the issue is reported here but apparently needs a fix in Qt and a fix in LO for it to be resolved. https://bugs.documentfoundation.org/show_bug.cgi?id=125934 Comment 15 of this post shows a workaround using window rules: By right clicking on the title bar > more actions there is the possibility to configure special window settings. I have added the option Window Title, which should partly be equal to "Libreoffice Writer", then I enforce that with another option that the desktop filename "libreoffice-writer" is used. I repeat this for the other applications and now I have separate icons on my wayland taskbar for each libreoffice app. Also it may be wider than Plasma / Qt since some issues on Gnome seem to be here too (might be a different problem though): https://ask.fedoraproject.org/t/broken-icon-for-libreoffice-writer-in-wayland/4987 Side track note: the issue mentioned about dropdown menu in Plasma wayland will be fixed in LO 7.3.3 which will make LO actually usable on wayland :) (I use many spreadsheet with dropdown cells): https://bugs.documentfoundation.org/show_bug.cgi?id=144585 -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 443334] Some flatpak programs don't show icons in taskbar
https://bugs.kde.org/show_bug.cgi?id=443334 --- Comment #11 from Gauthier --- Sorry the unclarity of my previous comment. What I meant was I installed Fedora 35 KDE edition in a VM (QEMU-KVM), and the Libreoffice icons in the task manager do not work properly on wayland. When you launch any of the LibreOffice app, you get the generic black icon instead of say the icon of the specific app (writer, calc, etc.). (ignore what I said about drop down menu being broken, I'll file another bug) -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 443334] Some flatpak programs don't show icons in taskbar
https://bugs.kde.org/show_bug.cgi?id=443334 --- Comment #10 from Gauthier --- (In reply to Nate Graham from comment #8) > On Neon, I think it's expected for apps installed via CLI since those are no > explicitly longer supported. Moving to Neon for further triage. Just read your comment so checked in Fedora 35 in a VM and I can reproduce this (at least on the live CD), so may not be neon specific. Also all drop down menus seem broken (including drop down menu in cells). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351217] Desktop widgets get absorbed by auto-hide top panels
https://bugs.kde.org/show_bug.cgi?id=351217 --- Comment #14 from Gauthier --- This is still present in Plasma 5.24 :( -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 443334] Some flatpak programs don't show icons in taskbar
https://bugs.kde.org/show_bug.cgi?id=443334 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #9 from Gauthier --- I can confirm this bug on Neon with LibreOffice. On Wayland, a generic icon appears in task manager (I use icon-only task manager and have pinned icons for LO writer and calc but as soon as I launch either apps an extra generic black libreoffice icon appears and the pinned icon don't become active). I have Libreoffice installed and updated via discover from the libreoffice stable ppa repository and not as Flatpack. So I agree that this has probably nothing to do with Flatpack. On X11 it works just fine. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 399523] Cannot move mouse cursor from edge of display with kdeconnect remote control other than primary display when more than one monitors are connected
https://bugs.kde.org/show_bug.cgi?id=399523 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #9 from Gauthier --- This bug is still present with KDEConnect 21.12.0 (on desktop) / 1.18.1 (Android) Operating System: KDE neon 5.23 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.3 Kernel Version: 5.11.9-051109-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 424620] external monitors do not appear in settings display configuration
https://bugs.kde.org/show_bug.cgi?id=424620 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #1 from Gauthier --- Issue with Kscreen not enabling outputs properly when a screen is plugged...while arandr does it just fine. I've also had erratic behaviour with Kscreen and plugging in external screens. This mostly affects screen plugged into the HDMI port on my laptop (a Lenvovo X1 Carbon 6th Gen - I know this laptop had issues witht he HDMI port but this has been corrected and is not the issue in that case - see below). Sometimes it works completely fine and then it stops. Usually it starts working if in addition to the plugging in a screen on the HDMI I also plug in a screen on the display port (suddenly everything comes on). Moreover, sometimes Kscreen detect that the screen is plugged in / unplugged (it says t detect the configuration has changed) but still no new screen appears. But today I had a BREAKTHROUGH :) The screen was not detected but then I looked at xrandr --verbose and saw that xrandr did detect the screen just fine (listing all the right resolutions etc.) So I installed arandr (another GUI for xrandr). There I still could see only my laptop screen, but the going to menu > Outputs the HDMI port was not greyed out and I could tick "enable", then the screen appeared in both arandr and Kscreen. So while in theory Kscreen also has the option to enable an "output" which it calls enabling a "screen", it does not seem to work quite as expected in some cases. It is to note that anyway the screen was not enabled when plugged in and even with arandr it required an extra step to enabling it. Happy to paste some output that might be useful to debug this. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 443822] Activities, widgets and wallpaper removed on upgrade to Plasma 5.23
https://bugs.kde.org/show_bug.cgi?id=443822 --- Comment #1 from Gauthier --- Just to add to this. Previous activities (before the upgrade) and note widgets were still present in plasma-org.kde.plasma.desktop-appletsrc but 2 completely new activities were also created in that file (with same ID as previous ones but with different containment numbers) and these were the ones used by plasmashell. This is why all configs were reverted and it looked like I had two completely new activities. I had to create new notes widgets on the desktop, then replace the note widget IDs with the previous ones and restart plasmashell to get the notes back. I also had to change the other settings, wallpaper, etc. manually. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #16 from Gauthier --- (In reply to Oded Arbel from comment #15) > (In reply to Gauthier from comment #14) > > > The lack of keyboard shortcut to > > > > "move a window to activity X" > > > > > as been pointed out in Bug 411688 > > IMO, the ability of the user to assign a custom keyboard shortcut to a "move > to activity" operation does not solve the inaccessibility of the taskbar to > keyboard operation. Please don't conflate "being able to assign keyboard > shortcuts" with "being able to use the keyboard to select and activate > things". Yes you are right, I meant that at least it provides a way for those who use the keyboard to move an activity :) > My point is that I understand that some people can make a good use the > taskbar with a mouse, but as someone who prefers to use the keyboard - the > taskbar is completely inaccessible to me and I use it as visual reference > only. As such, adding capabilities to the taskbar is *not* a good > replacement to missing window operations menu functionality (the window > operations menu is *very* keyboard accessible). I fully agree that it is not a replacement but the person who worked on this, also tried to address the kwin/title bar menu, they just didn't know how to do it. What I meant is that the process has started trying to solve the issue with "Show in activities" menu(s) as a whole. But yes the kwin / title bar is still not solved needs addressing. > (In reply to Gauthier from comment #13) > > Would it be possible to only keep the tick boxes, but ensure that the menu > > stays open AND changes are only applied after either: the mouse moves out of > > the menu (if using the mouse), or the ESC key is pressed (if navigating > > using the keyboard)? > > Tying "apply operations" to mouse movement is a problematic proposition - > some pointing devices (and some people) are very inaccurate and having a > wrong move trigger an operation that takes significant effort to revert (its > not just CTRL+Z), will be very frustrating to the user. ESC would work, but > you do want additionally something that is both discoverable and can be > operated by a mouse. While I fully agree with you in principle, and I think you're making very good points regarding accessibility. However in that case I'm not sure it applies since currently the mouse action (a click on a tick box) triggers the apply operation straight away as the menu closes and the change is applied. What I propose is actually a "delay" of the apply operation, until a further mouse action is done, i.e. moving the cursor outside the menu area. What do you think? > I thought about this a bit and in the context of a menu we are precluded > from a lot of guided interaction we can do with dialogs: you can't have > explanatory text and you can't have an "apply" button. There are some use > cases that are hard to do "properly" in a menu - so can we just stop > pretending to care about them? > > I want to support the following use cases: > > 1. Show the window in all activities. > 2. Add the window to this one additional activity. > 3. Move the window to this one other activity. > > I don't want to support the following use cases as I think they are niche, > can be achieved with a combination of actions (1), (2) and (3) (albeit > slower, as the menu would need to be reopened), and not worth sacrificing > the usability of (1), (2) and (3) for: > > 4. Add the window to 2 or more additional activities. > 5. Move the window to 2 or more other activities. > > (all the above also applies to virtual desktops, as appropriate, as it is > basically the same thing on a different axis). > > What do you think? Do you often find yourself moving a window from the > current activity to 2 other activities (as described in comment #2)? I would very much agree that we should prioritise the use cases 1. 2. and 3. I would think that even 1. and 3. would be the ultimate priority. Unless you still think it is a problem, it does feel like my above proposition (apply changes on moving mouse outside the menu / press ESC key) would solve most use cases you've outlined, no? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules
https://bugs.kde.org/show_bug.cgi?id=361708 --- Comment #8 from Gauthier --- Using a Lenovo ThinkPad X1 Carbon 6th Operating System: KDE neon 5.23 KDE Plasma Version: 5.23.0 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-37-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Upower 0.99.11 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules
https://bugs.kde.org/show_bug.cgi?id=361708 --- Comment #7 from Gauthier --- Created attachment 142583 --> https://bugs.kde.org/attachment.cgi?id=142583=edit Showing ac plugged even if unplugged -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules
https://bugs.kde.org/show_bug.cgi?id=361708 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #6 from Gauthier --- Sorry if there is a better place to report this but cold not find any more recent bug report on this issue. Sometimes my battery indicator in sys tray still says "plugged in" (and the icon has the power plug in it) even though I have unplugged the power adaptor . When hovering the mouse over it, it says "Plugged in but still discharging". When clicking on it, the indicator says, "discharging", and the battery icon inside the popup window is the correct one (i.e. without the power plug in it). See screenshot attached. The issue is that he system does not go to sleep any more. For info, I have rule to stop charging at 85% and start at 45%. I "think" the issue happens after a wake up from sleep but I'm not sure and it is a bit random. Plugging back the power adaptor and unplugging it does not solve the issue. The only thing that seem to solve it is rebooting (then it works fine). I saw the issue being reported here too: - https://www.linuxquestions.org/questions/slackware-14/plasma-5-systray-battery-monitor-incorrectly-says-plugged-in-4175671626/ - https://forum.manjaro.org/t/battery-icon-is-constantly-in-charging-mode/27605 - https://bbs.archlinux.org/viewtopic.php?id=236409 (in here it says it is a bug in upower, but I cannot test that as I cannot downgrade to the version proposed in the article - I run upower version 0.99.11) - https://www.reddit.com/r/kde/comments/mxampb/having_a_few_problems_with_kde/ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #14 from Gauthier --- I meant to write > The lack of keyboard shortcut to "move a window to activity X" > as been pointed out in Bug 411688 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #13 from Gauthier --- (In reply to Oded Arbel from comment #11) > (In reply to Gauthier from comment #7) > > Should it get marked as resolved? > > Looking at the MR that was merged, it adds the workaround to the task bar > context menu. This issue is about the window operations menu, so the MR does > not solve this issue in that it doesn't fix the window operations menu. You are right that technically this bug is about the menu in the title bar so it is not addressed by this new commit. Though the problematic behaviour is the same in both the title bar (kwin) menu and the task manager menu so it is an attempt to start address the issue as a whole. However, I agree with you that the proposed approach in the commit may not be the best (see below in response to your comment). > I'm not sure what is the use case for the task bar right click menu as I > almost > never use it and there is no keyboard shortcut to get to it. IMHO the window > operations menu should be the target for any improved behavior its better > accessible by both keyboard and mouse (Fitz law). I agree with ederad, it is a common use case, it is nice not to have to bring the window into focus to move them. I use that a lot. The lack of keyboard shortcut to "move to an activity" as been pointed out in Bug 411688 > > (In reply to Gauthier from comment #8) > > @Oded Have there been any progress on your MR for VDs, and if so, does it > > seem likely to also work for activities? > > I did not move forward with my work on the checkboxed window operations > submenus (I'm treating desktops and activities the same for this). I didn't > have a lot of time for that, but more than that I'm very confused about the > situation - in Kwin Wayland there is a workaround for the desktops menu that > is very similar in behavior to > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231, but not > identical, and of course that it wasn't implemented for activities. > > I think before any additional work is done, there should be some effort to > understand what is the UX that we are aiming for and how it should apply to > all relevant use cases - wayland, x11, window operations menu, plasma shell > task bar menus, activities, desktops, whatever else is relevant. Currently > there are too many different behaviors for things that should basically be > the same. I'm not sure how/where/when/with who to start such a discussion. I agree with you tat this whole things needs tidying up and made consistent across X11/Wayland, Activities, VDs, kwin menu and task manager menu. Not sure where to start either. > On that note, I personally dislike the "dual control" UX that is offered in > Wayland windows operation menu and the above mentioned MR: on my systems I > have few activities (2 or 3 normally) and many virtual desktops (6 or 8) and > while the "checkbox + move to items" is kind of manageable in the activities > selection, it is almost unusable for virtual desktops (the wayland window > operations desktops menu takes more than half the height of my screen now) - > it actually takes noticeable time and thought to locate the menu option I > need in order to just move this one window to desktop 4. I believe we can do > better, and would like to have a discussion about that. I think you are right here. When I looked at the commit I thought it would only work well if one has only 2/3 activities, but with many, the double of menu items would get long and cumbersome. Would it be possible to only keep the tick boxes, but ensure that the menu stays open AND changes are only applied after either: the mouse moves out of the menu (if using the mouse), or the ESC key is pressed (if navigating using the keyboard)? -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 443822] New: Activities, widgets and wallpaper removed on upgrade to Plasma 5.23
https://bugs.kde.org/show_bug.cgi?id=443822 Bug ID: 443822 Summary: Activities, widgets and wallpaper removed on upgrade to Plasma 5.23 Product: neon Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: neon-b...@kde.org Reporter: g.gue...@posteo.net CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org Target Milestone: --- SUMMARY I use two activity, the default one with the default wallpaper and some note widgets and another one with a custom wallpaper and also some note widgets. On reboot after upgrading to Plasma 5.23, I had no more activities listed (literary none - not even "default" - in the activity switcher), no more "Show in activities" menus, etc. I also lost all my note widgets. On next reboot activities were back :) but note widgets were still gone on both activities and the wallpaper on both activities have been change to the new Plasma 5.23 (I know this is normal for the default one, but it should not be the case for the other one). Effectively it felt like they were like two brand new activities (only their names had been retained). I know how to recover my notes so not a huge problem but I thought I should still report the behaviour as it does not seem great. Also it may or may not be Neon specific, I cannot test that right now. Operating System: KDE neon 5.23 KDE Plasma Version: 5.23.0 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-37-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 Gauthier changed: What|Removed |Added CC||dhar...@10100.to --- Comment #10 from Gauthier --- *** Bug 435892 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435892] Keep activities selector persistent in window menu
https://bugs.kde.org/show_bug.cgi?id=435892 Gauthier changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Gauthier --- *** This bug has been marked as a duplicate of bug 430440 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435892] Keep activities selector persistent in window menu
https://bugs.kde.org/show_bug.cgi?id=435892 --- Comment #4 from Gauthier --- This has now been partially solved with : https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 Scheduled for Plasma 5.24 (sad it got missed for 5.23). However the issue is not solved when one wants to select more than one activity. I'll make this a duplicate of Bug 430440 which original talks about the same use case as this one but then highlight the wider issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 Gauthier changed: What|Removed |Added CC||christianlu...@web.de --- Comment #9 from Gauthier --- *** Bug 434621 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434621] Selection of activities over window menu closes upon change
https://bugs.kde.org/show_bug.cgi?id=434621 Gauthier changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #2 from Gauthier --- *** This bug has been marked as a duplicate of bug 430440 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434621] Selection of activities over window menu closes upon change
https://bugs.kde.org/show_bug.cgi?id=434621 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #1 from Gauthier --- This specific use case is now solved with : https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 Scheduled for Plasma 5.24 (sad it got missed for 5.23). However the issue is not solved when one wants to select more than one activity. I'll make this a duplicate of Bug 430440 which original talks about the same use case as this one but then highlight the wider issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #8 from Gauthier --- Actually I hadn't read all comments, the new menu: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 solves it to move an activity to only one other one but does not solve the case of ticking several ones. @Oded Have there been any progress on your MR for VDs, and if so, does it seem likely to also work for activities? Since the work has started with the MR linked above to solve one use case (i.e. to move an activity), it would be great to solve this bug for selecting several activities and get all of that "Show in activities" function consistent for Plasma 5.24 (and ideally across both kwin and task manager menus). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 411688] Global shortcut to assign window/app to another activity
https://bugs.kde.org/show_bug.cgi?id=411688 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #2 from Gauthier --- That would be a good add indeed for Plasma 5.24! Especially as the new menu: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 is not yet working for kwin. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 419225] Consistency: Show in Activities Menu
https://bugs.kde.org/show_bug.cgi?id=419225 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #1 from Gauthier --- True that! Not a big deal but might be worth addressing along with the need for the feature parity on the "Show in activities" for kwin arising from: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #7 from Gauthier --- This is now solved with : https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 Scheduled for Plasma 5.24 (sad it got missed for 5.23). Should it get marked as resolved? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 Gauthier changed: What|Removed |Added CC||bastimeyer...@gmail.com --- Comment #6 from Gauthier --- *** Bug 437826 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437826] Moving a window to another activity via the task manager's context menu requires clicking activity twice
https://bugs.kde.org/show_bug.cgi?id=437826 Gauthier changed: What|Removed |Added Resolution|--- |DUPLICATE Status|CONFIRMED |RESOLVED --- Comment #5 from Gauthier --- *** This bug has been marked as a duplicate of bug 430440 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437826] Moving a window to another activity via the task manager's context menu requires clicking activity twice
https://bugs.kde.org/show_bug.cgi?id=437826 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #4 from Gauthier --- This is now solved with : https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231 Scheduled for Plasma 5.24 (sad it got missed for 5.23). -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 340137] Implement support for window groups (window tabs) in Breeze
https://bugs.kde.org/show_bug.cgi?id=340137 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #11 from Gauthier --- (In reply to Martin Flöser from comment #6) > yes, sure. But it needs someone to step up to do it (I unfortunately are > currently focused on Wayland). I guess no one has been stepping up for this? Or is there now any plans to bring it back? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343690] Missing windows tabbing
https://bugs.kde.org/show_bug.cgi?id=343690 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #29 from Gauthier --- Hello, For a while this feature was highlighted as missing in in the errata of new plasma release but now (for a long while in fact) it's not being shown at all. This makes me think it is now abandoned...am I right to think that there now no plans from the core plasma dev to bring it back? If so, is there any clues at to what makes it hard to port/implement from Plasma 4 to Plasma 5 so maybe someone else can have a go at the task (as this was such a brilliant feature)? Many thanks -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435892] Keep activities selector persistent in window menu
https://bugs.kde.org/show_bug.cgi?id=435892 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #3 from Gauthier --- I can confirm this behaviour and it is problematic as moving a window from one activity to another one always requires opening the menu twice. (And since gtk apps, firefox, LO, etc. still don't remember activities on start-up, we need to that often) If the behaviour is changed it would be great to change both in the activity selector menu opening from the windows title bar and from the task manager. Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Kernel Version: 5.11.8-051108-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434711] Feature request on Wayland: per screen widget layout and panel management settings to replace primary display
https://bugs.kde.org/show_bug.cgi?id=434711 --- Comment #2 from Gauthier --- (In reply to Nate Graham from comment #1) > One correction: Plasma devs didn't remove the concept, but rather it's not > implemented at all on Wayland. Yes you're right. Also I didn't mean any value judgement on this. I love plasma devs :). I suppose what I meant was that from what I read elsewhere, it was a decision not to implement it because it was "confusing" and "only dealt with panel placement". See first comment on this thread: https://www.reddit.com/r/kde/comments/ae8czw/plasma_wayland_works_great_but_how_do_i_set_a/ > It sounds like you are basically looking for a way to clone one screen's > layout onto another one or exchange the two, and have previously been using > the X11 primary display feature to approximate the feature. Would that be > accurate? I suppose what I meant here is that what the Primary Display feature actually does is cloning (actually switching) one screen widget (including panels) layout into another screen, but "only" does it for one screen layout. So the proposal is, if the feature is to come back, maybe a cool thing would be to be able to do it for multiple widget layouts (if say a user has/wants different widgets on different screens), which would make switching between different screen arrangements very versatile and convenient. And then create a separate section / title in KCM to manage this which describes what the feature is actually about (panel and widget layout) so it stops being confused with the Active Screen thingy. But if this is too complicated, just bringing back Primary Screen would be fine for many use cases. Maybe just with renaming the Primary Screen tick box in Kscreen settings as something like "Primary widget layout" (I'm not great for finding sexy feature title, am I). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433074] Notifications and panels appear on wrong screen
https://bugs.kde.org/show_bug.cgi?id=433074 --- Comment #10 from Gauthier --- Sorry don't mean to spam you all by sending gazillion messages, but while I've got my head into this, I've made proposal for a more advanced "per screen widget and panel management settings" if Primary Display function is going to disappear (still it feels that at least for now keeping what Primary Display does would just be easier). https://bugs.kde.org/show_bug.cgi?id=434711 I'll shut up now :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434711] New: Feature request on Wayland: per screen widget layout and panel management settings to replace primary display
https://bugs.kde.org/show_bug.cgi?id=434711 Bug ID: 434711 Summary: Feature request on Wayland: per screen widget layout and panel management settings to replace primary display Product: plasmashell Version: 5.21.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Multi-screen support Assignee: aleix...@kde.org Reporter: g.gue...@posteo.net CC: plasma-b...@kde.org Target Milestone: 1.0 On X11, a user can set a primary display, arrange panels and widgets on that display in any way they like and can then move this arrangement to another screen by switching primary display. It seems a shame for this not to be possible on Wayland but apparently users were confused by the idea of Primary Display vs Active Display (to do with windows placement) which pushed Plasma devs to remove the concept of Primary Display on Wayland. If Plasma Devs want to remove the concept of primary display in Wayland, maybe it could be replaced by a more generalised version of the idea of "per screen widgets and panel settings" currently provided by the concept of primary display on X11. By more generalised I mean: - The user set panels and widgets on any screen and save that config. For e.g. KCM has a new config sub-section under Display called "Panels and Widgets Layout", where people can save the widget config by selecting "save widget config present on Screen X" (where Screen X is a drop down) and give it a name (e.g. Primary). From that point on Plasma save any changes happening to the widget config on that screen and record the state of the config when a screen is unplugged or that particular config is not assigned to any screen. When no config is assigned, then we get the usual empty wallpaper. - The user can then apply a saved widget config on an screen by selecting..."apply widget config NameX on screen X" People could then save widget config on different screen, switch config between screens or assign any of them to any new screen. This would be a more involved widget management function and no idea how complicated it would be to implement something like this but here is an idea if useful anyway :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433074] Notifications and panels appear on wrong screen
https://bugs.kde.org/show_bug.cgi?id=433074 --- Comment #9 from Gauthier --- And that one: https://bugs.kde.org/show_bug.cgi?id=432349 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433074] Notifications and panels appear on wrong screen
https://bugs.kde.org/show_bug.cgi?id=433074 --- Comment #8 from Gauthier --- Reddit reference: https://www.reddit.com/r/kde/comments/ae8czw/plasma_wayland_works_great_but_how_do_i_set_a/ My config: Operating System: KDE neon 5.21 KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.10.17-051017-generic OS Type: 64-bit Graphics Platform: Wayland / X11 Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Possible duplicates / related: https://bugs.kde.org/show_bug.cgi?id=433840 https://bugs.kde.org/show_bug.cgi?id=425798 https://bugs.kde.org/show_bug.cgi?id=411681 https://bugs.kde.org/show_bug.cgi?id=429657 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433074] Notifications and panels appear on wrong screen
https://bugs.kde.org/show_bug.cgi?id=433074 --- Comment #7 from Gauthier --- (In reply to Nicolas Fella from comment #1) > Wayland has no concept of a "primary screen". > > What is it that you want to achieve? Happy to be told if there is now another way to move all panel and widgets into another screen in a few clicks. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433074] Notifications and panels appear on wrong screen
https://bugs.kde.org/show_bug.cgi?id=433074 Gauthier changed: What|Removed |Added CC||g.gue...@posteo.net --- Comment #6 from Gauthier --- I experience the same issue. I have one large external monitor + laptop screen. On X11 the primary display is my external monitor where I have two panels and 4 stcky notes (the desktop is in "Desktop" mode). When login into Wayland all panels *and widgets* appear on the "wrong" screen (i.e. on the laptop screen). There is no way to move it all back to the other screen easily. I can move it all back manually, through it is tedious, then everything works alright. But then, either: - if I unplug my external screen: I got the panels back but no widgets (sticky notes are gone, well in fact they stay in the "2nd screen"). - if I go back to X11, everything is moved in the non primary screen (and if no other screen is plugged in, it looks like it's all gone, it's only until I plug another screen that can see the widget and move them back manually to the primary screen) I read on a reddit thread from a KDE contributor that the reasoning behind removing the concept of primary screen on wayland is that it only deals with where panels are positioned but that it confused people because people thought it was about window placement. So the concept was removed altogether. I don't know if this is still where thoughts are but this "seems" wrong to me in two ways (IMHO): - Primary screen deals with panels AND widgets. It basically allows a per-screen set-up and to switch that set-up between screens in tow clicks (tick primary screen, press apply). Genius if you ask me! Not having that makes very tedious to re-setup everything each time you have a new screen config (e.g. plug into an unknown screen, add a 3rd screen, etc.) - That it is confused with the Active Display should be addressed with better UI, not by removing an entirely different function that happens to have a similar sounding name. Now I admit that unless specified otherwise in the Window Management settings, it seems to make sense for windows to open on the primary screen (i.e. for the Active Display setting to follow the Primary Screen setting by default, whereas the behaviour currently is a bit erratic). This would which partially solved that issue and if then users want a more elaborated behaviour, they look for it in Window Management settings, which seems consistant. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434658] Changing animation speed breaks auto-hide panel animation until reboot (wayland).
https://bugs.kde.org/show_bug.cgi?id=434658 Gauthier changed: What|Removed |Added Summary|Changing animation speed|Changing animation speed |breaks auto-hide panel |breaks auto-hide panel |animation until reboot. |animation until reboot ||(wayland). --- Comment #1 from Gauthier --- Sorry forgot to say, I'm on wayland, and here are the system info: Operating System: KDE neon 5.21 KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 Kernel Version: 5.10.17-051017-generic OS Type: 64-bit Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
