[plasma-systemmonitor] [Bug 488044] Loading overlay doesn't cover full page when entering Edit Page mode
https://bugs.kde.org/show_bug.cgi?id=488044 --- Comment #2 from tqd8 --- I think the culprit might be here? https://invent.kde.org/plasma/plasma-systemmonitor/-/blob/master/src/page/EditablePage.qml?ref_type=heads#L206 I don't have the ability to test changes to this right now, but I'm listing this here just in case it helps out. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 488044] Loading overlay doesn't cover full page when entering Edit Page mode
https://bugs.kde.org/show_bug.cgi?id=488044 --- Comment #6 from tqd8 --- Ah nice thanks! -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 479826] New: Incorrect string in "Show Text" checkbox for toolbar actions
https://bugs.kde.org/show_bug.cgi?id=479826 Bug ID: 479826 Summary: Incorrect string in "Show Text" checkbox for toolbar actions Classification: Applications Product: dolphin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: tempqd...@mailinator.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When right clicking on an action in the Dolphin toolbar, you see a checkbox option to toggle whether the action's name is shown next to its icon. However, the checkbox has a different string (its `text` instead of its `iconText`), so it doesn't make sense. The checkbox should indicate the exact text that will be shown/hidden by checking/unchecking the box. These two strings happen to be identical for some actions, so it's not always visible, but one good example of this bug is for the "Select" action. Additionally, the `text` string seems to only appear in the Configure Toolbar dialog --- and it only appears on the left-hand "Available actions" list, not on the right-hand "Current actions" list, which seems strange to me too. Maybe this issue is not specific to Dolphin alone? OS: openSUSE Krypton, latest snapshot -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 479826] Incorrect string in "Show Text" checkbox for toolbar actions
https://bugs.kde.org/show_bug.cgi?id=479826 --- Comment #1 from tqd8 --- Created attachment 164908 --> https://bugs.kde.org/attachment.cgi?id=164908&action=edit Incorrect text for "Select" action's Show Text checkbox -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 489756] New: System tray icon hover highlight broken on dark themes
https://bugs.kde.org/show_bug.cgi?id=489756 Bug ID: 489756 Summary: System tray icon hover highlight broken on dark themes Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: mate...@gmail.com Target Milestone: 1.0 Created attachment 171385 --> https://bugs.kde.org/attachment.cgi?id=171385&action=edit Hovering over system tray icons, with Breeze light and Breeze dark SUMMARY It looks like the hover effect on system tray icons is working fine on light themes (dark icons), but is broken on dark themes (light icons). The animation just flickers once instead of staying highlighted. Video attached. OS: openSUSE Krypton (today's git master) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 489759] New: System tray icon hover animation does not continuously fade from dark to light (for some parts of icons)
https://bugs.kde.org/show_bug.cgi?id=489759 Bug ID: 489759 Summary: System tray icon hover animation does not continuously fade from dark to light (for some parts of icons) Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: mate...@gmail.com Target Milestone: 1.0 Created attachment 171388 --> https://bugs.kde.org/attachment.cgi?id=171388&action=edit Hovering over system tray icons with slow animation speed SUMMARY When hovering over a system tray icon, we expect the icon to highlight continuously from normal to bright. However, if the icon has light parts (e.g. disconnected Wi-Fi, low speaker volume), those parts first get darker and then brighter. Video attached: Battery icon goes from normal to bright continuously as expected. Wi-Fi icon goes from light to dark to light. Speaker icon has parts that do both. (Note this is only visible with Breeze light due to bug#489756) OS: openSUSE Krypton (today's git master) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 489761] New: System tray icon hover animation instantly resets, rather than smoothly resetting
https://bugs.kde.org/show_bug.cgi?id=489761 Bug ID: 489761 Summary: System tray icon hover animation instantly resets, rather than smoothly resetting Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: mate...@gmail.com Target Milestone: 1.0 Created attachment 171389 --> https://bugs.kde.org/attachment.cgi?id=171389&action=edit Full hover animations; interrupted hover; interrupted un-hover SUMMARY The hover highlight animation is a smooth fade/blend. However, if you unhover before the animation has completed, it instantly resets back to the initial state. Hard to notice at normal animation speeds; it just looks like something is slightly off or glitchy. But at slow animation speeds it is very apparent. Video attached that shows: 1. Full hover and unhover animations, smoothly highlighted 2. Hover animation interrupted, instantly un-highlighted 3. Un-hover animation interrupted, instantly re-highlighted Expected: 1. Full hover and unhover animations, smoothly highlighted 2. Hover animation interrupted, smoothly un-highlights over time 3. Un-hover animation interrupted, smoothly re-highlights over time (Note this is only visible with Breeze light due to bug#489756) OS: openSUSE Krypton (today's git master) -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 488044] Loading overlay doesn't cover full page when entering Edit Page mode
https://bugs.kde.org/show_bug.cgi?id=488044 --- Comment #9 from tqd8 --- Created attachment 171390 --> https://bugs.kde.org/attachment.cgi?id=171390&action=edit Elements overlapping scrollbar while loading overlay is present Looks like another similar issue is happening now (on today's git master). Not sure if it was there before. When the loading overlay pops up, the underlying content can overlap the scrollbar (visible if you hover to highlight it). Note this only happens when the page doesn't have a scrollbar to begin with and only gets a scrollbar when the overlay appears. (That's maybe another bug: it seems the overlay is taller than the page, so when it appears, it gets a scrollbar no matter what.) So I'm guessing the margins/anchors of the elements underneath somehow don't take this temporary scrollbar width into account? Not sure if I should reopen or file a new bug report. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384782] Allow manually re-ordering tray icons
https://bugs.kde.org/show_bug.cgi?id=384782 --- Comment #41 from tqd8 --- (In reply to sethbotstar from comment #40) > I think it'd be great if the Entries in the settings had no > effect on how the icons were actually ordered in the panel, > it's just a convenient way to see what group it's under, > why should it have any effect on the actual order? If there's manual re-ordering, then there's no need for groups anymore. How often does one actually need to re-arrange tray icons on the fly? I think accidentally dragging a tiny icon (intending to simply click it) is a much more likely/frequent occurrence than purposely dragging one. If you need to configure tray icons, there's already only one place you can configure *when* an icon is shown/hidden -- the Entries list. So I'd say that, if you want to configure the *order* too, it makes sense to have that in the same place, rather than having the configuration split between the settings and the tray itself. I suppose draggable tray icons could be a toggleable option if users really want it though. Just might complicate the implementation a good bit. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 490633] New: When changing volume rapidly, the feedback sound pops/clicks
https://bugs.kde.org/show_bug.cgi?id=490633 Bug ID: 490633 Summary: When changing volume rapidly, the feedback sound pops/clicks Classification: Plasma Product: plasma-pa Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: isma...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY It seems the volume OSD's feedback sound immediately interrupts itself when re-triggered before the full sound has played. When any audio file's volume goes instantly to 0 (or a different value), this causes a click/pop noise. If the sound instead smoothly (but still quickly) faded to 0, there would be no clicks/pops and it would be much less abrasive to hear, and would be perceived as much less glitchy. When the volume down key is *held* (depending on how fast your key repeat rate is set), there's all kinds of ugly-sounding glitches; maybe there should additionally be a limit to how rapidly the sound can be played? STEP TO REPRODUCE 1. Press the volume down (or up) key rapidly, such that the feedback sounds interrupt each other OBSERVED RESULT Clicks and pops are heard EXPECTED RESULT No clicks or pops are heard OS: openSUSE Krypton (today's git master) -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 488044] Loading overlay doesn't cover full page when entering Edit Page mode
https://bugs.kde.org/show_bug.cgi?id=488044 --- Comment #11 from tqd8 --- 1. Ensure the System Monitor page is scaled large enough so that it has no scrollbar 2. Click "Edit Page" 3. A scrollbar appears -- move your mouse all around it. You should see the blue squares peeking into the scrollbar where your mouse hovers (like in my screenshot). Note: this doesn't happen if, in step 1, the page is small enough that it *does* have a scroll bar to begin with. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 485399] Feature Request: Native PipeWire graph control
https://bugs.kde.org/show_bug.cgi?id=485399 --- Comment #4 from tqd8 --- I was just thinking about discoverability (people may not know it exists) and a more streamlined implementation built right into the interface. Could still download qpwgraph for more control either way. Or maybe we could add a small indicator saying that graph apps are available, like in https://invent.kde.org/system/dolphin/-/merge_requests/674 or the browser integration? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 484901] Indicate whether reboot is needed in system tray icon
https://bugs.kde.org/show_bug.cgi?id=484901 --- Comment #1 from tqd8 --- Oh wait, to be clear: I mean to indicate a required restart in Discover's icon itself *even before* installation. I know we have a separate icon (that said, do some distros not use it?) for indicating a restart is required after installation. However I think that one could also be combined into Discover's circled-up-arrow icon rather than being separate. Hope this makes sense? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489761] Plasma widget tooltip appear/disappear hover animation instantly resets, rather than smoothly resetting
https://bugs.kde.org/show_bug.cgi?id=489761 --- Comment #3 from tqd8 --- Oh sorry, in retrospect I was completely ambiguous about this: this bug report refers to the *color of the tray icon itself changing* (getting lighter), not the popup boxes. Oops! My eyes completely glossed over the tooltip animations in my screencast. I will have to more closely investigate those as well separately, and I also want to make sure they visually mesh well with the icon animations after they're fixed. If this makes sense, I'll let you change the title again? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 470141] New: Plasma 6 suggestion: Monochrome group application indicator
https://bugs.kde.org/show_bug.cgi?id=470141 Bug ID: 470141 Summary: Plasma 6 suggestion: Monochrome group application indicator Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com Target Milestone: 1.0 SUMMARY The green circle with a plus symbol sticks out like a sore thumb compared to the monochrome icons in the rest of the taskbar. Plus, it's unclear to new users what it's trying to indicate. A green color, as opposed to the rest of the icons' neutral/monochrome color, communicates moreso that e.g. something has succeeded or that something good can be triggered. Is there an update available? Does clicking the green plus create a new window? Does it install a new feature? For something so simple and essential to the user experience --- indication that there is more than one window open --- I think it makes more sense to have a more subdued indicator icon. Windows 10/11 have stacked app squares as an indicator, which is elegant but sort of noisy. Maybe in the long run we can get more creative here, like in https://www.reddit.com/r/kde/comments/yggk5n/fancy_tasks_update/ ? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 470187] New: Clarify wording of mouse/touchpad acceleration settings
https://bugs.kde.org/show_bug.cgi?id=470187 Bug ID: 470187 Summary: Clarify wording of mouse/touchpad acceleration settings Classification: Applications Product: systemsettings Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: minor Priority: NOR Component: kcm_mouse Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: natalie_clar...@yahoo.de Target Milestone: --- SUMMARY The wording of "flat" and "adaptive" (and "acceleration profile" itself) seems unclear and perhaps overly technical. Plus, the word "adaptive" nowadays sounds more like it will learn from how you use the mouse and adapt itself over time, in a machine-learning sense. Or, it sounds like perhaps it will adapt based on the context your pointer is in, i.e. different applications will have different pointer behavior. What it really means is that there is simply acceleration. Calling it a "profile" and having the radio buttons with two options below the pointer speed bar also makes it seem like the choice will determine how the speed bar behaves. To me, "adaptive profile" seems like the bar will set how adaptive the acceleration is (which is not how it works, I don't think), especially in the touchpad settings where the bar is labeled "pointer acceleration" (should be labeled speed, I assume). I might suggest a simple toggle switch, "Acceleration: on/off". The hover (or perhaps an [i]) tooltip wording here (seemingly only in touchpad settings, by the way) would be trickier with only one on/off choice. In general the distinction between speed (velocity) and acceleration of the pointer is muddy when the user is constantly changing the pointer's speed themselves by moving their real-life mouse/finger at different speeds. So, maybe a better term than "acceleration" is possible here, like "boost" or "thrust" or something? OS: openSUSE Tumbleweed, latest snapshot -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 470188] New: Add mouse/touchpad safety measures
https://bugs.kde.org/show_bug.cgi?id=470188 Bug ID: 470188 Summary: Add mouse/touchpad safety measures Classification: Applications Product: systemsettings Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: minor Priority: NOR Component: kcm_mouse Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: natalie_clar...@yahoo.de Target Milestone: --- SUMMARY Currently if you disable the touchpad on a laptop and click apply, you are left with no pointer control and have to suddenly improvise and quickly learn to use the keyboard navigation to re-enable it, which is not very straightforward (I just tried it out with no prior experience and it was pretty challenging). Adding a "keep/revert" timer popup, like when changing display settings, could be a nice user safety feature. This could also help if you set your pointer speed way too high (or low) and consequently have difficulty hitting the buttons and moving the sliders to lower it back down. The touchpad settings have a spinbox to control the pointer speed in addition to the slider bar, but the mouse settings seem to lack one. The spinbox is helpful because, rather than slamming the bar to its edges with a speedy pointer, you can spend a few minutes positioning your mouse just right and then just click repeatedly until the speed is lowered back down (or type it in), then spend a few more minutes positioning your mouse over the Apply button. OS: openSUSE Tumbleweed, latest snapshot -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475988] New: Change header dropdown from "window borders" to "button size"
https://bugs.kde.org/show_bug.cgi?id=475988 Bug ID: 475988 Summary: Change header dropdown from "window borders" to "button size" Classification: Applications Product: systemsettings Version: master Platform: unspecified OS: Unspecified Status: REPORTED Severity: minor Priority: NOR Component: kcm_kwindecoration Assignee: kwin-bugs-n...@kde.org Reporter: tempqd...@mailinator.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Changing the size of the min/max/close/etc buttons is a much more common task than changing the window border size. In fact, the window border options are kind of weird-looking with the default Breeze theme. Plus it'd be a smaller dropdown that would make the currently-crowded header more neat. And it'd nicely match the "Configure Titlebar Buttons" button right next to it. (Or, alternatively, adding the button size dropdown to the "Configure Titlebar Buttons" page would be good.) Would be better to have the border size dropdown within each individual theme configuration (e.g. "Edit Breeze Theme"). OS: KDE Neon Unstable (2023 10 22) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475990] New: Inconsistent configuration popup behavior
https://bugs.kde.org/show_bug.cgi?id=475990
Bug ID: 475990
Summary: Inconsistent configuration popup behavior
Classification: Applications
Product: systemsettings
Version: master
Platform: unspecified
OS: Unspecified
Status: REPORTED
Severity: minor
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: tempqd...@mailinator.com
Target Milestone: ---
SUMMARY
In Global Theme settings, one can configure individual themes for Colors,
Application Style, and Window Decorations. However, their popups are not
consistent.
Edit Color Scheme...:
* Footer buttons are Reset, Save As..., Close
* Middle tab ("Colors") is selected upon opening instead of leftmost tab
* Closing without saving changes has warning popup ("You have unsaved changes.
Do you really want to quit?") which differs from System Settings' warning
popup. You can still click things in System Settings while the screen is
dimmed. It only appears if you click footer Close button, and not window X
button.
Configure Style...:
* Footer buttons are Defaults, OK, Cancel
* Footer buttons do not have tooltips on hover
* No warning popup when closing with unsaved changes
Edit [Name] Theme:
* Footer buttons are Help, Reset, Defaults, OK, Apply, Cancel
* Has large header ("[Name] Window Decoration") above tabs
* No warning popup when closing with unsaved changes
OS: KDE Neon Unstable (2023 10 22)
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 475991] New: Search has shrink animation but no grow animation
https://bugs.kde.org/show_bug.cgi?id=475991 Bug ID: 475991 Summary: Search has shrink animation but no grow animation Classification: Applications Product: systemsettings Version: master Platform: unspecified OS: Unspecified Status: REPORTED Severity: minor Priority: NOR Component: kcm_colors Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: noaha...@gmail.com, tantalising...@gmail.com, uhh...@gmail.com Target Milestone: --- SUMMARY When searching for color schemes (which, by the way, is this feature still necessary?), narrowing down the results makes themes shrink when disappearing. However, when more themes appear, they appear instantly with no animation. STEPS TO REPRODUCE 1. Have Breeze Classic, Breeze Light, Breeze Dark themes 2. Search for "a" and watch Breeze Light shrink and disappear 3. Search for "ar" and watch Breeze Classic shrink and disappear, then Breeze Dark slide over to the first position 4. Search for "a" and watch Breeze Classic instantly appear at first position, while simultaneously Breeze Dark instantly appears at second position EXPECTED RESULT Step 4 should be Breeze Dark sliding over to second position, then Breeze Classic growing in the first position Sorry about no screen recording! OS: KDE Neon Unstable (2023 10 22) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475992] New: "Play a sound" preview doesn't respect Ocean theme
https://bugs.kde.org/show_bug.cgi?id=475992 Bug ID: 475992 Summary: "Play a sound" preview doesn't respect Ocean theme Classification: Applications Product: systemsettings Version: master Platform: unspecified OS: Unspecified Status: REPORTED Severity: normal Priority: NOR Component: kcm_notify Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: k...@privat.broulik.de Target Milestone: --- SUMMARY When previewing a notification's sound with Ocean sound theme applied, it always plays the Oxygen sound effect instead. If FreeDesktop sound theme is applied, it plays the FreeDesktop sound effect, as expected. If Oxygen sound theme is applied, it plays the Oxygen sound effect, as expected. (Overall, the sound selection popup could be improved, it's a bit confusing seeing the filesystem.) OS: KDE Neon Unstable (2023 10 22) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475990] Inconsistent configuration popup behavior
https://bugs.kde.org/show_bug.cgi?id=475990 --- Comment #2 from tqd8 --- (In reply to Nate Graham from comment #1) > I'm afraid this isn't one bug, it's many one per issue on each page. See > https://community.kde.org/Get_Involved/ > Issue_Reporting#Multiple_issues_in_a_single_Bugzilla_ticket. Feel free to > submit new bug reports, one per issue. Thanks for understanding! Sure! Should I make, for instance, the following 3? Bug report 1 - "Colors KCM: make popup consistent with other Global Theme KCM popups" Bug report 2 - "Application Style KCM: make popup consistent with other Global Theme KCM popups" Bug report 3 - "Window Decorations KCM: make popup consistent with other Global Theme KCM popups" And copy/paste my 3 bulleted lists there, one list per report? I was assuming a dev working on making these 3 popups consistent with each other would need a centralized list of inconsistencies, but I can split them up if that'd be better! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475988] Change header dropdown from "window borders" to "button size"
https://bugs.kde.org/show_bug.cgi?id=475988 --- Comment #2 from tqd8 --- Created attachment 162521 --> https://bugs.kde.org/attachment.cgi?id=162521&action=edit Window borders dropdown -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475988] Change header dropdown from "window borders" to "button size"
https://bugs.kde.org/show_bug.cgi?id=475988 --- Comment #3 from tqd8 --- Created attachment 162522 --> https://bugs.kde.org/attachment.cgi?id=162522&action=edit Button size dropdown -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 476062] New: Colors KCM: Make "configure" popup consistent with other Global Theme KCM popups
https://bugs.kde.org/show_bug.cgi?id=476062
Bug ID: 476062
Summary: Colors KCM: Make "configure" popup consistent with
other Global Theme KCM popups
Classification: Applications
Product: systemsettings
Version: master
Platform: unspecified
OS: Unspecified
Status: REPORTED
Severity: minor
Priority: NOR
Component: kcm_colors
Assignee: plasma-b...@kde.org
Reporter: tempqd...@mailinator.com
CC: noaha...@gmail.com, tantalising...@gmail.com,
uhh...@gmail.com
Target Milestone: ---
SUMMARY
In Global Theme settings, one can configure individual themes for Colors,
Application Style, and Window Decorations. However, their popups are not
consistent.
* Tooltip is "Edit Color Scheme..." which differs from the other two's tooltips
* Footer buttons are "Reset, Save As..., Close" which differs from others
* Middle tab ("Colors") is selected upon opening instead of leftmost tab
* Closing without saving changes has warning popup ("You have unsaved changes.
Do you really want to quit?") which differs from System Settings' warning
popup. You can still click things in System Settings while the screen is
dimmed. It only appears if you click footer Close button, and not window X
button. The other two KCMs' behavior for saving changes differs from this.
(Centralized report for all 3 popups here:
https://bugs.kde.org/show_bug.cgi?id=475990)
OS: KDE Neon Unstable (2023 10 22)
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 476063] New: Application Style KCM: Make "configure" popup consistent with other Global Theme KCM popups
https://bugs.kde.org/show_bug.cgi?id=476063 Bug ID: 476063 Summary: Application Style KCM: Make "configure" popup consistent with other Global Theme KCM popups Classification: Applications Product: systemsettings Version: master Platform: unspecified OS: Unspecified Status: REPORTED Severity: normal Priority: NOR Component: kcm_style Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: m...@gikari.com Target Milestone: --- SUMMARY In Global Theme settings, one can configure individual themes for Colors, Application Style, and Window Decorations. However, their popups are not consistent. * Tooltip is "Configure Style..." which differs from the other two's tooltips * Footer buttons are "Defaults, OK, Cancel" which differs from others * Footer buttons do not have tooltips on hover, unlike the others * No warning popup when closing with unsaved changes, unlike the Colors KCM (Centralized report for all 3 popups here: https://bugs.kde.org/show_bug.cgi?id=475990) OS: KDE Neon Unstable (2023 10 22) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 476064] New: Window Decorations KCM: Make "configure" popup consistent with other Global Theme KCM popups
https://bugs.kde.org/show_bug.cgi?id=476064
Bug ID: 476064
Summary: Window Decorations KCM: Make "configure" popup
consistent with other Global Theme KCM popups
Classification: Applications
Product: systemsettings
Version: master
Platform: unspecified
OS: Unspecified
Status: REPORTED
Severity: normal
Priority: NOR
Component: kcm_kwindecoration
Assignee: kwin-bugs-n...@kde.org
Reporter: tempqd...@mailinator.com
CC: plasma-b...@kde.org
Target Milestone: ---
SUMMARY
In Global Theme settings, one can configure individual themes for Colors,
Application Style, and Window Decorations. However, their popups are not
consistent.
* Tooltip is "Edit [Name] Theme" which differs from the other two's tooltips
(also the only one without ellipsis)
* Footer buttons are "Help, Reset, Defaults, OK, Apply, Cancel" which differs
from others
* Has a large header ("[Name] Window Decoration") above tabs, which others
don't have (and is probably redundant)
* No warning popup when closing with unsaved changes, unlike the Colors KCM
(Centralized report for all 3 popups here:
https://bugs.kde.org/show_bug.cgi?id=475990)
OS: KDE Neon Unstable (2023 10 22)
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 475990] Inconsistent configuration popup behavior
https://bugs.kde.org/show_bug.cgi?id=475990 --- Comment #4 from tqd8 --- Thanks, done! https://bugs.kde.org/show_bug.cgi?id=476062 https://bugs.kde.org/show_bug.cgi?id=476063 https://bugs.kde.org/show_bug.cgi?id=476064 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475988] Change header dropdown from "window borders" to "button size"
https://bugs.kde.org/show_bug.cgi?id=475988 --- Comment #5 from tqd8 --- Okay, thanks! What do you think about adding (or moving) the Button Size dropdown to the "Configure Titlebar Buttons" page? So that you could change what the buttons are, and also change how big they are, on the same page. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384782] Allow manually re-ordering tray icons
https://bugs.kde.org/show_bug.cgi?id=384782
tqd8 changed:
What|Removed |Added
CC||tempqd...@mailinator.com
--- Comment #37 from tqd8 ---
I think the solution here could be pretty simple. A draggable ordered list of
entries in the settings menu, with two options of how to place newly-appeared
('shown when relevant') icons: always in the specified order, or always added
onto the end.
(Plus another option to reverse the displayed order of the tray, if you want
the up-arrow on the other side, perhaps)
In the popup's grid of hidden icons, the order would also follow the ordered
list of entries. (Or, if really desired, we could have one ordered list for
in-tray, and a separate ordered list for in-popup, but that'd maybe be
excessive)
To illustrate:
>Entries:
>App 1Always shown [-Drag-]
>App 2Shown when relevant [-Drag-]
>App 3Always shown [-Drag-]
>App 4Always shown [-Drag-]
>App 5Always hidden[-Drag-]
>App 6Always shown [-Drag-]
Tray when App 2 is idle:
> [1] [3] [4] [6] ^
Tray when App 2 becomes relevant (in-order setting):
> [1] (2) [3] [4] [6] ^
Tray when App 2 becomes relevant (added-onto-end setting):
> [1] [3] [4] [6] (2) ^
I don't think having the icons themselves draggable is important, as it might
complicate the logic, but I think it'd be possible to still pull off. No
groups/categories necessary in the entries list.
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 470187] Clarify wording of mouse/touchpad acceleration settings
https://bugs.kde.org/show_bug.cgi?id=470187 --- Comment #2 from tqd8 --- (In reply to Nate Graham from comment #1) > > Pointer acceleration: (O) Standard > > ( ) None > > ( ) [ Customize... ] That layout looks great to me. Custom acceleration sounds cool! Should I make a new bug report for the inconsistencies between mouse & touchpad settings (slider label and spinbox), or is this intended? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 470188] Mouse and touchpad can be disabled when they're the only input devices
https://bugs.kde.org/show_bug.cgi?id=470188 --- Comment #2 from tqd8 --- Makes sense to me. Maybe also count touchscreen since it can practically replace a mouse/touchpad too? The only counterpoint I can think of is users who want to go keyboard-only and disable a laptop's touchpad, but I'd assume that's pretty niche. Newer or less-savvy users are probably a better demographic to have in mind for this, I'd say. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 470316] New: Safety: Don't auto-unmute when lowering volume
https://bugs.kde.org/show_bug.cgi?id=470316 Bug ID: 470316 Summary: Safety: Don't auto-unmute when lowering volume Classification: Plasma Product: plasma-pa Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: isma...@gmail.com, m...@ratijas.tk, now...@gmail.com Target Milestone: --- SUMMARY A cool new feature I noticed in another OS is that, when the audio is muted, lowering the volume doesn't unmute automatically. This is (I assume) a safety feature: if your audio is too loud and you panic-mute to save your eardrums, you want to be able to lower the volume to a safe level before unmuting. Similarly, it may be desirable to disallow holding down the volume up shortcut to rapidly raise volume. If the key gets stuck, the audio can very quickly reach ear-damaging levels with no warning. STEPS TO REPRODUCE 1. Mute audio 2. Press "volume down" key shortcut (or drag volume slider down) OBSERVED RESULT Audio is unmuted and lowered simultaneously EXPECTED RESULT Audio lowers and remains muted OS: openSUSE Tumbleweed, latest snapshot -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 488044] New: Loading overlay doesn't cover full page when entering Edit Page mode
https://bugs.kde.org/show_bug.cgi?id=488044 Bug ID: 488044 Summary: Loading overlay doesn't cover full page when entering Edit Page mode Classification: Applications Product: plasma-systemmonitor Version: master Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: tempqd...@mailinator.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- Created attachment 170154 --> https://bugs.kde.org/attachment.cgi?id=170154&action=edit Screencast of loading overlay issue, not covering full page When clicking "Edit Page", the full-page overlay (containing the spinning gear icon) appears to cover only part of the page. The System Monitor sections on the page seem to peek out over the top of the overlay. Video attached. Happens at fractional and 100% scale, X11 and Wayland, at any window size. OS: openSUSE Krypton (today's git master) -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 484901] New: Indicate whether reboot is needed in system tray icon
https://bugs.kde.org/show_bug.cgi?id=484901 Bug ID: 484901 Summary: Indicate whether reboot is needed in system tray icon Classification: Applications Product: Discover Version: unspecified Platform: unspecified OS: Unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: Notifier Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: aleix...@kde.org Target Milestone: --- Currently, you can't tell from the tray icon whether a restart is needed for the available updates. The icon always shows a circular arrow surrounding the big up-arrow. This circular arrow iconography is used in the "reboot system" icon, so it's a bit conflated here. What if we split it into two icons: * Updates available: just an up-arrow (or up-arrow with closed circle surrounding it) * Updates available and reboot required: up-arrow with circular arrow surrounding it That way, you can tell at a glance whether a restart is needed, and you can infer whether changes will take effect immediately or only after restart, increasing predictability in behavior. This info may also be important to users when deciding whether to update right away or wait until later. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 485399] New: Feature Request: Native PipeWire graph control
https://bugs.kde.org/show_bug.cgi?id=485399 Bug ID: 485399 Summary: Feature Request: Native PipeWire graph control Classification: Plasma Product: plasma-pa Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: tempqd...@mailinator.com CC: isma...@gmail.com, m...@ratijas.tk Target Milestone: --- I think it could be nice to have PipeWire graph/routing controls (like qpwgraph/Helvum) built right into Plasma. Linux is very fortunate to have this very powerful system for audio, but this capability is not very discoverable. You have to know to download a 3rd party routing graph GUI in order to easily reach these controls. What if we had something like an "Advanced Audio Controls" section in the applet or kcm to expose some basic native graphical control of PipeWire routing? I imagine even the most barebones routing graph (no fancy saving/loading of configurations or L/R splitting or anything) could open up a whole world for users to control their audio and devices in ways that no other OS has natively. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 485399] Feature Request: Native PipeWire graph control
https://bugs.kde.org/show_bug.cgi?id=485399 --- Comment #2 from tqd8 --- Very fair! I indeed had power users in mind (powerful when needed!). For future implementers' reference, I can think of a few simple use cases off the top of my head, although I have no idea how common/niche these are among most users: * Two people listening to the same PC with two different pairs of headphones (instead of sharing one pair of earbuds) * Playing an audio file during a voice call without having to share your entire screen * Excluding your music from a screen share/recording I do want to try to implement this myself at some point in the future, though it might prove to be too difficult for me. -- You are receiving this mail because: You are watching all bug changes.
