[frameworks-qqc2-desktop-style] [Bug 434884] Scroll bar arrow buttons does not highlight on hover in QQC2 apps
https://bugs.kde.org/show_bug.cgi?id=434884 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #4 from Paul McAuley --- This fix isn't quite the same. On normal Qt widget apps the scrollbar highlights when that scrollarea is active, not just on hover. In QCC2 the scollbar only highlights on hover. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-qqc2-desktop-style] [Bug 483794] New: Scrollbar arrows scroll to the extreme top and bottom rather than just a small amount in QQC2 apps
https://bugs.kde.org/show_bug.cgi?id=483794 Bug ID: 483794 Summary: Scrollbar arrows scroll to the extreme top and bottom rather than just a small amount in QQC2 apps Classification: Frameworks and Libraries Product: frameworks-qqc2-desktop-style Version: 6.0.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: k...@paulmcauley.com CC: ahiems...@heimr.nl, k...@davidedmundson.co.uk, noaha...@gmail.com, notm...@gmail.com Target Milestone: --- STEPS TO REPRODUCE 1. Enable scrollbar arrows in Breeze application style 2. Open Discover or System Settings 3. Click on the scrollbar arrow OBSERVED RESULT The page scrolls to the extreme bottom or top EXPECTED RESULT The page should only scroll a small increment SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.0-63.fc40.1.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: Google Product Name: Pantheon System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456052] Background blur apply blur to titlebar component
https://bugs.kde.org/show_bug.cgi?id=456052 --- Comment #4 from Paul McAuley --- The lack of specific region parameter in KWindowEffects::enableBlurBehind also prevents Konsole from blurring at all when the application style also blurs a region. E.g.: https://github.com/paulmcauley/klassy/issues/114 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482294] KWindowEffects::enableBlurBehind() region is no longer relative to the top-left corner of the client area on Plasma6 Wayland
https://bugs.kde.org/show_bug.cgi?id=482294 --- Comment #3 from Paul McAuley --- (you should also disable any spacer buttons in the Window Decoration settings before installing Klassy otherwise it will crash - I have not yet updated it to deal with this new feature) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482294] KWindowEffects::enableBlurBehind() region is no longer relative to the top-left corner of the client area on Plasma6 Wayland
https://bugs.kde.org/show_bug.cgi?id=482294 Paul McAuley changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Paul McAuley --- (In reply to Vlad Zahorodnii from comment #1) > Can you provide a demo application showing the issue please? Sure. First install the latest Klassy plasma6.0 branch as follows: git clone https://github.com/paulmcauley/klassy.git cd klassy git checkout plasma6.0 ./install.sh Then enable both the Klassy window decoration and Klassy application style in system settings. Set your colour scheme to one which contains header colours, such as Breeze Light or Breeze Dark. Then go to the Window Decoration settings, click on the pencil icon when hovered over Klassy and then click "Presets..." button at the top-right. Load the "Glassy Klassy" preset. If you open an application with headers such as the latest Dolphin (Qt5), Kate (Qt5), Konsole (Qt6) or Kmail (Qt6) you will see the issue with blur missing halfway down the header, as in the screenshot I attached previously. I have also just made some changes, so the line which contains the call to KWindowEffects::enableBlurBehind() is now at: https://github.com/paulmcauley/klassy/blob/120332dfd4dd830359dd170020adcd5fd57ce229/kstyle/breezestyle.cpp#L1726 You can also install from the Plasma5.27 branch on Plasma 5.27 to see the headers showing blur as they should be. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482294] New: KWindowEffects::enableBlurBehind() region is no longer relative to the top-left corner of the client area on Plasma6 Wayland
https://bugs.kde.org/show_bug.cgi?id=482294 Bug ID: 482294 Summary: KWindowEffects::enableBlurBehind() region is no longer relative to the top-left corner of the client area on Plasma6 Wayland Classification: Plasma Product: kwin Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 166346 --> https://bugs.kde.org/attachment.cgi?id=166346=edit Illustration on Plasma6 of BlurBehind not being applied to the client top-left (scaling 100%) I am in the middle of porting an Application Style from Plasma 5 to Plasma 6 (https://github.com/paulmcauley/klassy/tree/plasma6.0). In Plasma 5 my Application Style could blur the tools area as in the screenshot at https://github.com/paulmcauley/klassy/raw/plasma6.0/screenshots/button_icon_menu.png?raw=true . This blur is applied by using the following function: KWindowEffects::enableBlurBehind(mw->windowHandle(), true, rect); ( https://github.com/paulmcauley/klassy/blob/861b93c30b6a0457427c488805a78f0ac770103d/kstyle/breezestyle.cpp#L1436 ) Note that I need to specify the rect parameter as a QRegion, which the API documentation states "The region is relative to the top-left corner of the client area". ( https://api.kde.org/frameworks/kwindowsystem/html/namespaceKWindowEffects.html#a23a8c1dd33fb9a4a9fa0bbde4ae830cb ) My problem is that on Plasma 6 Wayland the blurred region is not in the correct position, and looks like the attached screenshot. Looking at debug output, the height of the region is specified in this instance as 46 pixels, but the actual blurred height in the client is smaller. The unblurred gap is equivalent to the titlebar height, with the blurred region now 46 pixels from the top of the decoration, suggesting that the BlurBehind effect region is now relative to the decoration top-left rather than the client top-left. (Note that on Plasma 6 X11 this problem does not occur, it only is a problem on Wayland). Note also that this bug also applies to the style of both Qt5 apps (linked to KF5 version of KWindowSystem as in the Dolphin screenshot) and Qt6 apps (linked to KF6 version of KWindowSystem) hence I suspect it may be a wider problem than just in KWindowSystem. Operating System: openSUSE Tumbleweed 20240227 KDE Plasma Version: 6.0.80 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.6-1-default (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: Google Product Name: Pantheon System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479703] Expose global Wayland screen offsets of top-left of all given KDecoration2 geometries for pixel-snapping with fractional scaling
https://bugs.kde.org/show_bug.cgi?id=479703 Paul McAuley changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED Version|master |5.27.9 --- Comment #3 from Paul McAuley --- I can confirm that my pixel-snapping algorithm is now working for all fractional scales on Plasma 5.27.9 and all are sharp! Good job - snapping the decoration must have been a change in 5.27, or one of its point-releases, that went by me. I also changed my zero whole-pixel reference-point to be the deviceTransform map of KDecoration2::Decoration::rect().topLeft(). I hope this is the correct snapped point - would be good to confirm. ( https://github.com/paulmcauley/klassy/commit/3d829ae8a179463dbaee8faa9321a0df254040a3 ) (Also, ignore my previous comment on innerShadowRect() - I was writing away from a computer and had forgotten the detail on how a shadow was implemented) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479703] Expose global Wayland screen offsets of top-left of all given KDecoration2 geometries for pixel-snapping with fractional scaling
https://bugs.kde.org/show_bug.cgi?id=479703 --- Comment #2 from Paul McAuley --- (In reply to David Edmundson from comment #1) > We've jumped a few steps, let's back up from proposing solutions. > > All decoration content is snapped to the pixel grid when we render. As long > as you render at the provided for and align within the buffer you write to, > everything should be fine. If that's not the case, we need to investigate. OK, thanks for your reply David. I'll double-check on the latest Plasma code at the weekend and check to see if decoration button icon snapping is good at all scales and report back. Admittedly, my understanding is from when I last looked at this in detail at the time of Plasma 5.26. Would you know in what release this pixel-snapping of decoration was introduced? What reference geometry is snapped to a grid? I assume KDecoration2::Decoration::rect()? Is KDecoration2::DecorationShadow::innerShadowRect() also snapped? Regards -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479703] New: Expose global Wayland screen offsets of top-left of all given KDecoration2 geometries for pixel-snapping with fractional scaling
https://bugs.kde.org/show_bug.cgi?id=479703 Bug ID: 479703 Summary: Expose global Wayland screen offsets of top-left of all given KDecoration2 geometries for pixel-snapping with fractional scaling Classification: Plasma Product: kwin Version: master Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Hello, I am the developer of a C++ window decoration (https://www.github.com/paulmcauley/klassy). In my window decoration I have attempted to implement a pixel-snapping algorithm so that lines in icons (especially horizontal/vertical lines) and other painted items are sharp - this works on integer scale levels (and by fluke works on scales with a fractional part of 0.5 because I happen to multiply all my geometries by a factor of 2), however, it does not work properly on all fractional scales on Wayland. This is because I am currently assuming that the QPainter device geometry of the top-left of the titlebar is a zero pixel boundary reference point (https://github.com/paulmcauley/klassy/blob/3490b94f721d9cfab4d4cf4691fbfcac8570637d/kdecoration/breezebutton.cpp#L228C2-L228C2) . However, on Wayland this is not always the case with fractional scaling. Therefore, to implement pixel snapping properly with fractional scaling on Wayland, I would kindly request some additions to the KDecoration2 API. Namely, provide functions returning a QPointF that gives the offset position (call it e.g. ScreenPos() ) in global Wayland co-ordinates from the current screen position 0,0 to the top-left of a given geometry QRectF. This offset would not be an integer pixel offset, but rather an offset that would need to be floating point for Wayland in the same co-ordinate system used by Wayland, as Wayland co-ordinates are relative to 100% scaling dimensions. This would be a most welcome additional piece of data to complement the following s provided with KDecoration2, each with their own added "ScreenPos() " offset function: KDecoration2::DecorationButton::geometry() (this one is the most useful as it could be used with standalone buttons as well) KDecoration2::DecorationButtonGroup::geometry() KDecoration2::Decoration::rect() KDecoration2::Decoration::titleBar() (potentially useful in case want to draw on titlebar directly with custom graphics) KDecoration2::DecorationShadow::innerShadowRect() (could potentially be useful for drawing automatic sharper window outlines which are currently done as part of the shadow, though would need this offset available before a shadow is provided by the decoration). Thank you, Paul -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 463176] Add apply button to window decoration config dialogue
https://bugs.kde.org/show_bug.cgi?id=463176 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com --- Comment #1 from Paul McAuley --- +1 for this. I am the developer of a C++ window decoration plugin (https://github.com/paulmcauley/klassy , fork of breeze). My plugin has a lot of configuration options which would be easier for the user to compare if the window did not close when clicking OK, and I have had several requests from users for this feature. Therefore, this is a feature request to add an Apply button to the dialog which appears after clicking the pencil icon on each window decoration. I tried manipulating parent classes to try and add an Apply button from my own plugin class, but it seems that this is part of Plasma and the dialog is provided by the Window Decoration kcm's KCModule class which I don't seem to be able to configure to do this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478241] The overview/desktop grid effect with 4-finger-swipe in Plasma 6 Beta wastes space when no virtual desktops
https://bugs.kde.org/show_bug.cgi?id=478241 Paul McAuley changed: What|Removed |Added Resolution|INTENTIONAL |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #3 from Paul McAuley --- It is different to Plasma 5 as I got a full-screen overview there and I find it useful from a touchpad swipe. I actually don't mind it having a virtual desktop feature, my problem is how much space is wasted when you aren't using virtual desktops. If you look at my "Proposal" mock-up there is potential for all the same functionality, but using a much more space-efficient layout where you just put the "add virtual desktop" and "Configure virtual desktops..." buttons in the top-right beside the Filter button (which incidentally is also missing - I think these effects should be merged and it present). Could I therefore make this a feature request? I'm also not sure if it is for the correct product as I am not clear on which effect is now the Overview Effect and which is the Desktop Grid. I don't seem to be able to change the category. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478238] Power and battery indicator hides in tray even when battery is not fully charged
https://bugs.kde.org/show_bug.cgi?id=478238 Paul McAuley changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from Paul McAuley --- (In reply to Nate Graham from comment #1) > ...Do you, though? If it's charging, what's the difference between "charging > but at 25%" and "charging but at 90%"? is there anything actionable you the > user can do with this information? Charging at 25% means I still need the charge cable or cannot leave my current location. Charging at 90% means I can give the charge cable to someone else or leave. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478240] Excessively large space before application launcher when panel is not floating and full height in Plasma 6 beta
https://bugs.kde.org/show_bug.cgi?id=478240 --- Comment #3 from Paul McAuley --- (In reply to Nate Graham from comment #2) > This is to avoid the applets shifting vertically when the panel de-floats > (or horizontally, for a horizontal panel). If they did, then the relative > locations of the click targets would shift and your muscle memory would be > impaired. > > If you don't like the mechanics of the floating panel, you're welcome to > turn it off. I have turned off the floating panel. This is with a non-floating panel. Why should excess space be wasted for a useless feature that will never be used when off? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478241] The overview/desktop grid effect with 4-finger-swipe in Plasma 6 Beta wastes space when no virtual desktops
https://bugs.kde.org/show_bug.cgi?id=478241 --- Comment #1 from Paul McAuley --- Created attachment 163998 --> https://bugs.kde.org/attachment.cgi?id=163998=edit Proposal of where to put the virtual desktop functionality -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478241] New: The overview/desktop grid effect with 4-finger-swipe in Plasma 6 Beta wastes space when no virtual desktops
https://bugs.kde.org/show_bug.cgi?id=478241 Bug ID: 478241 Summary: The overview/desktop grid effect with 4-finger-swipe in Plasma 6 Beta wastes space when no virtual desktops Classification: Plasma Product: kwin Version: git master Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-desktop-grid Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 163997 --> https://bugs.kde.org/attachment.cgi?id=163997=edit The problem when swiping with 4 fingers In the Plasma 6 Beta 1 when I swipe with 4 fingers, I get a screen showing "No other virtual desktops to show". I do not use virtual desktops as I don't like having information hidden from me, therefore, all this screen is doing is wasting a lot of space rather than using it for showing more of my current desktop. The same functionality could be provided using a lot less space -- see the attached problem and a proposal to fix. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478240] Excessively large space before application launcher when panel is not floating and full height in Plasma 6 beta
https://bugs.kde.org/show_bug.cgi?id=478240 --- Comment #1 from Paul McAuley --- Created attachment 163996 --> https://bugs.kde.org/attachment.cgi?id=163996=edit Annotation marking excessively large gap before the application launcher -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478240] New: Excessively large space before application launcher when panel is not floating and full height in Plasma 6 beta
https://bugs.kde.org/show_bug.cgi?id=478240 Bug ID: 478240 Summary: Excessively large space before application launcher when panel is not floating and full height in Plasma 6 beta Classification: Plasma Product: plasmashell Version: 5.90.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 I am on Plasma 6 beta 1 and have noticed that when the panel is not floating and is set to full height it still has a large gap before the application launcher (see screenshot). Fitt's Law lets users take into account the advantages of being near the screen edges to easy click with the mouse, but having gaps like this not only wastes space, it makes the user not as aware that they can use the screen edge to click. (Then again if this latter consideration was taken into account we would have sensible defaults and not a silly floating panel!) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478238] New: Power and battery indicator hides in tray even when battery is not fully charged
https://bugs.kde.org/show_bug.cgi?id=478238 Bug ID: 478238 Summary: Power and battery indicator hides in tray even when battery is not fully charged Classification: Plasma Product: plasmashell Version: 5.90.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: mate...@gmail.com Target Milestone: 1.0 In Plasma 6 beta 1 I notice that the power and battery indicator hides in the tray even when the battery is not fully charged. The previous behaviour was that it would only hide when it was fully charged. This behaviour made more sense to me as you still want to know your battery status even when charging. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kded] [Bug 471001] New: Cursors/pointers are huge in Firefox with system scaling greater than 200%
https://bugs.kde.org/show_bug.cgi?id=471001 Bug ID: 471001 Summary: Cursors/pointers are huge in Firefox with system scaling greater than 200% Classification: Frameworks and Libraries Product: frameworks-kded Version: 5.106.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: fa...@kde.org Reporter: k...@paulmcauley.com CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 159641 --> https://bugs.kde.org/attachment.cgi?id=159641=edit Firefox with large pointer displayed, 250% scaling, cursor size 24 Using Plasma 5.27.5 with the Fedora 38 KDE spin, the cursor/pointer in Firefox (113.0.1) appears very large when the system scaling is set to 250% (or at any system scale greater than 200%). This is despite the cursor size being set to 24 in the system settings. See attached photo. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.4-201.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: Google Product Name: Pantheon System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 432939] Background blur doesn't work when a split without background blur is selected
https://bugs.kde.org/show_bug.cgi?id=432939 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com --- Comment #1 from Paul McAuley --- I assume this is the same bug as Bug 456052 Konsole probably needs to specify the region parameter in: KWindowEffects::enableBlurBehind(QWindow *window, bool enable = true, const QRegion = QRegion()) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456052] Background blur apply blur to titlebar component
https://bugs.kde.org/show_bug.cgi?id=456052 Paul McAuley changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||k...@paulmcauley.com --- Comment #3 from Paul McAuley --- I am the author of another window decoration and application style (https://github.com/paulmcauley/klassy) that applies blur to various components, and can confirm this bug in Konsole. Another side effect is that blur doesn't show at all with my Application Style when I blur the toolbar/header area to match the titlebar. This problem with Konsole is caused by the fact it is trying to apply blur to the entire window, rather than also specifying to blur just the input/output text area region. I'm assuming the following function is being used, and the problem is that the final optional region parameter has been omitted: KWindowEffects::enableBlurBehind(QWindow *window, bool enable = true, const QRegion = QRegion()) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456052] Background blur apply blur to titlebar component
https://bugs.kde.org/show_bug.cgi?id=456052 Paul McAuley changed: What|Removed |Added CC||dpearson1...@gmail.com --- Comment #2 from Paul McAuley --- *** Bug 457455 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 457455] Enabling Blur background causes weird issues at the corners of title bar.
https://bugs.kde.org/show_bug.cgi?id=457455 Paul McAuley changed: What|Removed |Added Status|REPORTED|RESOLVED CC||k...@paulmcauley.com Resolution|--- |DUPLICATE --- Comment #1 from Paul McAuley --- This is a duplicate of Bug 456052 *** This bug has been marked as a duplicate of bug 456052 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459778] Screen occasionally freezes "EGL_BAD_SURFACE" errors when launching application while using the Klassy window decoration
https://bugs.kde.org/show_bug.cgi?id=459778 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com --- Comment #59 from Paul McAuley --- (In reply to Vlad Zahorodnii from comment #53) > My best theory is that klassy tries (or did try in the past) to change the > shadow when kwin paints the decoration. With the current implementation, > changing the shadow when kwin composes the output will produce > EGL_BAD_SURFACE. On the other hand, the decoration should not mess with the > shadow in Decoration::paint(). > > Not sure what we can do without being able to reproduce the bug, we don't > have enough data to act on it. Hi Vlad, Klassy developer here. After much investigation, I can confirm that your theory is correct. Klassy has the option of coloured window outlines that are drawn as part of the shadow; these colours depend on the system colour scheme. Therefore, Klassy triggers an update of the shadow should the system colour scheme change by connecting the KDecoration2::DecoratedClient::paletteChanged signal. This is how the shadow can be changed when the paint() function is executing (the shadow is not "messed with in Decoration::paint()" directly). The EGL_BAD_SURFACE segfault only occurs with Klassy 4.0 from Plasma 5.26 beta onwards (did not occur in Plasma 5.25), and especially seems to be triggered when launching applications which have their own custom colour scheme options. As a temporary workaround, today I released Klassy 4.1 which seems to workaround this in the majority of cases, but I'm not sure how robust a fix it is (https://github.com/paulmcauley/klassy/commit/972edd08184b3a416b166053a1b1a3d042d33d92). I set a m_painting flag at the start of the decoration's paint() function and clear it at the end of paint() to try and detect when paint() is running (is there a better way to detect from the decoration when kwin is composing?). I then abort any attempt to change the shadow should the m_painting flag be set. I had also experimented with implementing delays instead of aborting, but this did not work as I don't think my detection of the kwin composing is accurate enough. Would it be possible to implement something more elegant/robust within kwin so that a call of setShadow() and paint() at the same time will not cause an EGL_BAD_SURFACE to occur e.g. delay shadow rendering until after paint()? Or even have that the segfault does not occur as in Plasma 5.25? Paul -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 456722] New: Add a default keyboard shortcut for System Monitor
https://bugs.kde.org/show_bug.cgi?id=456722 Bug ID: 456722 Summary: Add a default keyboard shortcut for System Monitor Product: frameworks-kglobalaccel Version: 5.96.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- The new System Monitor does not have a default keyboard shortcut (at least for me on OpenSUSE Leap 15.4 Argon). I would suggest adding Ctrl+Shift+Esc for the new System Monitor. Many people will be familiar with this as it matches Windows. This way Ctrl+Esc can still also be used to access the less resource intensive and older systemmonitor. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453229] New setBlurRegion() API gives blocky/aliased blur region corners on Wayland HiDPI
https://bugs.kde.org/show_bug.cgi?id=453229 Paul McAuley changed: What|Removed |Added Summary|New setBlurRegion() API |New setBlurRegion() API |gives blocky/aliased blur |gives blocky/aliased blur |region corners on Wayland |region corners on Wayland ||HiDPI -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453229] New setBlurRegion() API gives blocky/aliased blur region corners on Wayland
https://bugs.kde.org/show_bug.cgi?id=453229 --- Comment #4 from Paul McAuley --- (In reply to Mohammad from comment #3) > Created attachment 149902 [details] > floating panel > > The problem still exists in the floating panel. The setBlurRegion() function is only for window decorations, so this bug wouldn't cover that. That said, the KWindowEffects::enableBlurBehind function used for blurring regions in applications only accepts QRegions as well, so I suspect if they were ever used properly, that under Wayland you would not have smooth corners on HiDPI Wayland with KWindowEffects::enableBlurBehind either. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453229] New setBlurRegion() API gives blocky/aliased blur region corners on Wayland
https://bugs.kde.org/show_bug.cgi?id=453229 --- Comment #2 from Paul McAuley --- I should also mention that the above 2 screenshots are at 250% scaling. I was looking into this more, and guessing this is probably because in Wayland scaled rendering is done relative to a smaller 100% scaled grid (e.g. at 250% scaling with a 2840x2160 display, rendering is done relative to 1536x864), so on Wayland you probably need to use floating point values for more precise shapes on screens with scaling > 100%. You can, however, only construct a QRegion using integers (QRect and QPolygon; not QRectF and QPolygonF). In my own window decoration ( https://github.com/paulmcauley/classik/commit/fe48c052f529e889706214c9af3db200fbfdb2a8#diff-1c44374ff8b2c6b8bea9596fe31ea4878a23bea2f62d2ce01dcbdf119dc98474R1319 ) I convert from a QPainterPath (in the shape of the window) to a QPolygonF to a QPolygon and finally to a QRegion. If my assumption about the cause of this problem is correct, I would then propose extending the setBlurRegion() API in the decoration to accept a QPainterPath or a QPolygonF. A QPolygonF can then be easily converted to a QPolygon (just converts qreal to int) and then to a QRegion at the last minute after scaling and directly before the effect is applied to the actual pixels on screen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395725] Blur effect applied to decoration shadows
https://bugs.kde.org/show_bug.cgi?id=395725 --- Comment #82 from Paul McAuley --- I use my own theme to test this (git master branch of https://github.com/paulmcauley/classik which has the API implemented). The main problem I found is that on Wayland, blurred corners are quite aliased ( https://bugs.kde.org/show_bug.cgi?id=453229 ). -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 453167] GTK CSD window close icon (`window-close-symbolic`) does not match that of SSD apps
https://bugs.kde.org/show_bug.cgi?id=453167 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com --- Comment #8 from Paul McAuley --- Created attachment 149642 --> https://bugs.kde.org/attachment.cgi?id=149642=edit kirigami(?) apps with a fake pop-up window using the "window-close-symbolic" icon. On mouse hover the "window-close" icon then appears. (In reply to Eduardo Alvarado from comment #1) > This would also affect the close icon in notifications. The close icon in notifications uses "window-close", not "window-close-symbolic". I have been investigating this for my 3rd party icons, and the only applications I have found so far which use "window-close-symbolic" are (I think) kirigami-based ones which have a fake pop-up window. See the attached screenshot. When you hover the close button with the mouse in these fake pop-up windows, they then show the "window-close" icon. (In reply to Nate Graham from comment #7) > Indeed, `window-close-symbolic` is circled. > > If we change that to just be an uncircled X, I wonder if it could have any > other consequences... An uncircled X would need to be larger than the current icon to match the other symbolic GTK CSD window icons. In the case of the kirigami(?) examples I mentioned above this would cause problems with the mouse-over of "window-close" being smaller. Either you could change the (also circled but red) "window-close" icon to be larger as well to match, or get the kirigami(?) apps to draw their own mouse-over highlight like GTK rather than using an icon. Overall, I like that Adwaita GTK now uses the "symbolic" icons for windows and I now use Adwaita GTK rather than Breeze GTK for that reason. It partially solves the regression in Wayland in bug 437082, and allows third party icon themes to now have at least some consistency. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433854] A lot of times copy-paste does not work.
https://bugs.kde.org/show_bug.cgi?id=433854 Paul McAuley changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433854] A lot of times copy-paste does not work.
https://bugs.kde.org/show_bug.cgi?id=433854 --- Comment #18 from Paul McAuley --- Created attachment 149541 --> https://bugs.kde.org/attachment.cgi?id=149541=edit Example of copying and pasting not working in Firefox 101 body or address bar, Wayland Plasma 5.24.90 I managed to capture on this video Firefox 101 not copying to clipboard page body data (occurs sporadically) nor address bar data (occurs all the time). With the page body data I just get "timeout reading from pipe" in all fields in the clipboard tab of the Kwin debug console. With the address bar data all the fields in the clipboard tab of the debug console are blank. Also, I'm not sure what you mean for it not to be "completely mad" for this to happen, though it sure makes using Wayland infuriating! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454942] New: Provide devicePixelRatio in KDecoration2
https://bugs.kde.org/show_bug.cgi?id=454942 Bug ID: 454942 Summary: Provide devicePixelRatio in KDecoration2 Product: kwin Version: 5.24.90 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- This is a feature request for an additional parameter in the KDecoration2 API. Currently, in KDecoration you can only access devicePixelRatioF() (of the current screen which the window exists) within the Decoration::paint method via painter->device()->devicePixelRatioF(). However, in my own C++ window decoration I also paint some elements outside the Decoration::paint method (for example, a window outline in the shadow, and a separator under the titlebar). For these I would like access to devicePixelRatioF() for more precise painting (e.g. with a cosmetic brush) and alignment under Wayland. Vlad Zahorodnii also mentioned this as a possibility in an old merge request at https://invent.kde.org/plasma/breeze/-/merge_requests/75 : "Vlad Zahorodnii @vladz · 1 year ago Developer KWin is the true source of device pixel ratio information. If such information is needed, it can be added in KDecoration2 library, e.g. a devicePixelRatio getter and a signal." -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433854] A lot of times copy-paste does not work.
https://bugs.kde.org/show_bug.cgi?id=433854 Paul McAuley changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||k...@paulmcauley.com --- Comment #16 from Paul McAuley --- I have an issue under Wayland (Plasma 5.24.90 and before) whereby I never can copy the contents of the URL bar in Firefox (101.0 and before) and then paste it into another application (I though can paste successfully into a textarea in Firefox). Copying the contents from the body of a webpage in Firefox copys and pastes fine though. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454805] Glitchy maximize animation: isMaximized() returned true before the window has completed the maximize animation
https://bugs.kde.org/show_bug.cgi?id=454805 --- Comment #2 from Paul McAuley --- Created attachment 149436 --> https://bugs.kde.org/attachment.cgi?id=149436=edit Video showing glitchy maximize animation with ClassiK window decoration Here is another video of the glitchy maximize animation with my ClassiK window decoration (https://github.com/paulmcauley/classik). In this decoration, by default, the maximized titlebar has a smaller height than a non-maximized titlebar. This causes a noticeable tear below the titlebar at the start of the animation. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454805] Glitchy maximize animation: isMaximized() returned true before the window has completed the maximize animation
https://bugs.kde.org/show_bug.cgi?id=454805 --- Comment #1 from Paul McAuley --- Created attachment 149435 --> https://bugs.kde.org/attachment.cgi?id=149435=edit Still from maximize_animation_glitch_breeze_with_borders.mp4 illustrating gap Here is also a still from 1s into the previous video, showing the gap created by removing the window border before the maximize animation completes. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454805] New: Glitchy maximize animation: isMaximized() returned true before the window has completed the maximize animation
https://bugs.kde.org/show_bug.cgi?id=454805 Bug ID: 454805 Summary: Glitchy maximize animation: isMaximized() returned true before the window has completed the maximize animation Product: kwin Version: 5.24.90 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 149434 --> https://bugs.kde.org/attachment.cgi?id=149434=edit Video showing glitchy maximize animation with Breeze window decoration, normal borders This is an animation glitch which has existed a few years now (in both X11 and Wayland), and have been meaning to report and make videos of for some time. The problem is that the window maximize animation is glitchy. This is because the window titlebar will appear in the maximized state before the maximize animation has been completed. I assume the client->isMaximized() function is returning true to the window decoration before the maximize animation is complete. In the attached maximize_animation_glitch_breeze_with_borders.mp4 you can see that when maximize is clicked, the titlebar instantly transforms into the maximized state, losing its rounded corners and losing the window borders before the animation has even started. The expected behaviour would be for these things to change only after the maximize animation has completed. The restore animation seems to work fine. Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-150300.59.68-preempt (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 Manufacturer: Dell Inc. Product Name: XPS 15 9560 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454453] Window decoration Blur effect does not work with new setBlurRegion() API on 5.24.90, but always worked on 5.24.80 git master
https://bugs.kde.org/show_bug.cgi?id=454453 Paul McAuley changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Paul McAuley --- I have noticed with the latest kwin update on 5.24.90 from OpenSUSE that this has been fixed. Closing -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454522] [X11] Windows and context menus have square outline with no rounded corners
https://bugs.kde.org/show_bug.cgi?id=454522 Paul McAuley changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #2 from Paul McAuley --- I noticed that under System Settings->Display and Monitor->Compositor that "Compositing: Enable on startup" had become disabled. I re-enabled this and this problem has been fixed. Closing -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454522] [X11] Windows and context menus have square outline with no rounded corners
https://bugs.kde.org/show_bug.cgi?id=454522 --- Comment #1 from Paul McAuley --- Created attachment 149282 --> https://bugs.kde.org/attachment.cgi?id=149282=edit X11 illustration of windows and context menu with no rounded corners on 5.25 beta -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454522] New: [X11] Windows and context menus have square outline with no rounded corners
https://bugs.kde.org/show_bug.cgi?id=454522 Bug ID: 454522 Summary: [X11] Windows and context menus have square outline with no rounded corners Product: kwin Version: 5.24.90 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- In the 5.25 beta (5.24.90) under X11 I have square windows with no rounded corners. This is particularly obvious in GTK apps which have a large square outline. Context menus also have no rounded corners. This is fine under Wayland. It was also fine in 5.24.80 and on the git master. Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-150300.59.68-preempt (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 Manufacturer: Dell Inc. Product Name: XPS 15 9560 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454453] Window decoration Blur effect does not work with new setBlurRegion() API on 5.24.90, but always worked on 5.24.80 git master
https://bugs.kde.org/show_bug.cgi?id=454453 Paul McAuley changed: What|Removed |Added Summary|Window decoration Blur |Window decoration Blur |effect does not work with |effect does not work with |new setBlurRegion() API on |new setBlurRegion() API on |5.24.90, but always worked |5.24.90, but always worked |on git master |on 5.24.80 git master -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453229] New setBlurRegion() API gives blocky/aliased blur region corners on Wayland
https://bugs.kde.org/show_bug.cgi?id=453229 Paul McAuley changed: What|Removed |Added CC||mvourla...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454453] Window decoration Blur effect does not work with new setBlurRegion() API on 5.24.90, but always worked on git master
https://bugs.kde.org/show_bug.cgi?id=454453 Paul McAuley changed: What|Removed |Added CC||mvourla...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454453] New: Window decoration Blur effect does not work with new setBlurRegion() API on 5.24.90, but always worked on git master
https://bugs.kde.org/show_bug.cgi?id=454453 Bug ID: 454453 Summary: Window decoration Blur effect does not work with new setBlurRegion() API on 5.24.90, but always worked on git master Product: kwin Version: 5.24.90 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- I have implemented the new setBlurRegion() API for my C++ window decoration (https://github.com/paulmcauley/classik). This (mostly https://bugs.kde.org/show_bug.cgi?id=453229) works fine on the git master (and has for a month or so now), with a blur effect that matches the window shape. However, when I enable transparency and blur in my window decoration (this simply calls setBlurRegion() with the window shape) on the 5.24.90 beta I do not get any blur at all, just transparency. I have removed the "blur":true line from my .json file (as done by Michail Vourlakos for Aurorae) . Readding "blur": true to the .json enables blur again on 5.24.90, but with the kornerbug that the new setBlurRegion API was designed to fix (https://bugs.kde.org/show_bug.cgi?id=395725). Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-150300.59.68-preempt (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 Manufacturer: Dell Inc. Product Name: XPS 15 9560 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453229] New setBlurRegion() API gives blocky/aliased blur region corners on Wayland
https://bugs.kde.org/show_bug.cgi?id=453229 --- Comment #1 from Paul McAuley --- Created attachment 148475 --> https://bugs.kde.org/attachment.cgi?id=148475=edit X11 by contrast. Screenshot of ClassiK window decoration with 20% opacity titlebars/borders and blur on, corner radius=4, shadows disabled to emphasise bug. The corners are very smooth. By contrast here is a similar screenshot on X11. It results in very smooth corners to the blur region. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453229] New: New setBlurRegion() API gives blocky/aliased blur region corners on Wayland
https://bugs.kde.org/show_bug.cgi?id=453229 Bug ID: 453229 Summary: New setBlurRegion() API gives blocky/aliased blur region corners on Wayland Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 148474 --> https://bugs.kde.org/attachment.cgi?id=148474=edit Screenshot of ClassiK window decoration with 20% opacity titlebars/borders and blur on, corner radius=4, shadows disabled to emphasise bug. The corners exhibit very blocky aliasing. Hello, I have made a first attempt at implementing the new setBlurRegion() API (due to land in Plasma 5.25) in my C++ Window Decoration. This can be found on the branch at: https://github.com/paulmcauley/classik/tree/kornerbug-fix-plasma5.25 I construct my window shape using a QPainterPath (called m_windowPath) and then call setBlurRegion as follows: setBlurRegion( QRegion( m_windowPath->toFillPolygon().toPolygon() ) ) ; The results on X11 are excellent and produces very smooth corners when transparency and blur are enabled. However, on Wayland, the corners of the blur region are very blocky/aliased in appearance. Operating System: openSUSE Tumbleweed 20220421 KDE Plasma Version: 5.24.80 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Kernel Version: 5.17.3-1-default (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 Manufacturer: Dell Inc. Product Name: XPS 15 9560 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 --- Comment #9 from Paul McAuley --- I have reworked my C++ window decoration to use the new setBlurRegion API (due 5.25) on the branch at https://github.com/paulmcauley/classik/tree/kornerbug-fix-plasma5.25 This has worked around this issue for my specific case for now. I had to remove the blur config line entirely from the .json file and also match the Breeze behaviour of setting setOpaque(false) for non-maximized windows (even when I know that no transparency will be used in the window decoration) to avoid any artefacts. However, it would be good to get some guidance on what setOpaque() is for. Should a non-maximized window ever have setOpaque(true) set if transparency is never going to be used in the window decoration? I would have assumed this would be the case, and therefore that this bug is still generally relevant. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 Paul McAuley changed: What|Removed |Added Component|decorations |effects-various -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778
--- Comment #8 from Paul McAuley ---
Created attachment 147849
--> https://bugs.kde.org/attachment.cgi?id=147849=edit
0kwin 0a8de6c0 ("effects/blur: Avoid shrinking unrelated opaque regions",
2022-02-19) DOES have the bug
I managed to pinpoint this bug exactly to be caused by kwin commit 0a8de6c0
("effects/blur: Avoid shrinking unrelated opaque regions", 2022-02-19) (see
screenshot)
This would correspond to the merge request at
https://invent.kde.org/plasma/kwin/-/merge_requests/2045
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778
--- Comment #7 from Paul McAuley ---
Created attachment 147848
--> https://bugs.kde.org/attachment.cgi?id=147848=edit
kwin 5e448f063 ("effects/contrast: Remove paint area tracking", 2022-02-16)
does NOT have the bug
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 --- Comment #6 from Paul McAuley --- (In reply to Paul McAuley from comment #2) > (In reply to David Edmundson from comment #1) > > Nothing should have changed in the 5.24.x series. > > You are right - I double checked with a 5.24.0 ISO and it does also have > this problem. 5.23 releases definitely did not. Maybe I was confused by the > 5.24 beta releases. > > > The reason the Breeze window decoration does not have this problem is > because it has blur disabled in its .json file and also has setOpaque(false) > set for non-maximized windows. UPDATE: I also found a machine that was still on Plasma 5.24.1 and it does not have this bug. Immediately upon updating to Plasma 5.24.3 the bug appears. There seems to be a definite difference between 5.24.1 and later releases (see added screenshots). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 --- Comment #5 from Paul McAuley --- Created attachment 147723 --> https://bugs.kde.org/attachment.cgi?id=147723=edit 5.24.3 - bug is present on both Wayland and X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 --- Comment #4 from Paul McAuley --- Created attachment 147722 --> https://bugs.kde.org/attachment.cgi?id=147722=edit 5.24.1 Wayland - bug is not present -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 --- Comment #3 from Paul McAuley --- Created attachment 147721 --> https://bugs.kde.org/attachment.cgi?id=147721=edit 5.24.1 X11 - bug is not present -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 --- Comment #2 from Paul McAuley --- (In reply to David Edmundson from comment #1) > Nothing should have changed in the 5.24.x series. You are right - I double checked with a 5.24.0 ISO and it does also have this problem. 5.23 releases definitely did not. Maybe I was confused by the 5.24 beta releases. The reason the Breeze window decoration does not have this problem is because it has blur disabled in its .json file and also has setOpaque(false) set for non-maximized windows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451778] New: Blur/Kornerbug enabled even when a window is set to opaque
https://bugs.kde.org/show_bug.cgi?id=451778 Bug ID: 451778 Summary: Blur/Kornerbug enabled even when a window is set to opaque Product: kwin Version: 5.24.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 147655 --> https://bugs.kde.org/attachment.cgi?id=147655=edit New Kornerbug artefact visible in top corners of window. In this case transparency is disabled and the window is set to opaque with setOpaque(true). This artefact did not occur in 5.23 Hello, I have noticed some regressions (or intentional changes??) with recent point releases of Plasma 5.24 (I did not notice such changes 5.23 or in the original Plasma 5.24 release). I am the author of the Classik C++ window decoration plugin ( https://github.com/paulmcauley/classik ). I have blur enabled in my .json file as I have translucency as an option. In 5.23, and early 5.24 builds I used the same technique as the Lightly window decoration ( https://github.com/Luwx/Lightly ) to control when blur should be on or off. Namely, I use Decoration::setOpaque(true) to dynamically turn blur off and Decoration::setOpaque(false) to dynamically turn blur on. When translucency and blur was not needed I therefore used Decoration::setOpaque(true), and this prevented the Kornerbug from appearing by disabling blur for most default cases when blur was not needed. My problem is that this no longer works. I now get the kornerbug when using 5.24.3 and Decoration::setOpaque(true), suggesting that blur has been enabled even on a window set to opaque. I understand that there is to be a new API for setting a blurRegion mask in 5.25 to avoid kornerbug issues, but I am seeing changes here in 5.24.3. If this is an intentional change, what is the correct way to programmatically inform blur to disable? Is setOpaque() still used? Thanks, Paul Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-150300.59.54-preempt (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 428109] Fitts' Law broken for non-taskmanager panel applets
https://bugs.kde.org/show_bug.cgi?id=428109 --- Comment #30 from Paul McAuley --- (In reply to Paul McAuley from comment #29) > I am now just experiencing this on 5.23.4 with a bottom panel and an > application launcher at the extreme bottom-left. The extreme bottom-left > corner does not trigger the application launcher, and the extreme > bottom-right corner does not trigger show desktop. It has only appeared for > me as a problem on recent builds. > > It does not occur if I use a panel at the left with the application launcher > at the top-left corner. Some more info: I am using 250% scaling, on X11, have PLASMA_USE_QT_SCALING on and have a panel height of 40, no margin separators. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 428109] Fitts' Law broken for non-taskmanager panel applets
https://bugs.kde.org/show_bug.cgi?id=428109 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #29 from Paul McAuley --- I am now just experiencing this on 5.23.4 with a bottom panel and an application launcher at the extreme bottom-left. The extreme bottom-left corner does not trigger the application launcher, and the extreme bottom-right corner does not trigger show desktop. It has only appeared for me as a problem on recent builds. It does not occur if I use a panel at the left with the application launcher at the top-left corner. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435674] [X11] Maximized windows intermittently refuse to close from extreme top-right corner with HiDPI
https://bugs.kde.org/show_bug.cgi?id=435674 --- Comment #5 from Paul McAuley --- Another aspect of this bug is that sometimes clicking at the extreme top-right causes the window behind the one you want to close to close instead. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446585] Active header colour is used for colour mixing to create disabled items on inactive window
https://bugs.kde.org/show_bug.cgi?id=446585 --- Comment #1 from Paul McAuley --- A green line also appears underneath the header on an inactive window -- I am not sure if that was the desired effect. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 446585] New: Active header colour is used for colour mixing to create disabled items on inactive window
https://bugs.kde.org/show_bug.cgi?id=446585 Bug ID: 446585 Summary: Active header colour is used for colour mixing to create disabled items on inactive window Product: Breeze Version: 5.23.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: QStyle Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: noaha...@gmail.com Target Milestone: --- Created attachment 144285 --> https://bugs.kde.org/attachment.cgi?id=144285=edit Active header colour set to bright green. Inactive header colour grey. See the attached screenshot. I have set the active header colour to bright green, inactive header colour is grey. I still see green on the inactive window in disabled items, indicating that the active colour is being used for colour mixing on the inactive window. Expected: disabled items on the inactive window would use the inactive background colour for colour mixing. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 446584] New: No way to configure inactive header colours in kcm
https://bugs.kde.org/show_bug.cgi?id=446584 Bug ID: 446584 Summary: No way to configure inactive header colours in kcm Product: systemsettings Version: 5.23.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_colors Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: jpwhit...@kde.org, mwoehlke.fl...@gmail.com Target Milestone: --- The colors .configuration files contain sections "[Colors:Header]" and "[Colors:Header][Inactive]". The former is configurable in the kcm_colors but the latter is not. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 440231] After Blue Ocean changes, Dockable Panel / MDI buttons no longer have a hover highlight
https://bugs.kde.org/show_bug.cgi?id=440231 --- Comment #4 from Paul McAuley --- (In reply to Paul McAuley from comment #3) > https://invent.kde.org/plasma/breeze/-/commit/ > 8de82c4d508510a9f6a633d820fba1303c5d129a I left a comment at the link above. I have pinpointed this further to the function: bool Style::drawToolButtonLabelControl( const QStyleOption* option, QPainter* painter, const QWidget* widget ) const Restoring the following lines restores the previous hover behaviour in docks: else if( (!flat && hasFocus) || (flat && (state & State_Sunken) && !mouseOver) ) iconMode = QIcon::Selected; else if( mouseOver && flat ) iconMode = QIcon::Active; Deleting similar hover logic is done in 3 other places in this commit, so I'm not sure if there are any other side-effects caused by that commit. I would need to know what cblack's thinking was in deleting the hover logic. I see that animation logic has also been deleted. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 440231] After Blue Ocean changes, Dockable Panel / MDI buttons no longer have a hover highlight
https://bugs.kde.org/show_bug.cgi?id=440231 --- Comment #3 from Paul McAuley --- (In reply to Paul McAuley from comment #2) > I have isolated this regression to commit: > > 8de82c4d508510a9f6a633d820fba1303c5d129a Make buttons styled like Blue Ocean > mockups https://invent.kde.org/plasma/breeze/-/commit/8de82c4d508510a9f6a633d820fba1303c5d129a -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 440231] After Blue Ocean changes, Dockable Panel / MDI buttons no longer have a hover highlight
https://bugs.kde.org/show_bug.cgi?id=440231 --- Comment #2 from Paul McAuley --- I have isolated this regression to commit: 8de82c4d508510a9f6a633d820fba1303c5d129a Make buttons styled like Blue Ocean mockups -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 445040] Accent colors don't apply different hover and focus colours
https://bugs.kde.org/show_bug.cgi?id=445040 Paul McAuley changed: What|Removed |Added Assignee|plasma-b...@kde.org |k...@paulmcauley.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 445040] Accent colors don't apply different hover and focus colours
https://bugs.kde.org/show_bug.cgi?id=445040 Paul McAuley changed: What|Removed |Added Status|CONFIRMED |ASSIGNED Summary|Accent colors don't apply |Accent colors don't apply |different hover and focus |different hover and focus |colous |colours --- Comment #3 from Paul McAuley --- OK, I will take a look at this soon. I have came up with some different saturation thresholds than I posted in the code above, which work better with all the standard system accent colours, so will try to port them to Plasma. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 445138] "Allow resizing maximized windows from window edges" doesn't allow resizing from the right screen edge
https://bugs.kde.org/show_bug.cgi?id=445138 --- Comment #2 from Paul McAuley --- This only occurs if you have borders set to none. (and yes, I don't like this setting either, but I had a user of my Breeze fork using it) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 445040] Accent colors should apply different hover and focus colours
https://bugs.kde.org/show_bug.cgi?id=445040
--- Comment #1 from Paul McAuley ---
I worked around this in my own C++ window decoration by doing the following:
if(buttonFocusColor == buttonHoverColor) buttonHoverColor =
ColorTools::getDifferentiatedLessSaturatedColor(buttonHoverColor);
QColor ColorTools::getDifferentiatedLessSaturatedColor( const QColor&
inputColor )
{
int colorHsv[3];
inputColor.getHsv([0], [1], [2]);
if( colorHsv[1] > 125 ) colorHsv[1] -= 80; //decrease saturation if not
already low
else colorHsv[1] += 80; // else increase saturation if very low to
provide differentiation/contrast
QColor outputColor;
outputColor.setHsv(colorHsv[0], colorHsv[1], colorHsv[2]);
return outputColor;
}
I have to still apply this in several other places in the application style
where hover and focus colours are the same, and it would be better if I didn't
have to do this at all.
--
You are receiving this mail because:
You are watching all bug changes.
[Breeze] [Bug 445138] New: "Allow resizing maximized windows from window edges" doesn't allow resizing from the right screen edge
https://bugs.kde.org/show_bug.cgi?id=445138 Bug ID: 445138 Summary: "Allow resizing maximized windows from window edges" doesn't allow resizing from the right screen edge Product: Breeze Version: 5.23.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: window decoration Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: kwin-bugs-n...@kde.org Target Milestone: --- 1. Tick "Allow resizing maximized windows from window edges" in Breeze window decoration settings. 2. Maximize a window and try to resize the edges - the top, left and bottom edges resize, but the right edge does not. Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-59.27-preempt (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 445133] New: Qt Group Box title will only horizontally align center
https://bugs.kde.org/show_bug.cgi?id=445133 Bug ID: 445133 Summary: Qt Group Box title will only horizontally align center Product: Breeze Version: 5.23.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: QStyle Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: noaha...@gmail.com Target Milestone: --- I am trying to align a Qt Group Box title in Qt Designer to the left. However, if you try to horizontally align the Group Box title to the left or the right it still displays in the center. If I change my application style to Fusion this works perfectly, but not in Breeze. Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-59.27-preempt (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 445040] New: Accent colors should apply different hover and focus colours
https://bugs.kde.org/show_bug.cgi?id=445040 Bug ID: 445040 Summary: Accent colors should apply different hover and focus colours Product: systemsettings Version: 5.23.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_colors Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: jpwhit...@kde.org, mwoehlke.fl...@gmail.com Target Milestone: --- Currently the new accent colour feature sets the hover and focus colours to be the same. It would be better if the hover colour was set to a modification of the focus colour with reduced saturation. This is how it is done in the Breeze colour scheme. This current implementation is simply enforcing what I see as a design/usability regression from Breeze Light and Breeze Dark on all colour schemes, making the accent colour feature quite unappealing. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 434303] Elisa recreates it's database (using Baloo indexing) after restarting the pc
https://bugs.kde.org/show_bug.cgi?id=434303 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com --- Comment #5 from Paul McAuley --- I have this problem too. Every time I start Elisa it tries to re-import all 9000 music files taking 30 minutes. It does not seem to remember the imported files. I am using "fast native indexer" with Elisa 21.08.2 (though have experienced this issue pretty much since Elisa existed) on the following system: Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-59.27-preempt (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 444668] New: System Settings Renders upside down in icon view
https://bugs.kde.org/show_bug.cgi?id=444668 Bug ID: 444668 Summary: System Settings Renders upside down in icon view Product: kwin Version: 5.23.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 143031 --> https://bugs.kde.org/attachment.cgi?id=143031=edit Screenshot of how settings looks after clicking on Appearance In Wayland (with nVidia proprietary drivers) System Settings->Appearance (or almost any other kcm) renders upside down in icon view. STEPS TO REPRODUCE 1. Change system Settings to icon view under Configure... 2. Open the Appearance, or almost any other, kcm 3. The kcm does not display, and instead the settings window content is rendered upside down! SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.3 KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-59.27-default (64-bit) Graphics Platform: Wayland Processors: 48 × Intel® Xeon® CPU E5-2650L v3 @ 1.80GHz Memory: 125.8 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 nVidia proprietary driver G05 470.74 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 433206] Add the ability for RGBA i.e. additional alpha channel as well as RGB
https://bugs.kde.org/show_bug.cgi?id=433206 Paul McAuley changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |INTENTIONAL --- Comment #3 from Paul McAuley --- Having separately implemented alpha in my own window decorations and application style, I no longer think this is a good idea and will create more problems than it solves. Closing -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 442659] GTK3 Window decoration assets generated by kde-gtk-config are now all blank with Breeze window decoration
https://bugs.kde.org/show_bug.cgi?id=442659 --- Comment #2 from Paul McAuley --- (In reply to Tony from comment #1) > Can confirm this on opensuse tumbleweed. > It only happens on x11 session on wayland is Ok. Wayland probably works because the GTK window decorations there are hard-coded to Breeze and do not get dynamically updated by kde-gtk-config. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 442659] New: GTK3 Window decoration assets generated by kde-gtk-config are now all blank with Breeze window decoration
https://bugs.kde.org/show_bug.cgi?id=442659 Bug ID: 442659 Summary: GTK3 Window decoration assets generated by kde-gtk-config are now all blank with Breeze window decoration Product: Breeze Version: git-master Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: window decoration Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: kwin-bugs-n...@kde.org Target Milestone: --- SUMMARY I am using the 5.23 beta on KDE Neon Unstable in X11. I notice that now with the Breeze window decoration if I open Firefox, for example, there are now no minimize/maximize/close buttons displayed. Upon further investigation if I look in ~/.config/gtk-3.0/assets/ all the svg files generated automatically by the kde-gtk-config / kded5 kwin_bridge are now blank. This does not happen with other non-Breeze window decorations. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-34-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 440393] New: Gwenview Background colour text is cut off in British English
https://bugs.kde.org/show_bug.cgi?id=440393 Bug ID: 440393 Summary: Gwenview Background colour text is cut off in British English Product: gwenview Version: 21.07.80 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- Created attachment 140396 --> https://bugs.kde.org/attachment.cgi?id=140396=edit Screenshot of cut off Background colour text Gwenview "Background colour" text is cut off at the start. I assume is is due to the extra "u" character in the word colour in British English. (KDE Plasma 5.22.4 Wayland) -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 440231] New: After Blue Ocean changes, Dockable Panel / MDI buttons no longer have a hover highlight
https://bugs.kde.org/show_bug.cgi?id=440231 Bug ID: 440231 Summary: After Blue Ocean changes, Dockable Panel / MDI buttons no longer have a hover highlight Product: Breeze Version: unspecified Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: QStyle Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: noaha...@gmail.com Target Milestone: --- Created attachment 140303 --> https://bugs.kde.org/attachment.cgi?id=140303=edit For example, the restore/undock button here in KDevelop used to show a highlighted background when moused over: KDE Neon Unstable 5.22.80. After Blue Ocean changes, a regression has been introduced whereby Dockable Panel / MDI buttons no longer have a hover highlight on mouse-over. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 436559] GTK3 CSD buttons are noticeably smaller than regular Breeze Qt style
https://bugs.kde.org/show_bug.cgi?id=436559 --- Comment #13 from Paul McAuley --- The solution offered in the OP seems to fix the size at 100% display scaling, however, I am using 250% scaling and the size of the GTK CSD titlebar buttons is still too small even with the OP's change. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 436559] GTK3 CSD buttons are noticeably smaller than regular Breeze Qt style
https://bugs.kde.org/show_bug.cgi?id=436559 Paul McAuley changed: What|Removed |Added CC||k...@paulmcauley.com --- Comment #12 from Paul McAuley --- (In reply to Nate Graham from comment #7) > Actually I just noticed that the buttons are the right size on Wayland. They > are only too small on X11 for me. > > Can you confirm? Also, are you using any display scaling or a non-default > font DPI value? The difference you are seeing on Wayland is because you are likely using the default Breeze theme which is hard-coded on Wayland. On X11, the GTK CSD titlebar buttons are auto-generated based on your selected window decoration, but this auto-generation creates the titlebar buttons too small. Try a different window decoration on Wayland and you will see it is broken as always shows Breeze. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435674] [X11] Maximized windows intermittently refuse to close from extreme top-right corner with HiDPI
https://bugs.kde.org/show_bug.cgi?id=435674 Paul McAuley changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437177] System Tray has excessive padding in 5.22 beta
https://bugs.kde.org/show_bug.cgi?id=437177 Paul McAuley changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437177] System Tray has excessive padding in 5.22 beta
https://bugs.kde.org/show_bug.cgi?id=437177 --- Comment #7 from Paul McAuley --- Created attachment 138615 --> https://bugs.kde.org/attachment.cgi?id=138615=edit Plasma 5.21.5 likely set width ... though I likely had it set to around 56 to allow larger application icons. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437177] System Tray has excessive padding in 5.22 beta
https://bugs.kde.org/show_bug.cgi?id=437177 --- Comment #6 from Paul McAuley --- Created attachment 138614 --> https://bugs.kde.org/attachment.cgi?id=138614=edit Plasma 5.21.5 minimum panel with for 2 columns of systray icons (In reply to Nate Graham from comment #5) > Do you happen to remember the panel width you had before which previously > let you have two columns of icons? In Plasma 5.21.5 I could have a minimum width of 52 to achieve 2 columns of systray icons. (2.5x scaling if that still makes a difference) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437177] System Tray has excessive padding in 5.22 beta
https://bugs.kde.org/show_bug.cgi?id=437177 --- Comment #4 from Paul McAuley --- Created attachment 138564 --> https://bugs.kde.org/attachment.cgi?id=138564=edit Panel with minimum width for 2 columns of system tray icons, edit mode (In reply to Nate Graham from comment #3) > Can you attach a screenshot that shows your system tray while the panel is > in edit mode? See attached. This is the minimum width for 2 columns of system tray icons. I want the panel as narrow as possible with 2 columns, and in 5.21 could have narrower than this. This might not seem a big deal, but if you reduce the padding/margin back to what it was, someone who wants the extra padding can easily get it by increasing the panel width or using a margin separator. This is not true in reverse, as I cannot get rid of the padding on current 5.22 beta. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437177] System Tray has excessive padding in 5.22 beta
https://bugs.kde.org/show_bug.cgi?id=437177 Paul McAuley changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Paul McAuley --- (In reply to Nate Graham from comment #1) > Do you have a Margins Separator applet in your panel? If so, you can remove > it to go back to the margins you had before. No, I do not have a margins separator. The margins are larger than before even without a margins separator. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 437277] New: kstyle git master: StyleConfigData::animationsEnabled() is false, despite default true, and despite global animations are set to default middle speed
https://bugs.kde.org/show_bug.cgi?id=437277 Bug ID: 437277 Summary: kstyle git master: StyleConfigData::animationsEnabled() is false, despite default true, and despite global animations are set to default middle speed Product: Breeze Version: unspecified Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- SUMMARY StyleConfigData::animationsEnabled() is false when global animations are set to default middle speed, despite the default for AnimationsEnabled also to be true. When the default middle animation speed is set the ~/.config/kdeglobals file also does not have a AnimationDurationFactor value in the [KDE] section. STEPS TO REPRODUCE 1. Boot into git master unstable build of Plasma 2. Go to Settings->Appearance->Application Style->Breeze->Scrollbars and set both arrow types to One button. 3. Go to settings->workspace behaviour->general behaviour and set the animation speed to the middle position. OBSERVED RESULT Scrollbar arrows do not auto-hide when the mouse is not over them. EXPECTED RESULT Scrollbar arrows should auto-hide when the mouse is not over them and animations are enabled. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.22.80 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 Kernel Version: 5.4.0-71-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 ADDITIONAL INFORMATION Upon further debugging I found that the reasons for this are twofold: 1. In kstyle/breezestyle.cpp I output the value of StyleConfigData::animationsEnabled() before the Style::loadGlobalAnimationSettings() function is called. On the git master StyleConfigData::animationsEnabled() returns false, despite the fact that true is the default value for AnimationsEnabled in breeze.kcfg. On release branches (e.g. 5.21.5/5.21.90 ) StyleConfigData::animationsEnabled() returns true as expected. 2. When the default middle animation speed is set, the ~/.config/kdeglobals file also does not have a AnimationDurationFactor value in the [KDE] section. In kstyle/breezestyle.cpp , Style::loadGlobalAnimationSettings() tries to read this value. There is no AnimationDurationFactor set in ~/.config/kdeglobals in both the git master and the release branches. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 437177] New: System Tray has excessive padding in 5.22 beta
https://bugs.kde.org/show_bug.cgi?id=437177 Bug ID: 437177 Summary: System Tray has excessive padding in 5.22 beta Product: plasmashell Version: 5.21.90 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com Target Milestone: 1.0 I have a vertical panel and like to have two columns of system tray icons -- now I have to make the panel unnecessarily wide to have two columns. Please could you reduce the padding around the left and right (vertical panel) of system tray icons to what it was before as now I believe it to be excessive. Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.21.90 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-lp152.75-preempt (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 435862] Blur effect not working in unstable builds
https://bugs.kde.org/show_bug.cgi?id=435862 --- Comment #4 from Paul McAuley --- (In reply to Vlad Zahorodnii from comment #3) > Those are binary window decoration. Does this issue affect also aurorae > decorations? Can you also post the output of `qdbus org.kde.KWin /KWin > supportInformation` please? Just tried, and yes it also affects aurorae decorations. Here is output when a transparent aurorae decoration is selected: ~> qdbus org.kde.KWin /KWin supportInformation KWin Support Information: The following information should be used when requesting support on e.g. https://forum.kde.org. It provides information about the currently running instance, which options are used, what OpenGL driver and which effects are running. Please post the information provided underneath this introductory text to a paste bin service like https://paste.kde.org instead of pasting into support threads. == Version === KWin version: 5.21.90 Qt Version: 5.15.2 Qt compile version: 5.15.2 XCB compile version: 1.13 Operation Mode: X11 only Build Options = KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_EGL_STREAMS: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === Vendor: The X.Org Foundation Vendor Release: 12003000 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration == Plugin: org.kde.kwin.aurorae Theme: __aurorae__svg__Freeze Plugin recommends border size: No Blur: 1 onAllDesktopsAvailable: false alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 9, 7 decorationButtonsRight: 6, 3, 4, 5 borderSize: 3 gridUnit: 24 font: Noto Sans,10,-1,0,50,0,0,0,0,0 smallSpacing: 6 largeSpacing: 24 Platform == Name: KWin::X11StandalonePlatform Cursor == themeName: breeze_cursors themeSize: 48 Options === focusPolicy: 0 xwaylandCrashPolicy: xwaylandMaxCrashCount: 3 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 28 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 28 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 28 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777250 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true compositingMode: 1 useCompositing: true hiddenPreviews: 1 glSmoothScale: 2 xrenderSmoothScale: false glStrictBinding: true glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 101 glPlatformInterface: 1 windowsBlockCompositing: true latencyPolicy: renderTimeEstimator: Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens === Multi-Head: no Active screen follows mouse: yes Number of Screens: 1 Screen 0: - Name: eDP-1 Geometry: 0,0,3840x2160 Scale: 1 Refresh Rate: 59.996 Compositing === Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2) OpenGL version string: 4.6 (Core Profile) Mesa 19.3.4 OpenGL platform interface: GLX OpenGL shading language version string: 4.60 Driver: Intel GPU class: Unknown OpenGL version: 4.6 GLSL version: 4.60 Mesa version: 19.3.4 X server version: 1.20.3 Linux kernel version: 5.3.18 Direct rendering: Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Loaded Effects: --- kwin4_effect_fullscreen kwin4_effect_windowaperture zoom kwin4_effect_translucency kwin4_effect_squash kwin4_effect_sessionquit kwin4_effect_morphingpopups kwin4_effect_maximize kwin4_effect_logout kwin4_effect_login kwin4_effect_frozenapp kwin4_effect_fadingpopups kwin4_effect_fade kwin4_effect_dialogparent slidingpopups slide screenshot desktopgrid coverswitch colorpicker pr
[kwin] [Bug 435862] Blur effect not working in unstable builds
https://bugs.kde.org/show_bug.cgi?id=435862 --- Comment #2 from Paul McAuley --- Just got 5.21.90 on OpenSUSE and now blur is not working for window decorations for this branch. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436844] Shaded windows no longer have shadows with Xrender Rendering backend
https://bugs.kde.org/show_bug.cgi?id=436844 --- Comment #2 from Paul McAuley --- (In reply to Paul McAuley from comment #0) > This bug does not occur on Plasma 5.21.5. That statement is not true. It does also occur in Plasma 5.21.5. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436844] Shaded windows no longer have shadows with Xrender Rendering backend
https://bugs.kde.org/show_bug.cgi?id=436844 Paul McAuley changed: What|Removed |Added Component|decorations |compositing Summary|Shaded windows no longer|Shaded windows no longer |have shadows|have shadows with Xrender ||Rendering backend --- Comment #1 from Paul McAuley --- Some more information: this only happens when the Compositor has its Rendering Backend set to XRender. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 436844] New: Shaded windows no longer have shadows
https://bugs.kde.org/show_bug.cgi?id=436844 Bug ID: 436844 Summary: Shaded windows no longer have shadows Product: kwin Version: git master Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@paulmcauley.com Target Milestone: --- On the 5.21.80 git master on KDE Neon, shaded windows do not have shadows. This occurs not only for the Breeze window decoration, but also for other Breeze-derived window decorations. This bug does not occur on Plasma 5.21.5. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.21.80 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 Kernel Version: 5.4.0-71-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 436147] [Wayland] Titlebar and rest of window are not aligned horizontally by 1px, HiDPI
https://bugs.kde.org/show_bug.cgi?id=436147 --- Comment #1 from Paul McAuley --- Attachment should say 5.21.4 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 436147] New: [Wayland] Titlebar and rest of window are not aligned horizontally by 1px, HiDPI
https://bugs.kde.org/show_bug.cgi?id=436147 Bug ID: 436147 Summary: [Wayland] Titlebar and rest of window are not aligned horizontally by 1px, HiDPI Product: Breeze Version: 5.21.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: window decoration Assignee: plasma-b...@kde.org Reporter: k...@paulmcauley.com CC: kwin-bugs-n...@kde.org Target Milestone: --- Created attachment 137891 --> https://bugs.kde.org/attachment.cgi?id=137891=edit Screenshot zoomed in on Breeze Plasma 5.21.3 Wayland, 250% display scaling See attached image. This is a Breeze window decoration on Wayland on Plasma 5.21.4. The horizontal alignment of the titlebar and rest of window is off by 1px with 250% display scaling. I'm not sure if this is related to the window decoration or kwin, but it does not occur on X11. Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-lp152.72-preempt OS Type: 64-bit Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 426795] [Wayland] One line of transparent pixels remains on top of maximized windows when using a HiDPI scale factor
https://bugs.kde.org/show_bug.cgi?id=426795 --- Comment #3 from Paul McAuley --- Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-lp152.72-preempt OS Type: 64-bit Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 630 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 426795] [Wayland] One line of transparent pixels remains on top of maximized windows when using a HiDPI scale factor
https://bugs.kde.org/show_bug.cgi?id=426795 Paul McAuley changed: What|Removed |Added Summary|One line of transparent |[Wayland] One line of |pixels remains on top of|transparent pixels remains |maximized windows when |on top of maximized windows |using a 150% scale factor |when using a HiDPI scale ||factor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 426795] One line of transparent pixels remains on top of maximized windows when using a 150% scale factor
https://bugs.kde.org/show_bug.cgi?id=426795 Paul McAuley changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #2 from Paul McAuley --- It also occurs at 200% -- You are receiving this mail because: You are watching all bug changes.
