[frameworks-syntax-highlighting] [Bug 467271] New: stacked here-docs confuse the highlighter
https://bugs.kde.org/show_bug.cgi?id=467271 Bug ID: 467271 Summary: stacked here-docs confuse the highlighter Classification: Frameworks and Libraries Product: frameworks-syntax-highlighting Version: 5.103.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: syntax Assignee: kwrite-bugs-n...@kde.org Reporter: o...@kde.org CC: walter.von.entfer...@posteo.net Target Milestone: --- as documented in https://perldoc.perl.org/perlop#EOF, it is possible to have multiple adjacent here-documents: print <<"foo", <<"bar"; # you can stack them I said foo. foo I said bar. bar this isn't highlighted properly - the second here-doc isn't treated as such, which of course leads to all kinds of "interesting" followup effects when it contains quotes, etc. for an example with some extra complexity, see https://github.com/git/git/blob/v2.39.2/git-send-email.perl#L843 (yes, github is bungling it, too :-D). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456420] scale up notification popups in fullscreen
https://bugs.kde.org/show_bug.cgi?id=456420 Oswald Buddenhagen changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #8 from Oswald Buddenhagen --- no. while the issues are related, this is definitely NOT a duplicate. this isn't about noticeability, but about legibility under certain circumstances, which requires context-sensitive behavior. i see the issues as orthogonal (if you made the font size configurable, i'd *still* want a setting to double/triple its size while full-screen). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456420] scale up notification popups in fullscreen
https://bugs.kde.org/show_bug.cgi?id=456420 --- Comment #10 from Oswald Buddenhagen --- if supporting switching the font size in such a simple widget would impose an unbearable maintenance burden, then you should seriously rethink your technology choices. i wonder how bit-rotting would work for a feature that would be used on my systems almost daily? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 486488] New: poor handling of invalid --log-fd
https://bugs.kde.org/show_bug.cgi?id=486488 Bug ID: 486488 Summary: poor handling of invalid --log-fd Classification: Developer tools Product: valgrind Version: 3.24 GIT Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: o...@kde.org Target Milestone: --- > $ valgrind --log-fd=13 /bin/echo > ==3786620== Valgrind: failed to move log file descriptor into safe range, > using stderr > ==3786620== Memcheck, a memory error detector > [...] > ==3786620== Warning: invalid file descriptor 2 in syscall close() > ==3786620==Use --log-fd= to select an alternative log fd. > [...] firstly, the error message is very unhelpful, as the root cause is that the source descriptor is invalid. secondly, the message should be separated with an empty line from the blurb below, as otherwise it's way too easy to overlook. lastly, these warning messages (there can be lots of them; the particular syscalls vary depending on the traced program) make no sense; apparently something doesn't get reset properly. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 194144] Make log-fd really log to that fd (not dup on startup)
https://bugs.kde.org/show_bug.cgi?id=194144 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #1 from Oswald Buddenhagen --- this seems like an anti-feature to me, breaking the isolation between valgrind and the tracee. the proper solution would be a log daemon to which both can talk. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 486512] New: --log-fd does not mix well with --trace-children=yes
https://bugs.kde.org/show_bug.cgi?id=486512 Bug ID: 486512 Summary: --log-fd does not mix well with --trace-children=yes Classification: Developer tools Product: valgrind Version: 3.24 GIT Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: o...@kde.org Target Milestone: --- i have a daemon that re-opens stderr to its own log file. it also fork-execs child processes. notably, it closes all file descriptors except stdio after forking. this doesn't seem to play well with valgrind: valgrind's output for the child goes to the daemon's log, while the child's stderr apparently goes to nirvana. clearly, valgrind fails to rewrite the command line for recursive invocation to use the cloned/protected fd. the follow-up effects are likely bug 486488. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456420] New: scale up notification popups in fullscreen
https://bugs.kde.org/show_bug.cgi?id=456420 Bug ID: 456420 Summary: scale up notification popups in fullscreen Product: plasmashell Version: 5.24.5 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Notifications Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: k...@privat.broulik.de Target Milestone: 1.0 when a fullscreen application (like a video player) is in the foreground, there is a good chance that the user is located significantly further away from the screen than usually. therefore, for notification popups to be still useful, they need to be scaled up. UI-wise, i would realize this by adding a configurable integer scaling factor (default maybe 2 or 3) to the notification settings. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456421] New: delay timeout of notification popups when user appears to be absent
https://bugs.kde.org/show_bug.cgi?id=456421 Bug ID: 456421 Summary: delay timeout of notification popups when user appears to be absent Product: plasmashell Version: 5.24.5 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Notifications Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: k...@privat.broulik.de Target Milestone: 1.0 (passive) notification popups that time out are quite useful, but only as long as the user is actually paying attention to the device. therefore, i think it would make sense to postpone starting the timer while the user is apparently AFK. i suppose the right way to detect AFK would be KIdleTime reporting >15 secs inactivity, no simulated user activity, and no screensaver inhibitors being registered (i'll note that the fdo screensaver d-bus spec currently offers no way to query that). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456422] New: introduce clean solution for notification popups without summary
https://bugs.kde.org/show_bug.cgi?id=456422 Bug ID: 456422 Summary: introduce clean solution for notification popups without summary Product: plasmashell Version: 5.24.5 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Notifications Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: k...@privat.broulik.de Target Milestone: 1.0 i'm displaying notifications about new mails. i want to keep the visual clutter down, so the application name is abused to say "new mail in ", the summary says "from: " and the body says "*subject:* ". the problem with that is that the summary is completely in bold, which makes it use too much space, and looks just ugly. making the app name empty would be somewhat pointless, as a) that would not really save much screen real estate, as the notification's age and close button are displayed in the same line and b) the summary would then say "new mail ..." in bold, which is again needless clutter (the notifications are visually distinct due to their body). so a better solution would be permitting omitting the summary. pedantically, plasma actually allows empty summaries, and the spec does not explicitly forbid it, but it goes against the spirit of the spec, which aims to be presentation-agnostic. and the notify-send tool (from libnotify-bin) does enforce a non-empty summary. so i think a solution which would be clean enough to upstream into the spec would be introducing a new boolean notification hint, say redundant-summary, which being true would mean that the summary should be omitted if the body is also displayed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456420] scale up notification popups in fullscreen
https://bugs.kde.org/show_bug.cgi?id=456420 Oswald Buddenhagen changed: What|Removed |Added Resolution|INTENTIONAL |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #2 from Oswald Buddenhagen --- to make it more accurate, one can track user activity - excluding apps which have no idle time (compare #456421) pretty much eliminates everything that qualifies as a "productivity app". though one would have to exclude simulated user activity (screensaver suppression), which may be a bit tricky. one can also make the detection app-specific, for which the notification config already has provisions. though the existing infra won't help distinguishing between apps running in a browser - for that, window title matching would have to be done. wholesale scaling isn't an option for me, as my regular desktop (with a large-ish screen) is also my home cinema. this conveniently also makes the fullscreen app distinction a complete non-issue for me, as presentation apps are the *only* ones that ever run fullscreen. the size of the popups doesn't matter much for the annoyance level. if one doesn't want them, that's presumably what the app-specific dnd setting is for (though i have no clue how that state is determined). if you think that this would be too unreliable even with these qualifications, then leave the default scale factor at one (though that would make the feature a lot less discoverable). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456422] introduce clean solution for notification popups without summary
https://bugs.kde.org/show_bug.cgi?id=456422
Oswald Buddenhagen changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|DOWNSTREAM |---
Status|RESOLVED|REOPENED
--- Comment #2 from Oswald Buddenhagen ---
don't try to be so clever. the only abuse is in the exact use of the
parameters, because their intended usage isn't optimized for my use case.
swapping subject and body would make the issue even worse, as the subject is
usually longer than the from address, which would mean even more bold text.
i'm now using
gdbus call --session --dest org.freedesktop.Notifications --object-path
/org/freedesktop/Notifications --method org.freedesktop.Notifications.Notify
"New mail in INBOX" 0 "mail-unread-new" "" 'From:
fooish@baz.comSubject: earn millions in one day!!!11!' [] {}
15000
which produces a really neat result.
it's just too bad that this relies on undocumented, out-of-spec, kde-specific
behavior.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #33 from Oswald Buddenhagen --- i don't think the cursor problem is related. as you note yourself, the cursor is a separate entity, and the fact that it's not in the captured framebuffer is further evidence of this. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kidletime] [Bug 392679] playing a video with mpv counts as activity to RSIbreak
https://bugs.kde.org/show_bug.cgi?id=392679 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #4 from Oswald Buddenhagen --- according to the investigation in the mpv bug, the issue is that its screensaver/suspend prevention "punches through" to the idle time detection. there isn't really much to be done about that as long as it uses legacy apis - nowadays, it should be using the dbus inhibitor api. but according to my test it still doesn't. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 313571] org.freedesktop.ScreenSaver.GetSessionIdleTime returns milliseconds instead of seconds
https://bugs.kde.org/show_bug.cgi?id=313571 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[rsibreak] [Bug 413964] Make rsibreak's mouse movement detection less sensitive.
https://bugs.kde.org/show_bug.cgi?id=413964 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #2 from Oswald Buddenhagen --- that issue is more or less unsolvable at the rsibreak level: it uses the kidletime library, which uses whatever the windowing system reports to it. so basically, you need to file feature requests against xorg/xserver and potentially numerous wayland compositors. rsibreak can't track the events itself, as security measures against key-logging (are supposed to) prevent that. though it might be possible to configure a special authorization - i didn't check what options the display servers offer nowadays. that would also have the side effect of potentially fixing #392679. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456420] scale up notification popups in fullscreen
https://bugs.kde.org/show_bug.cgi?id=456420 Oswald Buddenhagen changed: What|Removed |Added Resolution|INTENTIONAL |--- Status|CLOSED |REOPENED --- Comment #4 from Oswald Buddenhagen --- switching the shell on the fly is not practical, as that may happen several times during a single "tv session". sometimes i un-fullscreen, sometimes switch the virtual desktop. this is supposed to be *fast* and non-disruptive. i don't see why plasma would need to distinguish desktops from laptops. it's supposed to be an *option*. laptop users just won't use it. please stop closing this as long as your only argument is "it can't be made perfect". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456420] scale up notification popups in fullscreen
https://bugs.kde.org/show_bug.cgi?id=456420 --- Comment #6 from Oswald Buddenhagen --- my primary use case is explained in bug 456422. these notifications do get through. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456422] introduce clean solution for notification popups without summary
https://bugs.kde.org/show_bug.cgi?id=456422 --- Comment #5 from Oswald Buddenhagen --- @nate: it's a weee bit over the top to call this malicious. if somebody had thought that this is a security or otherwise issue, the spec wouldn't make it so easy to "fake" it. and "New mail in ..." certainly is a good enough identification of the "app". also, this is a local script of mine, so literally no-one cares. @kai: that's also a hack, and not much better than what i already do (though it has the advantage of working with notify-send). deferring to XDG is just a way to say FU. this is a process that has to be actively driven by an actual downstream implementer. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #30 from Oswald Buddenhagen --- this suggests that this might have something to do with partial repaints. maybe it's picking the wrong buffer for updating. this is consistent with my observation that for me this usually affects only the panel when the clock is ticking away. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 432557] MTP limited to one application with no unmount
https://bugs.kde.org/show_bug.cgi?id=432557 Oswald Buddenhagen changed: What|Removed |Added Alias|barkingbandicoot| CC||o...@kde.org --- Comment #1 from Oswald Buddenhagen --- this appears to be more or less a duplicate of #412257. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 413204] [Possibly kio component][mtp] Dolphin doesn't re-read the state of the same mtp device, after reconnecting the device.
https://bugs.kde.org/show_bug.cgi?id=413204 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #2 from Oswald Buddenhagen --- possibly duplicated by Bug 440794 (which has a possibly useful log). -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 440794] Dolphin needs to be re-opened in order to access MTP device, after state changed between "No file transmission" and "File transmission"
https://bugs.kde.org/show_bug.cgi?id=440794 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #1 from Oswald Buddenhagen --- that might be related to Bug 412257 and/or Bug 442170 (the linked mageia bug has some potentially useful info). -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 412257] kiod5 doesn't release usb device when it is not in use
https://bugs.kde.org/show_bug.cgi?id=412257 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 442170] MTP mounting SOME Android phones doesn't work (only PTP mode)
https://bugs.kde.org/show_bug.cgi?id=442170 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 409994] better (link) support for TUI applications
https://bugs.kde.org/show_bug.cgi?id=409994 --- Comment #1 from Oswald Buddenhagen --- btw, #379294 provides a better solution than smart heuristics, but i think we will wait a really long time until all TUI programs will support it - not sure if even one of the toolkits supports this by now, given that this doesn't fit the "the screen is a matrix of cells" concept too well. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 409994] better (link) support for TUI applications
https://bugs.kde.org/show_bug.cgi?id=409994 --- Comment #2 from Oswald Buddenhagen --- (also, some cases simply can't be expected to be covered by the OSC8 support - an url that appears in a text file that is being edited most likely won't be recognized and marked as such by the editor.) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 421926] Konsole new tabs do not respect --profile argument
https://bugs.kde.org/show_bug.cgi?id=421926 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Oswald Buddenhagen --- when you open a new tab via the menu, you get to select the profile interactively, so that's obviously not the issue here. the issue manifests when the "new tab" action is activated via a key binding, as it does indeed always use the default profile. one way to deal with that would be indeed respecting the --profile option as you suggest. another way would be using the profile of the current tab. there is a precedent for this in form of the profile option to use the current tab's working directory. a third option would be a combination of the two: use --profile if specified, otherwise fall back to current profile. though this would make the behavior somewhat inconsistent, so it might be a tad confusing. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 185140] Konsole should send EOF before closing tabs
https://bugs.kde.org/show_bug.cgi?id=185140 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #12 from Oswald Buddenhagen --- for posterity: this change was fundamentally misguided (as per matthew's first comment). as always when deviating from decades of established protocol, this broke several things, like the already mentioned tmux (which was worked around later) and bug #401898. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 401898] Closing a tab is slow with something written on the prompt
https://bugs.kde.org/show_bug.cgi?id=401898 --- Comment #8 from Oswald Buddenhagen --- that sendEOF stuff is all nonsense; it's already explained in bug #185140 why it's technically unnecessary. bash isn't the only process that will behave weirdly on EOF when a line has been started - just try an interactive 'cat'. also, this can't possibly work reliably, as only the foreground process will get the EOF. SIGHUP was introduced for a reason, after all. so as far as i'm concerned, that EOF stuff should be just reverted (including the workarounds that followed it). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 421926] Konsole new tabs do not respect --profile argument
https://bugs.kde.org/show_bug.cgi?id=421926 --- Comment #5 from Oswald Buddenhagen --- i don't see why changing the behavior should be a notable problem in this case. anyway, how about separate actions? new-tab-default (aliased to the current new-tab), new-tab-current, new-tab-selected, and new-tab-smart (yay, who doesn't like an explosion of options). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 421926] Konsole new tabs do not respect --profile argument
https://bugs.kde.org/show_bug.cgi?id=421926 --- Comment #7 from Oswald Buddenhagen --- the wording was fairly indicative of sarcasm. ;) anyway, having multiple additional actions wouldn't be that bad in this case, as they would appear only in the shortcut config dialog (they aren't relevant for the menu, as i already pointed out). it would be also ok to have only one additional action, and possibly make its exact behavior configurable in the profile (though such a micro-option would add mostly useless clutter). i for one don't really care which of the proposed behaviors the new action would have, as my usage pattern is basically one profile per window, so they'd all do the same thing. but if i had to choose, i'd use my 2nd option, as it's most consistent with existing functionality (cf. $PWD). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 421926] Konsole new tabs do not respect --profile argument
https://bugs.kde.org/show_bug.cgi?id=421926
--- Comment #9 from Oswald Buddenhagen ---
--all-tab-profile=... maybe, to make it less verbose.
note that this is lacking the "copy current" mode. one could add
--new-tab-profile={default,current,smart} instead, but that just shifts the
additional choices to the command line, so it's not much of an improvement.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 443723] "Display geometry when moving or resizing" feature is missing
https://bugs.kde.org/show_bug.cgi?id=443723 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 399291] Don't include trailing colons when selecting words via double-click
https://bugs.kde.org/show_bug.cgi?id=399291 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org Summary|Don't include trailing |Don't include trailing |colons in URLs for the |colons when selecting words |purpose of double-click |via double-click |selection | -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 399291] Don't include trailing colons when selecting words via double-click
https://bugs.kde.org/show_bug.cgi?id=399291 --- Comment #6 from Oswald Buddenhagen --- hard-coding the exception is a rather questionable solution. a fully generic solution would be a configurable regular expression. however, that might be considered too complex for regular users, and not necessarily very useful to start with. a less complex solution would be having an additional character class: mid-word characters. these would be considered part of the word only if surrounded by regular word characters. apart from the colon, the period would be included here as well. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 472274] New: omit trailing punctuation when highlighting/invoking urls
https://bugs.kde.org/show_bug.cgi?id=472274 Bug ID: 472274 Summary: omit trailing punctuation when highlighting/invoking urls Classification: Applications Product: konsole Version: 22.12.3 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: o...@kde.org Target Milestone: --- in flowed text (e.g., emails) it's rather common for urls to be followed by a comma or full stop, sometimes a colon or semicolon. it's unhelpful when this punctuation is considered part of the url, as it typically invalidates it. therefore i think it would make sense to strip trailing characters with a clear punctuation function. (notably, colons are already treated specially.) somewhat related to bug 399291. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kinit] [Bug 402540] Login VERY slow due to cleanup_fds
https://bugs.kde.org/show_bug.cgi?id=402540 Oswald Buddenhagen changed: What|Removed |Added Version Fixed In||5.54.0 Latest Commit||26620aef0bd6d01b543e7523dd1 ||5dddc1bb871df Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED --- Comment #6 from Oswald Buddenhagen --- i think it's fair to claim that this is fixed. whether that code should be improved further can be debated in another issue, but i don't think there would be much point to it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #15 from Oswald Buddenhagen --- i think i have the same issue, with intel sandy bridge desktop graphics on x11. i consistently observe it for the panel (clock and task bar are obviously affected). i haven't observed this for app windows so far, though now that i read it here: occasionally one of my chromium windows also goes haywire in a way that could be plausibly related; closing and re-opening the window from history fixes the issue. like eduardo, i think that the buffers simply get mixed up - it alternates between two old states rather than showing the new contents. activity in app windows (e.g., a blinking cursor) causes "more correct" buffers to be used, though there continue to be glitches. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #17 from Oswald Buddenhagen --- as for my issue, that seems unlikely - that appears to be a recent regression, while i've been seeing this issue for ... well, i guess one should count it in years. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 412257] kiod5 doesn't release usb device when it is not in use
https://bugs.kde.org/show_bug.cgi?id=412257 --- Comment #13 from Oswald Buddenhagen --- it should be obvious that kde locking out other frameworks from accessing mtp devices by its mere presence is not acceptable, and deferring to a pipe dream solution just doesn't cut it. so kde needs to a) claim the device lazily (e.g., the file dialog doesn't really need it to merely show the device's presence) and b) release it eagerly. (i didn't check the current state of master, so i can't judge what actually still needs being done.) -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 412257] kiod5 doesn't release usb device when it is not in use
https://bugs.kde.org/show_bug.cgi?id=412257 --- Comment #15 from Oswald Buddenhagen --- what is (not), and why? -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 412257] kiod5 doesn't release usb device when it is not in use
https://bugs.kde.org/show_bug.cgi?id=412257 Oswald Buddenhagen changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #19 from Oswald Buddenhagen --- afaict, the question was about expectations, which imo has been adequately answered. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 Oswald Buddenhagen changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED Latest Commit||https://invent.kde.org/util ||ities/konsole/commit/2a6e52 ||0a7a92fe796add82f77cda922c5 ||4e091b9 --- Comment #9 from Oswald Buddenhagen --- Git commit 2a6e520a7a92fe796add82f77cda922c54e091b9 by Oswald Buddenhagen. Committed on 12/12/2020 at 14:09. Pushed by ossi into branch 'master'. ensure that window size is correct before starting session (again) commit b84c0f49 replaced the previous hack, clearly failing to notice that in-thread qobject conections are direct by default. we need to make the competing connection queued instead. this remains a hack; a proper solution would be avoiding the instant resize by skipping the initialization to 80x25, but i'm not going to touch any of that mess. M +5-3src/session/Session.cpp https://invent.kde.org/utilities/konsole/commit/2a6e520a7a92fe796add82f77cda922c54e091b9 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 421926] Konsole new tabs do not respect --profile argument
https://bugs.kde.org/show_bug.cgi?id=421926 --- Comment #10 from Oswald Buddenhagen --- so, there already is an action which is (mostly?) equivalent with the proposed new-tab-current: clone-tab. and as indicated on gitlab, the maintainers seem to be fine with changing the meaning of new-tab to heed the command line override. so we end up with two actions with rather obvious semantics. seems like a sensible outcome to me. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] [X11] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #40 from Oswald Buddenhagen --- i guess bug 429211 is a more appropriate reference. fwiw, i identified another situation which might or might not be related: when i restore a chromium session with tens of windows (and hundreds of tabs), (some of) the chromium windows flicker like crazy between "screenshots" of the windows' rectangles until the session restoration is complete. however, in this case disabling the compositor actually kinda helps - the windows then simply stay blank. *** This bug has been marked as a duplicate of bug 429211 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429211] [X11] Digital clock/whole panel sometimes stops updating until there is user interaction with Plasma
https://bugs.kde.org/show_bug.cgi?id=429211 Oswald Buddenhagen changed: What|Removed |Added CC||ed...@inbox.lv --- Comment #47 from Oswald Buddenhagen --- *** Bug 431446 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 492672] New: switching virtual desktop does not unmap windows
https://bugs.kde.org/show_bug.cgi?id=492672 Bug ID: 492672 Summary: switching virtual desktop does not unmap windows Classification: Plasma Product: kwin Version: 5.27.11 Platform: Debian unstable OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: o...@kde.org Target Milestone: --- on X11, if, and only if compositing is enabled, switching to a different virtual desktop does not unmap the windows from the previous desktop. i suppose this is simply a result of it being (supposedly) unnecessary, as the compositor takes care of hiding the out of view windows. it also has the nice side effect that switching is rather instant. however, it has the rather unfortunate side effect that applications don't know that they can stop repainting their windows entirely, so it causes a rather significant resource consumption problem. my go-to example for this is viewing https://www.wetteronline.de/wetter/berlin in chrome, which eats lots of cpu and gpu. this is sort of the same as closed bug #431242. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 198199] TOFU filter fails (sometimes?)
https://bugs.kde.org/show_bug.cgi?id=198199 --- Comment #10 from Oswald Buddenhagen --- probably ;) (In reply to Justin Zobel from comment #9) > Thank you for the bug report. > > As this report hasn't seen any changes in 5 years or more, we ask if you can > please confirm that the issue still persists. > > If this bug is no longer persisting or relevant please change the status to > resolved. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412479] New: "trim leading spaces" eats empty lines
https://bugs.kde.org/show_bug.cgi?id=412479 Bug ID: 412479 Summary: "trim leading spaces" eats empty lines Product: konsole Version: 19.08.1 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: copy-paste Assignee: konsole-de...@kde.org Reporter: o...@kde.org Target Milestone: --- enabling "trim leading spaces" in the profile leads to empty lines between paragraphs being discarded from the selection, which is certainly not expected for an option with this name. i also found it somewhat unhelpful that it eats leading spaces on each line rather than just the first one, but that's at least technically correct, as it's consistent with what "trim trailing spaces" does. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] New: messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 Bug ID: 412598 Summary: messed up character placement Product: konsole Version: 19.08.1 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: o...@kde.org Target Milestone: --- after a somewhat recent system upgrade (several weeks at least), the mutt mailer (an ncurses application) run in konsole occasionally produces garbled output. it *appears* that spurious linefeeds are inserted at somewhat random but stable positions (telling mutt to redraw the screen doesn't change a thing). i haven't been able to identify a pattern, other than the fact that today's system upgrade (which updated a bunch of libraries) made the problem much harder to reproduce. valgrind shows a few problems deep in qt (still 5.11.3; debian is being sluggish), but the screen corruption didn't appear in that run. the problem is not reproducible with xterm, rxvt, or gnome-terminal, so it must be either konsole itself, or how ncurses/terminfo uses it specifically. i realize that this isn't the most helpful report ever, but maybe it still rings a bell ... -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 --- Comment #2 from Oswald Buddenhagen --- Created attachment 123010 --> https://bugs.kde.org/attachment.cgi?id=123010&action=edit screenshot: mutt index there. i think it's obvious how it should look instead. ;) this is now actually 100% reproducible when starting konsole+mutt. but pressing ctrl-l (redraw) causes mutt to reconsider the index positions entirely, and the corruption disappears. valgrind still doesn't show anything beyond the problems deep in qt. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 --- Comment #3 from Oswald Buddenhagen --- Created attachment 123011 --> https://bugs.kde.org/attachment.cgi?id=123011&action=edit screenshot: mutt mail botched it gets crazier when i open your mail ... -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 --- Comment #4 from Oswald Buddenhagen --- Created attachment 123012 --> https://bugs.kde.org/attachment.cgi?id=123012&action=edit screenshot: mutt mail ok ... and in this case returns to normal when pressing ctrl-l. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 --- Comment #5 from Oswald Buddenhagen --- i also had the case in this mail display where the whole screen appeared to be scrolled up, so the top was missing, while the bottom was not repainted. in this case, pressing ctrl-l cleared the screen, but the vertical offset remained until changing the view. all this is (approximately) valgrind-clean. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 --- Comment #6 from Oswald Buddenhagen --- it's *weird*: running mutt (instead of konsole) in valgrind makes the issue disappear. however, running mutt (without vg) inside "xterm -tn xterm-256color" (that's what $TERM is inside konsole here) with the same geometry does _not_ make it reproducible. so ... running under vg slows the output down, so maybe a race condition? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 409994] New: better (link) support for TUI applications
https://bugs.kde.org/show_bug.cgi?id=409994 Bug ID: 409994 Summary: better (link) support for TUI applications Product: konsole Version: 18.04.0 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: o...@kde.org Target Milestone: --- applications based on ncurses, slang, or other text ui toolkits take control of newlines themselves, i.e., they hard-wrap text. this has the effect that links which span multiple lines are not recognized as such. my suggestion would be to re-join lines heuristically: if the "word" fills the whole line and the next line starts with another word character, join the two - this is relatively safe and handles properly wrapped flowed text as drawn by a mailer like mutt. while the mechanism is different, this obviously also affects selecting/copying from the terminal. there is another incarnation of the latter problem: an ssh public key copied from, say, mcview will contain newlines, which is often a nuisance. the problem here is that the text is _not_ properly flowed, but hard-wrapped, and contains multiple words to start with, so the above heuristic would not work. the distorted copying is less troublesome, as the "paste destination" typically offers the possibility to re-join the lines (or will even do it automatically), so i'm mostly mentioning it only for context, but you may still want to create a spin-off task for it. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 Oswald Buddenhagen changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #7 from Oswald Buddenhagen --- ok, this is clearly a bug in ncurses after all. i added logging code for the raw pty stream, and what mutt/ncurses is sending is just weird. cat'ing it in an xterm produces the same artifacts. it's still strange that running it in xterm in the first place does not trigger the problem, but whatever. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412598] messed up character placement
https://bugs.kde.org/show_bug.cgi?id=412598 Oswald Buddenhagen changed: What|Removed |Added Ever confirmed|0 |1 CC||kurt.hindenb...@gmail.com, ||martin.sandsm...@kde.org Resolution|NOT A BUG |--- Status|RESOLVED|REOPENED --- Comment #8 from Oswald Buddenhagen --- so, further investigation reveals that this *is* a konsole bug after all. it's a resurgence of bug #203185 introduced by commit b84c0f49a98cba53932c8bfc3c0a974983b14c1a (review trail at https://mail.kde.org/pipermail/konsole-devel/2016-April/025069.html which i'll refrain from commenting on for CoC reasons. i'll just suggest someone re-reads the documentation of qt signal delivery). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kinit] [Bug 402540] Login VERY slow due to cleanup_fds
https://bugs.kde.org/show_bug.cgi?id=402540 --- Comment #4 from Oswald Buddenhagen --- this code is only ever relevant if a not entirely well-behaved process (which doesn't use FD_CLOEXEC) launches kdeinit directly. i'm not even sure when that would happen. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 494048] New: add option to switch to alternate screen
https://bugs.kde.org/show_bug.cgi?id=494048 Bug ID: 494048 Summary: add option to switch to alternate screen Classification: Applications Product: konsole Version: 23.08.1 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: o...@kde.org Target Milestone: --- konsole supports the "alternate screen" function, which some full-screen applications use to display their TUI (i think ncurses does that by default). some of these applications temporarily switch back to the primary screen when launching helper processes (which is probably also done automatically by ncurses). to be able to inspect this output, it would be useful to have the option to manually switch the konsole display between the two screens. xterm has this function: ctrl + middle-click => "show alternate screen". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498035] "always visible" vs. "windows go below" panel visibility modes
https://bugs.kde.org/show_bug.cgi?id=498035 Oswald Buddenhagen changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|NOT A BUG |--- --- Comment #2 from Oswald Buddenhagen --- > Also panel de-floats when a window is touching the panel. uh, yeah, it does (which i didn't notice, because i disabled the floating as the first thing). what is the justification for such plainly weird behavior? > And of course you can drag your window over that panel. You don't lose any > window content in this case. no, i can't. that would be "windows can cover" mode, which was intentionally removed with a rather poor justification. in fact, it behaves like "windows go below", which is the central point of this report. maybe you should rename the mode, for example "make windows dodge" to contrast it with "dodge windows". i think i've seen it named "exclude windows" somewhere, but that's an equally bad name, as it can be understood only once one already knows what it does. but even then it's still not clear why dragged windows don't actually respect the border and just slide under the panel. i thought that this might be the effect of a kwin setting, but that doesn't appear to be the case. so at the very least the combos should have tooltips which explain the full set of behaviors and what external influences exist. and why does "windows go below" also apply to maximization? there is no sensible use case for such behavior (as opposed to manually sliding part of the window below the panel). either the panel or the window should dodge (probably the latter). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498057] spare layouts broken on x11
https://bugs.kde.org/show_bug.cgi?id=498057 Oswald Buddenhagen changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Oswald Buddenhagen --- turn out i actually _am_ on wayland and didn't even notice, except for the regressions. duh. *** This bug has been marked as a duplicate of bug 455431 *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 455431] "Spare Layouts" feature on Wayland
https://bugs.kde.org/show_bug.cgi?id=455431 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #24 from Oswald Buddenhagen --- *** Bug 498057 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[rsibreak] [Bug 498029] overlay window isn't actually fullscreen
https://bugs.kde.org/show_bug.cgi?id=498029 --- Comment #4 from Oswald Buddenhagen --- turns out i actually _am_ on wayland and didn't even notice, except for the regressions. duh. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows
https://bugs.kde.org/show_bug.cgi?id=498030 --- Comment #7 from Oswald Buddenhagen --- why are you being pedantic over what "klipper" exactly is rather than just trying with what it seems to be (which is exactly what you described)? anyone with a kde6 desktop and some familiarity with its customization interface can repro this issue within 30 seconds. i doubt that this can be much optimized by watching a video. leave alone the time you spent on trying to convince me that it totally would. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows
https://bugs.kde.org/show_bug.cgi?id=498030 --- Comment #9 from Oswald Buddenhagen --- if you can't repro it, then say so right away. i did some more experiments now. looking at klipper, i'd say that was a false alert. the UI is just bad (at least with theme breeze) - the popup looks as if it was cut off by the panel (list item text is cut off right at the bottom, and there is no visual distinction from regular windows that are actually cut off), but when you drag away the popup with alt-leftmouse, you see that it really ends there. so this should be spun off to a separate bug. as for syncthing-tray: under x11 it actually goes _over_ the panel, while on wayland it went _under_ it. this makes the placement bug less severe under x11. and it affects only standalone popups, not stuff plasma does itself. i now also tried vlc, telegram desktop, and uget, but these apps pop up "proper" windows (which restore their previous position), so they aren't affected (at least under x11; not gonna try wayland now). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows
https://bugs.kde.org/show_bug.cgi?id=498030 Oswald Buddenhagen changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from Oswald Buddenhagen --- i gave you the example apps; please figure out yourself what they actually do. rsibreak behaves differently on x11 (the window is centered on screen). this is a regular framed window. maybe related to #498027. klipper and syncthing-tray-kde are consistent between wayland and x11. these are frameless somethings. syncthing's popup looks kinda out of place, presumably because it's built with qt5. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] New: "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows
https://bugs.kde.org/show_bug.cgi?id=498030 Bug ID: 498030 Summary: "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows Classification: Plasma Product: plasmashell Version: 6.2.4 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: niccolo.venera...@gmail.com Target Milestone: 1.0 in all visibility modes except "always visible", the panel is apparently being considered to be invisible when system tray apps from that panel pop up windows. the effect is that the popup is partially covered by the panel (until the latter is actually hidden). i can reproduce this with klipper, rsibreak, syncthing-tray-kde, just for starters. tray icons that are built-in don't appear to be affected; specifically "audio volume" appears ok (can't tell for the others, as they currently have lots of unused space at the bottom). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498032] New: re-introduce "windows can cover" visibility mode
https://bugs.kde.org/show_bug.cgi?id=498032 Bug ID: 498032 Summary: re-introduce "windows can cover" visibility mode Classification: Plasma Product: plasmashell Version: 6.2.4 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: niccolo.venera...@gmail.com Target Milestone: 1.0 the "windows can cover" panel visibility mode seems to have been eliminated in plasma 6. i find that ... very unfortunate. please bring it back. i guess the "dodge windows" mode was supposed to kind of replace it, but i don't find that mode pleasant at all - it's "jumpy", and it's counter-productive to hide the entire panel when it would be only partially occluded. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498035] New: "always visible" vs. "windows go below" panel visibility modes
https://bugs.kde.org/show_bug.cgi?id=498035 Bug ID: 498035 Summary: "always visible" vs. "windows go below" panel visibility modes Classification: Plasma Product: plasmashell Version: 6.2.4 Platform: Debian unstable OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: niccolo.venera...@gmail.com Target Milestone: 1.0 it's not clear to me what the difference between the "always visible" and "windows go below" panel visibility modes is - the descriptions seem to be kind of synonymous, and superficially they appear to do the same thing. don't tell me to rtfm; it's already an UX fail that i have to ask the question. (also, F1 doesn't work there, and i fail to find tfm quickly). based on some random hits, i guess "always visible" is meant to be "block windows" (as opposed to "dodge windows"), so kind of "pretend to be the screen edge" - but that's pointless at least with my kwin config, as windows can be freely placed such that parts are off-screen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498027] New: kwin ignores applications' initial geometry requests
https://bugs.kde.org/show_bug.cgi?id=498027 Bug ID: 498027 Summary: kwin ignores applications' initial geometry requests Classification: Plasma Product: kwin Version: 6.2.4 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: X11 Integration Assignee: kwin-bugs-n...@kde.org Reporter: o...@kde.org Target Milestone: --- kwin seems to have become extremely opinionated about window placement in plasma 6. specifically, it seems to ignore the position specified on the command line. given this command: qdbusviewer6 --qwindowgeometry 400x800+900+100 the window size is heeded, but the position is plainly ignored. interestingly enough, the following command does what it should: xmessage -geometry 120x80+900+900 foo bar so as a first guess i'd say it's only ignoring the netwm hints, but heeds the old-style x11 geometry. KDE Frameworks Version: 6.8.0 Qt Version: 6.7.2 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 498036] New: window title & icon should reflect current session
https://bugs.kde.org/show_bug.cgi?id=498036 Bug ID: 498036 Summary: window title & icon should reflect current session Classification: Applications Product: konsole Version: 24.12.0 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: o...@kde.org Target Milestone: --- the profile allows configuring the title and icon ... for the tab bar. however, this doesn't help at all when trying to select the right konsole window in the task manager/switcher. therefore, i suggest that the current session's name should be included in the window title, and the session's icon be set as the window icon. provided it's not the default session. additionally, the configured tab title constructed from placeholders should be also included, provided the application didn't override the window title via an escape sequence. some examples: ~ : bash -- Konsole ~ : bash -- Root Shell -- Konsole mc [user@host]:~ -- Midnight Commander -- Konsole mc [root@host]:~ -- Root Shell -- Konsole Mail -- Konsole yeah, it's somewhat inconsistent and/or redundant, but it should serve the intended purpose well enough. -- You are receiving this mail because: You are watching all bug changes.
[rsibreak] [Bug 498029] New: overlay window isn't actually fullscreen
https://bugs.kde.org/show_bug.cgi?id=498029 Bug ID: 498029 Summary: overlay window isn't actually fullscreen Classification: Applications Product: rsibreak Version: unspecified Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: aa...@kde.org Reporter: o...@kde.org Target Milestone: --- note: version 0.12.15 is missing from the list. after upgrading to plasma 6, the overlay effect window isn't fullscreen anymore. instead it's a maximized semi-transparent framed window (that can be closed). it seems that kwin now needs a stronger hint that the window is indeed meant to be fullscreen. note that vlc and chromium manage to fullscreen themselves, so this isn't fundamentally broken. the position of the countdown dialog is also bogus, but that's probably already covered by bug #498027. KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.2.7 -- You are receiving this mail because: You are watching all bug changes.
[rsibreak] [Bug 498029] overlay window isn't actually fullscreen
https://bugs.kde.org/show_bug.cgi?id=498029 Oswald Buddenhagen changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Oswald Buddenhagen --- x11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498057] New: spare layouts broken on x11
https://bugs.kde.org/show_bug.cgi?id=498057 Bug ID: 498057 Summary: spare layouts broken on x11 Classification: Plasma Product: plasmashell Version: 6.2.4 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Keyboard Layout widget Assignee: plasma-b...@kde.org Reporter: o...@kde.org CC: butir...@gmail.com, duha.b...@gmail.com Target Milestone: 1.0 this is a re-occurrence of bug #403281; the description applies verbatim. note that unlike bug #455431, this is about x11, not wayland. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498027] kwin ignores applications' initial geometry requests for native Wayland windows
https://bugs.kde.org/show_bug.cgi?id=498027 Oswald Buddenhagen changed: What|Removed |Added Resolution|NOT A BUG |UPSTREAM --- Comment #6 from Oswald Buddenhagen --- > bugs are where something doesn't work as designed bad designs are also bugs, and it's nonsensical to argue against that. > as it's a core part of Wayland that the window manager alone is in charge of > positioning for native Wayland windows yeah, because giving control to primitive machines has always been such a great idea. totally. please reopen the bug, and link the upstream dependency appropriately. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498027] kwin ignores applications' initial geometry requests
https://bugs.kde.org/show_bug.cgi?id=498027 Oswald Buddenhagen changed: What|Removed |Added Resolution|NOT A BUG |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #4 from Oswald Buddenhagen --- let me elaborate: - this breaks scripted interactions like via kdialog (which was my original reason to make this report) - it breaks window placement upon session restore (whether by the session manager or the apps themselves) - it produces weird effects like bug #498027 so to put it into absolutely unambiguous terms: this IS a bug, and anyone who claims otherwise needs to recheck their priorities. i don't care if the protocol designers had /reasons/ to make it that way, for example because of security. design something that doesn't suck for users. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] panel not set to "always visible" covers window popping upon on left-clicking some system tray icons
https://bugs.kde.org/show_bug.cgi?id=498030 Oswald Buddenhagen changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |DUPLICATE --- Comment #14 from Oswald Buddenhagen --- system upgrade time, so i did another test run with wayland. the problem is very much still reproducible with rsibreak and syncthingtray-kde-plasma, but as i speculated, one needs to clutter up the desktop "the right way". so this is simply a duplicate of bug #498027. *** This bug has been marked as a duplicate of bug 498027 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498027] kwin ignores applications' initial geometry requests
https://bugs.kde.org/show_bug.cgi?id=498027 --- Comment #3 from Oswald Buddenhagen --- *** Bug 498030 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 498036] window title & icon should reflect current session
https://bugs.kde.org/show_bug.cgi?id=498036 Oswald Buddenhagen changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from Oswald Buddenhagen --- > When I update a tab's title, that then becomes the first part of the window > title well, it doesn't for me; there is just nothing in front of the emdash. ... and this is caused by the "show window title on the titlebar" option. this option should not exist, especially not as a global option. i now see that the tab format string already supports the %w expando. this should mostly address the need. it would make sense to support conditionals in there, to avoid redundancy, but still have a fallback when %w has the default value or is empty. there are examples for useful syntaxes for that, e.g. https://neomutt.org/guide/reference#3-511-%C2%A0status_format. as an aside, the tab titling isn't terribly useful for the current tab, because the info is redundant with what the visible terminal certainly shows anyway, and it steals space from the other tabs, where it would be actually interesting. so ideally, the current tab's title would "move" to the window title, leaving the tab itself "mostly untitled" (what exactly to show instead is an interesting question; you could intro a conditional for that as well, so one could configure an arbitrary short(ened) title). there is still the issue that the profile name should somehow end up in the window title. one could introduce a format string for the window title, but that seems terribly over-engineered to me; hard-coding the inclusion as proposed above should be just fine. supporting a profile name expando would make even less sense, as the format string is/would be profile-bound anyway, so one can just put an appropriate identifier directly into the format string. btw, the profiles and colorschemes living in .local/share rather than .config is bogus. they are every bit part of the configuration as konsolerc is. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows
https://bugs.kde.org/show_bug.cgi?id=498030 --- Comment #11 from Oswald Buddenhagen --- were you able to repro the issue now? (you don't actually need to _use_ rsibreak or syncthing-tray; it's easy enough to get them into the tray just for testing purposes.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] panel not set to "always visible" covers window popping upon on left-clicking some system tray icons
https://bugs.kde.org/show_bug.cgi?id=498030 Oswald Buddenhagen changed: What|Removed |Added Summary|Left click menu from system |panel not set to "always |tray icon shown under panel |visible" covers window |set to "dodge windows", |popping upon on |"windows go below", and |left-clicking some system |"auto hide" |tray icons -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] panel not set to "always visible" covers window popping upon on left-clicking some system tray icons
https://bugs.kde.org/show_bug.cgi?id=498030 --- Comment #13 from Oswald Buddenhagen --- no idea why your rsibreak window placement works under wayland, but that makes the test worthless. maybe try cluttering up the desktop with other windows first, so kwin thinks the new window needs to go to the apparently "more free" area at the bottom. the package is actually called syncthingtray-kde-plasma here. did you use a sufficiently loose search? dunno about syncthing-gtk - can't get it to run here, maybe because a "real" syncthing (managed by systemd) is already running. but i'm not going to re-try wayland now anyway, as restarting sessions takes way too much time, and lightdm apparently doesn't let me start a second session for the same user. unless the problem was fixed in 6.2.5, there might be a behavior difference between the gtk and qt5 frontends - maybe one of them is using wayland directly while in a wayland session. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498035] Difference between "Always visible" and "Windows go below" visibility modes is not clear from the labels alone
https://bugs.kde.org/show_bug.cgi?id=498035 --- Comment #9 from Oswald Buddenhagen --- i don't think that some tiny animations will adequately confer the subtleties of the different modes, if only because the effects are different between manual resizing and maximization. but then, i don't even know what animations you're talking about. "all" in the commit message suggests that "some" were already present, but i didn't notice anything like that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498027] kwin ignores applications' initial geometry requests
https://bugs.kde.org/show_bug.cgi?id=498027 --- Comment #2 from Oswald Buddenhagen --- so yet another intentional regression. truly the way of the future. but i'm stunned that i actually _am_ on wayland. something went wrong with session selection in lightdm, and i didn't even notice, except for a few regressions. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 486701] Windows can cover is missing from panels
https://bugs.kde.org/show_bug.cgi?id=486701 --- Comment #5 from Oswald Buddenhagen --- as noted in the duplicate, "dodge windows" mode is NOT an adequate replacement - it's "jumpy", and it's counter-productive to hide the entire panel when it would be only partially occluded. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498035] "always visible" vs. "windows go below" panel visibility modes
https://bugs.kde.org/show_bug.cgi?id=498035 --- Comment #4 from Oswald Buddenhagen --- > Clearly there is a use case or else this option wouldn’t exist. i didn't question the option, but a particular aspect of it. and that could have been just coincidental, or "just because" - happens often enough. > I have seen people just have a small clock in the corner of the screen that > wouldn’t impact window placement. hmm, indeed, i was thinking of full-size panels only. though "always on top" would be probably a better name, also because that's the terminology used by window managers. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 498030] "dodge windows", "windows go below", and "auto hide" visibility modes vs. tray popup windows
https://bugs.kde.org/show_bug.cgi?id=498030 Oswald Buddenhagen changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Oswald Buddenhagen --- i mean that many systray apps pop up some sort of interaction window when the tray icon is (left-)clicked. notably, this does _not_ affect the context menu that pops up on right-click. -- You are receiving this mail because: You are watching all bug changes.
[rsibreak] [Bug 498029] overlay window isn't actually fullscreen
https://bugs.kde.org/show_bug.cgi?id=498029 --- Comment #3 from Oswald Buddenhagen --- somewhat probably related to that, "suppress if fullscreen windows present" also doesn't work anymore. hmm, come to think of it, the activity tracking doesn't work anymore, either. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 357443] black/invisible squares on systray and top left of screen after kwin restarted
https://bugs.kde.org/show_bug.cgi?id=357443 Oswald Buddenhagen changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED CC||o...@kde.org --- Comment #5 from Oswald Buddenhagen --- clicking the area in the systray where the proxied application is shown causes the proxy windows to be "re-absorbed". that's of course quite a challenge, as these windows are usually placed somewhat exactly at this place (they are always a few pixels off, and sometimes there is almost no overlap - probably related to the preceding kwin crash and the resulting re-layouting). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356937] Xembed icons have black background
https://bugs.kde.org/show_bug.cgi?id=356937 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #13 from Oswald Buddenhagen --- not sure if this has the same root cause, but it sure sounds related: the somewhat dynamic gnome-mail-notification tray icon dissolves into a blurry mess over time. it appears that it expects the proxy window to be pre-cleared for it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 366047] New: sni proxy scaling not always appropriate
https://bugs.kde.org/show_bug.cgi?id=366047 Bug ID: 366047 Summary: sni proxy scaling not always appropriate Product: plasmashell Version: 5.6.5 Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: XembedSNIProxy Assignee: plasma-b...@kde.org Reporter: o...@kde.org the sni proxy apparently scales the embedded window's contents, presumably to make them visually fit into the surroundings. however, if the window contains sharp edges and/or text, the scaling can be rather unhelpful. an example of such an application is gnome-mail-notification, which shows a fairly tiny icon with the number of new messages. i suggest to provide a per-app option to disable scaling which is not an integral multiple, and just centering the icon instead. i'm not quite sure how to integrate it gui-wise, though. i suppose one could react to alt-rightclick, as that's a window manager gesture which is otherwise meaningless in this context. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341934] Highlight windows option hides tooltip
https://bugs.kde.org/show_bug.cgi?id=341934 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #24 from Oswald Buddenhagen --- it appears that the popup menu for choosing among grouped windows suffers from the same problem (kwin 5.7.0, plasma 5.6.5 (debian being funny)). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 347946] Task Manager tooltip reveal/move animations flickering and showing redraw artifacts when happening alongside window highlight effect
https://bugs.kde.org/show_bug.cgi?id=347946 Oswald Buddenhagen changed: What|Removed |Added CC||o...@kde.org --- Comment #4 from Oswald Buddenhagen --- i have no problem with the tooltip, but the described behavior applies to the popup menu for choosing among grouped windows. and the guess about the blur effect seems to be spot-on. -- You are receiving this mail because: You are watching all bug changes.
