[kwin] [Bug 366651] Kwin Compositor Stops Updating Windows
https://bugs.kde.org/show_bug.cgi?id=366651 Rickard Westman changed: What|Removed |Added CC||rwest...@bredband.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 410594] Reverse switching uses "recently used" when "stacking order" is chosen
https://bugs.kde.org/show_bug.cgi?id=410594 --- Comment #6 from Rickard Westman --- Seems fixed as of this version: Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 With this version, the reproduction steps in the original report no longer triggers the bug, and the seemingly related problem in comment #1 doesn't occur either. I haven't changed the status of the bug since I'm not a KDE developer, but perhaps it should be. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 342326] window contents freeze
https://bugs.kde.org/show_bug.cgi?id=342326 Rickard Westman changed: What|Removed |Added CC||rwest...@bredband.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 440540] Toggle raise lower no longer lowers windows
https://bugs.kde.org/show_bug.cgi?id=440540 --- Comment #6 from Rickard Westman --- (In reply to Nate Graham from comment #5) > I'm afraid Plasma 5.20.5 is unfortunately no longer eligible for support or > maintenance from KDE. (...) > If this issue is still reproducible for you in Plasma 5.27, feel free to > re-open this bug report. What about Plasma 5.24.7 – is that as unmaintained as 5.20.5? Because I see the bug with Kubuntu 22.04 running Plasma 5.24.7. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 440540] Toggle raise lower no longer lowers windows
https://bugs.kde.org/show_bug.cgi?id=440540 --- Comment #4 from Rickard Westman --- Confirming this still happens with kwin 5.24.7 on Kubuntu 22.04 (X11). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 440540] Toggle raise lower no longer lowers windows
https://bugs.kde.org/show_bug.cgi?id=440540 Rickard Westman changed: What|Removed |Added CC||rwest...@bredband.net -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 464234] New: Left-clicking in history pane messes up subsequent formatting
https://bugs.kde.org/show_bug.cgi?id=464234 Bug ID: 464234 Summary: Left-clicking in history pane messes up subsequent formatting Classification: Applications Product: kcalc Version: 21.12.3 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ete...@alum.rit.edu Reporter: rwest...@bredband.net Target Milestone: --- Created attachment 155257 --> https://bugs.kde.org/attachment.cgi?id=155257=edit Screenshot showing garbled history output SUMMARY If you click the left mouse button in the history pane, subsequent calculations are not inserted cleanly at the top anymore, but intermingled with old calculations. STEPS TO REPRODUCE 1. Ensure history pane is enabled. 2. Calculate 1+2 (calculation shows up in history) 3. Left-click somewhere below "1 + 2 = 3" in the history pane. 4. Calculate 3*4 OBSERVED RESULT History now shows one line: "3 x 4 = 121 + 2 = 3" EXPECTED RESULT History should show two separate lines: "3 x 4 = 12" and "1 + 2 = 3". SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION The bad effect is delayed and might therefore not be associated with the click (Bug 452061, closed with status RESOLVED WORKSFORME, is probably an example of this bug). Possible reasons why the user might click in the pane: 1) Wanting to focus the entire window (click-to-focus) and choosing the history pane as it's a large and seemingly passive area. 2) Wanting to select some older result for copy & paste. 3) Exploring possibly hidden functionality in the history pane (that's how I ran into it). -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 463278] "Time from now" alarms are unexpectedly imprecise
https://bugs.kde.org/show_bug.cgi?id=463278 --- Comment #6 from Rickard Westman --- That sounds like a good idea! Perhaps rounding to the nearest minute (rather than truncating) would also be a rather simple change, cutting the relative error in half? -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 463278] "Time from now" alarms are unexpectedly imprecise
https://bugs.kde.org/show_bug.cgi?id=463278 --- Comment #4 from Rickard Westman --- It's not really stopwatch accuracy I expect, but more like kitchen timer accuracy. An alarm set for 2 minutes should not trigger after 1 minute. An alarm set for 1 minute should not trigger after 0 seconds. So it's not really about users being surprised they don't get precision down to the second, but more of an expectation that the minutes they specify in KAlarm are about as long as a minute is in real life. So a minute implemented as 58 seconds or 62 seconds could be within expectations, but a minute implemented as 0 seconds or 120 seconds would not. I don't really buy the argument that a time interval specified in minutes comes with an expectation that the error can also be up to a minute – the relative error matters as well, and a relative error of 100% (as can happen with KAlarm) is just too huge to be reasonably expected. -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 463278] "Time from now" alarms are unexpectedly imprecise
https://bugs.kde.org/show_bug.cgi?id=463278 --- Comment #2 from Rickard Westman --- I understand the technical reason, but when you can set an alarm for 1 minute and it fires after 1 second, it strains belief that any non-developer could see that as expected and intended behavior. So even if it's intentional from a technical/internal perspective, I'd encourage thinking about it from the user perspective. What is the user intent of specifying a 1 minute interval? To get an alarm after 1 minute, or getting an alarm at a random time between 0 and 60 seconds? Is there any scenario at all where the latter would be useful? -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 463278] New: "Time from now" alarms are unexpectedly imprecise
https://bugs.kde.org/show_bug.cgi?id=463278 Bug ID: 463278 Summary: "Time from now" alarms are unexpectedly imprecise Classification: Applications Product: kalarm Version: 3.3.6 Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: djar...@kde.org Reporter: rwest...@bredband.net Target Milestone: --- STEPS TO REPRODUCE 1. Open the dialog box for a new display alarm. 2. For the alarm time, select "Time from now" with a period of 1 minute, but don't click OK immediately. 3. Wait until the system time is 5 seconds before a whole minute, then click OK. OBSERVED RESULT The display alarm is triggered after 5 seconds, rather than the requested 1 minute. EXPECTED RESULT I expected the display alarm to trigger after 1 minute, precise to the second or so. SOFTWARE/OS VERSIONS Linux distribution: Kubuntu 22.04.1 LTS KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL COMMENTS I assume the alarm trigger time is always converted to an absolute time, and that the truncation to whole minutes takes place because absolute times are only kept with minute precision. Fine for absolute trigger times, but not really adequate for relative times which could reasonably be a small number of minutes. For minimal changes, perhaps store the time with second precision and use that for triggering, but round to nearest minute when shown/edited as an absolute time in the UI? -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 411525] New: Editing existing events in KOrganizer suddenly stopped working, restarting Akonadi helped
https://bugs.kde.org/show_bug.cgi?id=411525
Bug ID: 411525
Summary: Editing existing events in KOrganizer suddenly stopped
working, restarting Akonadi helped
Product: korganizer
Version: 5.7.3
Platform: Kubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: incidence editors
Assignee: kdepim-b...@kde.org
Reporter: rwest...@bredband.net
Target Milestone: ---
SUMMARY
I opened KOrganizer to edit an event that I'd dealt with, and thus didn't need
to be reminded of any more. At the time, it had an active reminder that was
suspended for 30 minutes, and a number of scheduled reminders for the next few
days. When I double-clicked on the event, the event editor didn't open as it
normally does. Double-clicking on other events did not open the event editor
either, and neither did selecting events and choosing "Edit" in the Action
menu. The mouse-over information for the event displayed OK, so it's not that
the event information could be accessed at all.
Looking at the .xsession-errors log, I could see the following error message
occuring every time I attempted to open the editor:
org.kde.pim.incidenceeditor: free slot calculation: invalid range.
range( 0 ) / mSlotResolutionSeconds( 900 ) = 0
As a workaround, I first tried restarting KOrganizer by selecting "Quit" in its
main meny, and launching it again. The problem persisted. I recalled that
another spurious KOrganizer malfunction corrected itself when I restarted
Akonadi, so I tried that ("akonadictl stop", waiting for a few seconds, then
"akonadictl start"). This did the trick, and I no longer see the problem. I
noticed that the error message quoted above still showed up every time I opened
the editor for an event, so maybe it's unrelated to the actual problem.
STEPS TO REPRODUCE
I tried to reproduce the problem, but couldn't. I've only seen it once, but
I've seen several other spurious KOrganizer problems that resolve when Akonadi
is restarted. Perhaps every other week or so in a long-running session.
Despite being irreproducible, I thought I'd report it, since a non-technical
user would not think of restarting Akonadi, resulting in a quite serious
persisting problem. If nothing can be done to fix the bug, then at least the
problem and a workaround can be found in this report.
OBSERVED RESULT
Event editor didn't open.
EXPECTED RESULT
Event editor to open.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 18.04
KDE Plasma Version: 5.12.8
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5
ADDITIONAL INFORMATION
Reported this is a KOrganizer / incidence editor bug, since that's where I
experienced the problem as an end-user. I don't know whether the fact that
restarting Akonadi helped means that the problem is more likely to be there, or
in some other general infrastructure. Please edit if you know better.
--
You are receiving this mail because:
You are watching all bug changes.
[korganizer] [Bug 374761] Event/To-do/Journal editor fails to populate calendar combo box
https://bugs.kde.org/show_bug.cgi?id=374761 Rickard Westman changed: What|Removed |Added CC||rwest...@bredband.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 410594] Reverse switching uses "recently used" when "stacking order" is chosen
https://bugs.kde.org/show_bug.cgi?id=410594 --- Comment #2 from Rickard Westman --- Just noticed that this bug was originally filed for a newer version of KDE than the one I'm running, so I'm not sure whether my added comment #1 really applies. I'm running these versions: Linux/KDE Plasma: Kubuntu 18.04 KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 410594] Reverse switching uses "recently used" when "stacking order" is chosen
https://bugs.kde.org/show_bug.cgi?id=410594 Rickard Westman changed: What|Removed |Added CC||rwest...@bredband.net --- Comment #1 from Rickard Westman --- Bug also applies to the actions "Walk Through Windows of Current Application (Reverse)", "Walk Through Windows of Current Application Alternative (Reverse)", and "Walk Through Windows Alternative (Reverse)". Also note that the options "recently used" and "stacking order" are not simply swapped around - when "stacking order" is used (erroneously due to this bug) it's not reversed with respect to the normal/forward cycling order, but the same. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 411231] Shortcut action "Walk through Windows of Current Application" just switches between two of them
https://bugs.kde.org/show_bug.cgi?id=411231 --- Comment #2 from Rickard Westman --- I had the two actions bound to function keys without a modifier, and then it worked in the weird asymmetric way I described. It doesn't matter if it's a brief key press or a long one - a long one for the forward cycle will just flicker quickly between two of the windows. With the Alt modifier added to the forward binding, it works as you describe. But when the Alt modifier is added to the backward binding, there is now another weird asymmetry: I can walk through the windows in the forward direction with the Alt key down, but for the backward direction I have to lift the Alt key between every step, otherwise it's just stuck on one window. So it only works sensibly when the forward key binding has an Alt modifier, and the reverse binding doesn't. Whether you use Alt modifiers for both, or for none, the user experience is bad. I think it would be much better if the actions simply did the thing their name says, with the reverse action doing exactly the same thing as the forward action but in reverse. An action to toggle between the last two windows might be nice, but there is nothing in the action name suggesting this function. And the name absolutely doesn't say that this is the *only* thing the action can do unless you bind it with an Alt modifier. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 411231] New: Shortcut action "Walk through Windows of Current Application" just switches between two of them
https://bugs.kde.org/show_bug.cgi?id=411231 Bug ID: 411231 Summary: Shortcut action "Walk through Windows of Current Application" just switches between two of them Product: kwin Version: 5.12.8 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: rwest...@bredband.net Target Milestone: --- SUMMARY After binding shortcut keys to "Walk through Windows of Current Application" and "Walk through Windows of Current Application (reverse)", only the latter works as expected (i.e. it walks through all the windows of the current application). The normal/forward version of the shortcut instead toggles between two of the windows, never reaching the others. STEPS TO REPRODUCE 1. Ensure there are 4 Konsole windows (opened individually from the launcher) on the current desktop. 2. Bind keys in "Global Keyboard Shortcuts / System Settings" for the actions "Walk through Windows of Current Application" and "Walk through Windows of Current Application (reverse)". 3. Use the key for "Walk through Windows of Current Application (reverse)" repeatedly and notice how it cycles through all four windows as expected. 4. Use the key for "Walk through Windows of Current Application" repeatedly and notice how it only moves between two of the four windows. OBSERVED RESULT "Walk through Windows of Current Application" toggles between two windows whereas "Walk through Windows of Current Application (reverse)" walks through all four windows. EXPECTED RESULT I expected "Walk through Windows of Current Application" and "Walk through Windows of Current Application (reverse)" to walk through all four windows, but in the reverse order of each other. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.04 KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 410795] "Focus prevention: High" prevents windows from being raised, despite independent raise & focus preference
https://bugs.kde.org/show_bug.cgi?id=410795 --- Comment #2 from Rickard Westman --- Perhaps the function should just be renamed "focus stealing and raise prevention"? Or at least, mention that they are connected in the help? When the settings otherwise allow focus and raise operations to be independent, it's very confusing that they are forcibly connected here without any mention of that being the case. This is no problem for me personally, now, since I can live with changing the focus & raise prevention level to medium. Then I can successfully launch applications from one part of KDE without another part of KDE working against me. But I would never had found that solution myself, i.e. changing a focus-related setting to solve a problem that has nothing to do with focus behavior. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 410795] New: "Focus prevention: High" prevents windows from being raised, despite independent raise & focus preference
https://bugs.kde.org/show_bug.cgi?id=410795
Bug ID: 410795
Summary: "Focus prevention: High" prevents windows from being
raised, despite independent raise & focus preference
Product: kwin
Version: 5.12.8
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: rwest...@bredband.net
Target Milestone: ---
SUMMARY
For some time, I've been annoyed by new application instances opening their
windows *underneath* my existing windows instead of on top of them, with a new
yellow-tinted icon appearing in the icons-only task manager instead of merging
with the one I clicked. I was at a loss understanding where this annoying
behavior came from, until I found a forum post where someone explained that it
could be caused by focus prevention policy. I had indeed changed that, but had
no idea that focus prevention would affect depth order. It is hardly
self-explanatory, is not stated in the help text, and isn't something I want
given my preference to have focus and depth order independent of each other
("click to focus" and "click raises active window" both turned off).
STEPS TO REPRODUCE
1. Under "Windows Management / Window Behavior / Focus", set "Focus stealing
prevention" to "High", uncheck "Click raises active window", set "Focus Policy"
to "Focus Follows Mouse - Mouse Precedence".
2. Ensure you have the current workspace covered with windows (to make it clear
whether a newly opened window is opened above or below other windows), and an
application focused that is not Konsole.
3. Go to the icons-only task manager and middle click on the Konsole icon to
open a new instance of Konsole.
OBSERVED RESULT
The new Konsole window opens below the existing windows, and a new
yellow-tinted icon appears indicating that focus prevention took place for this
window.
EXPECTED RESULT
The new Konsole window should open on top of the other windows, regardless of
focus prevention.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 18.04
KDE Plasma Version: 5.12.8
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5
--
You are receiving this mail because:
You are watching all bug changes.
[korganizer] [Bug 407965] Applying two changes in a row in the event editor fails with "Only resources can modify remote identifiers"
https://bugs.kde.org/show_bug.cgi?id=407965 --- Comment #1 from Rickard Westman --- > You then have to cancel out of the dialog to exit it. That came out wrong - I meant that you have to cancel out of the editor since pressing "OK" (re-)triggers the problem. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 407965] New: Applying two changes in a row in the event editor fails with "Only resources can modify remote identifiers"
https://bugs.kde.org/show_bug.cgi?id=407965 Bug ID: 407965 Summary: Applying two changes in a row in the event editor fails with "Only resources can modify remote identifiers" Product: korganizer Version: 5.7.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: incidence editors Assignee: kdepim-b...@kde.org Reporter: rwest...@bredband.net Target Milestone: --- SUMMARY The event editor UI allows you to apply a change immediately by pressing "Apply". But if you make more than one change without closing the editor in-between, the second one fails with an error dialog. You then have to cancel out of the dialog to exit it. This happens whether you try to apply the second change using the "Apply" button or the "OK" button. STEPS TO REPRODUCE 1. Press "New Event..." button and edit the Title field to say "Test" 2. Press "Apply" 3. Edit the Title field to say "Foo". 4. Press "Apply". OBSERVED RESULT An error dialog appears after the last step. The title is "Sorry - KOrganizer" and the message text is: "Error while trying to modify calendar item. Error was: Only resources can modify remote identifiers" When you click OK, you get a warning dialog saying "Unable to store the incidence in the calendar. Try again?". If you try again, the first error dialog will show again. It is possible to work around the bug by exiting the event editor, selecting the event created in step 2 for modification, and then redoing steps 3 to 4. EXPECTED RESULT I expected to be able to make many edits to an event, pressing "Apply" after each one, without getting the errors dialogs described. SOFTWARE/OS VERSIONS Linux distribution: Kubuntu 18.04 KDE Plasma Version: 5.12.7 KDE Frameworks Version: 5.44.0 Qt Version: 5.95 Kernel Version: 4.18.0-20-generic ADDITIONAL INFORMATION Maybe related to bug #307383, marked as fixed in 2012? -- You are receiving this mail because: You are watching all bug changes.
